From spakes@snmp.com Fri May 1 13:52: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 E4DB73A6BFC for ; Fri, 1 May 2009 13:52:50 -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 DHuI4q084P69 for ; Fri, 1 May 2009 13:52:43 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 224763A70D8 for ; Fri, 1 May 2009 13:52:39 -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 QAA06157; Fri, 1 May 2009 16:54:01 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA26069; Fri, 1 May 2009 16:54:01 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 1 May 2009 16:54:01 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org In-Reply-To: <200904300904.21808.david.partain@ericsson.com> Message-ID: References: <200904300904.21808.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] float vs. decimal 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, 01 May 2009 20:52:51 -0000 If I read section 9.3 of draft-ietf-netmod-yang-05.txt correctly, and if I didn't punch any incorrect keys on my keyboard, and assuming the implementation of Microsoft's calc.exe works correctly on my PC, I calculate the largest positive and largest negative values that can be represented in a decimal64 as follows: largest int64 = (2^63)-1 = 9223372036854775807 smallest int64 = -(2^63) = -9223372036854775808 10^-1 = 0.1 10^-18 = 0.000000000000000001 (largest int64)*(10^-1) = 922337203685477580.7 (largest int64)*(10^-18) = 9.223372036854775807 (smallest int64)*(10^-18) = -9.223372036854775808 (smallest int64)*(10^-1) = -922337203685477580.8 Largest positive value that can be represented in a decimal64: 922337203685477580.7 Largest negative value that can be represented in a decimal64: -922337203685477580.8 I think the text in the draft is clear and concise, however, I don't believe in the average software developer's ability to arrive at the same numbers that I just did. From years ago when I worked in a support role, I can still remember having unpleasant conversations with a clients; e.g., one who argued that some code was broken, because he insisted that a Megabyte is 1,000,000 bytes, not 1,048,576 bytes. As one of Jeff Case's down-on-the-farm sayings goes, "Your mileage may vary." Therefore, before this draft goes to publication, I would like to see the following text added for clarity: The largest positive value that can be represented as a decimal64 is 922337203685477580.7. The largest negative value that can be represented as a decimal64 is -922337203685477580.8. Regards, David Spakes On Thu, 30 Apr 2009, David Partain wrote: > Re: [netmod] Working Group Last Call: draft-ietf-netmod-yang-05.txt > > 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ------------------------------------------------------------- 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 andy@netconfcentral.com Sun May 3 13:03: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 CE9BB3A6DEA for ; Sun, 3 May 2009 13:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-0.740, 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 e-OOvpyOUBSj for ; Sun, 3 May 2009 13:03:54 -0700 (PDT) Received: from n11.bullet.mail.mud.yahoo.com (n11.bullet.mail.mud.yahoo.com [209.191.125.210]) by core3.amsl.com (Postfix) with SMTP id E6E483A6D2C for ; Sun, 3 May 2009 13:03:53 -0700 (PDT) Received: from [68.142.200.221] by n11.bullet.mail.mud.yahoo.com with NNFMP; 03 May 2009 20:05:17 -0000 Received: from [68.142.201.68] by t9.bullet.mud.yahoo.com with NNFMP; 03 May 2009 20:05:17 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 03 May 2009 20:05:17 -0000 X-Yahoo-Newman-Id: 553026.71556.bm@omp420.mail.mud.yahoo.com Received: (qmail 80719 invoked from network); 3 May 2009 20:05:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 3 May 2009 20:05:16 -0000 X-YMail-OSG: nBJjkdcVM1ki_3cJRdQsRmS4lNHGHxS1Pzl1Td4QS3ry_DPqhncK.kXW2LBqPzsrfDNh2j22KwmdVbmMqw1eY3rJ169Zhk4uUsymtnGeCq6Ijip41rWHk._UzSD2E4Bt6MOw3n_Rh91f_lwP8LuHk8CbhLT8mmRQtAJamfODywpITsgKWp7L8UyDVe03iliN.V4q9HQXEzz4WAxBNWlQ7viG0JMdiAkJSZ6pF5RULkHFAZ7Ra14U4WFRZwHfJQ.A6pzD8.jsKHrqDUk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49FDF8FA.3040108@netconfcentral.com> Date: Sun, 03 May 2009 13:05:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Spakes References: <200904300904.21808.david.partain@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 03 May 2009 20:03:54 -0000 David Spakes wrote: > If I read section 9.3 of draft-ietf-netmod-yang-05.txt correctly, and > if I didn't punch any incorrect keys on my keyboard, and assuming the > implementation of Microsoft's calc.exe works correctly on my PC, I > calculate the largest positive and largest negative values that can be > represented in a decimal64 as follows: > > > largest int64 = (2^63)-1 = 9223372036854775807 > smallest int64 = -(2^63) = -9223372036854775808 > > 10^-1 = 0.1 > 10^-18 = 0.000000000000000001 > > (largest int64)*(10^-1) = 922337203685477580.7 > (largest int64)*(10^-18) = 9.223372036854775807 > (smallest int64)*(10^-18) = -9.223372036854775808 > (smallest int64)*(10^-1) = -922337203685477580.8 > > > Largest positive value that can be represented in a decimal64: > 922337203685477580.7 > > Largest negative value that can be represented in a decimal64: > -922337203685477580.8 > I think the ranges are different for each value of fraction-digits: fd min max --------------------------------------------------------- 1 -922337203685477580.8 922337203685477580.7 2 -92233720368547758.08 92233720368547758.07 3 -9223372036854775.808 9223372036854775.807 4 -922337203685477.5808 922337203685477.5807 5 -92233720368547.75808 92233720368547.75807 6 -9223372036854.775808 9223372036854.775807 7 -922337203685.4775808 922337203685.4775807 8 -92233720368.54775808 92233720368.54775807 9 -9223372036.854775808 9223372036.854775807 10 -922337203.6854775808 922337203.6854775807 11 -92233720.36854775808 92233720.36854775807 12 -9223372.036854775808 9223372.036854775807 13 -922337.2036854775808 922337.2036854775807 14 -92233.72036854775808 92233.72036854775807 15 -9223.372036854775808 9223.372036854775807 16 -922.3372036854775808 922.3372036854775807 17 -92.23372036854775808 92.23372036854775807 18 -9.223372036854775808 9.223372036854775807 > > I think the text in the draft is clear and concise, however, I don't > believe in the average software developer's ability to arrive at the > same numbers that I just did. From years ago when I worked in a support > role, I can still remember having unpleasant conversations with a clients; > e.g., one who argued that some code was broken, because he insisted that > a Megabyte is 1,000,000 bytes, not 1,048,576 bytes. As one of Jeff Case's > down-on-the-farm sayings goes, "Your mileage may vary." > > Therefore, before this draft goes to publication, I would like to see the > following text added for clarity: > > The largest positive value that can be represented as a decimal64 > is 922337203685477580.7. The largest negative value that can be > represented as a decimal64 is -922337203685477580.8. > > > Regards, > > David Spakes > > Andy From mbj@tail-f.com Sun May 3 13:14: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 BE8C63A6826 for ; Sun, 3 May 2009 13:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_40=-0.185, 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 lNE4LtwI+YjN for ; Sun, 3 May 2009 13:14: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 AA23D3A7122 for ; Sun, 3 May 2009 13:14: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 E0856616015; Sun, 3 May 2009 22:15:54 +0200 (CEST) Date: Sun, 03 May 2009 22:15:54 +0200 (CEST) Message-Id: <20090503.221554.167790073.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49FDF8FA.3040108@netconfcentral.com> References: <200904300904.21808.david.partain@ericsson.com> <49FDF8FA.3040108@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] float vs. decimal 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, 03 May 2009 20:14:47 -0000 Andy Bierman wrote: > I think the ranges are different for each value of fraction-digits: [table deleted] Exactly. It is important to note that the full type is decimal64 + a fixed value for fraction-digits. /martin From andy@netconfcentral.com Sun May 3 13:19: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 CDB7F3A6AE5 for ; Sun, 3 May 2009 13:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.320, 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 6SiztGhOGuf6 for ; Sun, 3 May 2009 13:19:00 -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 EF5E23A696C for ; Sun, 3 May 2009 13:18:48 -0700 (PDT) Received: (qmail 70288 invoked from network); 3 May 2009 20:20:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 3 May 2009 20:20:11 -0000 X-YMail-OSG: czyUmHQVM1ke6wlqgd8r9TVbNMXoJVSmxna3Hwp0UMHqop1WLifTNbOZG3pkrz8JcTY_57mHa0_CC7M4kriO7rGkp4RYZR5BXEhWA6NlCq1Yd0G90XBpObn_VQ_cLp__uPrHVfiM9L0YmNQ3mB.YNFU_.xGA6VYe.NXESG.XtxAgd4Wxpn.HjCAdadVzitu3P3LpsQVT7nUOq5LhPZqEjycCfaKvWAYi5yGEaC8t1TUQEwjplN48WL7iqTzYT3AWwZm3fQpdXdJk.Pf_Az9We9Dc.ZiB6LmHUDDcGWiRY9GpfcYlduIfKHfH9W.kVvzrCmqo0c3chay9Vdtx5wuI4BaVYHR3hPpoCWyBRfSWQRr_VJ0R X-Yahoo-Newman-Property: ymail-3 Message-ID: <49FDFC79.8080108@netconfcentral.com> Date: Sun, 03 May 2009 13:20:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <200904300904.21808.david.partain@ericsson.com> <49FDF8FA.3040108@netconfcentral.com> <20090503.221554.167790073.mbj@tail-f.com> In-Reply-To: <20090503.221554.167790073.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] float vs. decimal 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, 03 May 2009 20:19:00 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I think the ranges are different for each value of fraction-digits: > > [table deleted] > > Exactly. It is important to note that the full type is decimal64 + a > fixed value for fraction-digits. > Do you think the table should go in the draft? > > /martin > > Andy From andy@netconfcentral.com Sun May 3 19: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 DACB73A6F5A for ; Sun, 3 May 2009 19:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_50=0.001, 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 lNvibHd1h2pl for ; Sun, 3 May 2009 19:53:10 -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 3B2783A67DB for ; Sun, 3 May 2009 19:53:10 -0700 (PDT) Received: (qmail 61863 invoked from network); 4 May 2009 02:54:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 4 May 2009 02:54:32 -0000 X-YMail-OSG: pdhkCSEVM1nXGXV3pzV39tixroSagZw1ySiFVeVcDS_bfNcFl3Yye38_2qUT1aDVCIuhTGUCZrRr5slPgv7zyh7fKqUIHUQLd1jKEWbQsAEws3gEqBsGRw5kn1hWRmvXx3FfNFJhzYAF7zT4ZBxA63uAnkF6DhuIK9hkD0YtyiMCkCjW1YnsmB8_jOmCDyEBMQYjbwFr9Q_4kjbbQ8viuuruXB40QZuJpF3o2RM9BLUPPCsBEKyzCAIz.UkAtMSOlc1yeTGsLBhcGtovQMjvpyWbgf_6rRumd4aUSYB.Dwrc.smMW0A- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49FE58E7.7000107@netconfcentral.com> Date: Sun, 03 May 2009 19:54:31 -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] decimal64 canonical form 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, 04 May 2009 02:53:10 -0000 Hi, yang-05, sec. 9.3.2 says that leading and trailing zeros are prohibited. Perhaps the word 'extra' trailing zeros is intended here. By this rule, even 0.0 is an invalid canonical form. I do not think trailing zeros should be prohibited. The exact fraction-digits value SHOULD be used by the agent to make the precision of the number clear every time it is used. Think about the usage survey Phil posted awhile back. Data types like percentage, currency, and probability should all be printed with the complete number of fraction digits. That affects the canonical form of zero (0.0). I suggest '0' instead of '0.0', '0.0000', etc. Andy From mbj@tail-f.com Mon May 4 00:58: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 555F73A6B97 for ; Mon, 4 May 2009 00:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_50=0.001, 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 1fFmUSAkiMiN for ; Mon, 4 May 2009 00:58:11 -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 D400F3A6ABA for ; Mon, 4 May 2009 00:57:56 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0552C616005; Mon, 4 May 2009 09:59:22 +0200 (CEST) Date: Mon, 04 May 2009 09:59:21 +0200 (CEST) Message-Id: <20090504.095921.198478510.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49FE58E7.7000107@netconfcentral.com> References: <49FE58E7.7000107@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] decimal64 canonical form 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, 04 May 2009 07:58:12 -0000 Andy Bierman wrote: > Hi, > > yang-05, sec. 9.3.2 says that leading and trailing zeros > are prohibited. > > Perhaps the word 'extra' trailing zeros is intended here. > By this rule, even 0.0 is an invalid canonical form. You didn't quote the entire sentence. It says: Leading and trailing zeros are prohibited, subject to the rule that there MUST be at least one digit before and after the decimal point. This is they way it works in XSD, and I believe we have WG consensus to do the same. /martin From andy@netconfcentral.com Mon May 4 06:37: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 E12EB3A6E53 for ; Mon, 4 May 2009 06:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.337, 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 toyLwrKZ9qG1 for ; Mon, 4 May 2009 06:37:48 -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 45B053A6B7B for ; Mon, 4 May 2009 06:37:48 -0700 (PDT) Received: (qmail 46210 invoked from network); 4 May 2009 13:39:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 4 May 2009 13:39:09 -0000 X-YMail-OSG: uiKvLJEVM1kOI6hSxPZTXGIB6SEvkfCgkR7Kyl4V8Iz0GORwL1yGpFIAY_qwZNDL_2DYK11xrCUObcbvOU8tQ7VAboAD957AWbljLkFor4ao3J6TVukRKTeEO2qzYSMyPyTH5rBW0zez7mO.lw2yHtxfk9.K4Y_APE6Z5ia2HlPDm_PvULda8UX86D55E7XmarNgFRafH77eyWlv1eEgJ4rwAr1wJ.OzNpX_9J.pdn6iiYq8P_bqWaaAmBK5c.5KaSGYz0V9PPaBA7tAoc84UiQQadwIVbQEsQ9R_o7_a1IjZo8PDhAlIHvdiTAZPTV_lr41yMZZv44.DOQgdAPojpOy_BsXazJ3kQJve.I.DYFx9N3f X-Yahoo-Newman-Property: ymail-3 Message-ID: <49FEEFFB.2070108@netconfcentral.com> Date: Mon, 04 May 2009 06:39:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49FE58E7.7000107@netconfcentral.com> <20090504.095921.198478510.mbj@tail-f.com> In-Reply-To: <20090504.095921.198478510.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] decimal64 canonical form 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, 04 May 2009 13:37:49 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> yang-05, sec. 9.3.2 says that leading and trailing zeros >> are prohibited. >> >> Perhaps the word 'extra' trailing zeros is intended here. >> By this rule, even 0.0 is an invalid canonical form. > > You didn't quote the entire sentence. It says: > > Leading and trailing zeros are prohibited, subject to the rule that > there MUST be at least one digit before and after the decimal > point. > > This is they way it works in XSD, and I believe we have WG consensus > to do the same. > I do not agree. By this rule, percentage and currency will not be printed correctly. It is far more likely that fixed-point numbers are printed this way than with truncated trailing zeros. This is a CLR -- saying agents MUST NOT return 3.00 for three dollars, etc. (Agents MUST return canonical form.) It is hard to follow the logic of this WG sometimes. Usually, XML or XSD is irrelevant and incomplete and that's why YANG is different instead. Other times, for no apparent reason, YANG *must* follow exactly what XML or XSD did, or the sky will fall in. That's why I prefer to cite use-cases to support technical changes. At least that can be evaluated objectively, unlike this "be like XSD when it suites us" argument. > > > /martin > > Andy From phil@juniper.net Mon May 4 07:07: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 AC0EF3A6FFC for ; Mon, 4 May 2009 07:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.844 X-Spam-Level: X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_05=-1.11, 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 KqHDMdTxVTfR for ; Mon, 4 May 2009 07:07:50 -0700 (PDT) Received: from chip3og57.obsmtp.com (chip3og57.obsmtp.com [64.18.14.179]) by core3.amsl.com (Postfix) with ESMTP id B41E93A6C5F for ; Mon, 4 May 2009 07:07:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob57.postini.com ([64.18.6.12]) with SMTP ID DSNKSf73CAfumNLON4sOW1+FFva32mjwqtNe@postini.com; Mon, 04 May 2009 07:09:16 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, 4 May 2009 07:04: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); Mon, 4 May 2009 07:04:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 07:04:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 07:04:45 -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 n44E4jM91518; Mon, 4 May 2009 07:04: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 n44Dv2uD062604; Mon, 4 May 2009 13:57:02 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905041357.n44Dv2uD062604@idle.juniper.net> To: Andy Bierman In-Reply-To: <49FEEFFB.2070108@netconfcentral.com> Date: Mon, 4 May 2009 09:57:02 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 May 2009 14:04:45.0757 (UTC) FILETIME=[47873ED0:01C9CCC1] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 04 May 2009 14:07:50 -0000 Andy Bierman writes: >It is hard to follow the logic of this WG sometimes. IMHO the logic is something like this: - if there's something that exists that does what we need then use it - else if we can closely follow something existing then do - else if we have to go our own way then do it and pay the price There's a cost for inventing new technology, so we want to ensure there's a matching benefit. Here we are making something new but trying to allow it to be expressed in something existing, thereby reducing the impact and increasing the utility of the XSD output that can be generated from YANG. As far as use cases, your percentages would be expressed as "percent 99.94" or "percent 70.0", so I don't see an issue here (though I voted to nuke the trailing ".0" since it too closely resembles significant digits to me, but the WG saw the utility in allowing something that can be expressed in XSD, so...). I agree that money would not be adequately addressed. Do we need to invent a "retained-digits" to specify the number of digits to the right of the decimal point that are retained in the canonical form? Given the rarity of netconf devices handling money, I'm not sure this is needed. Thanks, Phil From andy@netconfcentral.com Mon May 4 07:40: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 30A6F3A6A04 for ; Mon, 4 May 2009 07:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.712, 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 nKRvLjn6Um1i for ; Mon, 4 May 2009 07:40:14 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id 450AF3A6B29 for ; Mon, 4 May 2009 07:40:14 -0700 (PDT) Received: from [68.142.200.225] by n19.bullet.mail.mud.yahoo.com with NNFMP; 04 May 2009 14:41:38 -0000 Received: from [68.142.201.70] by t6.bullet.mud.yahoo.com with NNFMP; 04 May 2009 14:41:37 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 04 May 2009 14:41:37 -0000 X-Yahoo-Newman-Id: 962466.25838.bm@omp422.mail.mud.yahoo.com Received: (qmail 20585 invoked from network); 4 May 2009 14:41:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 4 May 2009 14:41:36 -0000 X-YMail-OSG: vMph4tcVM1lpDmCOlXCVwJ11i2KN6mXMdpYk_WDOlpbqxD1Ha8jeojRuYAnxq6LIhD4TE.dICbJvJ9ATwkETe8jDp6BnvsDu0pK8mNLRh980OnBHuAEjcgHkmkxRWkdpAzHliL_GN0Eeob.BebgoEedsJwfc94ZTx9xrkwPmUGuPLNwru_qazoBLG8ZGE1MtUn4qla0tnqv1m9PBQQ3_x6SroGeNjydCVnquucC3X3RVmfNP.zAwThfj7BGfKNpe_q5aAgUzX1ZDLT4p0Sz6CeuvOlNVD3hSLIcaBtD3YDnkDaIEEVE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49FEFE9E.2000703@netconfcentral.com> Date: Mon, 04 May 2009 07:41:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905041357.n44Dv2uD062604@idle.juniper.net> In-Reply-To: <200905041357.n44Dv2uD062604@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 04 May 2009 14:40:15 -0000 Phil Shafer wrote: > Andy Bierman writes: >> It is hard to follow the logic of this WG sometimes. > > IMHO the logic is something like this: > - if there's something that exists that does what we need > then use it > - else if we can closely follow something existing > then do > - else if we have to go our own way > then do it and pay the price > > There's a cost for inventing new technology, so we want to ensure > there's a matching benefit. Here we are making something new but > trying to allow it to be expressed in something existing, thereby > reducing the impact and increasing the utility of the XSD output > that can be generated from YANG. > > As far as use cases, your percentages would be expressed as "percent > 99.94" or "percent 70.0", so I don't see an issue here (though I > voted to nuke the trailing ".0" since it too closely resembles > significant digits to me, but the WG saw the utility in allowing > something that can be expressed in XSD, so...). > I am used to viewing spreadsheets. I have never seen a spreadsheet truncate fixed-point numbers. They are always printed with the specified number of decimal places, like 99.94 or 70.00. > I agree that money would not be adequately addressed. Do we need > to invent a "retained-digits" to specify the number of digits to > the right of the decimal point that are retained in the canonical > form? Given the rarity of netconf devices handling money, I'm not > sure this is needed. > What problem is being solved by forcing agents to remove 'extra' zeros at the end of a string representing a decimal64 number? It is wasted bandwidth? We can't bear to send those extra 2 or 3 bytes on the wire? That hardly fits with the rest of XML verbosity. Is it to save operators from viewing redundant information? Trailing zeros have meaning. 3.0 and 3.000 are not the same numbers. Chopping off these zeros turns +/- 5 ten-thousandths into +/- 5 hundredths. For currency, it is more than unusual to remove trailing zeros. Is it to save work? Removing these zeros is a little extra work for the agent, and a lot of extra work for applications and operators who need to refer back to the YANG file just to view a decimal64 data type correctly. Since selecting a large number of fraction digits dramatically reduces the range of numbers (-9 to 9 in the worst case), YANG data modelers will be very careful when using decimal64. The requested number of digits is not going to be arbitrary. The data modeler probably wants to see those digits. > Thanks, > Phil > > Andy From spakes@snmp.com Mon May 4 07:43: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 A2FE73A6CB4 for ; Mon, 4 May 2009 07:43:03 -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 PjEQa+nms9wI for ; Mon, 4 May 2009 07:43:02 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 767433A6A04 for ; Mon, 4 May 2009 07:43:02 -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 KAA09169; Mon, 4 May 2009 10:44:27 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA26983; Mon, 4 May 2009 10:44:27 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 4 May 2009 10:44:26 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <49FDFC79.8080108@netconfcentral.com> Message-ID: References: <200904300904.21808.david.partain@ericsson.com> <49FDF8FA.3040108@netconfcentral.com> <20090503.221554.167790073.mbj@tail-f.com> <49FDFC79.8080108@netconfcentral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 04 May 2009 14:43:03 -0000 On Sun, 3 May 2009, Andy Bierman wrote: > David Spakes wrote: > > Largest positive value that can be represented in a decimal64: > > 922337203685477580.7 > > > > Largest negative value that can be represented in a decimal64: > > -922337203685477580.8 > > > I think the ranges are different for each value of fraction-digits: > > fd min max > --------------------------------------------------------- > 1 -922337203685477580.8 922337203685477580.7 > 2 -92233720368547758.08 92233720368547758.07 > 3 -9223372036854775.808 9223372036854775.807 > 4 -922337203685477.5808 922337203685477.5807 > 5 -92233720368547.75808 92233720368547.75807 > 6 -9223372036854.775808 9223372036854.775807 > 7 -922337203685.4775808 922337203685.4775807 > 8 -92233720368.54775808 92233720368.54775807 > 9 -9223372036.854775808 9223372036.854775807 > 10 -922337203.6854775808 922337203.6854775807 > 11 -92233720.36854775808 92233720.36854775807 > 12 -9223372.036854775808 9223372.036854775807 > 13 -922337.2036854775808 922337.2036854775807 > 14 -92233.72036854775808 92233.72036854775807 > 15 -9223.372036854775808 9223.372036854775807 > 16 -922.3372036854775808 922.3372036854775807 > 17 -92.23372036854775808 92.23372036854775807 > 18 -9.223372036854775808 9.223372036854775807 I fully agree, Andy. To choose a value for fraction-digits, the designer must find the correct balance between magnitude and precision for the application. The greater the precision, the smaller the magnitude that can be represented. The greater the magnitude, the samller the precision that can be represented. Note than in your entire table, the largest-magnitude positive number is 922337203685477580.7 and the largest-magnitude negative number is -922337203685477580.8. Both are achieved when fraction-digits specifies the coarsest precision of 1. > Do you think the table should go in the draft? I originally proposed only that the largest-magnitude positive number and the largest-magnitude negative number be stated in the text. However, I would be in favor of including your table in the draft if others are also in favor, since it conveys in no uncertain terms the choices for balancing magnitude and precision. Regards, David Spakes ------------------------------------------------------------- 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 andy@netconfcentral.com Mon May 4 09:01: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 814183A706F for ; Mon, 4 May 2009 09:01:13 -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.345, 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 eCaIHFuwF2FO for ; Mon, 4 May 2009 09:01:12 -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 A23223A6F3B for ; Mon, 4 May 2009 09:00:48 -0700 (PDT) Received: (qmail 41875 invoked from network); 4 May 2009 16:02:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 4 May 2009 16:02:11 -0000 X-YMail-OSG: Ui4gJycVM1lOUiwYtudetT0DxyKrh34ffi_mn8qyXmfW3kKUrZInTevWjUP5.8trtX0mRDUvlUJ1YHmeDS86TJrXssbCtNh2e_.m7M3O3HZRxskMP8fT6MceINt8TGhx5nniCIQDojf_TzuhnH5dhbDN7v4po9BVKdsVd9AMEU1b0FPiFDgChUHD05d.QDNf4VBwPajqzvyuALGxEXixrcKTyitjFjd5QpSAfnVASWpr6fhSvgbIbaViJWMPDPn30P05IoegkZf3n71VlkI8gvADHqkdOrfH5vE8NNQ8J3oL.0ucm3M- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49FF1181.2050003@netconfcentral.com> Date: Mon, 04 May 2009 09:02:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905041357.n44Dv2uD062604@idle.juniper.net> In-Reply-To: <200905041357.n44Dv2uD062604@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 04 May 2009 16:01:13 -0000 Phil Shafer wrote: > Andy Bierman writes: >> It is hard to follow the logic of this WG sometimes. > > IMHO the logic is something like this: > - if there's something that exists that does what we need > then use it > - else if we can closely follow something existing > then do > - else if we have to go our own way > then do it and pay the price > > There's a cost for inventing new technology, so we want to ensure > there's a matching benefit. Here we are making something new but > trying to allow it to be expressed in something existing, thereby > reducing the impact and increasing the utility of the XSD output > that can be generated from YANG. > > As far as use cases, your percentages would be expressed as "percent > 99.94" or "percent 70.0", so I don't see an issue here (though I > voted to nuke the trailing ".0" since it too closely resembles > significant digits to me, but the WG saw the utility in allowing > something that can be expressed in XSD, so...). > Which part of XSD are we not reinventing here? I cannot find any fixed point data types in XSD. In scientific, business, and other areas where fixed point data types are actually supported, they are never rendered with truncated zeros. I propose that the canonical form MUST include exactly the number of fraction digits specified in the YANG file, except the number zero, which is always represented as '0' for all numeric data types in YANG. > Thanks, > Phil > > Andy From phil@juniper.net Mon May 4 09:07: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 C99EC3A6E18 for ; Mon, 4 May 2009 09:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 B9zWNavY6kcO for ; Mon, 4 May 2009 09:07:55 -0700 (PDT) Received: from chip3og63.obsmtp.com (chip3og63.obsmtp.com [64.18.14.203]) by core3.amsl.com (Postfix) with ESMTP id EBFBD3A6A19 for ; Mon, 4 May 2009 09:07:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob63.postini.com ([64.18.6.12]) with SMTP ID DSNKSf8TLAI+3rjkbNWhzJc+rvsaMG/sqUPD@postini.com; Mon, 04 May 2009 09:09:18 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, 4 May 2009 08:08:29 -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, 4 May 2009 08:08:27 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 08:08:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 08:08: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 n44F8QM69425; Mon, 4 May 2009 08:08: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 n44F0hLL063320; Mon, 4 May 2009 15:00:43 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905041500.n44F0hLL063320@idle.juniper.net> To: "Romascanu, Dan (Dan)" In-Reply-To: Date: Mon, 4 May 2009 11:00:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 May 2009 15:08:27.0280 (UTC) FILETIME=[2D556100:01C9CCCA] MIME-Version: 1.0 Content-Type: text/plain 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: Mon, 04 May 2009 16:07:55 -0000 "Romascanu, Dan (Dan)" writes: >Here are my comments and questions. I apologize for the delay. Appreciate the comments and have incorporated them. Some issues: >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. NETMOD is the name of the working group, not any specific technology. In this section, NETCONF is referring to a protocol, not a working group. In a few years, the term NETMOD will be meaningless, so I'd like to avoid referencing it. Is YIN integral? One can make a complete YANG-based system with out needing YIN. YIN is a means of allowing folks to avoid implementing YANG parsers, using XML parsers instead. I don't see this as integral. >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. This section explains the architecture behind YANG's features and deviations. > 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. The document uses "node" in the YANG sense, here and elsewhere. Do I need to replicate parts of the YANG draft's terminology here? >6. Section 7 does not seem to say anything useful Please suggest new wording or contents. >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? I didn't think we were not addressing access rights in the WG. What does the draft need to say on the subject? Thanks, Phil From dromasca@avaya.com Mon May 4 09:16: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 F2DE53A6358 for ; Mon, 4 May 2009 09:16:44 -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 w2H27n+YMhW7 for ; Mon, 4 May 2009 09:16:44 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 2BD743A6B18 for ; Mon, 4 May 2009 09:16:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238990400"; d="scan'208";a="169805183" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 May 2009 12:18:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 May 2009 12:18:09 -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: Mon, 4 May 2009 18:17:50 +0200 Message-ID: In-Reply-To: <200905041500.n44F0hLL063320@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Arch draft comments Thread-Index: AcnM0rA8QMRhTpSXS1KgxfABRrAiFAAADldw References: <200905041500.n44F0hLL063320@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: Mon, 04 May 2009 16:16:45 -0000 Thanks for the answer. Much of what you say makes sense. A couple of clarifications in line.=20 Dan =20 > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net]=20 >=20 > The document uses "node" in the YANG sense, here and elsewhere. > Do I need to replicate parts of the YANG draft's terminology here? Maybe you should to the extent of making clear the intent to a person who is reading this document first out of the pile of NETMOD documents.=20 >=20 > >6. Section 7 does not seem to say anything useful >=20 > Please suggest new wording or contents. Take it out! >=20 > >7. I am not sure that the Security Considerations section should be=20 > >null. We are defining an architecture and not only a data modeling=20 > >language in this document. Is there nothing to say for example about=20 > >access-rights on the different elements of the management domain and=20 > >how they are being kept or mapped in the different translations? >=20 > I didn't think we were not addressing access rights in the=20 > WG. What does the draft need to say on the subject? Can different clients have different access rights (or no rights) to certain parts of the configuration in the servers?=20 >=20 > Thanks, > Phil >=20 From dromasca@avaya.com Mon May 4 09:19: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 5F34C3A6927; Mon, 4 May 2009 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.844, 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 kpdsCsHhjtqb; Mon, 4 May 2009 09:19:47 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D215D3A6358; Mon, 4 May 2009 09:19:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238990400"; d="scan'208";a="160271775" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 04 May 2009 12:21:11 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 May 2009 12:21:11 -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: Mon, 4 May 2009 18:21:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XML Schema Definition Language (XSD) 1.1 a Candidate Recommendation (Call for Implementations) Thread-Index: AcnM0j54z7w/lRXJQECRYBDIMOGZXQAAebLw From: "Romascanu, Dan (Dan)" To: , Subject: [netmod] FW: XML Schema Definition Language (XSD) 1.1 a Candidate Recommendation (Call for Implementations) 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, 04 May 2009 16:19:48 -0000 =20 This announcement from W3C may be of interest for NETMOD and NETCONF.=20 Regards, Dan --------------------------- I am pleased to announce that XML Schema Definition Language (XSD) is a Candidate Recommendation: W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/ W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/ The approval and publication are in response to this transition request: http://lists.w3.org/Archives/Member/chairs/2009AprJun/0030 For the disposition of Last Call comments see: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Apr/0051 There were no Formal Objections. Patent disclosures relevant to this specification may be found on the XML Schema Working Group Working Group's patent disclosure page in conformance with W3C policy: http://www.w3.org/2004/01/pp-impl/19482/status The XML Schema Working Group Working Group expects to receive more comments in the form of implementation feedback and test cases. The Working Group does not expect to have satisfied its implementation criteria before 3 August 2009. See below for the group's "exit criteria." This Call for Implementations follows section 7.4.3 of the W3C Process Document: http://www.w3.org/2005/10/Process-20051014/tr#cfi Thank you, For Tim Berners-Lee, Director, and Liam Quin, XML Activity Activity Lead; Ian Jacobs, Head of W3C Communications =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Exit Criteria The Working Group does not plan to request transition to Proposed Recommendation until the following criteria are satisfied: 1) The XML Schema Test Suite (http://www.w3.org/XML/2004/xml-schema-test-suite/index.html) has been updated to include tests which cover all the new or changed features of these specifications since XML Schema 1.0 (Second Edition); 2) Each feature in the specifications has received two interoperable implementations as demonstrated by test suite results. These specifications contain a number of features identified by the Working Group as "Features at Risk" -- depending on implementation feedback and other input, they may be removed from the subsequent Proposed Recommendations without requiring a return to Last Call. In particular, the decision with respect to the new precisionDecimal datatype included in XML Schema 1.1 Part 2: Datatypes, which is a Feature at Risk, will depend not only on the existence of two demonstrably interoperable implementations and other feedback, but also "on the degree of uptake of [IEEE 754-2008] in the industry". Evidence of uptake to be taken into consideration will likely include support from hardware manufacturers and availability of supporting libraries for programming languages and tools, particularly when such libraries are part of standard distributions. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quoting from the XML Schema 1.1 W3C Candidate Recommendations - 30 April 2009 Abstract (from http://www.w3.org/TR/xmlschema11-1/) -------- This document specifies the XML Schema Definition Language, which offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML vocabulary and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML document type definitions (DTDs). This specification depends on XML Schema Definition Language 1.1 Part 2: Datatypes. Abstract (from http://www.w3.org/TR/xmlschema11-2/) -------- XML Schema: Datatypes is part 2 of the specification of the XML Schema language. It defines facilities for defining datatypes to be used in XML Schemas as well as other XML specifications. The datatype language, which is itself represented in XML, provides a superset of the capabilities found in XML document type definitions (DTDs) for specifying datatypes on elements and attributes. Status of This Document (from both documents, leaving out ----------------------- some boilerplate and detailed change listing) This W3C Candidate Recommendation specifies W3C XML Schema Definition Language (XSD) 1.1. It is here made available for review by W3C members and the public. XSD 1.1 retains all the essential features of XSD 1.0, but adds several new features to support functionality requested by users, fixes many errors in XSD 1.0, and clarifies wording. For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (non-normative) is the recommended starting point. It summarizes both changes made since XSD 1.0 and some changes which were expected (and predicted in earlier drafts of this specification) but have not been made after all. Accompanying versions of this document display in color all changes to normative text since version 1.0 and since the previous Working Draft. The Candidate Recommendation review period for this document extends until 3 August 2009. Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (Public archive at http://lists.w3.org/Archives/Public/www-xml-schema-comments/) Each Bugzilla entry and email message should contain only one comment. Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated "priority feedback" aspects of the design, and identified as such in editorial notes at appropriate points in this draft. Any feature mentioned in a priority feedback note is a "feature at risk": the feature may be retained as is or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors. The W3C XML Schema Working Group intends to request advancement of this specification and publication as a Proposed Recommendation (possibly with editorial changes, and possibly removing features identified as being at risk) as soon after 3 August 2009 as the following conditions are met. * A test suite is available which tests each required and optional feature of XSD 1.1. * Each feature of the specification has been implemented successfully by at least two independent implementations. * The Working Group has responded formally to all issues raised against this document during the Candidate Recommendation period. At the time this Candidate Recommendation was published, no interoperability or implementation report had yet been prepared. This document has been produced by the W3C XML Schema Working Group (http://www.w3.org/XML/Schema.html) as part of the W3C XML Activity (http://www.w3.org/XML/). The goals of XSD 1.1 are discussed in the document Requirements for XML Schema 1.1 (http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/). The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group (http://www.w3.org/2004/01/pp-impl/19482/status); that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. [1] http://www.w3.org/2009/04/29-xmlschema-minutes.html#item07 -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 From phil@juniper.net Mon May 4 09:31: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 645FA28C1F7 for ; Mon, 4 May 2009 09:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Lc3CLuM2dSeC for ; Mon, 4 May 2009 09:31:28 -0700 (PDT) Received: from chip3og65.obsmtp.com (chip3og65.obsmtp.com [64.18.14.207]) by core3.amsl.com (Postfix) with ESMTP id 8052F3A6ABA for ; Mon, 4 May 2009 09:30:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob65.postini.com ([64.18.6.12]) with SMTP ID DSNKSf8Yg9M7aP93WziMF2SC5MnhaK3mBUDA@postini.com; Mon, 04 May 2009 09:32: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; Mon, 4 May 2009 08:37: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); Mon, 4 May 2009 08:37:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 08:37:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 08:37: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 n44FbRM94907; Mon, 4 May 2009 08:37:27 -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 n44FTiJG063516; Mon, 4 May 2009 15:29:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905041529.n44FTiJG063516@idle.juniper.net> To: Andy Bierman In-Reply-To: <49FEFE9E.2000703@netconfcentral.com> Date: Mon, 4 May 2009 11:29:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 May 2009 15:37:27.0716 (UTC) FILETIME=[3AB6D640:01C9CCCE] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 04 May 2009 16:31:29 -0000 Andy Bierman writes: >What problem is being solved by forcing agents to remove 'extra' >zeros at the end of a string representing a decimal64 number? Are you asking why we have canonical representations? We do this to maximize the ability of tools to process values without knowing their type, for example, in an xpath expression or an xslt script. >Trailing zeros have meaning. >3.0 and 3.000 are not the same numbers. >Chopping off these zeros turns +/- 5 ten-thousandths >into +/- 5 hundredths. For currency, it is more than unusual >to remove trailing zeros. Are you talking about significant digits? For most of the world, 3 is identical to 3.000000. And $1.99 is identical to $1.99000000000 Thanks, Phil From andy@netconfcentral.com Mon May 4 10:01: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 26E733A6A3E for ; Mon, 4 May 2009 10:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 kISzsCYKgRtD for ; Mon, 4 May 2009 10:01:37 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id E6A033A6D26 for ; Mon, 4 May 2009 10:00:38 -0700 (PDT) Received: from [68.142.200.227] by n10.bullet.mail.mud.yahoo.com with NNFMP; 04 May 2009 17:02:03 -0000 Received: from [68.142.201.73] by t8.bullet.mud.yahoo.com with NNFMP; 04 May 2009 17:02:03 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 04 May 2009 17:02:03 -0000 X-Yahoo-Newman-Id: 217171.96438.bm@omp425.mail.mud.yahoo.com Received: (qmail 42880 invoked from network); 4 May 2009 17:02:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 4 May 2009 17:02:02 -0000 X-YMail-OSG: iRHUL7sVM1lpcdsj_jil9TQtb0a6j6KOvjZIXi1hMOm6aF.5mspeImfnoLdd372MESF3gA08DFk4EEYJp8BHbzmmvumuwd6UIl0ie9BxQeIzl9yZGilJTdxTPx6UNG7JHqqO9raInNTaYpAMA0dgVaNM9TUNUUv1leqitBLEmNcxSYW8ApXNGd6Nn3ou8zwHn_SRfe1jp6jQEsOlxkuE4QJIJabVwHvM5OdUsNDVChdjG5UGqjTiz1eP6oBvegzlHFpXN.UPLvZ9gsU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49FF1F88.5060302@netconfcentral.com> Date: Mon, 04 May 2009 10:02:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905041529.n44FTiJG063516@idle.juniper.net> In-Reply-To: <200905041529.n44FTiJG063516@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 04 May 2009 17:01:38 -0000 Phil Shafer wrote: > Andy Bierman writes: >> What problem is being solved by forcing agents to remove 'extra' >> zeros at the end of a string representing a decimal64 number? > > Are you asking why we have canonical representations? We do this > to maximize the ability of tools to process values without knowing > their type, for example, in an xpath expression or an xslt script. > No, I am asking we we are truncating zeros when there are many use cases in which the zeros are important. In every case there is no problem if the exact number of significant digits are generated. The manager can easily remove any extra zeros if the user requests that these numbers should be displayed that way. >> Trailing zeros have meaning. >> 3.0 and 3.000 are not the same numbers. >> Chopping off these zeros turns +/- 5 ten-thousandths >> into +/- 5 hundredths. For currency, it is more than unusual >> to remove trailing zeros. > > Are you talking about significant digits? For most of the world, > 3 is identical to 3.000000. And $1.99 is identical to $1.99000000000 > I disagree. Did you get to $1.99 via rounding or some other mechanism? I think you are mixing up the raw data at the protocol PDU layer with the user-visible presentation layer in the NMS. > Thanks, > Phil > > Andy From wjhns1@hardakers.net Tue May 5 04:43: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 E4E173A6BF4 for ; Tue, 5 May 2009 04:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, 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 WAlv2kVu4rTW for ; Tue, 5 May 2009 04:43:39 -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 0E1723A6A8C for ; Tue, 5 May 2009 04:43:39 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 98A48399BF8; Tue, 5 May 2009 04:45:05 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> Date: Tue, 05 May 2009 04:45:05 -0700 In-Reply-To: <49FF1F88.5060302@netconfcentral.com> (Andy Bierman's message of "Mon, 04 May 2009 10:02:00 -0700") 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] decimal64 canonical form 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, 05 May 2009 11:43:40 -0000 >>>>> On Mon, 04 May 2009 10:02:00 -0700, Andy Bierman said: AB> Did you get to $1.99 via rounding or some other mechanism? AB> I think you are mixing up the raw data at the protocol PDU layer AB> with the user-visible presentation layer in the NMS. You're both talking about two different use cases and trying to use one datatype to meet both needs. 1) a number without any extra encoded information. "1.0" really is the same as "1.000" if there is no precision information associated with it. Go ask any language that supports floats if 1.0 == 1.000 and it'll return true. 2) a number with some level of implied precision associated with the data, where 1.000 really implies a different level of confidence associated with the calculation than 1.0. For science this is frequently an important attribute to know and understand. Though I would argue that if you take "1.000" out of context you really have lost all knowledge of why those trailing zeros were there and can't bet on the fact that it is promising precision out to that point. Shouldn't a number with a defined precision level get its own datatype that would encode the precision definitely along with it so that when you transfer it around that definition isn't lost? And canonicalization of both of those cases are likely to have different results, which is where you're running into trouble. >From a data storage perspective and machine generic coding perspective, the advantage of canonicalization is that I can expect and compare the same data with a generic compare routine (memcmp) instead of needing to know the type so that 1.0 really is different than 1.000 because I'm functionally treating everything as a binary blob or string. I think that's already been said though. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From andy@netconfcentral.com Tue May 5 05:45:33 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 2E0AB3A7199 for ; Tue, 5 May 2009 05:45:33 -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.343, 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 K7R5++yFMPoM for ; Tue, 5 May 2009 05:45:32 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 720EC3A6C55 for ; Tue, 5 May 2009 05:45:32 -0700 (PDT) Received: (qmail 93205 invoked from network); 5 May 2009 12:46:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 5 May 2009 12:46:55 -0000 X-YMail-OSG: qW_CyroVM1kyjohOanczupJsxtM0Njnx_FFtQtiCyhSV4mry8QznT3BbIrTj4irOIf7thtHrNVb3iCTx0LmHkbN7E9VUlqE1neOFzjWYjrpOreZ54hW_0RXxaQrvPOerBMQoASfu6t6zP18dRWN7caL5NVnDHdDFIlMRPisVRSON9RvY1UPSaSMawEFVbL2hw34DybojuDTO21lNFCJhD8S91lkU5Znxm3gmZVOhMA6m9x1ROVYMQ7rbvzb02Qu_OddLn6tvWDKfvwoQ0QlWtNc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A00353D.5080404@netconfcentral.com> Date: Tue, 05 May 2009 05:46:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Wes Hardaker References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 05 May 2009 12:45:33 -0000 Wes Hardaker wrote: >>>>>> On Mon, 04 May 2009 10:02:00 -0700, Andy Bierman said: > > AB> Did you get to $1.99 via rounding or some other mechanism? > > AB> I think you are mixing up the raw data at the protocol PDU layer > AB> with the user-visible presentation layer in the NMS. > > You're both talking about two different use cases and trying to use one > datatype to meet both needs. > > 1) a number without any extra encoded information. "1.0" really is the > same as "1.000" if there is no precision information associated with > it. Go ask any language that supports floats if 1.0 == 1.000 and > it'll return true. > > 2) a number with some level of implied precision associated with the > data, where 1.000 really implies a different level of confidence > associated with the calculation than 1.0. For science this is > frequently an important attribute to know and understand. Though I > would argue that if you take "1.000" out of context you really have > lost all knowledge of why those trailing zeros were there and can't > bet on the fact that it is promising precision out to that point. > > Shouldn't a number with a defined precision level get its own > datatype that would encode the precision definitely along with it so > that when you transfer it around that definition isn't lost? > > And canonicalization of both of those cases are likely to have different > results, which is where you're running into trouble. > >>From a data storage perspective and machine generic coding perspective, > the advantage of canonicalization is that I can expect and compare the > same data with a generic compare routine (memcmp) instead of needing to > know the type so that 1.0 really is different than 1.000 because I'm > functionally treating everything as a binary blob or string. I think > that's already been said though. > The current proposal is that zero is '0' for all numeric types except decimal64, which is encoded as '0.0' instead. So your memcmp test fails already. '23' and '23.0' are not going to compare correctly either. If the manager saves '23.0' and the agent then rejects any filter match on '23.0' (because it only will match '23' instead), then have we solved the problem or just moved it somewhere else? Andy From per@tail-f.com Tue May 5 06:24: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 11A863A71A1 for ; Tue, 5 May 2009 06:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=0.883, 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 ZdznrKoHdPgz for ; Tue, 5 May 2009 06:24: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 371703A67DA for ; Tue, 5 May 2009 06:24:41 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 76EF1616020; Tue, 5 May 2009 15:26:04 +0200 (CEST) Message-ID: <4A003E6B.7010801@tail-f.com> Date: Tue, 05 May 2009 15:26:03 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Andy Bierman References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> <4A00353D.5080404@netconfcentral.com> In-Reply-To: <4A00353D.5080404@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 05 May 2009 13:24:42 -0000 On 05/05/09 14:46, Andy Bierman wrote: > > The current proposal is that zero is '0' for all numeric types > except decimal64, which is encoded as '0.0' instead. Hm, an alternate but as far as I know equally valid description is "the current proposal is that the canonical form of zero is '0' for all integer types and '0.0' for all decimal types". Also, I fail to see why this difference is any more "interesting" than the same for '1' vs '1.0' etc. > So your > memcmp test fails already. '23' and '23.0' are not going to compare > correctly either. If the manager saves '23.0' and the agent > then rejects any filter match on '23.0' (because it only will > match '23' instead), then have we solved the problem or just moved > it somewhere else? Is it a goal that it should be possible to do "implicit" value space comparison via textual comparison between elements of different types? FWIW, I don't see any particular value in the "strip trailing zeroes" rule - i.e. "always print decimals" seems like an equally reasonable definition of the canonical form. --Per From andy@netconfcentral.com Tue May 5 08:18: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 A367728C130 for ; Tue, 5 May 2009 08:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_61=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 bM05tlg6gPh0 for ; Tue, 5 May 2009 08:18:51 -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 DA0C928C201 for ; Tue, 5 May 2009 08:18:51 -0700 (PDT) Received: (qmail 68176 invoked from network); 5 May 2009 15:20:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 5 May 2009 15:20:15 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A00592D.5040004@netconfcentral.com> Date: Tue, 05 May 2009 08:20:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Per Hedeland References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> <4A00353D.5080404@netconfcentral.com> <4A003E6B.7010801@tail-f.com> In-Reply-To: <4A003E6B.7010801@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 05 May 2009 15:18:52 -0000 Per Hedeland wrote: > On 05/05/09 14:46, Andy Bierman wrote: >> The current proposal is that zero is '0' for all numeric types >> except decimal64, which is encoded as '0.0' instead. > > Hm, an alternate but as far as I know equally valid description is "the > current proposal is that the canonical form of zero is '0' for all > integer types and '0.0' for all decimal types". Also, I fail to see why > this difference is any more "interesting" than the same for '1' vs '1.0' > etc. > >> So your >> memcmp test fails already. '23' and '23.0' are not going to compare >> correctly either. If the manager saves '23.0' and the agent >> then rejects any filter match on '23.0' (because it only will >> match '23' instead), then have we solved the problem or just moved >> it somewhere else? > > Is it a goal that it should be possible to do "implicit" value space > comparison via textual comparison between elements of different types? > I think the point of having a canonical form is to allow managers to compare values in the lexical space -- the decoded XML, without any concept of the YANG semantics associated with the XML (e.g., strcmp(a, b)). The flaw with this plan is that it only works on a subset of YANG data types, and the manager doesn't understand the value-space (YANG definition), so it doesn't know which XML nodes sent by the agent can be compared this way. > FWIW, I don't see any particular value in the "strip trailing zeroes" > rule - i.e. "always print decimals" seems like an > equally reasonable definition of the canonical form. > thanks for phrasing it this way. The choice we are making is which arbitrary algorithm should be used to help support this flawed plan. IMO, the majority of use cases for fixed-point numbers, the user prefers to view all the fraction digits. It is also possible for any manager (even dumb ones, which are unaware of the YANG semantics) to remove extra zeros. It is impossible for a dumb manager to add back any zeros that the agent has already removed. > --Per > > Andy From per@tail-f.com Tue May 5 09:21: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 E1D873A69C0 for ; Tue, 5 May 2009 09:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_61=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 B24sAazBySWb for ; Tue, 5 May 2009 09:21:53 -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 1A15B3A6899 for ; Tue, 5 May 2009 09:21:53 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A1D8A61601D; Tue, 5 May 2009 18:23:18 +0200 (CEST) Message-ID: <4A0067F6.9030708@tail-f.com> Date: Tue, 05 May 2009 18:23:18 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Andy Bierman References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> <4A00353D.5080404@netconfcentral.com> <4A003E6B.7010801@tail-f.com> <4A00592D.5040004@netconfcentral.com> In-Reply-To: <4A00592D.5040004@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 05 May 2009 16:21:54 -0000 On 05/05/09 17:20, Andy Bierman wrote: > Per Hedeland wrote: >> >> Is it a goal that it should be possible to do "implicit" value space >> comparison via textual comparison between elements of different types? >> > > I think the point of having a canonical form is to allow > managers to compare values in the lexical space -- the > decoded XML, without any concept of the YANG semantics > associated with the XML (e.g., strcmp(a, b)). Yes of course - but values of *different types*? I can't even see how any non-data-model-aware software could expect to be able to compare anything other than different instances of the same XML element - nor why it would be useful for it to be able to do so. > It is also possible for any manager (even dumb ones, which > are unaware of the YANG semantics) to remove extra zeros. That would be completely broken IMO - if the manager isn't aware of the data model, it could be removing critical information from some application-specific string type. It can't just assume that it's a numerical/decimal type from the fact that an instance of the textual representation consists of only digits and a dot. --Per Hedeland From j.schoenwaelder@jacobs-university.de Tue May 5 09:48: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 CCE753A71CE for ; Tue, 5 May 2009 09:48:03 -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 cXN9jdvGnOfn for ; Tue, 5 May 2009 09:48:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2CE4F3A71D3 for ; Tue, 5 May 2009 09:47:30 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5350CC0101; Tue, 5 May 2009 18:48:56 +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 8+5-OmJ7Pm5m; Tue, 5 May 2009 18:48:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF0BEC0022; Tue, 5 May 2009 18:48:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29400ADB113; Tue, 5 May 2009 18:48:35 +0200 (CEST) Date: Tue, 5 May 2009 18:48:35 +0200 From: Juergen Schoenwaelder To: Per Hedeland Message-ID: <20090505164835.GA20696@elstar.local> Mail-Followup-To: Per Hedeland , Andy Bierman , "netmod@ietf.org" References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> <4A00353D.5080404@netconfcentral.com> <4A003E6B.7010801@tail-f.com> <4A00592D.5040004@netconfcentral.com> <4A0067F6.9030708@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0067F6.9030708@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] decimal64 canonical form 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: Tue, 05 May 2009 16:48:03 -0000 On Tue, May 05, 2009 at 06:23:18PM +0200, Per Hedeland wrote: [...] 1) Canonicalization is a type specific property. 2) We need canonicalization primarily so that tools comparing lets say different versions of a specific configuration can operate on the lexical respresentations. /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 Tue May 5 09:55: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 6CE773A718E for ; Tue, 5 May 2009 09:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_61=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 B5ppGZhLq9nq for ; Tue, 5 May 2009 09:55:35 -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 B24FD3A6D8B for ; Tue, 5 May 2009 09:55:35 -0700 (PDT) Received: (qmail 40345 invoked from network); 5 May 2009 16:57:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 5 May 2009 16:57:00 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A006FDA.40404@netconfcentral.com> Date: Tue, 05 May 2009 09:56:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Per Hedeland References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> <4A00353D.5080404@netconfcentral.com> <4A003E6B.7010801@tail-f.com> <4A00592D.5040004@netconfcentral.com> <4A0067F6.9030708@tail-f.com> In-Reply-To: <4A0067F6.9030708@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 05 May 2009 16:55:36 -0000 Per Hedeland wrote: > On 05/05/09 17:20, Andy Bierman wrote: >> Per Hedeland wrote: >>> Is it a goal that it should be possible to do "implicit" value space >>> comparison via textual comparison between elements of different types? >>> >> I think the point of having a canonical form is to allow >> managers to compare values in the lexical space -- the >> decoded XML, without any concept of the YANG semantics >> associated with the XML (e.g., strcmp(a, b)). > > Yes of course - but values of *different types*? I can't even see how > any non-data-model-aware software could expect to be able to compare > anything other than different instances of the same XML element - nor > why it would be useful for it to be able to do so. > OK, for the same element the manager can compare different instances of the same object without knowing any semantics. >> It is also possible for any manager (even dumb ones, which >> are unaware of the YANG semantics) to remove extra zeros. > > That would be completely broken IMO - if the manager isn't aware of the > data model, it could be removing critical information from some > application-specific string type. It can't just assume that it's a > numerical/decimal type from the fact that an instance of the textual > representation consists of only digits and a dot. > You are right. The manager could guess that '0' equals '0.0' or . is a number, but it is only a guess. > --Per Hedeland > Andy From phil@juniper.net Tue May 5 11: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 87C773A7192 for ; Tue, 5 May 2009 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 amx3splRMcHt for ; Tue, 5 May 2009 11:08:10 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id BEF7E3A6E31 for ; Tue, 5 May 2009 11:08:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSgCA25tV02zHNGmSmaw3lY6h4TSYsIAd@postini.com; Tue, 05 May 2009 11:09:37 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; Tue, 5 May 2009 11:06:03 -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, 5 May 2009 11:06:03 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 11:06:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 11:06:02 -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 n45I61L00984; Tue, 5 May 2009 11:06:01 -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 n45HwHxI075836; Tue, 5 May 2009 17:58:17 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905051758.n45HwHxI075836@idle.juniper.net> To: "Romascanu, Dan (Dan)" In-Reply-To: Date: Tue, 5 May 2009 13:58:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2009 18:06:02.0288 (UTC) FILETIME=[26A05300:01C9CDAC] MIME-Version: 1.0 Content-Type: text/plain 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, 05 May 2009 18:08:11 -0000 "Romascanu, Dan (Dan)" writes: >Can different clients have different access rights (or no rights) to >certain parts of the configuration in the servers? IMHO sure, as dictated by the access control model. But we do not yet have an architecture for this, so I did not mention it. Thanks, Phil From wjhns1@hardakers.net Wed May 6 10:35: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 AA0D13A70C3 for ; Wed, 6 May 2009 10:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, 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 xn4R946+7C0R for ; Wed, 6 May 2009 10:35:07 -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 07D1728C2C2 for ; Wed, 6 May 2009 10:30:11 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id A7FC439A0F1; Wed, 6 May 2009 10:31:37 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> <4A00353D.5080404@netconfcentral.com> Date: Wed, 06 May 2009 10:31:37 -0700 In-Reply-To: <4A00353D.5080404@netconfcentral.com> (Andy Bierman's message of "Tue, 05 May 2009 05:46:53 -0700") 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] decimal64 canonical form 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, 06 May 2009 17:35:08 -0000 >>>>> On Tue, 05 May 2009 05:46:53 -0700, Andy Bierman said: AB> The current proposal is that zero is '0' for all numeric types AB> except decimal64, which is encoded as '0.0' instead. AB> So your memcmp test fails already. No, the memcmp would still succeed because agents would be returning canonical forms of each variable in the tree in identical ways. A manager would never generically compare something in one part of the tree of a one type (int) to another part of the tree in another type (decimal64). That being said, managers should ideally understand the data types that they're trying to look at. But generic "fetch and store" mechanisms can't always do this. I've worked with people that can't get broken MIBs to load, so they use generic data. SNMP has an advantage here since the data is sent over in typed format and the storage/printing engines don't need the yang data type around to understand the fundamental nature of the value. This isn't true with netconf (I'm not arguing it should be; I'm just pointing it out). Operators *will* try and hack around cases where they don't have the yang module available or the yang module is not parsable by their tools. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From andy@netconfcentral.com Wed May 6 12:04: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 39F213A721E for ; Wed, 6 May 2009 12:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.036, 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 dWs7isqwHU0A for ; Wed, 6 May 2009 12:04:06 -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 7579C3A6F5F for ; Wed, 6 May 2009 11:54:35 -0700 (PDT) Received: (qmail 43343 invoked from network); 6 May 2009 18:56:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 6 May 2009 18:56:00 -0000 X-YMail-OSG: g306YhoVM1mrVS8PSGQhwM3v_0WPgYEktmlypXRoeUHK1Jv8MQc013N7VOMZrZWVoZSQwz_pGH_fhluQvNpBKIh5QUQs6I6j5RON2._7Z2JQQOyKViaSfqNfbtm2cyltw32LUV1SsgQywL7YknhCRwnl3GYR9kTWZGKal1deVn9sg0ANKOOwLHvjqcIhsRHYRC7nJizDF6sNsOARQcFh1drNQJLjLZOf7LMx.zAM7Wu_AnbI4To1dTfKQNBvvyzqCSlS8UYYm9siWTho8v9IJAe0Jg08mYCeGK4vgJ1FJYlJt95ApQGBDSUaAXcFQjdL4Vq62hsbX.H2QI4KCPBKaoV_4UbuEoHmPeCXBMnWPCoCXUFk X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A01DD3E.1090001@netconfcentral.com> Date: Wed, 06 May 2009 11:55:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Wes Hardaker References: <200905041529.n44FTiJG063516@idle.juniper.net> <49FF1F88.5060302@netconfcentral.com> <4A00353D.5080404@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 canonical form 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, 06 May 2009 19:04:07 -0000 Wes Hardaker wrote: >>>>>> On Tue, 05 May 2009 05:46:53 -0700, Andy Bierman said: > > AB> The current proposal is that zero is '0' for all numeric types > AB> except decimal64, which is encoded as '0.0' instead. > AB> So your memcmp test fails already. > > No, the memcmp would still succeed because agents would be returning > canonical forms of each variable in the tree in identical ways. A > manager would never generically compare something in one part of the > tree of a one type (int) to another part of the tree in another type > (decimal64). > This can happen as a side effect of subtree and/or XPath filtering, depending on the filter and data model contents. > That being said, managers should ideally understand the data types that > they're trying to look at. But generic "fetch and store" mechanisms > can't always do this. I've worked with people that can't get broken > MIBs to load, so they use generic data. SNMP has an advantage here > since the data is sent over in typed format and the storage/printing > engines don't need the yang data type around to understand the > fundamental nature of the value. This isn't true with netconf (I'm not > arguing it should be; I'm just pointing it out). > > Operators *will* try and hack around cases where they don't have the > yang module available or the yang module is not parsable by their tools. IMO, this is an NMS presentation issue. The NMS can let the user format unknown leafs however they want. The user can say "treat this as an int32, or a decimal64 w/ 4 fraction digits", or whatever. If the application has the YANG module, then it can figure out how to compare values. Just assuming the agent correctly returned the canonical form may not always work. Andy From andy@netconfcentral.com Thu May 7 08:50: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 3C3F73A722A for ; Thu, 7 May 2009 08:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.032, 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 fnheZQ3ZSEtO for ; Thu, 7 May 2009 08:50:50 -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 6DB2728C2EA for ; Thu, 7 May 2009 08:50:11 -0700 (PDT) Received: (qmail 80482 invoked from network); 7 May 2009 15:51:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2009 15:51:37 -0000 X-YMail-OSG: uDr30nUVM1mDLIYTR8qJHt0pTLlXBUKoM7cCDi0bk_IDEEz2iVcCbOXDqOLbWY7EuolpUAWhkjizkYS6vu_HZzx_MokUwA1jggcXvXSNBk5JIGMnLQPkl5CKOAh2fRoVvWqH4kV9dv8dD8MtHTWzR01nkbmgAUoNn52.GTM2VFeU26wzk7yYsxVAmO0qv3pfqRDypr40_eyMJqdTV3081WHtb4jtyT.Y2YfPlQwRFeUNubWhepJblfT.PDY7n1M4.CRqxX85nDIgY6ZXaZrIbQGsBkOaB6nQ2bkHMs0wjhlZZElxplI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A030388.9020105@netconfcentral.com> Date: Thu, 07 May 2009 08:51:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <200904271931.n3RJVNDZ074545@idle.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 07 May 2009 15:50:51 -0000 Romascanu, Dan (Dan) wrote: > Here are my comments and questions. I apologize for the delay. > > 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'. > I don't think there is any hidden agenda here. The operation is not a secret. The use of vendor RPC operations as verbs is no secret either. What you call a hidden agenda, I call a pent-up demand for replacement of a 20 year old technology base with something more powerful and extensible. How about 'improve certain aspects of network management' or some other phrase indicating a subset of NM? Andy From dromasca@avaya.com Thu May 7 08:56: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 571703A6F63 for ; Thu, 7 May 2009 08:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 ojEJDHvVSa7l for ; Thu, 7 May 2009 08:56:49 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B3A793A6A90 for ; Thu, 7 May 2009 08:56:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,311,1238990400"; d="scan'208";a="170187056" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 May 2009 11:58:11 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 May 2009 11:58:10 -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: Thu, 7 May 2009 17:57:49 +0200 Message-ID: In-Reply-To: <4A030388.9020105@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Arch draft comments Thread-Index: AcnPK7Y2tKg6feDwRfeRlnOcO5VuAwAAMDaw References: <200904271931.n3RJVNDZ074545@idle.juniper.net> <4A030388.9020105@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" 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: Thu, 07 May 2009 15:56:50 -0000 =20 > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com]=20 > Sent: Thursday, May 07, 2009 6:52 PM > To: Romascanu, Dan (Dan) > Cc: Phil Shafer; netmod@ietf.org > Subject: Re: [netmod] Arch draft comments >=20 > Romascanu, Dan (Dan) wrote: > > Here are my comments and questions. I apologize for the delay.=20 > >=20 > > Regards, > >=20 > > Dan > >=20 > >=20 > > 1. In the Abstract you say ' NETCONF and YANG are pieces of an > > ambitious plan to improve network management.'. Please keep your=20 > > hidden agenda in the dark :-) Neither NETCONF nor YANG were=20 > chartered=20 > > with such ambitious plans. I suggest to reformulate the phrasing=20 > > keeping the scope to what was approved by consensus in the IETF=20 > > (configuration management, notifications capabilities). You can=20 > > certainly mention that the architecture is extensible and may cover=20 > > more management functionality in the future, but better=20 > keep it less=20 > > declarative at this phase. The title should also rather be=20 > 'A NETCONF=20 > > and NETMOD based Architecture for Network Management'. > >=20 >=20 > I don't think there is any hidden agenda here. > The operation is not a secret. > The use of vendor RPC operations as verbs is no secret either. > What you call a hidden agenda, I call a pent-up demand for=20 > replacement of a 20 year old technology base with something=20 > more powerful and extensible. >=20 >=20 > How about >=20 > 'improve certain aspects of network management' >=20 > or some other phrase indicating a subset of NM? >=20 >=20 > Andy >=20 This would be better and reflect what NETCONF was chartered to do at this phase.=20 Dan From phil@juniper.net Thu May 7 10:23: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 317623A6972 for ; Thu, 7 May 2009 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 YRBQgdHvHk2c for ; Thu, 7 May 2009 10:23:24 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 8F73A3A68D2 for ; Thu, 7 May 2009 10:23:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob60.postini.com ([64.18.6.12]) with SMTP ID DSNKSgMZULd8Yfgk5lgOTApGZ+wqnle0so0r@postini.com; Thu, 07 May 2009 10:24:52 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, 7 May 2009 10:19:21 -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, 7 May 2009 10:19:21 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 10:19:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 10:19:20 -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 n47HJJL83786; Thu, 7 May 2009 10:19:19 -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 n47HBWb1095391; Thu, 7 May 2009 17:11:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905071711.n47HBWb1095391@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A030388.9020105@netconfcentral.com> Date: Thu, 7 May 2009 13:11:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2009 17:19:20.0027 (UTC) FILETIME=[F52CBAB0:01C9CF37] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 07 May 2009 17:23:25 -0000 Andy Bierman writes: >What you call a hidden agenda, I call a pent-up demand for replacement >of a 20 year old technology base with something more powerful >and extensible. I nuked the sentence completely. Thanks, Phil From andy@netconfcentral.com Thu May 7 10:33: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 A23823A6E30 for ; Thu, 7 May 2009 10:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-1.102, 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 gLZ+9DIuR4WP for ; Thu, 7 May 2009 10:33:27 -0700 (PDT) Received: from n5a.bullet.mud.yahoo.com (n5a.bullet.mud.yahoo.com [209.191.126.232]) by core3.amsl.com (Postfix) with SMTP id B5F1F3A6CB1 for ; Thu, 7 May 2009 10:33:27 -0700 (PDT) Received: from [68.142.194.243] by n5.bullet.mud.yahoo.com with NNFMP; 07 May 2009 17:34:53 -0000 Received: from [68.142.201.66] by t1.bullet.mud.yahoo.com with NNFMP; 07 May 2009 17:34:53 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 07 May 2009 17:34:53 -0000 X-Yahoo-Newman-Id: 954534.64904.bm@omp418.mail.mud.yahoo.com Received: (qmail 96490 invoked from network); 7 May 2009 17:34:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2009 17:34:52 -0000 X-YMail-OSG: 1OV4VfQVM1mAAXp1_hfzvlAK7G4zaw1hd6vOFlu9qmaAIWzGryvBXH64qOWPxynKZ17g7IpRgvK5Z2Csvr5h4Sv.jXh7zfz3UHcOvljVM8ryZA2ket._CAzKuk8hDBWBfxYi0QgaOTEfYTu1SnXxoKsNzDh52fyPrbuOX5.Aa0xGdfDiJ0ceHkq.P8eDfSyRKo.i3xpQ0zfezUJvO0RqPBZjyc9nA4mphAuZeDkTHrMFtahqsSDZYRFPRPQuXLPTTVMV6laBmSJB6.OGHvABgYMIgl24x3qk5vo.hjt29un5JQ6gGLw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A031BBB.3080006@netconfcentral.com> Date: Thu, 07 May 2009 10:34:51 -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] WGLC comments on deviation-stmt 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, 07 May 2009 17:33:28 -0000 Hi, IMO, the deviation-stmt as currently designed is not implementable. I know of 2 developers who have tried, but both of us needed to indicate the deviations file(s) to the compiler along with the module-under-test (MUT). There is no indication whatsoever in the MUT that any external deviations exist. Unlike augment (the only other way this can happen), deviations are destructive to the MUT. An external augment cannot possibly alter the validity of the MUT by itself (by design). In order to make use of deviations, they must be implementable. The current approach in the standard is that deviations can appear in any module, and alter the contents of any other random module. IMO, this is not implementable. A compiler needs perfect knowledge of all the deviation files in advance, and standard ignores this fact completely. Andy From jmh@joelhalpern.com Thu May 7 11:05: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 210D93A7124 for ; Thu, 7 May 2009 11:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 nOFQvWYl4aPA for ; Thu, 7 May 2009 11:05: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 D0FDA3A716E for ; Thu, 7 May 2009 11:03:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4373B4301FF for ; Thu, 7 May 2009 11:04:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D0BDB430182 for ; Thu, 7 May 2009 11:04:39 -0700 (PDT) Message-ID: <4A0322B1.4050006@joelhalpern.com> Date: Thu, 07 May 2009 14:04:33 -0400 From: "Joel M. Halpern" 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] Confusion about mandatory 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, 07 May 2009 18:05:59 -0000 While reading the YANG document again, I have managed to confuse myself about the effect of "Mandatory". In the absence of choice: I am left unsure as to whether the text in 7.6.4 on the non-choice effects of "mandatory" are clear, or correct. Must there always be something that is not a "non-presence container" above the leaf in the tree? Does the module or submodule count for this purpose? Presumably, all intermediate containers between the leaf and the selected ancestor must also exist if the leaf is forced to exist? In the presence of choice, suppose that the only element of the choice is a non-presence container. Presumably, if that non-presence container is created, because that is which branch of the choice is being taken, then the leaf must exist. (i.e. if the leaf has siblings in the container, but no other nodes exist in this case?) Joel From mbj@tail-f.com Thu May 7 11:33: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 4D45E28C34B for ; Thu, 7 May 2009 11:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.195, 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 FGhpqTpq1UC8 for ; Thu, 7 May 2009 11:33:29 -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 B888828C364 for ; Thu, 7 May 2009 11:32:11 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5458D76C340; Thu, 7 May 2009 20:33:39 +0200 (CEST) Date: Thu, 07 May 2009 20:33:38 +0200 (CEST) Message-Id: <20090507.203338.174531220.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A031BBB.3080006@netconfcentral.com> References: <4A031BBB.3080006@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] WGLC comments on deviation-stmt 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, 07 May 2009 18:33:30 -0000 Hi, Andy Bierman wrote: > Hi, > > IMO, the deviation-stmt as currently designed > is not implementable. I know of 2 developers > who have tried, but both of us needed to indicate > the deviations file(s) to the compiler along > with the module-under-test (MUT). But this is the intention. As you describe below, this is how deviations work. In general of course YANG does not *require* any tool chain at all - you are free to write your YANG models and code them by hand. If you do, you can write down in your deviations module how you deviate from the main module. But if you have tool support, you will first write your deviation module how you will deviate from the main module, then feed the main module and the deviations module to your tools, which will generate code for the "patched" module. In both cases, your agent will advertise to the client the main module, and along with it also the deviation module. > There is no indication whatsoever in the MUT > that any external deviations exist. Just like in SMIv2 where there is no indication in the IF-MIB that vendor X has a AGENT-CAPABILITIES module describing how it deviates from the IF-MIB. > Unlike > augment (the only other way this can happen), > deviations are destructive to the MUT. > An external augment cannot possibly alter > the validity of the MUT by itself (by design). > > In order to make use of deviations, they must be implementable. > The current approach in the standard is that deviations > can appear in any module, and alter the contents > of any other random module. IMO, this is not implementable. > > A compiler needs perfect knowledge of all the deviation files > in advance, and standard ignores this fact completely. It does not ignore this. In fact, this is the reason that the deviation module is advertised *in the same capability string* as the main module. /martin From andy@netconfcentral.com Thu May 7 11:55: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 9533F3A6920 for ; Thu, 7 May 2009 11:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, 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 U2CZG8MItglo for ; Thu, 7 May 2009 11:55:11 -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 C967B3A6898 for ; Thu, 7 May 2009 11:55:11 -0700 (PDT) Received: (qmail 53111 invoked from network); 7 May 2009 18:56:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2009 18:56:38 -0000 X-YMail-OSG: GN7qFcMVM1kBerj4CBbODHNJzPK5KsQ5GThsIWzBolRBi7I4EleTalLLqdIipMi9e3f4sO1VH1jvwO_qq9sTfndlXTFQfrwTI4vhOil48uzf9JGL57_e_AVA1MPYu3Prvf0eEVr.24BHF5Jd6ZD7keyf8fU5z7__v7S7jROlxf2bEQMPmydulM1Mmh6e8cZlInQvC1_9aOEmQmczMeO0Sv1aAKct11.eDSimCgZMN1mJBu1MxvLWXcNukm6w7iSHoSBlN9kqjM5kd4fbHzSib2T1MuNi04DiKFHiDPACvK73od8S6xkkeK44Fty_hpYI3MHqgXo19QP646TfKPUgKdYk6eKfG4W9L56U7AR8lYkcML2m X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A032EE4.9080903@netconfcentral.com> Date: Thu, 07 May 2009 11:56:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A031BBB.3080006@netconfcentral.com> <20090507.203338.174531220.mbj@tail-f.com> In-Reply-To: <20090507.203338.174531220.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] WGLC comments on deviation-stmt 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, 07 May 2009 18:55:12 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> IMO, the deviation-stmt as currently designed >> is not implementable. I know of 2 developers >> who have tried, but both of us needed to indicate >> the deviations file(s) to the compiler along >> with the module-under-test (MUT). > > But this is the intention. As you describe below, this is how > deviations work. > This is not specified in the standard. There is a difference between what a user MAY choose to do with the tools and what a tool MUST support. Assuming that tools will have mechanisms to identify all the deviations files associated with a module should be written in the standard (or avoided completely). I think the IESG and other reviewers will be interested in knowing how interoperability for deviations-stmt is going to be measured in the future, when YANG either advances on the standards track or moves to Historic status. I have already posted emails demonstrating that implementation of deviations depends on the order the deviations are applied. The point of a standard data modeling language is to provide a set of constructs that will be implemented consistently across all devices and tools. That means, given the same YANG module (in isolation), two independent implementations should agree on the validity of that module. I do not think deviations-stmt currently meets that minimum level of interoperability. Andy > In general of course YANG does not *require* any tool chain at all - > you are free to write your YANG models and code them by hand. If you > do, you can write down in your deviations module how you deviate from > the main module. > > But if you have tool support, you will first write your deviation > module how you will deviate from the main module, then feed the main > module and the deviations module to your tools, which will generate > code for the "patched" module. > > In both cases, your agent will advertise to the client the main > module, and along with it also the deviation module. > >> There is no indication whatsoever in the MUT >> that any external deviations exist. > > Just like in SMIv2 where there is no indication in the IF-MIB that > vendor X has a AGENT-CAPABILITIES module describing how it deviates > from the IF-MIB. > >> Unlike >> augment (the only other way this can happen), >> deviations are destructive to the MUT. >> An external augment cannot possibly alter >> the validity of the MUT by itself (by design). >> >> In order to make use of deviations, they must be implementable. >> The current approach in the standard is that deviations >> can appear in any module, and alter the contents >> of any other random module. IMO, this is not implementable. >> >> A compiler needs perfect knowledge of all the deviation files >> in advance, and standard ignores this fact completely. > > It does not ignore this. In fact, this is the reason that the > deviation module is advertised *in the same capability string* as the > main module. > > > /martin > > From jmh@joelhalpern.com Thu May 7 13:46: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 3E30D3A6E3E for ; Thu, 7 May 2009 13:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 ADg9QHCr5ZAl for ; Thu, 7 May 2009 13:46:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D46923A70A9 for ; Thu, 7 May 2009 13:46:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D974430358 for ; Thu, 7 May 2009 13:47:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 21822430281 for ; Thu, 7 May 2009 13:47:49 -0700 (PDT) Message-ID: <4A0348EE.2050907@joelhalpern.com> Date: Thu, 07 May 2009 16:47:42 -0400 From: "Joel M. Halpern" 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] WG last call 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: Thu, 07 May 2009 20:46:23 -0000 Having noticed the WG last call on YANG, I have done another read through he document. The following comments are all relatively minor or editorial. They are about presentation of information in the document, not about technical choices made by the working group. Minor: 1) In the definition of Mandatory node in section 3.1, it talks about a container node with a "mandatory" child. What if that mandatory child is within a choice construct (probably indirectly, and the choice itself is not explicitly marked mandatory), i.e. in the choice case A is such that there are no mandatory parts, but case B contains constructs which are Mandatory. Is the parent mandatory? 2) In section 5.6.4 defining the syntax for announcing conformance, there appears to be some ambiguity in the intended structure. It appears that arbitrarily many revision, module, and feature parameter are allowed, in any order. Presumably, a module parameter is required before any revision, deviation, or feature parameters? And revision, deviation, and feature parameters are to be interpreted as applying to the most recent prior module parameter? What does it mean if there are multiple revision parameters after a module parameter (I.e. after the only module parameter, or between one module parameter and the next.) The feature parameter allows a comma separated list of feature names. If there are multiple feature parameters that apply to the same module parameter, are the features to be concatenated, overwritten, first parameter kept? (The obvious meaning in that case is to concatenate, but it does not say so.) And what of multiple deviation parameters? 3) The reference for schema discovery (section 5.6.5) should point somewhere. If it can not point at least to an I-D, then the section should be removed. (I think we can get away with making it an informative reference, although it is right on the edge.) It might make sense to remove it anyway, and just include the text in the Schema Discovery document. 4) Is it intentional that submodule is defined to occur at most once, and module does not have such a restriction? (in section 7.) 5) In section 7.5.8 on the use of edit-config with containers, there seem to be a number of pieces that are not described. Some of these are covered by the general description in netconf (for example on the relationship between merge and replace.) Even so, a sentence here saying that would be helpful. However, there is one case where the netconf stuff does not seem to help. On "replace," if the node exists, what happens with regard to child nodes present in the XML and the datastore? (It seems clear that the recursive behavior of "replace" is somewhat different from "replace" on the parent, and for good reasons.) 6) Should there be some sort of comment in the description of choice that the given rules are not sufficient to ensure that all choice definitions are unambiguous, and it is the model developer's responsibility to ensure that if the distinction matters that the various combinations of possible defaults is unambiguous? (I am thinking about a choice without an explicit default, where two of the branches are such that they can legally exist with with just default values (they have no mandatory components.) I think that the rules as written permit ambiguities, and that the system could not determine which branch was actually the case. In particular, if someone was trying to get the config with-defaults, the system might not know which case to use. (It would likely be a situations where the two cases, in default, resulted in the same behavior. But one XML needs to be returned.) 7) In the definition of the RPC element, I presume that there are constraints on the use of the "grouping" element? When groupings appear directly in the rpc element, they can not define any data components other than input or output? And the collection of grouping, input, and output elements can not define more than 1 input and 1 output? (If so, this does mean that the cardinality limit on grouping directly in rpc is 0..2, not 0..n, I think.) 8) In defining notifications, is it part of the definition to indicate that certain fields are supposed to be used to represent values from other parts of the data tree (like the src address of the packet in error, or the power level of the misbehaving laser, or the temperature from the thermal senor...) I think, if I am reading this right, that the plan in netmod is to simply define the information to be reported, and to use description clauses to indicate where the information really comes from? A little more explanation of this in the notification section would be helpful. 9) The text on updating a module specifies that updates must not cause interoperability problems in the case where a client using the old module talks to a server using the new module. The allowed changes include expanding the set of legitimate values. (contract the valid set would be as bad or worse.) But this seems to mean that a client may receive values that it considers invalid from the server. It seems to me that somewhere there ought to be a statement that says "although clients must be aware of teh definition of valoid values for generating configuration data, they must also be prepared to receive apparently invalid values from the server if teh server working with a newer version of a module. Editorial comments: The type statement is forward referenced at the end of 4.2.4. It should be to section 7.4, not to section 9. In the example of special strings in 6.1.3.1, just to confirm the expected, would it be worth including "'"? Since section 7.1.6 (The include Statement) is reference for submodules as well as modules, the text of the first sentence probably ought to read: The "include" statement is used to make content from a submodule available that submodules parent module, or any other submodules of that parent module. (The text in the first sentence currently says it makes it available only to modules.) Section 7.8 The list statement, in the sentence after the introductory paragraph says "A list entry is uniquely identified by the values of the list's key." However, the first sentence in 7.8.2 says that the "key" statement is optional for state data. So shouldn't the sentence in 7.8 be somewhat qualified? ("if defined" at the end of the sentence might well suffice.) It would probably be nice to remind readers in section 7.8.2 (The list's key Statement) that while fields in containers can not be used as key fields, leafs defined in groups can be used. (This gets around my biggest concerns with the requirement that the key elements be direct leaf elements in the list.) Should the definition of the reference statement (7.19.5) say something about the syntax? Related to that, the text leaves me completely puzzled as to what "reference" elements are for. I thought for a while they were related to the leafref type. But they aren't. I think that there ought to be some more text in 7.19.4 telling the reader just what the content is supposed / expected to be, other than "string" as defined by the ABNF. It seems odd and confusing that a range statement is not required to have its values in canonical form. At least, it would seem useful to have a sentence saying that, and stating why it is so. In section 10 on Updating a Module, it says that obsolete definitions MUST NOT be removed. In the status section it says that obsolete is specifically for things that can be removed, as deprecated is for things that can not be removed? I think the difference is between "removed from specification" and "removed from implementation. A few extra words here would avoid confusing the reader. (Something like "Although explicitly obsolete elements may be removed from implementations, they must not be removed from specifications so as to avoid rendering other definitions syntactically invalid.") From phil@juniper.net Fri May 8 06:34: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 DEB513A6AEC for ; Fri, 8 May 2009 06:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 ORam8GZyUK+7 for ; Fri, 8 May 2009 06:34:56 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 7F39F3A6A57 for ; Fri, 8 May 2009 06:34:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSgQ1ViQY0RPE+Y5CCxN76wSwwnt497YJ@postini.com; Fri, 08 May 2009 06:36:25 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, 8 May 2009 06:26:41 -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, 8 May 2009 06:26:41 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 06:26:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 May 2009 06:26:40 -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 n48DQeL64558; Fri, 8 May 2009 06:26:40 -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 n48DGYp0003973; Fri, 8 May 2009 13:16:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905081316.n48DGYp0003973@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A032EE4.9080903@netconfcentral.com> Date: Fri, 8 May 2009 09:16:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 May 2009 13:26:40.0968 (UTC) FILETIME=[9F571C80:01C9CFE0] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 08 May 2009 13:34:57 -0000 Andy Bierman writes: >The point of a standard data modeling language is to >provide a set of constructs that will be implemented >consistently across all devices and tools. That means, >given the same YANG module (in isolation), two independent >implementations should agree on the validity of that module. And the point of deviations is to admit that, for a variety of reasons, the constructs detailed in a standard module cannot be implemented consistently across all devices. Historically, an implementation that is not able to fully implement that standard has two choices: (a) don't implement that standard, or (b) lie and say they implement the full standard, fudging input and output when needed. Given marketing/customer/plm pressures, (a) may not be an option. If the device support 99% of the standard, lying about the one bit that cannot be implemented may well be the lesser of two evils. Deviations give implementations a third option, allowing them to detail the places where they fail to fully implement the standard. This in no way reduces the need to push for interoperability by maximizing the ability of an implementation to fully statisfy the constraints of the standard, but by allowing the truth to be known, applications can better deal with implementations that aren't fully compliant. So interoperability does not benefit from implementations that deviate from the standard, but interoperability _does_ benefit from allowing implementations to express (and applications to intergrate the knowledge of) the places where the standard has not been fully implemented. We've not encouraging deviations, but we are wise enough to admit that they occur and should not be ignored. The working group has repeatedly decided that this feature is useful and worthwhile. Nothing in the above comments is new. Do we really need/want to rehash this again? Thanks, Phil From andy@netconfcentral.com Fri May 8 08:27: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 4331228C16A for ; Fri, 8 May 2009 08:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 wJbiAXcqg1as for ; Fri, 8 May 2009 08:27:45 -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 40F2C3A7009 for ; Fri, 8 May 2009 08:27:44 -0700 (PDT) Received: from [68.142.200.224] by n24.bullet.mail.mud.yahoo.com with NNFMP; 08 May 2009 15:29:07 -0000 Received: from [68.142.201.245] by t5.bullet.mud.yahoo.com with NNFMP; 08 May 2009 15:29:07 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 08 May 2009 15:29:06 -0000 X-Yahoo-Newman-Id: 983143.53993.bm@omp406.mail.mud.yahoo.com Received: (qmail 91905 invoked from network); 8 May 2009 15:29:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2009 15:29:05 -0000 X-YMail-OSG: 3OhkcwAVM1ml5CzqiURZRameE567zTpTiqb7NbAnz7zzguns1oS97ZQXQvAi27Qg4T8QlGCrS21aSA96OH.fdIyCJXvQZFLXoUU.YUpd.dtsfHyucN8IQtMk9mjrgEdNB1T2SBXKFsoffunAyfX1y8FcSNK4EnAbc1QlktQKjsVZX9ufuX3yCCt4Q9cTtFUSMhD5v7WTA67RhU3x2OyWBTo6BfQddIED55ENdVwad0xLwKRtaqWIkoyLhwBSynbhfV5dTxJ6GEdJCEo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A044FBF.6000103@netconfcentral.com> Date: Fri, 08 May 2009 08:29:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905081316.n48DGYp0003973@idle.juniper.net> In-Reply-To: <200905081316.n48DGYp0003973@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 08 May 2009 15:27:46 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The point of a standard data modeling language is to >> provide a set of constructs that will be implemented >> consistently across all devices and tools. That means, >> given the same YANG module (in isolation), two independent >> implementations should agree on the validity of that module. > > And the point of deviations is to admit that, for a variety of > reasons, the constructs detailed in a standard module cannot be > implemented consistently across all devices. > > Historically, an implementation that is not able to fully implement > that standard has two choices: (a) don't implement that standard, > or (b) lie and say they implement the full standard, fudging input > and output when needed. Given marketing/customer/plm pressures, > (a) may not be an option. If the device support 99% of the standard, > lying about the one bit that cannot be implemented may well be the > lesser of two evils. > > Deviations give implementations a third option, allowing them to > detail the places where they fail to fully implement the standard. > This in no way reduces the need to push for interoperability by > maximizing the ability of an implementation to fully statisfy the > constraints of the standard, but by allowing the truth to be known, > applications can better deal with implementations that aren't fully > compliant. > > So interoperability does not benefit from implementations that > deviate from the standard, but interoperability _does_ benefit from > allowing implementations to express (and applications to intergrate > the knowledge of) the places where the standard has not been fully > implemented. > > We've not encouraging deviations, but we are wise enough to admit > that they occur and should not be ignored. > > The working group has repeatedly decided that this feature is useful > and worthwhile. Nothing in the above comments is new. Do we really > need/want to rehash this again? > You misunderstood my point. I am not trying to remove deviations-stmt. Every single language construct in YANG must be implementable in a manner that will allow data modelers to reuse their YANG files in different tool-sets. Every compliant YANG tool should be able to agree that a specific YANG file contains well-formed YANG. But arbitrary combinations of deviation modules can result in invalid YANG. Unless 2 validation tools use the same YANG files, the results will not likely be the same. The section on deviations needs to have some text that explains that tools MAY require that the 'deviations modules' be specified at YANG module compile time, since they cannot be easily identified any other way. > Thanks, > Phil > > Andy From phil@juniper.net Fri May 8 10:06: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 F32AE3A6BED for ; Fri, 8 May 2009 10:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 YgTBUvLrSkem for ; Fri, 8 May 2009 10:06:38 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 731B73A6CC2 for ; Fri, 8 May 2009 10:06:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSgRm0/i7G2qij6AaTDpyB1E8Q2Y0WXfZ@postini.com; Fri, 08 May 2009 10:07:41 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, 8 May 2009 10:01:09 -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, 8 May 2009 10:01:09 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 10:01:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 10:01:07 -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 n48H16L01396; Fri, 8 May 2009 10:01:06 -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 n48Gouwg005903; Fri, 8 May 2009 16:50:56 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905081650.n48Gouwg005903@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A044FBF.6000103@netconfcentral.com> Date: Fri, 8 May 2009 12:50:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 May 2009 17:01:07.0572 (UTC) FILETIME=[946F1340:01C9CFFE] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 08 May 2009 17:06:39 -0000 Andy Bierman writes: >The section on deviations needs to have some text that explains >that tools MAY require that the 'deviations modules' be specified >at YANG module compile time, since they cannot be easily >identified any other way. Do we need to specify what tools may or may not need? This will vary among tool chains, and isn't constant nor part of the language. Thanks, Phil From andy@netconfcentral.com Fri May 8 10:56: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 85BEA3A6F81 for ; Fri, 8 May 2009 10:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, GB_I_LETTER=-2, 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 ylaDQllqwVA2 for ; Fri, 8 May 2009 10:56:19 -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 E28F93A6ED3 for ; Fri, 8 May 2009 10:56:02 -0700 (PDT) Received: (qmail 66658 invoked from network); 8 May 2009 17:57:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2009 17:57:28 -0000 X-YMail-OSG: efGe_WcVM1m1sozy4UsbMFBbcGS.ZgHXKgiMpZGSodo4ExEDUoG_2zD90NEMV7DOEme4KqqV6zUNgxOkhFlFwj82Twk3tZt1PlmQJ9L8G0a6WvIy2Pi5XvEV6eA5A8ChqjtZ1zFD8Fjr.oSpSvqhFhj2AR3bO_5AXnHbc5UTo.oJ6kwJ24KuJHiLTKjKM03jwEDfqUX8Uoe79cWmxWD3Z8OxLozhDd22ZnjCqWekEvk0eGYbIAeS1jtvbGqe2.p16aQes4iTWDkDBZXTCsiIG52c5PFDXw9WGxx3uwMTrL_KOugY7Kk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A047286.90004@netconfcentral.com> Date: Fri, 08 May 2009 10:57:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905081650.n48Gouwg005903@idle.juniper.net> In-Reply-To: <200905081650.n48Gouwg005903@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 08 May 2009 17:56:20 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The section on deviations needs to have some text that explains >> that tools MAY require that the 'deviations modules' be specified >> at YANG module compile time, since they cannot be easily >> identified any other way. > > Do we need to specify what tools may or may not need? This will > vary among tool chains, and isn't constant nor part of the language. > Don't we already do that by declaring that XML order does not matter at all, except for a couple corner-cases that are specifically intended to allow implementations to use a non-buffering design? The "keys MUST be encoded first" CLR isn't part of the language either. There is a presumption that this is so important to tools, that all managers and all agents MUST special code this little rule. (BTW, what is the error code that the agent is supposed to return? "YANG-forced-reject-of-valid-XML" ;-) I suspect that market forces will weed out any lame implementations, but it is always frustrating to consumers of a standard when implementors of the standard do very different things and all claim to be following the standard to the letter. > Thanks, > Phil > Andy From phil@juniper.net Fri May 8 11:19: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 BC1C13A68AE for ; Fri, 8 May 2009 11:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 2OtHhWtrCqVG for ; Fri, 8 May 2009 11:19:01 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 0479E3A693F for ; Fri, 8 May 2009 11:18:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSgR35pLo1kTstet2MppQEYa1GcfvGJmT@postini.com; Fri, 08 May 2009 11:20:30 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, 8 May 2009 11:14:24 -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, 8 May 2009 11:14:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 11:14:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 11:14:23 -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 n48IEML48129; Fri, 8 May 2009 11:14:22 -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 n48I4GJt006537; Fri, 8 May 2009 18:04:17 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905081804.n48I4GJt006537@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A047286.90004@netconfcentral.com> Date: Fri, 8 May 2009 14:04:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 May 2009 18:14:23.0147 (UTC) FILETIME=[D06697B0:01C9D008] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 08 May 2009 18:19:01 -0000 Andy Bierman writes: >Don't we already do that by declaring that XML order >does not matter at all, except for a couple corner-cases >that are specifically intended to allow implementations >to use a non-buffering design? Nope, this part of the spec refers to over-the-wire behavior, which belongs in the spec. Saying that some tool chains may need deviations at compile time .vs. run time is strictly a tools issue. Thanks, Phil From andy@netconfcentral.com Fri May 8 11:27: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 0E6D43A6D15 for ; Fri, 8 May 2009 11:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.032, 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 Zjf57NMKKoYl for ; Fri, 8 May 2009 11:27:36 -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 64AA03A67DA for ; Fri, 8 May 2009 11:27:36 -0700 (PDT) Received: (qmail 56229 invoked from network); 8 May 2009 18:29:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2009 18:29:02 -0000 X-YMail-OSG: UybY9rEVM1l8wHY8qgmBU.0kejwa7YATIZsvKqi03ZjkiMBDjKtFtlt43BIeoFGb8ESiM5Ax_o1xcWlavgohckHuuP6sckLThyw.PpuLluw.j8F._sbc3kINiqlcJDOwLE1_Akg6qlqAfku8Zl6h_3ZUfIigfmxiMFWTRIOcN9WalBO9o2oAZoabE1FWMMNHZnjHn6r7qMWG.3BgGjsQ8uljKNTcxS39bzonhY29Y4jO1A.XrMvcXTmDYwD9FcnAHxVrGw4qAFPqnw8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0479EC.3050305@netconfcentral.com> Date: Fri, 08 May 2009 11:29:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905081804.n48I4GJt006537@idle.juniper.net> In-Reply-To: <200905081804.n48I4GJt006537@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 08 May 2009 18:27:37 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Don't we already do that by declaring that XML order >> does not matter at all, except for a couple corner-cases >> that are specifically intended to allow implementations >> to use a non-buffering design? > > Nope, this part of the spec refers to over-the-wire behavior, > which belongs in the spec. Saying that some tool chains may > need deviations at compile time .vs. run time is strictly a > tools issue. > OK. The reason I agree with you is that we already have optional import/include by revision. This is so extremely implementation-dependent that there is little chance that 2 tool-chains will find the same version (if more than 1 exists) unless the revision date is specified. Since nobody seems to actually use revision dates in their import-stmts, this will become a real problem. It is fixed by relying on out-of-scope configuration parameters for the YANG tools themselves. (What irony :-) Since we are currently on version 1 of everything, this is not a problem yet. > Thanks, > Phil > > Andy From mbj@tail-f.com Fri May 8 12:24: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 E79843A6D57 for ; Fri, 8 May 2009 12:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.193, 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 EPyVWFu3bHp4 for ; Fri, 8 May 2009 12:24: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 2A6563A6D2F for ; Fri, 8 May 2009 12:24: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 DE66E616012; Fri, 8 May 2009 21:25:57 +0200 (CEST) Date: Fri, 08 May 2009 21:25:57 +0200 (CEST) Message-Id: <20090508.212557.59490846.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A0479EC.3050305@netconfcentral.com> References: <200905081804.n48I4GJt006537@idle.juniper.net> <4A0479EC.3050305@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] WGLC comments on deviation-stmt 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, 08 May 2009 19:24:31 -0000 Andy Bierman wrote: > The reason I agree with you is that we already have > optional import/include by revision. This is so > extremely implementation-dependent How do you mean? If you import/include by revision there is no doubt which module you're importing/including. If you *don't* use this optional feature, things are unclear. Maybe you augement something in the module you import, but the object you augment was added in version 2 of the module. that there is > little chance that 2 tool-chains will find the > same version (if more than 1 exists) unless the > revision date is specified. Since nobody seems to > actually use revision dates in their import-stmts, > this will become a real problem. It is fixed > by relying on out-of-scope configuration parameters > for the YANG tools themselves. (What irony :-) > > Since we are currently on version 1 of everything, > this is not a problem yet. > > > > Thanks, > > Phil > > > > Andy > From mbj@tail-f.com Fri May 8 12:28: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 BA3F728C115 for ; Fri, 8 May 2009 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.191, 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 mUwW8UBlpEhs for ; Fri, 8 May 2009 12:28: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 0A3D23A7134 for ; Fri, 8 May 2009 12:28:23 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 960EE616012; Fri, 8 May 2009 21:29:51 +0200 (CEST) Date: Fri, 08 May 2009 21:29:51 +0200 (CEST) Message-Id: <20090508.212951.224339624.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A0479EC.3050305@netconfcentral.com> References: <200905081804.n48I4GJt006537@idle.juniper.net> <4A0479EC.3050305@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] WGLC comments on deviation-stmt 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, 08 May 2009 19:28:23 -0000 [resend - I accidentally hit send too early] Andy Bierman wrote: > The reason I agree with you is that we already have > optional import/include by revision. This is so > extremely implementation-dependent How do you mean? If you import/include by revision there is no doubt which module you're importing/including. What exactly is implementation-dependent? If you *don't* use this optional feature, things are unclear. Maybe module A augements something in the imported module B, but the object module A augments was added in version 2 of module B. Unless module A imports B revision, one tool set might give an error, and another tool might say it is ok. But as has been said before, there are use cases where you do want import without revision (IANAifType-MIB e.g.) /martin From andy@netconfcentral.com Fri May 8 12:57: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 A59773A6D76 for ; Fri, 8 May 2009 12:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.032, 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 5H5sTMQK2e85 for ; Fri, 8 May 2009 12:57:35 -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 E49583A6C44 for ; Fri, 8 May 2009 12:57:35 -0700 (PDT) Received: (qmail 93842 invoked from network); 8 May 2009 19:59:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2009 19:59:02 -0000 X-YMail-OSG: LhyOcXYVM1lEN0Grv3trDZz_6bVYmPROVAzo.nEif0UHUHBgsq.dKk0p96bJ.Qd.5hpa.QEEq6UWcqyvZ.86HY.KZvcr_Ov7hvLrbHu25ECknyH_qGJGhcjWGiN31_EwFmIwmunvljpEBY.DX2gmu0BktL22lzrG_n1HmCP6wGCO1B0VHU900ate8u0MKOxgYTWmcyuy2URt7ST5GLEuV2cwuTLUHdAh0GLqkVhE_gveEYHkzVILZgQgewmalauZ5O1vbNg4k7eO9LCNhkcdcQJKDs.GNqhCGf4weGaiAqrd9cFPYRGEUyYDDwyUybv03bWGqBiTGa4i X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A048F04.10205@netconfcentral.com> Date: Fri, 08 May 2009 12:59:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <200905081804.n48I4GJt006537@idle.juniper.net> <4A0479EC.3050305@netconfcentral.com> <20090508.212951.224339624.mbj@tail-f.com> In-Reply-To: <20090508.212951.224339624.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] WGLC comments on deviation-stmt 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, 08 May 2009 19:57:36 -0000 Martin Bjorklund wrote: > [resend - I accidentally hit send too early] > > Andy Bierman wrote: >> The reason I agree with you is that we already have >> optional import/include by revision. This is so >> extremely implementation-dependent > > How do you mean? If you import/include by revision there is no doubt > which module you're importing/including. What exactly is > implementation-dependent? If you *don't* use this optional feature, > things are unclear. Maybe module A augements something in the > imported module B, but the object module A augments was added in > version 2 of module B. Unless module A imports B revision, one tool > set might give an error, and another tool might say it is ok. > > But as has been said before, there are use cases where you do want > import without revision (IANAifType-MIB e.g.) > I do not believe import-any-revision will be used only in this special case. It seems to be used this way every time. Maybe that will change as YANG stabilizes. If external files (imports/includes) are used without a revision-date (very common practice) then it is completely up to the tool implementation what file will actually be found to match the import or include. Since we are comfortable with this very basic level of tool-specific behavior for an issue that shows up almost 100% of the time, then we should also accept the 1% corner-cases that show up wrt/ deviation-stmt. > > /martin > > Andy From andy@netconfcentral.com Fri May 8 13:48: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 0AA533A6CDC for ; Fri, 8 May 2009 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 QC-u-H9NxNfj for ; Fri, 8 May 2009 13:48:56 -0700 (PDT) Received: from n23a.bullet.mail.mud.yahoo.com (n23a.bullet.mail.mud.yahoo.com [68.142.207.189]) by core3.amsl.com (Postfix) with SMTP id 2B6193A69F1 for ; Fri, 8 May 2009 13:48:56 -0700 (PDT) Received: from [68.142.200.224] by n23.bullet.mail.mud.yahoo.com with NNFMP; 08 May 2009 20:50:21 -0000 Received: from [68.142.201.66] by t5.bullet.mud.yahoo.com with NNFMP; 08 May 2009 20:50:21 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 08 May 2009 20:50:21 -0000 X-Yahoo-Newman-Id: 675814.20477.bm@omp418.mail.mud.yahoo.com Received: (qmail 51552 invoked from network); 8 May 2009 20:50:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2009 20:50:20 -0000 X-YMail-OSG: y_XjIRsVM1lluOUyEzwa49H4FPSp2jFEg5nNrz7Zjm2wkZarWhr2tKav4SaeIu0GEBzxJjHvL7wAGFuyA5wTkcMFzRY1vOF0IYTaahtpkcSHj2BzSs1x5BUqhvk81JEp4_3Vt9yCATeopyHiZTH7BPPEH9M0s3cv8iVKe0B9pHsj3t53oeOqUofxbsYxmee.15GCeuPAJCPp5r.5jmo.nuFgIqrSBoicc9iPepmP_Ue3YtbXy1YpT9GeCiSZq32FMe_ra35HU9smH.o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A049B0A.8060406@netconfcentral.com> Date: Fri, 08 May 2009 13:50:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A0322B1.4050006@joelhalpern.com> In-Reply-To: <4A0322B1.4050006@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Confusion about mandatory 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, 08 May 2009 20:48:57 -0000 Joel M. Halpern wrote: > While reading the YANG document again, I have managed to confuse myself > about the effect of "Mandatory". > > In the absence of choice: > I am left unsure as to whether the text in 7.6.4 on the non-choice > effects of "mandatory" are clear, or correct. > Must there always be something that is not a "non-presence container" > above the leaf in the tree? Does the module or submodule count for this > purpose? > Presumably, all intermediate containers between the leaf and the > selected ancestor must also exist if the leaf is forced to exist? > I see what you mean. Sec. 7.6.4 para 2 does not account for a leaf defined at the top-level of a [sub]module. It only talks about ancestor nodes, and there are none in this case. > In the presence of choice, > suppose that the only element of the choice is a non-presence container. > Presumably, if that non-presence container is created, because that is > which branch of the choice is being taken, then the leaf must exist. > (i.e. if the leaf has siblings in the container, but no other nodes > exist in this case?) > This has been a recent topic... An empty NP-container MAY get deleted by the agent. If mandatory is true on the choice, then this leads to a error every time the manager explicitly creates the empty NP container, but only if the agent deletes the empty container. If the agent keeps it, then it will not be an error (just a no-op). Lada raised this issue as well. He is not comfortable with the garbage-in/garbage-out explanation I came up with -- a choice with just an NP container doesn't do anything. It needs child nodes, either direct or via augment, to have any semantics. It's the word 'MAY' above that is causing concern I think. A manager does not know what the agent will do with the empty NP container a-priori. > Joel Andy From jmh@joelhalpern.com Fri May 8 14:08: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 D51C23A6D21 for ; Fri, 8 May 2009 14:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 peyqiBtXyW-D for ; Fri, 8 May 2009 14:08:31 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0BBB83A6CEA for ; Fri, 8 May 2009 14:08:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 414A043044E for ; Fri, 8 May 2009 14:10:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AF9F5430440 for ; Fri, 8 May 2009 14:09:59 -0700 (PDT) Message-ID: <4A049FA4.8050303@joelhalpern.com> Date: Fri, 08 May 2009 17:09:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group References: <4A0322B1.4050006@joelhalpern.com> <4A049B0A.8060406@netconfcentral.com> In-Reply-To: <4A049B0A.8060406@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Confusion about mandatory 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, 08 May 2009 21:08:31 -0000 Andy, thanks for responding. Comment below on the choice issue (and a little more on the general issue of no containing presence container): Andy Bierman wrote: > Joel M. Halpern wrote: >> While reading the YANG document again, I have managed to confuse >> myself about the effect of "Mandatory". >> >> In the presence of choice, >> suppose that the only element of the choice is a non-presence >> container. Presumably, if that non-presence container is created, >> because that is which branch of the choice is being taken, then the >> leaf must exist. (i.e. if the leaf has siblings in the container, but >> no other nodes exist in this case?) >> > > This has been a recent topic... > An empty NP-container MAY get deleted by the agent. > > If mandatory is true on the choice, then this leads to > a error every time the manager explicitly creates the > empty NP container, but only if the agent deletes > the empty container. If the agent keeps it, then > it will not be an error (just a no-op). > > Lada raised this issue as well. > He is not comfortable with the garbage-in/garbage-out > explanation I came up with -- a choice with just > an NP container doesn't do anything. It needs > child nodes, either direct or via augment, to > have any semantics. > > It's the word 'MAY' above that is causing concern I think. > A manager does not know what the agent will do with > the empty NP container a-priori. > >> Joel > > Andy Let us suppose that the choice is not itself mandatory. And that one of the cases is a single NP container (X), which further inside has a mandatory leaf. Presumably, the intent is that if X is created, the mandatory buried (possibly via other NP containers) inside it must be created. But the description for the logic for when a Mandatory element must be created talks only about creation of a presence container, or about creation of a peer element in a case (within a choice.) There is no peer in the case. And there is no P-container. In trying to understand this, I am pretty sure that the point of the condition was the converse. If the containing choice is not exercising the case that has the mandatory element, then it does not need to be created. And similarly, if the mandatory element is in a presence container then it only has to exist when the presence container itself exists. (But intermediate NP containers do not mask this.) The text however seems to not deal with the other cases that can occur (no NP between the mandatory leaf and the root, no peer in the case.) I would not be surprised if this relates in part to assumptions about when presence needs to be used. But I am unable to deduce those assumptions from the text. Joel From andy@netconfcentral.com Fri May 8 14:40: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 5A0F43A6B23 for ; Fri, 8 May 2009 14:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 EqWvu8gvw3iU for ; Fri, 8 May 2009 14:40:12 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id D48DA3A7047 for ; Fri, 8 May 2009 14:40:10 -0700 (PDT) Received: from [68.142.200.224] by n14.bullet.mail.mud.yahoo.com with NNFMP; 08 May 2009 21:41:38 -0000 Received: from [68.142.201.248] by t5.bullet.mud.yahoo.com with NNFMP; 08 May 2009 21:41:38 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 08 May 2009 21:41:38 -0000 X-Yahoo-Newman-Id: 279442.39472.bm@omp409.mail.mud.yahoo.com Received: (qmail 48697 invoked from network); 8 May 2009 21:41:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2009 21:41:36 -0000 X-YMail-OSG: QNcXpfAVM1mYY0VZ0E5q4ZW3zY6hotoJL4jOJa45GH7Lbu00nG4ra09bCKL3tZlVZtG5MBsVWmLclrOpVucCB0QoJwqZxEYQf9lkRZ8Rb1C9WnsCBAVPhn2TB.8erzCnRYTpY.P797iXnTlfpy87PWseM6Mvpd5Isjs25e_5iwIzaTx4RJqGjG2KmwRAN3nfuLGK3cUc_7Av7VIM0yMBahfzkvnvGYF22IDBy3ZNrWzYJ2KRypIRNXY6Vd5J97ENTgZAg232.S4UBeE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A04A70F.5030102@netconfcentral.com> Date: Fri, 08 May 2009 14:41:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A0322B1.4050006@joelhalpern.com> <4A049B0A.8060406@netconfcentral.com> <4A049FA4.8050303@joelhalpern.com> In-Reply-To: <4A049FA4.8050303@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Confusion about mandatory 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, 08 May 2009 21:40:13 -0000 Joel M. Halpern wrote: > Andy, thanks for responding. > Comment below on the choice issue (and a little more on the general > issue of no containing presence container): > > Andy Bierman wrote: >> Joel M. Halpern wrote: >>> While reading the YANG document again, I have managed to confuse >>> myself about the effect of "Mandatory". >>> > >>> In the presence of choice, >>> suppose that the only element of the choice is a non-presence >>> container. Presumably, if that non-presence container is created, >>> because that is which branch of the choice is being taken, then the >>> leaf must exist. (i.e. if the leaf has siblings in the container, but >>> no other nodes exist in this case?) >>> >> >> This has been a recent topic... >> An empty NP-container MAY get deleted by the agent. >> >> If mandatory is true on the choice, then this leads to >> a error every time the manager explicitly creates the >> empty NP container, but only if the agent deletes >> the empty container. If the agent keeps it, then >> it will not be an error (just a no-op). >> >> Lada raised this issue as well. >> He is not comfortable with the garbage-in/garbage-out >> explanation I came up with -- a choice with just >> an NP container doesn't do anything. It needs >> child nodes, either direct or via augment, to >> have any semantics. >> >> It's the word 'MAY' above that is causing concern I think. >> A manager does not know what the agent will do with >> the empty NP container a-priori. >> >>> Joel >> >> Andy > > Let us suppose that the choice is not itself mandatory. > And that one of the cases is a single NP container (X), which further > inside has a mandatory leaf. > Presumably, the intent is that if X is created, the mandatory buried > (possibly via other NP containers) inside it must be created. > But the description for the logic for when a Mandatory element must be > created talks only about creation of a presence container, or about > creation of a peer element in a case (within a choice.) There is no > peer in the case. And there is no P-container. > Apparently, implementing YANG is the only way to overcome the confusion. ;-) The NP-container becomes mandatory when it has mandatory nodes defined within it. There is a CLR preventing augment from adding mandatory nodes. A sibling (or top-level) NP-container springs into existence if it contains child nodes which are default leafs or default cases. The mandatory property of child nodes within an NP-container is inherited, but it is not inherited for P-containers. The mandatory-stmt is not allowed for containers, so this is always inherited for NP-containers. P-containers must always be created explicitly by the manager (although I think default-case should be allowed for empty P-containers). Two of the biggest sources of confusion in YANG are choices and containers. * choice and case exist only in the schema tree, never in the XML, so they are transparent wrt/ naming, but they affect the actual XML that can be present (by grouping properties of siblings), which is confusing * NP containers exist in the XML, but unlike choice/case, they are transparent wrt/ YANG properties, which is confusing > In trying to understand this, I am pretty sure that the point of the > condition was the converse. If the containing choice is not exercising > the case that has the mandatory element, then it does not need to be > created. Yes. I think the section on choice-stmt says that somewhere. Only 1 case is 'visible' at a time. Unselected cases are completely ignored. Selecting a new case deletes all the members of the old case. The when-stmt XPath expression can change everything of course. It is especially interesting if false 'when nodes' exist in the choice and the order nodes are created may impact the XPath evaluation results (but I digress...) > > And similarly, if the mandatory element is in a presence container then > it only has to exist when the presence container itself exists. (But > intermediate NP containers do not mask this.) > > The text however seems to not deal with the other cases that can occur > (no NP between the mandatory leaf and the root, no peer in the case.) > > I would not be surprised if this relates in part to assumptions about > when presence needs to be used. But I am unable to deduce those > assumptions from the text. > I agree the text could be more clear about all the aspects of the mandatory property. Maybe some examples would help. > Joel > Andy From jmh@joelhalpern.com Fri May 8 15:22: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 40C703A68EA for ; Fri, 8 May 2009 15:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 G29gYW0LNFLo for ; Fri, 8 May 2009 15:22:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 35DCF3A6830 for ; Fri, 8 May 2009 15:22:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 734EE43400E for ; Fri, 8 May 2009 15:23:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A62AD434003 for ; Fri, 8 May 2009 15:23:49 -0700 (PDT) Message-ID: <4A04B0F2.2090501@joelhalpern.com> Date: Fri, 08 May 2009 18:23:46 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group References: <4A0322B1.4050006@joelhalpern.com> <4A049B0A.8060406@netconfcentral.com> <4A049FA4.8050303@joelhalpern.com> <4A04A70F.5030102@netconfcentral.com> In-Reply-To: <4A04A70F.5030102@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Confusion about mandatory 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, 08 May 2009 22:22:22 -0000 After this discussion, I am pretty sure that the text in 7.6.4 about the effect of the leaf's mandatory statement is at best misleading, and possibly just flat wrong. As written, if there is no P-container or choice ancestor, there is no time when the leaf must exist. Also as written, if the nearest choice or P-container ancestor is a choice in which the specific case leading to this leaf does not have "any other node from the case" defined (presumably meaning any one other than the one leading to the leaf?) The following is probably not the right text, but is intended to capture what I think is intended: If we call leaf's closest ancestor with is no a non-presence container the "relevant parent", then if the relevant parent exists, or any container between the leaf and the relevant parent exists, the leaf must exist. In the absence of a relevant parent, the existence of any container between the leaf and the root means that the leaf must exist. Further, if the relevant parent is a choice, then the leaf must exist if either the container in the case containing the leaf exists, or if any other node in the same case with that container exists. Joel Andy Bierman wrote: > Joel M. Halpern wrote: >> Andy, thanks for responding. >> Comment below on the choice issue (and a little more on the general >> issue of no containing presence container): >> >> Andy Bierman wrote: >>> Joel M. Halpern wrote: >>>> While reading the YANG document again, I have managed to confuse >>>> myself about the effect of "Mandatory". >>>> >> >>>> In the presence of choice, >>>> suppose that the only element of the choice is a non-presence >>>> container. Presumably, if that non-presence container is created, >>>> because that is which branch of the choice is being taken, then the >>>> leaf must exist. (i.e. if the leaf has siblings in the container, >>>> but no other nodes exist in this case?) >>>> >>> >>> This has been a recent topic... >>> An empty NP-container MAY get deleted by the agent. >>> >>> If mandatory is true on the choice, then this leads to >>> a error every time the manager explicitly creates the >>> empty NP container, but only if the agent deletes >>> the empty container. If the agent keeps it, then >>> it will not be an error (just a no-op). >>> >>> Lada raised this issue as well. >>> He is not comfortable with the garbage-in/garbage-out >>> explanation I came up with -- a choice with just >>> an NP container doesn't do anything. It needs >>> child nodes, either direct or via augment, to >>> have any semantics. >>> >>> It's the word 'MAY' above that is causing concern I think. >>> A manager does not know what the agent will do with >>> the empty NP container a-priori. >>> >>>> Joel >>> >>> Andy >> >> Let us suppose that the choice is not itself mandatory. >> And that one of the cases is a single NP container (X), which further >> inside has a mandatory leaf. >> Presumably, the intent is that if X is created, the mandatory buried >> (possibly via other NP containers) inside it must be created. >> But the description for the logic for when a Mandatory element must be >> created talks only about creation of a presence container, or about >> creation of a peer element in a case (within a choice.) There is no >> peer in the case. And there is no P-container. >> > > Apparently, implementing YANG is the only way > to overcome the confusion. ;-) > > The NP-container becomes mandatory when it has > mandatory nodes defined within it. There is a CLR > preventing augment from adding mandatory nodes. > > A sibling (or top-level) NP-container springs > into existence if it contains child nodes which > are default leafs or default cases. > The mandatory property of child nodes within an > NP-container is inherited, but it is not inherited > for P-containers. The mandatory-stmt is not > allowed for containers, so this is always inherited > for NP-containers. P-containers must always be created > explicitly by the manager (although I think default-case > should be allowed for empty P-containers). > > Two of the biggest sources of confusion in YANG are > choices and containers. > > * choice and case exist only in the schema tree, > never in the XML, so they are transparent > wrt/ naming, but they affect the actual XML that > can be present (by grouping properties of siblings), > which is confusing > > * NP containers exist in the XML, but unlike choice/case, > they are transparent wrt/ YANG properties, which is confusing > > >> In trying to understand this, I am pretty sure that the point of the >> condition was the converse. If the containing choice is not >> exercising the case that has the mandatory element, then it does not >> need to be created. > > Yes. I think the section on choice-stmt says that somewhere. > Only 1 case is 'visible' at a time. Unselected cases > are completely ignored. Selecting a new case deletes > all the members of the old case. > > The when-stmt XPath expression can change everything of course. > It is especially interesting if false 'when nodes' exist in > the choice and the order nodes are created may impact the > XPath evaluation results (but I digress...) > > >> >> And similarly, if the mandatory element is in a presence container >> then it only has to exist when the presence container itself exists. >> (But intermediate NP containers do not mask this.) >> >> The text however seems to not deal with the other cases that can occur >> (no NP between the mandatory leaf and the root, no peer in the case.) >> >> I would not be surprised if this relates in part to assumptions about >> when presence needs to be used. But I am unable to deduce those >> assumptions from the text. >> > > I agree the text could be more clear about all > the aspects of the mandatory property. Maybe > some examples would help. > > >> Joel >> > > > Andy > > > From mbj@tail-f.com Sun May 10 12:30: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 0CE223A6D31 for ; Sun, 10 May 2009 12:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-0.555, 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 2UvVCTexi852 for ; Sun, 10 May 2009 12:30:05 -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 F41623A6A19 for ; Sun, 10 May 2009 12:30:04 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 919EC61601E; Sun, 10 May 2009 21:31:31 +0200 (CEST) Date: Sun, 10 May 2009 21:31:31 +0200 (CEST) Message-Id: <20090510.213131.167455790.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A0322B1.4050006@joelhalpern.com> References: <4A0322B1.4050006@joelhalpern.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] Confusion about mandatory 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, 10 May 2009 19:30:06 -0000 Hi Joel, I will reply to your first and last emails in one go: "Joel M. Halpern" wrote: > While reading the YANG document again, I have managed to confuse > myself about the effect of "Mandatory". > > In the absence of choice: > I am left unsure as to whether the text in 7.6.4 on the non-choice > effects of "mandatory" are clear, or correct. > Must there always be something that is not a "non-presence container" > above the leaf in the tree? Does the module or submodule count for > this purpose? No you are right. Text is missing about this case - if the mandatory leaf is on the top-level (or it only has np-containers above itself) then it must always exist. > In the presence of choice, > suppose that the only element of the choice is a non-presence > container. Presumably, if that non-presence container is created, > because that is which branch of the choice is being taken, then the > leaf must exist. (i.e. if the leaf has siblings in the container, but > no other nodes exist in this case?) Let's look at an example: choice x { container a { leaf b { mandatory true; ... } leaf c { mandatory false; ... } leaf d { mandatory false; ... } } ... } The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. As Andy wrote, an np-container is transparent to the leafs, so if we modify the example a bit: choice x { container a { leaf b { mandatory true; ... } container cc { leaf c { mandatory false; ... } } container dd { leaf d { mandatory false; ... } } } ... } Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. > As written, if there is no P-container or choice ancestor, there is no > time when the leaf must exist. Yes, this must be fixed. > Also as written, if the nearest choice or P-container ancestor is a > choice in which the specific case leading to this leaf does not have > "any other node from the case" defined (presumably meaning any one > other than the one leading to the leaf?) I don't understand this concern. I think a 'then' clause is missing from your 'if' above... > The following is probably not the right text, but is intended to > capture what I think is intended: > > If we call leaf's closest ancestor with is no a non-presence container > the "relevant parent", then if the relevant parent exists, or any > container between the leaf and the relevant parent exists, the leaf > must exist. s/or any container between the leaf and the relevant parent exists// ...since such a container by definition must be a np-container, and they are transparent. > In the absence of a relevant parent, the existence of any > container between the leaf and the root means that the leaf must > exist. Again, since such a container must be a np-container, this should be: In the absence of a relevant parent, the leaf must exist. > Further, if the relevant parent is a choice, then the leaf must exist > if either the container in the case containing the leaf exists, or if > any other node in the same case with that container exists. I believe the text in 7.6.4 is correct in this case: If this ancestor is a case node, the leaf MUST exist if any other node from the case exists. So, I believe the only fix we need is the text about the leaf on the top-level. /martin From andy@netconfcentral.com Sun May 10 12:39: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 39BD93A6CEC for ; Sun, 10 May 2009 12:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.028, 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 0nVkmgl7C7XP for ; Sun, 10 May 2009 12:39:55 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 7FCEA3A6A19 for ; Sun, 10 May 2009 12:39:55 -0700 (PDT) Received: (qmail 41106 invoked from network); 10 May 2009 19:41:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 10 May 2009 19:41:22 -0000 X-YMail-OSG: bgZeqQ0VM1lWOtFugCRnsbFnp93ggDvVnJZHPNPVPxpaWUtDbKKL4D65tbDPT7rUdtz4HX06fO.fYJzHPp_RT44HOvcvEm2Spi2S9hlmLGgRFiqwEymY7OTWvmq0KBpdXmKl6IAGw5ADag77.Kd8X0oOCQZOQwUTJtS1FdiEjn7fzJsIi3U_Xsv2_16HNdB0rjZBxSLteB2LXGKem1n7ZGjzonBppOqrIcjA5V1yLqIFJeRo.9Y4E6CUdJgGSFak9vCelu4Yy7ulLbseGJ2v_0PJKYgs2kusoNd4vNN8MotOUTiUxR44F0rd.rS_URWpKtWXqVc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A072DE0.8050307@netconfcentral.com> Date: Sun, 10 May 2009 12:41:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A0322B1.4050006@joelhalpern.com> <20090510.213131.167455790.mbj@tail-f.com> In-Reply-To: <20090510.213131.167455790.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] Confusion about mandatory 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, 10 May 2009 19:39:56 -0000 Martin Bjorklund wrote: > Hi Joel, > > I will reply to your first and last emails in one go: > > "Joel M. Halpern" wrote: >> While reading the YANG document again, I have managed to confuse >> myself about the effect of "Mandatory". >> >> In the absence of choice: >> I am left unsure as to whether the text in 7.6.4 on the non-choice >> effects of "mandatory" are clear, or correct. >> Must there always be something that is not a "non-presence container" >> above the leaf in the tree? Does the module or submodule count for >> this purpose? > > No you are right. Text is missing about this case - if the mandatory > leaf is on the top-level (or it only has np-containers above itself) > then it must always exist. > >> In the presence of choice, >> suppose that the only element of the choice is a non-presence >> container. Presumably, if that non-presence container is created, >> because that is which branch of the choice is being taken, then the >> leaf must exist. (i.e. if the leaf has siblings in the container, but >> no other nodes exist in this case?) > > Let's look at an example: > > choice x { > container a { > leaf b { mandatory true; ... } > leaf c { mandatory false; ... } > leaf d { mandatory false; ... } > } > ... > } > > The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. > > As Andy wrote, an np-container is transparent to the leafs, so if we > modify the example a bit: > > choice x { > container a { > leaf b { mandatory true; ... } > container cc { > leaf c { mandatory false; ... } > } > container dd { > leaf d { mandatory false; ... } > } > } > ... > } > > Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. > I implemented this differently. According to the draft -- I think. If /a exists, then all the child nodes of /a will be 'instance-checked'. That way, if /a is given in a create request, it will fail because /a/b is missing. This corner-case has nothing to do with the siblings of 'b'. .... > > /martin Andy From mbj@tail-f.com Sun May 10 12:59: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 14F4B3A6EF3 for ; Sun, 10 May 2009 12:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.195, 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 MdC+8P7OdiMI for ; Sun, 10 May 2009 12:59:22 -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 07FF33A6C6C for ; Sun, 10 May 2009 12:59: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 0F03A61601E; Sun, 10 May 2009 22:00:52 +0200 (CEST) Date: Sun, 10 May 2009 22:00:51 +0200 (CEST) Message-Id: <20090510.220051.123480027.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A072DE0.8050307@netconfcentral.com> References: <4A0322B1.4050006@joelhalpern.com> <20090510.213131.167455790.mbj@tail-f.com> <4A072DE0.8050307@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] Confusion about mandatory 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, 10 May 2009 19:59:23 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi Joel, > > I will reply to your first and last emails in one go: > > "Joel M. Halpern" wrote: > >> While reading the YANG document again, I have managed to confuse > >> myself about the effect of "Mandatory". > >> > >> In the absence of choice: > >> I am left unsure as to whether the text in 7.6.4 on the non-choice > >> effects of "mandatory" are clear, or correct. > >> Must there always be something that is not a "non-presence container" > >> above the leaf in the tree? Does the module or submodule count for > >> this purpose? > > No you are right. Text is missing about this case - if the mandatory > > leaf is on the top-level (or it only has np-containers above itself) > > then it must always exist. > > > >> In the presence of choice, > >> suppose that the only element of the choice is a non-presence > >> container. Presumably, if that non-presence container is created, > >> because that is which branch of the choice is being taken, then the > >> leaf must exist. (i.e. if the leaf has siblings in the container, but > >> no other nodes exist in this case?) > > Let's look at an example: > > choice x { > > container a { > > leaf b { mandatory true; ... } > > leaf c { mandatory false; ... } > > leaf d { mandatory false; ... } > > } > > ... > > } > > The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. > > As Andy wrote, an np-container is transparent to the leafs, so if we > > modify the example a bit: > > choice x { > > container a { > > leaf b { mandatory true; ... } > > container cc { > > leaf c { mandatory false; ... } > > } > > container dd { > > leaf d { mandatory false; ... } > > } > > } > > ... > > } > > Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. > > > > > I implemented this differently. > According to the draft -- I think. > > If /a exists, then all the child nodes > of /a will be 'instance-checked'. It seems we may have some inconsistencies in the draft. If so they must be fixed. Which text in the draft leads to the conclusion that if 'a' exists then 'a/b' MUST exist? (I think 7.6.4 is clear in this regard) /martin From andy@netconfcentral.com Sun May 10 13:57: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 DC9703A6D6F for ; Sun, 10 May 2009 13:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=-0.716, 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 xsdQWlbTtj6T for ; Sun, 10 May 2009 13:57:11 -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 EB3583A6C17 for ; Sun, 10 May 2009 13:57:03 -0700 (PDT) Received: (qmail 20889 invoked from network); 10 May 2009 20:58:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 10 May 2009 20:58:30 -0000 X-YMail-OSG: HxeHyAsVM1kIf0lAm5liRASjorNO81NkFkHI2bNPcTwtHfvPm0sfSdFRks6OXUTeRiuAnqvIbFFUd2fraeI78jJi4ZeY4W64JWTu.8TxoA00.yNYw8JktmtAWvgKmDm4Nck1eQvt5355SNjg1w2QUoQ8YV4vko7mgIcZoMLncQwMRprjB5JXGurSRcjTCsChpC5VfC8imH6KhPiVb6dyWSZmfOO0KRrHSm4N4sEvod3euoZGEfVmuQQG5Dg4hq5HJw9hSNjORvHg6YBiFGgpxsoaOKeB7sgD51dV0nbWOSJsgydLjiNRhBs2bM1fi0SQ8dYjGog- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A073FF5.9050604@netconfcentral.com> Date: Sun, 10 May 2009 13:58:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A0322B1.4050006@joelhalpern.com> <20090510.213131.167455790.mbj@tail-f.com> <4A072DE0.8050307@netconfcentral.com> <20090510.220051.123480027.mbj@tail-f.com> In-Reply-To: <20090510.220051.123480027.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] Confusion about mandatory 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, 10 May 2009 20:57:11 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi Joel, >>> I will reply to your first and last emails in one go: >>> "Joel M. Halpern" wrote: >>>> While reading the YANG document again, I have managed to confuse >>>> myself about the effect of "Mandatory". >>>> >>>> In the absence of choice: >>>> I am left unsure as to whether the text in 7.6.4 on the non-choice >>>> effects of "mandatory" are clear, or correct. >>>> Must there always be something that is not a "non-presence container" >>>> above the leaf in the tree? Does the module or submodule count for >>>> this purpose? >>> No you are right. Text is missing about this case - if the mandatory >>> leaf is on the top-level (or it only has np-containers above itself) >>> then it must always exist. >>> >>>> In the presence of choice, >>>> suppose that the only element of the choice is a non-presence >>>> container. Presumably, if that non-presence container is created, >>>> because that is which branch of the choice is being taken, then the >>>> leaf must exist. (i.e. if the leaf has siblings in the container, but >>>> no other nodes exist in this case?) >>> Let's look at an example: >>> choice x { >>> container a { >>> leaf b { mandatory true; ... } >>> leaf c { mandatory false; ... } >>> leaf d { mandatory false; ... } >>> } >>> ... >>> } >>> The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. >>> As Andy wrote, an np-container is transparent to the leafs, so if we >>> modify the example a bit: >>> choice x { >>> container a { >>> leaf b { mandatory true; ... } >>> container cc { >>> leaf c { mandatory false; ... } >>> } >>> container dd { >>> leaf d { mandatory false; ... } >>> } >>> } >>> ... >>> } >>> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. >>> >> >> I implemented this differently. >> According to the draft -- I think. >> >> If /a exists, then all the child nodes >> of /a will be 'instance-checked'. > > It seems we may have some inconsistencies in the draft. If so they > must be fixed. > > Which text in the draft leads to the conclusion that if 'a' exists > then 'a/b' MUST exist? (I think 7.6.4 is clear in this regard) > > What difference does it make if /a is a P or NP container? If the manager explicitly creates /a then it is responsible for doing it correctly. What if leaf b were the only child of /a? What if the other leafs are added by augment and all unrelated to 'b', and all optional? It is better the flag /a/b as a missing node that just silently delete /a. The agent needs to convey "there is a way to configure the /a subtree, but that isn't it." > /martin > > Andy From mbj@tail-f.com Sun May 10 14:14: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 86E673A6BE0 for ; Sun, 10 May 2009 14:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.193, 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 hetii07VecXD for ; Sun, 10 May 2009 14:14: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 C08873A680D for ; Sun, 10 May 2009 14:14:13 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0ADF276C040; Sun, 10 May 2009 23:15:43 +0200 (CEST) Date: Sun, 10 May 2009 23:15:42 +0200 (CEST) Message-Id: <20090510.231542.108420990.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A0348EE.2050907@joelhalpern.com> References: <4A0348EE.2050907@joelhalpern.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] WG last call 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: Sun, 10 May 2009 21:14:15 -0000 Hi, "Joel M. Halpern" wrote: > Minor: > 1) In the definition of Mandatory node in section 3.1, it talks about > a > container node with a "mandatory" child. What if that mandatory child > is within a choice construct (probably indirectly, and the choice > itself > is not explicitly marked mandatory), i.e. in the choice case A is such > that there are no mandatory parts, but case B contains constructs > which > are Mandatory. Is the parent mandatory? Note that the text says "mandatory child" not "mandatory descendant". So if a container has a choice as the only child, the container is mandatory if and only if the choice is mandatory. > 2) In section 5.6.4 defining the syntax for announcing conformance, > there appears to be some ambiguity in the intended structure. > It appears that arbitrarily many revision, module, and feature > parameter are allowed, in any order. > Presumably, a module parameter is required before any revision, > deviation, or feature parameters? Hmm. The intention is at least that there can be at most one of those parameters. This can be solved in two ways: 1) tighten up the ABNF to: parameter = [revision-parameter] [module-parameter] [feature-parameter] [deviation-parameter] i.e. explicit zero-or-one, in specified order, or 2) keep the ABNF, but add text that says "each parameter can appear at most once". i.e. keep the current order-does-not-matter parameter list Personally, I prefer 2. > The feature parameter allows a comma separated list of feature > names. If there are multiple feature parameters that apply to the same > module parameter, are the features to be concatenated, overwritten, > first parameter kept? (The obvious meaning in that case is to > concatenate, but it does not say so.) The 'feature-parameter' simply list which features of the module the device implements. Do we need more text added to 5.6.4.2 (and 5.6.4.3)? > 3) The reference for schema discovery (section 5.6.5) should point > somewhere. If it can not point at least to an I-D, then the section > should be removed. I realized after hitting the submit-button that I forgot to remove this Open Issue. This section will be removed, and the relevant text added to the schema discovery draft. > 4) Is it intentional that submodule is defined to occur at most once, > and module does not have such a restriction? (in section 7.) No. I suggest we model 7.2 after 7.1 and change section 7.2: OLD: 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. NEW: The "submodule" statement defines the submodule's name, and groups all statements which belong to the submodule together. The "submodule" statement's argument is the name of the submodule, followed by a block of substatements that hold detailed submodule information. The submodule name follows the rules for identifiers in ^identifiers^. > 5) In section 7.5.8 on the use of edit-config with containers, there > seem to be a number of pieces that are not described. Some of these > are covered by the general description in netconf (for example on the > relationship between merge and replace.) Even so, a sentence here > saying that would be helpful. > However, there is one case where the netconf stuff does not seem to > help. > On "replace," if the node exists, what happens with regard to child > nodes present in the XML and the datastore? (It seems clear that the > recursive behavior of "replace" is somewhat different from "replace" > on the parent, and for good reasons.) 7.5.8 says: If the operation is "replace" and the node exists, all child nodes not present in the XML are deleted, and child nodes present in the XML but not present in the datastore are created. Doesn't this cover your question? > 6) Should there be some sort of comment in the description of choice > that the given rules are not sufficient to ensure that all choice > definitions are unambiguous, and it is the model developer's > responsibility to ensure that if the distinction matters that the > various combinations of possible defaults is unambiguous? (I am > thinking about a choice without an explicit default, where two of the > branches are such that they can legally exist with with just default > values (they have no mandatory components.) > I think that the rules as > written permit ambiguities, and that the system could not determine > which branch was actually the case. Could you clarify this, preferably by giving an example which you think is ambiguous? > 7) In the definition of the RPC element, I presume that there are > constraints on the use of the "grouping" element? When groupings > appear directly in the rpc element, they can not define any data > components other than input or output? A grouping can never define 'input' or 'output'. Note that the grouping statement *defines* the grouping (like typedef defines a type), so having a grouping under the rpc just defines a grouping which can be reused in the substatements to 'input' and 'output'. > 8) In defining notifications, is it part of the definition to indicate > that certain fields are supposed to be used to represent values from > other parts of the data tree (like the src address of the packet in > error, or the power level of the misbehaving laser, or the temperature > from the thermal senor...) If you want to make such a reference, you can use a 'leafref' type. > I think, if I am reading this right, that > the plan in netmod is to simply define the information to be reported, > and to use description clauses to indicate where the information > really comes from? A little more explanation of this in the > notification section would be helpful. Could you suggest some text to add? > 9) The text on updating a module specifies that updates must not cause > interoperability problems in the case where a client using the old > module talks to a server using the new module. The allowed changes > include expanding the set of legitimate values. (contract the valid > set would be as bad or worse.) But this seems to mean that a client > may receive values that it considers invalid from the server. It > seems to me that somewhere there ought to be a statement that says > "although clients must be aware of teh definition of valoid values for > generating configuration data, they must also be prepared to receive > apparently invalid values from the server if teh server working with a > newer version of a module. Yes, you are right. Depending on the query, clients must also be prepared to receive XML elements they don't understand; either from some other namespace that the client does not know about (when augment has been used), or from the same namespace (when the server has a newer version). > > Editorial comments: > The type statement is forward referenced at the end of 4.2.4. It > should be to section 7.4, not to section 9. Fixed. > In the example of special strings in 6.1.3.1, just to confirm the > expected, would it be worth including "'"? Do you mean like this: "'" - string containing a single quote > Since section 7.1.6 (The include Statement) is reference for > submodules as well as modules, the text of the first sentence probably > ought to read: > The "include" statement is used to make content from a submodule > available that submodules parent module, or any other submodules > of that parent module. Ok. I changed it to this: The "include" statement is used to make content from a submodule available to that submodule's parent module, or to another submodule of that parent module. > Section 7.8 The list statement, in the sentence after the introductory > paragraph says "A list entry is uniquely identified by the values of > the list's key." However, the first sentence in 7.8.2 says that the > "key" statement is optional for state data. So shouldn't the sentence > in 7.8 be somewhat qualified? ("if defined" at the end of the > sentence might well suffice.) Ok, I added "if defined". > It would probably be nice to remind readers in section 7.8.2 (The > list's key Statement) that while fields in containers can not be used > as key fields, leafs defined in groups can be used. (This gets around > my biggest concerns with the requirement that the key elements be > direct leaf elements in the list.) Would this text work (as a new sentence last in the first paragraph): The leafs can be defined directly in substatements to the list, or in groupings used in the list. > Should the definition of the reference statement (7.19.5) say > something about the syntax? > Related to that, the text leaves me completely puzzled as to what > "reference" elements are for. I thought for a while they were related > to the leafref type. But they aren't. I think that there ought to be > some more text in 7.19.4 telling the reader just what the content is > supposed / expected to be, other than "string" as defined by the ABNF. It says something more than just "string": The "reference" statement takes as an argument a string which is used to specify a textual cross-reference to an external document, either another module which defines related management information, or a document which provides additional information relevant to this definition. This text is taken from rfc 2578 (the REFERENCE clause in SMIv2). If more text is needed, I welcome any suggestions. > It seems odd and confusing that a range statement is not required to > have its values in canonical form. At least, it would seem useful to > have a sentence saying that, and stating why it is so. It seems to me that requiring this to be in canonical form would not help interoperability, but help readers of the module. As such, this is probably a good rule to add to the YANG usage guidelines draft. > In section 10 on Updating a Module, it says that obsolete definitions > MUST NOT be removed. In the status section it says that obsolete is > specifically for things that can be removed, as deprecated is for > things that can not be removed? I think the difference is between > "removed from specification" and "removed from implementation. A few > extra words here would avoid confusing the reader. (Something like > "Although explicitly obsolete elements may be removed from > implementations, they must not be removed from specifications so as to > avoid rendering other definitions syntactically invalid.") Section 10 explicitly says "removed from modules" (and section 10 is about updating *modules* (not implementations)). But 7.19.2 just says "removed". I suggest we clarify 7.19.2 to read: - "obsolete" means the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations. /martin From mbj@tail-f.com Sun May 10 14:19: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 C54AC3A6C7B for ; Sun, 10 May 2009 14:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.191, 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 Tq2Pd5Swt8ir for ; Sun, 10 May 2009 14:19: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 B85013A680D for ; Sun, 10 May 2009 14:19: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 68F2176C040; Sun, 10 May 2009 23:21:14 +0200 (CEST) Date: Sun, 10 May 2009 23:21:14 +0200 (CEST) Message-Id: <20090510.232114.86038371.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A073FF5.9050604@netconfcentral.com> References: <4A072DE0.8050307@netconfcentral.com> <20090510.220051.123480027.mbj@tail-f.com> <4A073FF5.9050604@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] Confusion about mandatory 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, 10 May 2009 21:19:47 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Hi Joel, > >>> I will reply to your first and last emails in one go: > >>> "Joel M. Halpern" wrote: > >>>> While reading the YANG document again, I have managed to confuse > >>>> myself about the effect of "Mandatory". > >>>> > >>>> In the absence of choice: > >>>> I am left unsure as to whether the text in 7.6.4 on the non-choice > >>>> effects of "mandatory" are clear, or correct. > >>>> Must there always be something that is not a "non-presence container" > >>>> above the leaf in the tree? Does the module or submodule count for > >>>> this purpose? > >>> No you are right. Text is missing about this case - if the mandatory > >>> leaf is on the top-level (or it only has np-containers above itself) > >>> then it must always exist. > >>> > >>>> In the presence of choice, > >>>> suppose that the only element of the choice is a non-presence > >>>> container. Presumably, if that non-presence container is created, > >>>> because that is which branch of the choice is being taken, then the > >>>> leaf must exist. (i.e. if the leaf has siblings in the container, but > >>>> no other nodes exist in this case?) > >>> Let's look at an example: > >>> choice x { > >>> container a { > >>> leaf b { mandatory true; ... } > >>> leaf c { mandatory false; ... } > >>> leaf d { mandatory false; ... } > >>> } > >>> ... > >>> } > >>> The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. > >>> As Andy wrote, an np-container is transparent to the leafs, so if we > >>> modify the example a bit: > >>> choice x { > >>> container a { > >>> leaf b { mandatory true; ... } > >>> container cc { > >>> leaf c { mandatory false; ... } > >>> } > >>> container dd { > >>> leaf d { mandatory false; ... } > >>> } > >>> } > >>> ... > >>> } > >>> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. > >>> > >> > >> I implemented this differently. > >> According to the draft -- I think. > >> > >> If /a exists, then all the child nodes > >> of /a will be 'instance-checked'. > > It seems we may have some inconsistencies in the draft. If so they > > must be fixed. > > Which text in the draft leads to the conclusion that if 'a' exists > > then 'a/b' MUST exist? (I think 7.6.4 is clear in this regard) > > > > What difference does it make if /a is a P or NP container? It makes all the difference! By definition an NP container has no semantic meaning. I will ask the question again - is there any text in the draft that leads to the conclusion that if 'a' exists then 'a/b' MUST exist? > If the manager explicitly creates /a then it is responsible > for doing it correctly. > > What if leaf b were the only child of /a? > What if the other leafs are added by augment > and all unrelated to 'b', and all optional? Then if the client creates one of these augmented nodes, it would have to create 'a/b'. /martin From andy@netconfcentral.com Sun May 10 14:43: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 21D5E3A6AFA for ; Sun, 10 May 2009 14:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=-0.896, 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 6LObGP1IZWA8 for ; Sun, 10 May 2009 14:43:44 -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 53EFC3A6AB8 for ; Sun, 10 May 2009 14:43:44 -0700 (PDT) Received: (qmail 40143 invoked from network); 10 May 2009 21:45:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 10 May 2009 21:45:11 -0000 X-YMail-OSG: Xz_HcFcVM1lHAU.ou5_McoyyhumObgaGavoIVbXBF8wPDBSlGUKL6nR.z3q1aeF0bWwLc_9VT6yF4wP4llwqST__g9OMLwdQjaR5va04KleEcVcMO_61ZZyGXMbPuO.Z4rOiZ78BMpOPHw_H5cNho2njqlSzaGgs7kUQFmki6kgdlsCCjzEYgaq2bCnb8FM4qKPx1_ZS6vRYifgswHaH655NkgSmX0ecX_sfxlcXMZn4GT7UYJGDM24puwzSoksGyARGa5Cr4ynfSVfQrhv9CSTT2iW3eftK3VRLj73_fCYdUm5Tg9Wyh9BBLxKLoBGKue93Hil1y6D_lFN4Xy_mYkxFYnFhLdapZLkV72hsfGk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A074AE6.9040103@netconfcentral.com> Date: Sun, 10 May 2009 14:45:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A072DE0.8050307@netconfcentral.com> <20090510.220051.123480027.mbj@tail-f.com> <4A073FF5.9050604@netconfcentral.com> <20090510.232114.86038371.mbj@tail-f.com> In-Reply-To: <20090510.232114.86038371.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] Confusion about mandatory 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, 10 May 2009 21:43:45 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Hi Joel, >>>>> I will reply to your first and last emails in one go: >>>>> "Joel M. Halpern" wrote: >>>>>> While reading the YANG document again, I have managed to confuse >>>>>> myself about the effect of "Mandatory". >>>>>> >>>>>> In the absence of choice: >>>>>> I am left unsure as to whether the text in 7.6.4 on the non-choice >>>>>> effects of "mandatory" are clear, or correct. >>>>>> Must there always be something that is not a "non-presence container" >>>>>> above the leaf in the tree? Does the module or submodule count for >>>>>> this purpose? >>>>> No you are right. Text is missing about this case - if the mandatory >>>>> leaf is on the top-level (or it only has np-containers above itself) >>>>> then it must always exist. >>>>> >>>>>> In the presence of choice, >>>>>> suppose that the only element of the choice is a non-presence >>>>>> container. Presumably, if that non-presence container is created, >>>>>> because that is which branch of the choice is being taken, then the >>>>>> leaf must exist. (i.e. if the leaf has siblings in the container, but >>>>>> no other nodes exist in this case?) >>>>> Let's look at an example: >>>>> choice x { >>>>> container a { >>>>> leaf b { mandatory true; ... } >>>>> leaf c { mandatory false; ... } >>>>> leaf d { mandatory false; ... } >>>>> } >>>>> ... >>>>> } >>>>> The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. >>>>> As Andy wrote, an np-container is transparent to the leafs, so if we >>>>> modify the example a bit: >>>>> choice x { >>>>> container a { >>>>> leaf b { mandatory true; ... } >>>>> container cc { >>>>> leaf c { mandatory false; ... } >>>>> } >>>>> container dd { >>>>> leaf d { mandatory false; ... } >>>>> } >>>>> } >>>>> ... >>>>> } >>>>> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. >>>>> >>>> I implemented this differently. >>>> According to the draft -- I think. >>>> >>>> If /a exists, then all the child nodes >>>> of /a will be 'instance-checked'. >>> It seems we may have some inconsistencies in the draft. If so they >>> must be fixed. >>> Which text in the draft leads to the conclusion that if 'a' exists >>> then 'a/b' MUST exist? (I think 7.6.4 is clear in this regard) >>> >> What difference does it make if /a is a P or NP container? > > It makes all the difference! By definition an NP container has no > semantic meaning. > > I will ask the question again - is there any text in the draft that > leads to the conclusion that if 'a' exists then 'a/b' MUST exist? > 3.1. Mandatory nodes A mandatory node is one of: o A leaf or choice node with a "mandatory" statement with the value "true". I think the text in other sections (like 7.6) about P containers only is wrong. >> If the manager explicitly creates /a then it is responsible >> for doing it correctly. >> >> What if leaf b were the only child of /a? >> What if the other leafs are added by augment >> and all unrelated to 'b', and all optional? > > Then if the client creates one of these augmented nodes, it would have > to create 'a/b'. > What if 'b' is the only child? What if there are only mandatory leafs? container a { leaf b { mandatory true; type string; } } Containers are not transparent in the XML like choices and cases. If the manager creates a container node, whether it is a P or NP container, then all of the tests for mandatory (mandatory-stmt, min-elements, etc.) need to be checked for all the nodes defined within the container. What if a data modeler wants to add a layer of hierarchy in the XML just because they want it, (i.e., NP container) and they have 50 mandatory leafs to put in it, but no optional leafs? The agent cannot issue an error for any missing leafs until (and if) one of the leafs is created? This seems very confusing to the manager. I do not understand why there should be any difference between the mandatory tests for descendants of P vs. NP containers, once the manager has created an instance of the container. These P/NP containers are complicated enough already. > > /martin > > Andy From mbj@tail-f.com Mon May 11 00:03: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 D5E3D3A686D for ; Mon, 11 May 2009 00:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-0.556, 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 ksTK9DhQv+W6 for ; Mon, 11 May 2009 00:02:57 -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 B52973A6A84 for ; Mon, 11 May 2009 00:02:56 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 55C6F616006; Mon, 11 May 2009 09:04:24 +0200 (CEST) Date: Mon, 11 May 2009 09:04:23 +0200 (CEST) Message-Id: <20090511.090423.12298971.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A074AE6.9040103@netconfcentral.com> References: <4A073FF5.9050604@netconfcentral.com> <20090510.232114.86038371.mbj@tail-f.com> <4A074AE6.9040103@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] Confusion about mandatory 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, 11 May 2009 07:03:01 -0000 Andy Bierman wrote: > >>>>> Let's look at an example: > >>>>> choice x { > >>>>> container a { > >>>>> leaf b { mandatory true; ... } > >>>>> leaf c { mandatory false; ... } > >>>>> leaf d { mandatory false; ... } > >>>>> } > >>>>> ... > >>>>> } > >>>>> The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. > >>>>> As Andy wrote, an np-container is transparent to the leafs, so if we > >>>>> modify the example a bit: > >>>>> choice x { > >>>>> container a { > >>>>> leaf b { mandatory true; ... } > >>>>> container cc { > >>>>> leaf c { mandatory false; ... } > >>>>> } > >>>>> container dd { > >>>>> leaf d { mandatory false; ... } > >>>>> } > >>>>> } > >>>>> ... > >>>>> } > >>>>> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. [...] > >> What if leaf b were the only child of /a? > >> What if the other leafs are added by augment > >> and all unrelated to 'b', and all optional? > > Then if the client creates one of these augmented nodes, it would have > > to create 'a/b'. > > > > What if 'b' is the only child? Then the mandatory statement has no real effect. > What if there are only mandatory leafs? Then all of them must exist. > What if a data modeler wants to add a layer of hierarchy > in the XML just because they want it, (i.e., NP container) > and they have 50 mandatory leafs to put in it, > but no optional leafs? The agent cannot issue > an error for any missing leafs until (and if) > one of the leafs is created? This seems very > confusing to the manager. > > I do not understand why there should be any > difference between the mandatory tests for > descendants of P vs. NP containers, once > the manager has created an instance of the container. > These P/NP containers are complicated enough already. This only happens when there is a np container directly under a case, and the client tries to create only this node. We discuessed this earlier in another thread in some detail. /martin From andy@netconfcentral.com Mon May 11 02:27: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 93CF93A6993 for ; Mon, 11 May 2009 02:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=-0.888, 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 cE8S1B4sbGC1 for ; Mon, 11 May 2009 02:27:46 -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 D57DA3A67DD for ; Mon, 11 May 2009 02:27:46 -0700 (PDT) Received: (qmail 46480 invoked from network); 11 May 2009 09:29:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2009 09:29:14 -0000 X-YMail-OSG: RskzE7AVM1neXYdTLlgffZqm6gGpONxHnUEI0eUzeUT7uJ68EtFaKLy1ui5ozmLrsFvH.LbtHHEDmb1GUD7jCtNopZveLPJMke_w.m6C0ZJihqG20KLtmyoQ8Wlv_Vxi5bFDbklnkCj3wXJsekuAboZCXMyDzaBqht24.15oRSt3niR3MJeW_T_EBf2NaqM.h4E8X9h.PDvqRJpWVedvwOYU.Hb_KgyCcCpTTsUQLsJSyTXTtX71usRAFYKmepTrAtMVZDZw.9wktzdEyJyxzyWLDqG3XyG1UKkeYBykV7Q6oA6kYklLvbKY0kWirF8KcjnpZ8OuP.RnuFSaSgZfiXxgsCfO7ppKpua1zJSGx3dfYvGK X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A07EFE8.9060007@netconfcentral.com> Date: Mon, 11 May 2009 02:29:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A073FF5.9050604@netconfcentral.com> <20090510.232114.86038371.mbj@tail-f.com> <4A074AE6.9040103@netconfcentral.com> <20090511.090423.12298971.mbj@tail-f.com> In-Reply-To: <20090511.090423.12298971.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] Confusion about mandatory 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, 11 May 2009 09:27:47 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>>>>>> Let's look at an example: >>>>>>> choice x { >>>>>>> container a { >>>>>>> leaf b { mandatory true; ... } >>>>>>> leaf c { mandatory false; ... } >>>>>>> leaf d { mandatory false; ... } >>>>>>> } >>>>>>> ... >>>>>>> } >>>>>>> The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. >>>>>>> As Andy wrote, an np-container is transparent to the leafs, so if we >>>>>>> modify the example a bit: >>>>>>> choice x { >>>>>>> container a { >>>>>>> leaf b { mandatory true; ... } >>>>>>> container cc { >>>>>>> leaf c { mandatory false; ... } >>>>>>> } >>>>>>> container dd { >>>>>>> leaf d { mandatory false; ... } >>>>>>> } >>>>>>> } >>>>>>> ... >>>>>>> } >>>>>>> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. > > [...] > >>>> What if leaf b were the only child of /a? >>>> What if the other leafs are added by augment >>>> and all unrelated to 'b', and all optional? >>> Then if the client creates one of these augmented nodes, it would have >>> to create 'a/b'. >>> >> What if 'b' is the only child? > > Then the mandatory statement has no real effect. > >> What if there are only mandatory leafs? > > Then all of them must exist. > but according to your CLR, the agent is NOT ALLOWED to report any error about the missing leafs until one of them is entered. This seems rather broken from an operational POV. >> What if a data modeler wants to add a layer of hierarchy >> in the XML just because they want it, (i.e., NP container) >> and they have 50 mandatory leafs to put in it, >> but no optional leafs? The agent cannot issue >> an error for any missing leafs until (and if) >> one of the leafs is created? This seems very >> confusing to the manager. >> >> I do not understand why there should be any >> difference between the mandatory tests for >> descendants of P vs. NP containers, once >> the manager has created an instance of the container. >> These P/NP containers are complicated enough already. > > > This only happens when there is a np container directly under a case, > and the client tries to create only this node. We discuessed this > earlier in another thread in some detail. > > > /martin > > > > Andy From andy@netconfcentral.com Mon May 11 02:55: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 8CA513A6B7A for ; Mon, 11 May 2009 02:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=-1.159, 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 ehKtuFdfymXj for ; Mon, 11 May 2009 02:55:03 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id B4E003A6A1D for ; Mon, 11 May 2009 02:55:03 -0700 (PDT) Received: (qmail 1867 invoked from network); 11 May 2009 09:56:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2009 09:56:34 -0000 X-YMail-OSG: rUiYolAVM1nIOBKdak8dnRwxCa4rBiPntPupS3UrdjW_67f4jU1iE4.LBd55GKb71FE41TLjtbXnvB30RUatgCAkaMzXcEbxVKaYsqT4VTYRdC8HfrCIJ8RAZVFnViliX.QCU71iOf3YFUitdcN8274Wu.MUTdbo8YhBT_nRB8AH.8kp6ld5MfOueA2dAtVSV0Yj3aqlm96CpP0KxC7cbhWM9Vd2iBJ5PPgp9pDQuuY8vIn5e0RQBXywP8VEPEMnBEZeBc2rlJxU0AlA_VDCw3TlQLdsTSgE6Sa.pbfpZmhM.Rr0P2_M4ZlpYckk.bdxOtg291Xl2qN8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A07F650.7060808@netconfcentral.com> Date: Mon, 11 May 2009 02:56:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A073FF5.9050604@netconfcentral.com> <20090510.232114.86038371.mbj@tail-f.com> <4A074AE6.9040103@netconfcentral.com> <20090511.090423.12298971.mbj@tail-f.com> In-Reply-To: <20090511.090423.12298971.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] Confusion about mandatory 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, 11 May 2009 09:55:05 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>>>>>> Let's look at an example: >>>>>>> choice x { >>>>>>> container a { >>>>>>> leaf b { mandatory true; ... } >>>>>>> leaf c { mandatory false; ... } >>>>>>> leaf d { mandatory false; ... } >>>>>>> } >>>>>>> ... >>>>>>> } >>>>>>> The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. >>>>>>> As Andy wrote, an np-container is transparent to the leafs, so if we >>>>>>> modify the example a bit: >>>>>>> choice x { >>>>>>> container a { >>>>>>> leaf b { mandatory true; ... } >>>>>>> container cc { >>>>>>> leaf c { mandatory false; ... } >>>>>>> } >>>>>>> container dd { >>>>>>> leaf d { mandatory false; ... } >>>>>>> } >>>>>>> } >>>>>>> ... >>>>>>> } >>>>>>> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. > > [...] > >>>> What if leaf b were the only child of /a? >>>> What if the other leafs are added by augment >>>> and all unrelated to 'b', and all optional? >>> Then if the client creates one of these augmented nodes, it would have >>> to create 'a/b'. >>> >> What if 'b' is the only child? > > Then the mandatory statement has no real effect. > >> What if there are only mandatory leafs? > > Then all of them must exist. > >> What if a data modeler wants to add a layer of hierarchy >> in the XML just because they want it, (i.e., NP container) >> and they have 50 mandatory leafs to put in it, >> but no optional leafs? The agent cannot issue >> an error for any missing leafs until (and if) >> one of the leafs is created? This seems very >> confusing to the manager. >> >> I do not understand why there should be any >> difference between the mandatory tests for >> descendants of P vs. NP containers, once >> the manager has created an instance of the container. >> These P/NP containers are complicated enough already. > > > This only happens when there is a np container directly under a case, > and the client tries to create only this node. We discuessed this > earlier in another thread in some detail. > > I think it happens anytime an empty NP container gets created. I think I see your concern, and wonder if it an implementation detail or needs to be mentioned in the draft. This affects the 'commit-test' (or edit-config on running). If the internal code removes empty NP containers before checking for missing instances, then the error for the missing '/a/b' leaf will never get generated. If the agent chooses to keep NP containers around, then the missing leafs are an issue. The current rule allows the empty NP container to hang around without any impact on the validity of the data model. I'm not sure I like this approach better than simply requiring the agent to remove empty NP containers. > /martin > > > > Andy From mbj@tail-f.com Mon May 11 03:22: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 3FD693A6BA8 for ; Mon, 11 May 2009 03:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.195, 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 s5BYuHpoPk1d for ; Mon, 11 May 2009 03:22: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 727283A6801 for ; Mon, 11 May 2009 03:22: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 2E5F376C040; Mon, 11 May 2009 12:24:07 +0200 (CEST) Date: Mon, 11 May 2009 12:24:06 +0200 (CEST) Message-Id: <20090511.122406.171066697.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A07F650.7060808@netconfcentral.com> References: <4A074AE6.9040103@netconfcentral.com> <20090511.090423.12298971.mbj@tail-f.com> <4A07F650.7060808@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] Confusion about mandatory 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, 11 May 2009 10:22:41 -0000 Andy Bierman wrote: > > This only happens when there is a np container directly under a case, > > and the client tries to create only this node. We discuessed this > > earlier in another thread in some detail. > > > > I think it happens anytime an empty NP container > gets created. But if it's not under a case, then it's either on the top-level, or under a list or p-container. A typical example to illustrate: list server { key id; leaf id { ... } container address { leaf ip { mandatory true; ... } leaf port { mandatory true; ... } ... } Now, when a server instance gets created, values for address/ip and address/port MUST be provided, regardless of whether 'address' gets created empty or not. /martin From mbj@tail-f.com Mon May 11 05:02: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 CB4173A6EBC for ; Mon, 11 May 2009 05:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=-0.552, 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 uQ-VNSU70jcM for ; Mon, 11 May 2009 05:02: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 D990C3A6F31 for ; Mon, 11 May 2009 05:01:48 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6230B616001; Mon, 11 May 2009 14:03:16 +0200 (CEST) Date: Mon, 11 May 2009 11:40:51 +0200 (CEST) Message-Id: <20090511.114051.181384500.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A07EFE8.9060007@netconfcentral.com> References: <4A074AE6.9040103@netconfcentral.com> <20090511.090423.12298971.mbj@tail-f.com> <4A07EFE8.9060007@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] Confusion about mandatory 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, 11 May 2009 12:02:20 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >>>>>>> Let's look at an example: > >>>>>>> choice x { > >>>>>>> container a { > >>>>>>> leaf b { mandatory true; ... } > >>>>>>> leaf c { mandatory false; ... } > >>>>>>> leaf d { mandatory false; ... } > >>>>>>> } > >>>>>>> ... > >>>>>>> } > >>>>>>> The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists. > >>>>>>> As Andy wrote, an np-container is transparent to the leafs, so if we > >>>>>>> modify the example a bit: > >>>>>>> choice x { > >>>>>>> container a { > >>>>>>> leaf b { mandatory true; ... } > >>>>>>> container cc { > >>>>>>> leaf c { mandatory false; ... } > >>>>>>> } > >>>>>>> container dd { > >>>>>>> leaf d { mandatory false; ... } > >>>>>>> } > >>>>>>> } > >>>>>>> ... > >>>>>>> } > >>>>>>> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists. > > [...] > > > >>>> What if leaf b were the only child of /a? > >>>> What if the other leafs are added by augment > >>>> and all unrelated to 'b', and all optional? > >>> Then if the client creates one of these augmented nodes, it would have > >>> to create 'a/b'. > >>> > >> What if 'b' is the only child? > > Then the mandatory statement has no real effect. > > > >> What if there are only mandatory leafs? > > Then all of them must exist. > > > > but according to your CLR, > the agent is NOT ALLOWED to report any error > about the missing leafs until one of them is entered. I should have written: Then all of them must exist if any one exist. /martin From lhotka@cesnet.cz Mon May 11 06:31: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 B34533A6B9F for ; Mon, 11 May 2009 06:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[AWL=-1.010, 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 Qx738Qi3v0DZ for ; Mon, 11 May 2009 06:31:13 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8C15D3A6B92 for ; Mon, 11 May 2009 06:30: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 EE470D800C0 for ; Mon, 11 May 2009 15:32:08 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4A048F04.10205@netconfcentral.com> References: <200905081804.n48I4GJt006537@idle.juniper.net> <4A0479EC.3050305@netconfcentral.com> <20090508.212951.224339624.mbj@tail-f.com> <4A048F04.10205@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 11 May 2009 15:32:09 +0200 Message-Id: <1242048729.6502.54.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 11 May 2009 13:31:13 -0000 Andy Bierman píše v Pá 08. 05. 2009 v 12:59 -0700: > > I do not believe import-any-revision will be > used only in this special case. It seems to > be used this way every time. Maybe that will > change as YANG stabilizes. There is also a possible interaction with module namespace URI: A developer of a module might decide to avoid the separate revision mechanism of YANG and encode the revision info into the namespace URI instead. This way, the revision would have to be always specified. According to the draft, such an approach seems to be allowed, but together with YANG revisions it could result in an awful mess. YANG should IMO choose between these two options: 1. Keep the revision mechanism and state that the namespace must not change during the module lifetime. 2. Use the namespace URI for encoding both module and revision info, and remove the revision statement (or use it only as editorial documentation). Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon May 11 06:47: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 B93193A688B for ; Mon, 11 May 2009 06:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.198, 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 cGhPDxcb+n-k for ; Mon, 11 May 2009 06: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 E52473A67F0 for ; Mon, 11 May 2009 06:47: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 BF24E76C040; Mon, 11 May 2009 15:49:00 +0200 (CEST) Date: Mon, 11 May 2009 15:49:00 +0200 (CEST) Message-Id: <20090511.154900.119911918.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242048729.6502.54.camel@missotis> References: <20090508.212951.224339624.mbj@tail-f.com> <4A048F04.10205@netconfcentral.com> <1242048729.6502.54.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] WGLC comments on deviation-stmt 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, 11 May 2009 13:47:32 -0000 Ladislav Lhotka wrote: > There is also a possible interaction with module namespace URI: A > developer of a module might decide to avoid the separate revision > mechanism of YANG and encode the revision info into the namespace URI > instead. This way, the revision would have to be always specified. > > According to the draft, such an approach seems to be allowed Section 10 lists the legal modifications to a module, and changing the namespace URI is not listed. In fact, the current text says: Furthermore, the "namespace" statement MUST NOT be changed, /martin From lhotka@cesnet.cz Mon May 11 07:18: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 0C40A3A6F70 for ; Mon, 11 May 2009 07:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=-0.442, 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 j0e0mjTzxcDw for ; Mon, 11 May 2009 07:18:42 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3C0CE3A6F6E for ; Mon, 11 May 2009 07:18:42 -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 9380DD800BD for ; Mon, 11 May 2009 16:20:12 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20090511.154900.119911918.mbj@tail-f.com> References: <20090508.212951.224339624.mbj@tail-f.com> <4A048F04.10205@netconfcentral.com> <1242048729.6502.54.camel@missotis> <20090511.154900.119911918.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 11 May 2009 16:20:13 +0200 Message-Id: <1242051613.6502.81.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 11 May 2009 14:18:43 -0000 Martin Bjorklund píše v Po 11. 05. 2009 v 15:49 +0200: > Ladislav Lhotka wrote: > > There is also a possible interaction with module namespace URI: A > > developer of a module might decide to avoid the separate revision > > mechanism of YANG and encode the revision info into the namespace URI > > instead. This way, the revision would have to be always specified. > > > > According to the draft, such an approach seems to be allowed > > Section 10 lists the legal modifications to a module, and changing the > namespace URI is not listed. In fact, the current text says: > > Furthermore, the "namespace" statement MUST NOT be changed, It depends on how you interpret the word "module", whether it is just a given YANG text or an abstract entity with a certain life cycle. The first interpretation is supported by many formulations in the text, e.g., in sec. 4.2.1.: "A module contains three types of statements: ...". What if the said developer encodes the revision in the module name as well? module foo-1.2.3 { namespace "http://example.com/ns/foo/1.2.3"; ... } Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon May 11 07:24: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 CBF393A6D96 for ; Mon, 11 May 2009 07:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.196, 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 ep3Xyk-3Xw2b for ; Mon, 11 May 2009 07:24:05 -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 B74D53A6A74 for ; Mon, 11 May 2009 07:24:04 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 53FB276C040; Mon, 11 May 2009 16:25:35 +0200 (CEST) Date: Mon, 11 May 2009 16:25:34 +0200 (CEST) Message-Id: <20090511.162534.216851905.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242051613.6502.81.camel@missotis> References: <1242048729.6502.54.camel@missotis> <20090511.154900.119911918.mbj@tail-f.com> <1242051613.6502.81.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] WGLC comments on deviation-stmt 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, 11 May 2009 14:24:05 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQbyAxMS4gMDUuIDIwMDkgdiAxNTo0OSArMDIwMDoNCj4gPiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gVGhlcmUgaXMgYWxzbyBh IHBvc3NpYmxlIGludGVyYWN0aW9uIHdpdGggbW9kdWxlIG5hbWVzcGFjZSBVUkk6IEENCj4gPiA+ IGRldmVsb3BlciBvZiBhIG1vZHVsZSBtaWdodCBkZWNpZGUgdG8gYXZvaWQgdGhlIHNlcGFyYXRl IHJldmlzaW9uDQo+ID4gPiBtZWNoYW5pc20gb2YgWUFORyBhbmQgZW5jb2RlIHRoZSByZXZpc2lv biBpbmZvIGludG8gdGhlIG5hbWVzcGFjZSBVUkkNCj4gPiA+IGluc3RlYWQuIFRoaXMgd2F5LCB0 aGUgcmV2aXNpb24gd291bGQgaGF2ZSB0byBiZSBhbHdheXMgc3BlY2lmaWVkLg0KPiA+ID4gDQo+ ID4gPiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LCBzdWNoIGFuIGFwcHJvYWNoIHNlZW1zIHRvIGJl IGFsbG93ZWQNCj4gPiANCj4gPiBTZWN0aW9uIDEwIGxpc3RzIHRoZSBsZWdhbCBtb2RpZmljYXRp b25zIHRvIGEgbW9kdWxlLCBhbmQgY2hhbmdpbmcgdGhlDQo+ID4gbmFtZXNwYWNlIFVSSSBpcyBu b3QgbGlzdGVkLiAgSW4gZmFjdCwgdGhlIGN1cnJlbnQgdGV4dCBzYXlzOg0KPiA+IA0KPiA+ICAg IEZ1cnRoZXJtb3JlLCB0aGUgIm5hbWVzcGFjZSIgc3RhdGVtZW50IE1VU1QgTk9UIGJlIGNoYW5n ZWQsDQo+IA0KPiBJdCBkZXBlbmRzIG9uIGhvdyB5b3UgaW50ZXJwcmV0IHRoZSB3b3JkICJtb2R1 bGUiLCB3aGV0aGVyIGl0IGlzIGp1c3QgYQ0KPiBnaXZlbiBZQU5HIHRleHQgb3IgYW4gYWJzdHJh Y3QgZW50aXR5IHdpdGggYSBjZXJ0YWluIGxpZmUgY3ljbGUuIFRoZQ0KPiBmaXJzdCBpbnRlcnBy ZXRhdGlvbiBpcyBzdXBwb3J0ZWQgYnkgbWFueSBmb3JtdWxhdGlvbnMgaW4gdGhlIHRleHQsDQo+ IGUuZy4sIGluIHNlYy4gNC4yLjEuOiAiQSBtb2R1bGUgY29udGFpbnMgdGhyZWUgdHlwZXMgb2YN Cj4gc3RhdGVtZW50czogLi4uIi4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuICBD b3VsZCB5b3UgcHJvcG9zZSBzb21lIHRleHQgdGhhdCBjb3VsZA0KZ28gaW50byBzZWN0aW9uIDEw IHRvIG1ha2Ugc3VyZSB3ZSB1c2UgdGhlIHdvcmQgJ21vZHVsZScNCnVuYW1iaWd1b3VzbHk/DQoN Cj4gV2hhdCBpZiB0aGUgc2FpZCBkZXZlbG9wZXIgZW5jb2RlcyB0aGUgcmV2aXNpb24gaW4gdGhl IG1vZHVsZSBuYW1lIGFzDQo+IHdlbGw/DQo+IA0KPiBtb2R1bGUgZm9vLTEuMi4zIHsNCj4gICAg IG5hbWVzcGFjZSAiaHR0cDovL2V4YW1wbGUuY29tL25zL2Zvby8xLjIuMyI7DQo+ICAgICAuLi4N Cj4gfQ0KDQpUaGlzIGRvZXNuJ3QgY2hhbmdlIGFueXRoaW5nLiAgSWYgdGhpcyBkZXZlbG9wZXIg ZXZlciBwdWJsaXNoZXMgYSBuZXcNCnJldmlzaW9uIG9mIHRoZSBtb2R1bGUgZm9vLTEuMi4zLCB0 aGUgcnVsZXMgZnJvbSAxMCBzaG91bGQgYmUNCmZvbGxvd2VkLg0KDQpJZiB0aGUgZGV2ZWxvcGVy IHB1Ymxpc2hlcyBhIG1vZHVsZSBjYWxsZWQgZm9vLTEuMi40IHRoZW4gdGhhdCdzIGENCmNvbXBs ZXRlbHkgZGlmZmVyZW50IG1vZHVsZSB0aGFuIGZvby0xLjIuMy4gIFRoZSBtb2R1bGUgbmFtZSBp cyBqdXN0DQphbiBvcGFxdWUgc3RyaW5nLg0KDQoNCi9tYXJ0aW4NCg== From lhotka@cesnet.cz Mon May 11 08:39: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 E9B973A6CB5 for ; Mon, 11 May 2009 08:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=0.308, 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 XyVKnpyGOarz for ; Mon, 11 May 2009 08:39:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CFA223A6F31 for ; Mon, 11 May 2009 08:39:25 -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 4687DD800CC; Mon, 11 May 2009 17:40:56 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090511.162534.216851905.mbj@tail-f.com> References: <1242048729.6502.54.camel@missotis> <20090511.154900.119911918.mbj@tail-f.com> <1242051613.6502.81.camel@missotis> <20090511.162534.216851905.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 11 May 2009 17:40:56 +0200 Message-Id: <1242056457.6502.110.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments on deviation-stmt 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, 11 May 2009 15:39:27 -0000 Martin Bjorklund píše v Po 11. 05. 2009 v 16:25 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Po 11. 05. 2009 v 15:49 +0200: > > > Ladislav Lhotka wrote: > > > > There is also a possible interaction with module namespace URI: A > > > > developer of a module might decide to avoid the separate revision > > > > mechanism of YANG and encode the revision info into the namespace URI > > > > instead. This way, the revision would have to be always specified. > > > > > > > > According to the draft, such an approach seems to be allowed > > > > > > Section 10 lists the legal modifications to a module, and changing the > > > namespace URI is not listed. In fact, the current text says: > > > > > > Furthermore, the "namespace" statement MUST NOT be changed, > > > > It depends on how you interpret the word "module", whether it is just a > > given YANG text or an abstract entity with a certain life cycle. The > > first interpretation is supported by many formulations in the text, > > e.g., in sec. 4.2.1.: "A module contains three types of > > statements: ...". > > I don't understand your point. Could you propose some text that could > go into section 10 to make sure we use the word 'module' > unambiguously? If you say that a module has revisions, it means it is more complicated than a simple content of a text file. It is important that the manager and agent always use the same data model, so I'd prefer to always specify (or be able to unambiguously resolve) the revision. What is actually the exact procedure for resolving the module name and/or namespace URI to a concrete YANG file if the revision is not specified? What if the manager has access to the newest revisions of a module but the agent doesn't? > > > What if the said developer encodes the revision in the module name as > > well? > > > > module foo-1.2.3 { > > namespace "http://example.com/ns/foo/1.2.3"; > > ... > > } > > This doesn't change anything. If this developer ever publishes a new > revision of the module foo-1.2.3, the rules from 10 should be > followed. > > If the developer publishes a module called foo-1.2.4 then that's a > completely different module than foo-1.2.3. The module name is just > an opaque string. Right, so this could indeed be used as a brute-force alternative to YANG revisions. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Mon May 11 08:47: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 839C528C18B for ; Mon, 11 May 2009 08:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_20=-0.74, 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 r1axnnMLNTXL for ; Mon, 11 May 2009 08:47:42 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 186393A6F78 for ; Mon, 11 May 2009 08:45:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4B30543070F for ; Mon, 11 May 2009 08:47:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 0BBCA430721 for ; Mon, 11 May 2009 08:47:13 -0700 (PDT) Message-ID: <4A08487D.50007@joelhalpern.com> Date: Mon, 11 May 2009 11:47:09 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <4A074AE6.9040103@netconfcentral.com> <20090511.090423.12298971.mbj@tail-f.com> <4A07F650.7060808@netconfcentral.com> <20090511.122406.171066697.mbj@tail-f.com> In-Reply-To: <20090511.122406.171066697.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Confusion about mandatory 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, 11 May 2009 15:47:43 -0000 Let me try restating with an example, both to indicate what I think the point is, and what I think the problem is. (Apologies if I get the syntax slightly wrong. Also sorry for the length) Suppose we have two container definitions, which appear may appear in various places. container a { container b { ..... leaf c { mandatory; type int; description ...} } container d { ... leaf e { content, not mandatory ...} } } container ax { container bx { presence ... leaf cx { mandatory; type int; description ...} } container dx { ... leaf ex { content, not mandatory ...} } } Now, if a is in the top level of a module, and a user attempts to do a create operation on a/d/e, it seems to me that the point of c being mandatory is that a/b/c has to also be created (by the user) at the same time. Conversely, if ax is in the top level of a module, and a user attempts to create ax/dx/ex, the fact that bx is a presence container means that ax/bx/cd does not need to be created at that time. ax/bx/cx needs to be created either when the user want sot create it explicitly, or when the user wants to create some sibling of cx in bx. The problem that far is that the document simply does not talk about what happens when there is no parent presence container. And it does not suffice to treat the module as a presence container that is created whenever anything in it is created, because that would mean that if a above is defined in the top level of the module, that defining anything else (outside of a) that is also in the module would trigger the requirement that a/b/c be created by the user. In a choice, there is a similar, but not identical problem. choice f { case g: insert container a here with no other siblings case h: some other options } As written, since a has no siblings in g, if the user goes to create a/d/e, there is no requirement that a/b/c must be created at the same time. But if a had other siblings in the choice, creating one of them would trigger a requirement for the user to also create a/b/c. The given requirement makes sense. It is the exclusion of the first requirement that I can not understand. (One way of looking at this case is that if the non-presence container had not been used, b/c would have siblings (d) in the case, so that the creation of d/e would have triggered the check for b/c.) To phrase this differently, the mental model I have starts from a non-presence container is conceptually created whenever any element inside it is created. As a corollary, if we determine that a non-presence container is being created, any of its parent containers are also being created. Mandatory checking is triggered by creation of the environment in which the mandatory element is defined. However, this environment is constrained by the closest choice or presence container. So when a container (presence or non-presence, list, choice case ...) is created, the mandatory checker checks if there are any mandatory elements in scope, where scope is everything inside that container that is not shielded by a suitable other container (list, case, presence.) There may well be an argument that the cases I am describing represent bad design. But I think we still have to understand what the tag means in those cases. Yours, with unfortunate excess verbosity, Joel From andy@netconfcentral.com Mon May 11 09:39: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 8E1BD3A6C55 for ; Mon, 11 May 2009 09:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=-0.687, 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 1k68J1b4CmXd for ; Mon, 11 May 2009 09:39:45 -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 B25C33A6BF2 for ; Mon, 11 May 2009 09:39:45 -0700 (PDT) Received: (qmail 62286 invoked from network); 11 May 2009 16:41:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2009 16:41:14 -0000 X-YMail-OSG: eHc.U38VM1n3H_eNNFTkC1IgHoub2dfmYJ1r8EdlWQQMN7ZM3mF6.Hm2Xz.J_OZXFKOnnRwF2t9_zDofzx0wmYhg5hHqE.vJ1mMOrfZwj9AFagb63h13f6sH4_zx2ySljAN3Jw.QyYv_RSC9NtiQkjaXizHVpgyS3J4Lxcy2vFIVmH8jLWonZvZBr3LSFy8uV6V37TzByY05l_7T7DKUaPJKzzGZiGQZr7PUPvxFl.y3wSnZ93SGt4hZrdh9uwNKKMAE_afEoD4fK34- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A085528.7020501@netconfcentral.com> Date: Mon, 11 May 2009 09:41:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A074AE6.9040103@netconfcentral.com> <20090511.090423.12298971.mbj@tail-f.com> <4A07F650.7060808@netconfcentral.com> <20090511.122406.171066697.mbj@tail-f.com> <4A08487D.50007@joelhalpern.com> In-Reply-To: <4A08487D.50007@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Confusion about mandatory 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, 11 May 2009 16:39:46 -0000 Joel M. Halpern wrote: > Let me try restating with an example, both to indicate what I think the > point is, and what I think the problem is. > (Apologies if I get the syntax slightly wrong. Also sorry for the length) > > Suppose we have two container definitions, which appear may appear in > various places. > > container a { > container b { > ..... > leaf c { mandatory; type int; description ...} > } > container d { > ... > leaf e { content, not mandatory ...} > } > } > > container ax { > container bx { > presence > ... > leaf cx { mandatory; type int; description ...} > } > container dx { > ... > leaf ex { content, not mandatory ...} > } > } > I do not think it is a 'feature' that containers behave differently in so many contexts. What if your container 'b' (or other sub-tree) was derived from a uses-stmt? The mandatory property of node 'b/c' was written without any knowledge of container 'd'. grouping B { container b { leaf c { mandatory true; ... } } } container a { uses B; container d { ... } } There is no intent by the data modeler to couple the existence of leaf 'c' with leaf 'e', but that is exactly what an NP container does. Only the NP container (dx) gives the expected behavior. That means container 'b' will become mandatory (or not) depending on the siblings and any ancestors of the uses-stmt. There should really only be two type of containment that need to be considered within a NETCONF database: 1 - XML nodes associated with a top-level data node 2 - XML nodes associated with a child of a top-level data node In case (1) there is clearly no intent to couple the existence semantics for any sibling nodes. Just the opposite in case (2). Only lists and containers can have any child nodes. Anyxml nodes do no count. Lists and P-containers behave as expected, but not NP-containers. Does this mean everybody will define containers as P-containers just to be safe? Or will data modelers just get it wrong, and complain when "sometimes it works and sometimes it doesn't"? > Now, if a is in the top level of a module, and a user attempts to do a > create operation on a/d/e, it seems to me that the point of c being > mandatory is that a/b/c has to also be created (by the user) at the same > time. > > Conversely, if ax is in the top level of a module, and a user attempts > to create ax/dx/ex, the fact that bx is a presence container means that > ax/bx/cd does not need to be created at that time. ax/bx/cx needs to be > created either when the user want sot create it explicitly, or when the > user wants to create some sibling of cx in bx. > > The problem that far is that the document simply does not talk about > what happens when there is no parent presence container. And it does > not suffice to treat the module as a presence container that is created > whenever anything in it is created, because that would mean that if a > above is defined in the top level of the module, that defining anything > else (outside of a) that is also in the module would trigger the > requirement that a/b/c be created by the user. > >... [ skipping 2nd half for now] > Yours, > with unfortunate excess verbosity, > Joel Andy From andy@netconfcentral.com Mon May 11 10:18: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 66CA83A672F for ; Mon, 11 May 2009 10:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-0.867, 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 N4-kPV8PVy9k for ; Mon, 11 May 2009 10:18:23 -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 8DE253A6829 for ; Mon, 11 May 2009 10:18:23 -0700 (PDT) Received: (qmail 87933 invoked from network); 11 May 2009 17:19:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2009 17:19:50 -0000 X-YMail-OSG: NSj_90IVM1mQ8Ij_rGNe.oFpphhc4yL1XGY0FcmMzHHTc3wDOBvQLjARlWizRRe1GcXGHiKAcA8qdRjAT7UNI8WEka5R2srPXQmdpLtX5yW3oEvZSYcF4wOD1OHHYOhTp5w7aRD9EhZgYI3pCs5yEOl6eGeSerq4EeeVur4WqqPg1k6dYEgw7f7e3O8eF6cp51Ta36ewH.xoMCUk1tfbIHj.I6pMvJ8fS8hiihBamSGFJtQ0.Sdki4BN.pBgMfp2jvvH6hY_D5DJkdg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A085E34.2010203@netconfcentral.com> Date: Mon, 11 May 2009 10:19:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A074AE6.9040103@netconfcentral.com> <20090511.090423.12298971.mbj@tail-f.com> <4A07F650.7060808@netconfcentral.com> <20090511.122406.171066697.mbj@tail-f.com> <4A08487D.50007@joelhalpern.com> <4A085528.7020501@netconfcentral.com> In-Reply-To: <4A085528.7020501@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Confusion about mandatory (correction) 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, 11 May 2009 17:18:24 -0000 Andy Bierman wrote: > Joel M. Halpern wrote: >> Let me try restating with an example, both to indicate what I think >> the point is, and what I think the problem is. >> (Apologies if I get the syntax slightly wrong. Also sorry for the >> length) >> >> Suppose we have two container definitions, which appear may appear in >> various places. >> >> container a { >> container b { >> ..... >> leaf c { mandatory; type int; description ...} >> } >> container d { >> ... >> leaf e { content, not mandatory ...} >> } >> } >> >> container ax { >> container bx { >> presence >> ... >> leaf cx { mandatory; type int; description ...} >> } >> container dx { >> ... >> leaf ex { content, not mandatory ...} >> } >> } >> > > I do not think it is a 'feature' that containers > behave differently in so many contexts. > > What if your container 'b' (or other sub-tree) > was derived from a uses-stmt? The mandatory > property of node 'b/c' was written without any > knowledge of container 'd'. > > grouping B { > container b { > leaf c { mandatory true; ... } > } > } > > container a { > uses B; > container d { ... } > } > > There is no intent by the data modeler to couple > the existence of leaf 'c' with leaf 'e', but that > is exactly what an NP container does. Only the > NP container (dx) gives the expected behavior. > s/NP container (dx)/P container (dx)/ > That means container 'b' will become mandatory (or not) > depending on the siblings and any ancestors of the uses-stmt. > > There should really only be two type of containment > that need to be considered within a NETCONF database: > > 1 - XML nodes associated with a top-level data node > 2 - XML nodes associated with a child of a top-level data node > > In case (1) there is clearly no intent to couple > the existence semantics for any sibling nodes. > Just the opposite in case (2). > There is no intent in case 1 to couple nodes from other YANG modules. Within a single YANG module, it may be the intent (e.g., a top-level choice creates associated sibling nodes at the top-level). > Only lists and containers can have any child nodes. > Anyxml nodes do no count. Lists and P-containers behave > as expected, but not NP-containers. > > Does this mean everybody will define containers as P-containers > just to be safe? Or will data modelers just get it wrong, > and complain when "sometimes it works and sometimes it doesn't"? > > >> Now, if a is in the top level of a module, and a user attempts to do >> a create operation on a/d/e, it seems to me that the point of c being >> mandatory is that a/b/c has to also be created (by the user) at the >> same time. >> >> Conversely, if ax is in the top level of a module, and a user attempts >> to create ax/dx/ex, the fact that bx is a presence container means >> that ax/bx/cd does not need to be created at that time. ax/bx/cx >> needs to be created either when the user want sot create it >> explicitly, or when the user wants to create some sibling of cx in bx. >> >> The problem that far is that the document simply does not talk about >> what happens when there is no parent presence container. And it does >> not suffice to treat the module as a presence container that is >> created whenever anything in it is created, because that would mean >> that if a above is defined in the top level of the module, that >> defining anything else (outside of a) that is also in the module would >> trigger the requirement that a/b/c be created by the user. >> > >... [ skipping 2nd half for now] > >> Yours, >> with unfortunate excess verbosity, >> Joel > > Andy > Andy From mbj@tail-f.com Mon May 11 12:18: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 5E37528C146 for ; Mon, 11 May 2009 12:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.194, 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 LCwCBElinX6Y for ; Mon, 11 May 2009 12:18:11 -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 DBFCF3A6E3E for ; Mon, 11 May 2009 12:18:07 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E246176C040; Mon, 11 May 2009 21:19:37 +0200 (CEST) Date: Mon, 11 May 2009 21:19:37 +0200 (CEST) Message-Id: <20090511.211937.198859624.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A08487D.50007@joelhalpern.com> References: <4A07F650.7060808@netconfcentral.com> <20090511.122406.171066697.mbj@tail-f.com> <4A08487D.50007@joelhalpern.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] Confusion about mandatory 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, 11 May 2009 19:18:13 -0000 "Joel M. Halpern" wrote: > Let me try restating with an example, both to indicate what I think the point > is, and what I think the problem is. > (Apologies if I get the syntax slightly wrong. Also sorry for the length) > > Suppose we have two container definitions, which appear may appear in various > places. > > container a { > container b { > ..... > leaf c { mandatory; type int; description ...} > } > container d { > ... > leaf e { content, not mandatory ...} > } > } > > container ax { > container bx { > presence > ... > leaf cx { mandatory; type int; description ...} > } > container dx { > ... > leaf ex { content, not mandatory ...} > } > } > > Now, if a is in the top level of a module, and a user attempts to do a create > operation on a/d/e, it seems to me that the point of c being mandatory is that > a/b/c has to also be created (by the user) at the same time. Actually, if a is in the top level, the effect of having a/b/c as mandatory is the same as if c was a mandatory leaf on the top level - an agent that implements this module will require that a/b/c always exists. > Conversely, if ax is in the top level of a module, and a user attempts to > create ax/dx/ex, the fact that bx is a presence container means that ax/bx/cd > does not need to be created at that time. ax/bx/cx needs to be created either > when the user want sot create it explicitly, or when the user wants to create > some sibling of cx in bx. > > The problem that far is that the document simply does not talk about what > happens when there is no parent presence container. Yes, as I said in my earlier email, I agree that this is a problem that must be addressed. > In a choice, > there is a similar, but not identical problem. > > choice f { > case g: > insert container a here > with no other siblings > > case h: > some other options > } > > As written, since a has no siblings in g, if the user goes to create a/d/e, > there is no requirement that a/b/c must be created at the same time. The intention is that a/b/c must be created in this case. Following 7.6.4, the closest ancestor node to f/g/a/b/c in the schema tree which is not a p-container is f/g (the case node). Then 7.6.4 says If this ancestor is a case node, the leaf MUST exist if any other node from the case exists. And in this case the nodes f/g/a, f/g/a/d and f/g/a/d/e exist, so it follows that f/g/a/b/c also must exist. > To phrase this differently, the mental model I have starts from > a non-presence container is conceptually created whenever any element inside it > is created. Yes, and further that np containers are really transparent - you get the same effect by removing all np containers (modulo the object's names of course). /martin From andy@netconfcentral.com Mon May 11 14:09: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 47ABF3A6AA4 for ; Mon, 11 May 2009 14:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 xM4q8iPDsu7u for ; Mon, 11 May 2009 14:09:53 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id 6C0A43A6A8C for ; Mon, 11 May 2009 14:09:53 -0700 (PDT) Received: from [68.142.200.226] by n19.bullet.mail.mud.yahoo.com with NNFMP; 11 May 2009 21:11:22 -0000 Received: from [68.142.201.252] by t7.bullet.mud.yahoo.com with NNFMP; 11 May 2009 21:11:22 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 11 May 2009 21:11:22 -0000 X-Yahoo-Newman-Id: 547133.60351.bm@omp413.mail.mud.yahoo.com Received: (qmail 85330 invoked from network); 11 May 2009 21:11:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2009 21:11:21 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A089477.2090806@netconfcentral.com> Date: Mon, 11 May 2009 14:11:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A07F650.7060808@netconfcentral.com> <20090511.122406.171066697.mbj@tail-f.com> <4A08487D.50007@joelhalpern.com> <20090511.211937.198859624.mbj@tail-f.com> In-Reply-To: <20090511.211937.198859624.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] Confusion about mandatory 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, 11 May 2009 21:09:54 -0000 Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> Let me try restating with an example, both to indicate what I think the point >> is, and what I think the problem is. >> (Apologies if I get the syntax slightly wrong. Also sorry for the length) >> >> Suppose we have two container definitions, which appear may appear in various >> places. >> >> container a { >> container b { >> ..... >> leaf c { mandatory; type int; description ...} >> } >> container d { >> ... >> leaf e { content, not mandatory ...} >> } >> } >> >> container ax { >> container bx { >> presence >> ... >> leaf cx { mandatory; type int; description ...} >> } >> container dx { >> ... >> leaf ex { content, not mandatory ...} >> } >> } >> >> Now, if a is in the top level of a module, and a user attempts to do a create >> operation on a/d/e, it seems to me that the point of c being mandatory is that >> a/b/c has to also be created (by the user) at the same time. > > Actually, if a is in the top level, the effect of having a/b/c as > mandatory is the same as if c was a mandatory leaf on the top level - > an agent that implements this module will require that a/b/c always > exists. > OK (agreed) -- and if a/b/c is inside: - case: then it is mandatory when its case is selected (one of its siblings in the case is present) - list: will be mandatory in any list with a key, since 'a' is a sibling of the key(s) (what about a list without any keys, read-only?) - P-container: will be mandatory if the P container is created by the manager - NP-container: logic transferred up one layer, not decided here? Or is 'a' mandatory if it has any siblings created in the NP-container, regardless of the existence of its parent NP container? still confused... >... > /martin Andy From mbj@tail-f.com Mon May 11 14:38: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 C7AFC3A6EE7 for ; Mon, 11 May 2009 14:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.189, 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 7dblVyyUNVFx for ; Mon, 11 May 2009 14:38: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 B61AE3A6E51 for ; Mon, 11 May 2009 14:37:59 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C7DB476C040; Mon, 11 May 2009 23:39:29 +0200 (CEST) Date: Mon, 11 May 2009 23:39:29 +0200 (CEST) Message-Id: <20090511.233929.91211465.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A089477.2090806@netconfcentral.com> References: <4A08487D.50007@joelhalpern.com> <20090511.211937.198859624.mbj@tail-f.com> <4A089477.2090806@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] Confusion about mandatory 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, 11 May 2009 21:38:00 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > "Joel M. Halpern" wrote: > >> Let me try restating with an example, both to indicate what I think the > >> point > >> is, and what I think the problem is. > >> (Apologies if I get the syntax slightly wrong. Also sorry for the length) > >> > >> Suppose we have two container definitions, which appear may appear in > >> various > >> places. > >> > >> container a { > >> container b { > >> ..... > >> leaf c { mandatory; type int; description ...} > >> } > >> container d { > >> ... > >> leaf e { content, not mandatory ...} > >> } > >> } > >> > >> container ax { > >> container bx { > >> presence > >> ... > >> leaf cx { mandatory; type int; description ...} > >> } > >> container dx { > >> ... > >> leaf ex { content, not mandatory ...} > >> } > >> } > >> > >> Now, if a is in the top level of a module, and a user attempts to do a > >> create > >> operation on a/d/e, it seems to me that the point of c being mandatory is > >> that > >> a/b/c has to also be created (by the user) at the same time. > > Actually, if a is in the top level, the effect of having a/b/c as > > mandatory is the same as if c was a mandatory leaf on the top level - > > an agent that implements this module will require that a/b/c always > > exists. > > > > OK (agreed) -- and if a/b/c is inside: > > - case: then it is mandatory when its case is selected > (one of its siblings in the case is present) Yes. > - list: will be mandatory in any list with a key, > since 'a' is a sibling of the key(s) Yes. > (what about a list without any keys, read-only?) They a/b/c must be present in a (idealized) reply. (see Section 8) > - P-container: will be mandatory if the P container > is created by the manager Yes. > - NP-container: logic transferred up one layer, Yes. > not decided here? Or is 'a' mandatory if > it has any siblings created in the NP-container, > regardless of the existence of its parent NP container? If a has siblings created, their common parent will also be created (so yes, this implies that if any sibling to a is created then a/b/c must also be created). (But I still prefer not to think of this as 'a' being mandatory - it is a/b/c that is mandatory, and from this it follows that a and b also will be created. ) /martin From andy@netconfcentral.com Mon May 11 17:00: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 F32893A6BA0 for ; Mon, 11 May 2009 17:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 Y3Fa2+qjl4H0 for ; Mon, 11 May 2009 17:00:17 -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 10F6628C13C for ; Mon, 11 May 2009 17:00:16 -0700 (PDT) Received: from [68.142.200.221] by n20.bullet.mail.mud.yahoo.com with NNFMP; 12 May 2009 00:01:44 -0000 Received: from [68.142.201.243] by t9.bullet.mud.yahoo.com with NNFMP; 12 May 2009 00:01:44 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 12 May 2009 00:01:44 -0000 X-Yahoo-Newman-Id: 554077.49779.bm@omp404.mail.mud.yahoo.com Received: (qmail 19850 invoked from network); 12 May 2009 00:01:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 12 May 2009 00:01:43 -0000 X-YMail-OSG: K.A2CKUVM1mxDS474Ak4u4h3l3FsK6mQI9qwZE9CkbO7.LofNPhWW2uAUU4tiApoqLL03pw7e_dSm6YyiMLy8cSDZYXzaa9GXYLcbwTw4sHzz5INAmoRLKtk3n243viab3JXVORLAHnV5D1Z77QyoV7vALXvzh4jbXgI2cA1lsHuR5YMcMcDvNTGS3JslDP20oyxNDNX5EFcv.235f0YORlZcl5QWT9sHZIF0ZZSn25WvgDpXGYW5LkuE86fBL9cUin3AvgMs4rYwSyCaO3dkgtAZkphPSJN_1Q2FqQAII6eTb0kT4NKhXvphgAlwQPm5B90l08MpI5r4I0JxfFyGn7AdRiisCpSXviQKSlWF.c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A08BC65.1010606@netconfcentral.com> Date: Mon, 11 May 2009 17:01:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A08487D.50007@joelhalpern.com> <20090511.211937.198859624.mbj@tail-f.com> <4A089477.2090806@netconfcentral.com> <20090511.233929.91211465.mbj@tail-f.com> In-Reply-To: <20090511.233929.91211465.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] Confusion about mandatory 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, 12 May 2009 00:00:18 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> "Joel M. Halpern" wrote: >>>> Let me try restating with an example, both to indicate what I think the >>>> point >>>> is, and what I think the problem is. >>>> (Apologies if I get the syntax slightly wrong. Also sorry for the length) >>>> >>>> Suppose we have two container definitions, which appear may appear in >>>> various >>>> places. >>>> >>>> container a { >>>> container b { >>>> ..... >>>> leaf c { mandatory; type int; description ...} >>>> } >>>> container d { >>>> ... >>>> leaf e { content, not mandatory ...} >>>> } >>>> } >>>> >>>> container ax { >>>> container bx { >>>> presence >>>> ... >>>> leaf cx { mandatory; type int; description ...} >>>> } >>>> container dx { >>>> ... >>>> leaf ex { content, not mandatory ...} >>>> } >>>> } >>>> >>>> Now, if a is in the top level of a module, and a user attempts to do a >>>> create >>>> operation on a/d/e, it seems to me that the point of c being mandatory is >>>> that >>>> a/b/c has to also be created (by the user) at the same time. >>> Actually, if a is in the top level, the effect of having a/b/c as >>> mandatory is the same as if c was a mandatory leaf on the top level - >>> an agent that implements this module will require that a/b/c always >>> exists. >>> >> OK (agreed) -- and if a/b/c is inside: >> >> - case: then it is mandatory when its case is selected >> (one of its siblings in the case is present) > > Yes. > >> - list: will be mandatory in any list with a key, >> since 'a' is a sibling of the key(s) > > Yes. > >> (what about a list without any keys, read-only?) > > They a/b/c must be present in a (idealized) reply. (see Section > 8) > >> - P-container: will be mandatory if the P container >> is created by the manager > > Yes. > >> - NP-container: logic transferred up one layer, > > Yes. > >> not decided here? Or is 'a' mandatory if >> it has any siblings created in the NP-container, >> regardless of the existence of its parent NP container? > > If a has siblings created, their common parent will also be created > (so yes, this implies that if any sibling to a is created then a/b/c > must also be created). > yes, of course; I should have said 'not just the existence of the parent'. > (But I still prefer not to think of this as 'a' being mandatory - it > is a/b/c that is mandatory, and from this it follows that a and b also > will be created. ) > OK So what was the original answer given to Phil when he complained that leaving empty NP containers in the config database was not OK, and they MUST be removed? That is, only empty P (not NP) containers should take up space is a valid config because they have 1 bit of semantics, whereas an NP-container has 0 bits. That seems like a good idea to me. (I don't know what edits would be needed however.) > > /martin > > Andy From jmh@joelhalpern.com Mon May 11 18:56: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 BCE2B3A694A for ; Mon, 11 May 2009 18:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.742, 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 Qo8WGFb+gmj9 for ; Mon, 11 May 2009 18:56:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F02263A6359 for ; Mon, 11 May 2009 18:55:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 766CA43400E for ; Mon, 11 May 2009 18:57:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 4D515434003 for ; Mon, 11 May 2009 18:57:21 -0700 (PDT) Message-ID: <4A08D77D.8060908@joelhalpern.com> Date: Mon, 11 May 2009 21:57:17 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <4A07F650.7060808@netconfcentral.com> <20090511.122406.171066697.mbj@tail-f.com> <4A08487D.50007@joelhalpern.com> <20090511.211937.198859624.mbj@tail-f.com> In-Reply-To: <20090511.211937.198859624.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Confusion about mandatory 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, 12 May 2009 01:56:22 -0000 (Leaving the text below, after my response, if someone wants the full context.) With regard to the case where the non-presence container is in the top level, a) What you assert about the mandatory leaf always being mandatory is not at all what the document says. (I am not sure whether your later comment about the text needing clarification was intended to say that.) b) It is not particularly obvious to me that making that leaf always mandatory is in any way related to what people would expect. But at least if we write it clearly, folks will know what to do. (If they don't want it always mandatory, make the top level container a presence container.) With regard to the choice/case issue, your udnerstanding of the text from the document: If this ancestor is a case node, the leaf MUST exist if any other node from the case exists. that this applies to sibling inside the container, as well as to siblings at the case, agrees with what I think is the behavior we want. However, it is not the meaning I get from the face of the words. I was looking for other nodes, other than the one containing the leaf, in the case. If we agree on the meaning, please improve the words. Thank you, Joel M. Halpern Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> Let me try restating with an example, both to indicate what I think the point >> is, and what I think the problem is. >> (Apologies if I get the syntax slightly wrong. Also sorry for the length) >> >> Suppose we have two container definitions, which appear may appear in various >> places. >> >> container a { >> container b { >> ..... >> leaf c { mandatory; type int; description ...} >> } >> container d { >> ... >> leaf e { content, not mandatory ...} >> } >> } >> >> container ax { >> container bx { >> presence >> ... >> leaf cx { mandatory; type int; description ...} >> } >> container dx { >> ... >> leaf ex { content, not mandatory ...} >> } >> } >> >> Now, if a is in the top level of a module, and a user attempts to do a create >> operation on a/d/e, it seems to me that the point of c being mandatory is that >> a/b/c has to also be created (by the user) at the same time. > > Actually, if a is in the top level, the effect of having a/b/c as > mandatory is the same as if c was a mandatory leaf on the top level - > an agent that implements this module will require that a/b/c always > exists. > >> Conversely, if ax is in the top level of a module, and a user attempts to >> create ax/dx/ex, the fact that bx is a presence container means that ax/bx/cd >> does not need to be created at that time. ax/bx/cx needs to be created either >> when the user want sot create it explicitly, or when the user wants to create >> some sibling of cx in bx. >> >> The problem that far is that the document simply does not talk about what >> happens when there is no parent presence container. > > Yes, as I said in my earlier email, I agree that this is a problem > that must be addressed. > >> In a choice, >> there is a similar, but not identical problem. >> >> choice f { >> case g: >> insert container a here >> with no other siblings >> >> case h: >> some other options >> } >> >> As written, since a has no siblings in g, if the user goes to create a/d/e, >> there is no requirement that a/b/c must be created at the same time. > > The intention is that a/b/c must be created in this case. Following > 7.6.4, the closest ancestor node to f/g/a/b/c in the schema tree which > is not a p-container is f/g (the case node). Then 7.6.4 says > > If this ancestor is a case node, the leaf MUST exist if any other > node from the case exists. > > And in this case the nodes f/g/a, f/g/a/d and f/g/a/d/e exist, so it > follows that f/g/a/b/c also must exist. > >> To phrase this differently, the mental model I have starts from >> a non-presence container is conceptually created whenever any element inside it >> is created. > > Yes, and further that np containers are really transparent - you get > the same effect by removing all np containers (modulo the object's > names of course). > > > /martin > From mbj@tail-f.com Tue May 12 05:28: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 3A5F23A6B71 for ; Tue, 12 May 2009 05:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.185, 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 aM4hsfsK5uU4 for ; Tue, 12 May 2009 05:28: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 2211D3A6A80 for ; Tue, 12 May 2009 05:28: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 F3DBB76C4E6; Tue, 12 May 2009 14:29:28 +0200 (CEST) Date: Tue, 12 May 2009 14:29:28 +0200 (CEST) Message-Id: <20090512.142928.267840994.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A08D77D.8060908@joelhalpern.com> References: <4A08487D.50007@joelhalpern.com> <20090511.211937.198859624.mbj@tail-f.com> <4A08D77D.8060908@joelhalpern.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] Confusion about mandatory 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, 12 May 2009 12:28:01 -0000 "Joel M. Halpern" wrote: > With regard to the case where the non-presence container is in the top level, > a) What you assert about the mandatory leaf always being mandatory is not at > all what the document says. (I am not sure whether your later comment about > the text needing clarification was intended to say that.) It was. See below. > b) It is not particularly obvious to me that making that leaf always mandatory > is in any way related to what people would expect. But at least if we write it > clearly, folks will know what to do. (If they don't want it always mandatory, > make the top level container a presence container.) For the rationale, consider this example with two mandatory leafs: leaf ip { mandatory true; type inet:ip-address; } leaf port { mandatory true; type inet:port-number; } When their relevant parent node is created, they must also be created. Now, suppose I want this behavior, but for organizational reasons, I want to wrap these leafs in a container: container address { leaf ip { mandatory true; type inet:ip-address; } leaf port { mandatory true; type inet:port-number; } } The semantics are the same - whenever the relevant parent node is created, the two leafs must be created. The same rules should apply to top-level nodes - if I have: module system { ... leaf sys-name { mandatory true; type string: } ... } The leaf 'sys-name' must exist in a server which implements the 'system' module. With an organizational wrapper container: module system { ... container sys { leaf name { mandatory true; type string: } ... } ... } The leaf /sys/name must always exist. I suggest the following change to 7.6.4: OLD: 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): o If this ancestor is a case node, the leaf MUST exist if any other node from the case exists. o Otherwise, the leaf MUST exist if the ancestor node exists. NEW: 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): o If no such ancestor exists, the leaf MUST exist. o Otherwise, if this ancestor is a case node, the leaf MUST exist if any other node from the case exists. o Otherwise, the leaf MUST exist if the ancestor node exists. > With regard to the choice/case issue, your udnerstanding of the text from the > document: > If this ancestor is a case node, the leaf MUST exist if any other > node from the case exists. > that this applies to sibling inside the container, as well as to siblings at > the case, agrees with what I think is the behavior we want. > However, it is not the meaning I get from the face of the words. I was looking > for other nodes, other than the one containing the leaf, in the case. If we > agree on the meaning, please improve the words. Can we just remove the word 'other' and get: o Otherwise, if this ancestor is a case node, the leaf MUST exist if any node from the case exists. /martin From jmh@joelhalpern.com Tue May 12 08:01: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 09F683A6BAB for ; Tue, 12 May 2009 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.005 X-Spam-Level: X-Spam-Status: No, score=-3.005 tagged_above=-999 required=5 tests=[AWL=0.594, 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 D6aNAb0rc8qe for ; Tue, 12 May 2009 08:01:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3102A3A6BAA for ; Tue, 12 May 2009 08:01:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5D26C430363 for ; Tue, 12 May 2009 08:03:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 3270643034D for ; Tue, 12 May 2009 08:03:06 -0700 (PDT) Message-ID: <4A098FA6.1070908@joelhalpern.com> Date: Tue, 12 May 2009 11:03:02 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <4A08487D.50007@joelhalpern.com> <20090511.211937.198859624.mbj@tail-f.com> <4A08D77D.8060908@joelhalpern.com> <20090512.142928.267840994.mbj@tail-f.com> In-Reply-To: <20090512.142928.267840994.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Confusion about mandatory 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, 12 May 2009 15:01:38 -0000 The combined set of changes below work for me. Thank you, Joel PS: Thinking about it over night, making a leaf which is marked mandatory and in the module itself via non-presence containers mandatory is actually quite reasonable. Your example makes sense to me. Thanks. Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> With regard to the case where the non-presence container is in the top level, >> a) What you assert about the mandatory leaf always being mandatory is not at >> all what the document says. (I am not sure whether your later comment about >> the text needing clarification was intended to say that.) > > It was. See below. > >> b) It is not particularly obvious to me that making that leaf always mandatory >> is in any way related to what people would expect. But at least if we write it >> clearly, folks will know what to do. (If they don't want it always mandatory, >> make the top level container a presence container.) > > For the rationale, consider this example with two mandatory leafs: > > leaf ip { > mandatory true; > type inet:ip-address; > } > leaf port { > mandatory true; > type inet:port-number; > } > > When their relevant parent node is created, they must also be > created. > > Now, suppose I want this behavior, but for organizational reasons, I > want to wrap these leafs in a container: > > container address { > leaf ip { > mandatory true; > type inet:ip-address; > } > leaf port { > mandatory true; > type inet:port-number; > } > } > > The semantics are the same - whenever the relevant parent node is > created, the two leafs must be created. > > > The same rules should apply to top-level nodes - if I have: > > module system { > ... > leaf sys-name { > mandatory true; > type string: > } > ... > } > > The leaf 'sys-name' must exist in a server which implements the > 'system' module. > > With an organizational wrapper container: > > module system { > ... > container sys { > leaf name { > mandatory true; > type string: > } > ... > } > ... > } > > The leaf /sys/name must always exist. > > > I suggest the following change to 7.6.4: > > OLD: > > 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): > > o If this ancestor is a case node, the leaf MUST exist if any other > node from the case exists. > > o Otherwise, the leaf MUST exist if the ancestor node exists. > > NEW: > > 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): > > o If no such ancestor exists, the leaf MUST exist. > > o Otherwise, if this ancestor is a case node, the leaf MUST exist > if any other node from the case exists. > > o Otherwise, the leaf MUST exist if the ancestor node exists. > > > >> With regard to the choice/case issue, your udnerstanding of the text from the >> document: >> If this ancestor is a case node, the leaf MUST exist if any other >> node from the case exists. >> that this applies to sibling inside the container, as well as to siblings at >> the case, agrees with what I think is the behavior we want. >> However, it is not the meaning I get from the face of the words. I was looking >> for other nodes, other than the one containing the leaf, in the case. If we >> agree on the meaning, please improve the words. > > Can we just remove the word 'other' and get: > > o Otherwise, if this ancestor is a case node, the leaf MUST exist > if any node from the case exists. > > > /martin > From jmh@joelhalpern.com Tue May 12 08:26: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 7233B3A68C3 for ; Tue, 12 May 2009 08:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.104 X-Spam-Level: X-Spam-Status: No, score=-3.104 tagged_above=-999 required=5 tests=[AWL=0.495, 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 RfSfndUqGJp1 for ; Tue, 12 May 2009 08:26:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7214E3A680F for ; Tue, 12 May 2009 08:26:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 61C41430348 for ; Tue, 12 May 2009 08:28:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 26851430324 for ; Tue, 12 May 2009 08:28:23 -0700 (PDT) Message-ID: <4A099593.5090006@joelhalpern.com> Date: Tue, 12 May 2009 11:28:19 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <4A0348EE.2050907@joelhalpern.com> <20090510.231542.108420990.mbj@tail-f.com> In-Reply-To: <20090510.231542.108420990.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] WG last call 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, 12 May 2009 15:26:52 -0000 Thanks for the response. Most of them look good. Here are amplifications on a few points. Thank you, Joel Martin Bjorklund wrote: > Hi, > > "Joel M. Halpern" wrote: >> Minor: ... >> 5) In section 7.5.8 on the use of edit-config with containers, there >> seem to be a number of pieces that are not described. Some of these >> are covered by the general description in netconf (for example on the >> relationship between merge and replace.) Even so, a sentence here >> saying that would be helpful. >> However, there is one case where the netconf stuff does not seem to >> help. >> On "replace," if the node exists, what happens with regard to child >> nodes present in the XML and the datastore? (It seems clear that the >> recursive behavior of "replace" is somewhat different from "replace" >> on the parent, and for good reasons.) > > 7.5.8 says: > > If the operation is "replace" and the node exists, all child nodes > not present in the XML are deleted, and child nodes present in the > XML but not present in the datastore are created. > > Doesn't this cover your question? The question is what happens with child nodes present in both the XML and the datastore. Neither of the two clauses covers that. (Given the subtleties, even if you think the existing netconf definition covers it, please restate here.) > >> 6) Should there be some sort of comment in the description of choice >> that the given rules are not sufficient to ensure that all choice >> definitions are unambiguous, and it is the model developer's >> responsibility to ensure that if the distinction matters that the >> various combinations of possible defaults is unambiguous? (I am >> thinking about a choice without an explicit default, where two of the >> branches are such that they can legally exist with with just default >> values (they have no mandatory components.) >> I think that the rules as >> written permit ambiguities, and that the system could not determine >> which branch was actually the case. > > Could you clarify this, preferably by giving an example which you > think is ambiguous? After looking at this some more, I believe that the intended meaning has no ambiguity. But this relies on the question of the scope of identifiers under cases in a choice. Looking back at 6.2.1, leaf and container names are scoped to their "parent node." If the case is the parent node, then one could get name duplication across cases within a choice, and all sorts of confusion could result. I believe the intent is that for name scoping purposes, the scope is the entire choice, not the individual case. Is there somewhere we can say that? (In 6.2.1. would seem right.) > >> 7) In the definition of the RPC element, I presume that there are >> constraints on the use of the "grouping" element? When groupings >> appear directly in the rpc element, they can not define any data >> components other than input or output? > > A grouping can never define 'input' or 'output'. Note that the > grouping statement *defines* the grouping (like typedef defines a > type), so having a grouping under the rpc just defines a grouping > which can be reused in the substatements to 'input' and 'output'. Sorry, I don't follow. The input and output substatements each explicitly allow "uses." That's fine. But the rpc element itself allows "uses." If groupings can not define input or output, then a grouping can not appear directly under rpc, and should not be listed there. > >> 8) notifications ... >> I think, if I am reading this right, that >> the plan in netmod is to simply define the information to be reported, >> and to use description clauses to indicate where the information >> really comes from? A little more explanation of this in the >> notification section would be helpful. > > Could you suggest some text to add? "A notification will typically be defined to include the indication of what the problem is, and any relevant data. The relevant data is defined as leaf elements in the notification. The semantics that these are copies of other information in the datastore, for reporting purposes, is captured in the relevant description clauses." ... From mbj@tail-f.com Tue May 12 13:35: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 BA5873A6D59 for ; Tue, 12 May 2009 13:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.183, 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 qVYKvQ0Pbfbw for ; Tue, 12 May 2009 13:35:18 -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 762593A69EE for ; Tue, 12 May 2009 13:35:18 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1AA89616019; Tue, 12 May 2009 22:36:47 +0200 (CEST) Date: Tue, 12 May 2009 22:36:46 +0200 (CEST) Message-Id: <20090512.223646.258818796.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A099593.5090006@joelhalpern.com> References: <4A0348EE.2050907@joelhalpern.com> <20090510.231542.108420990.mbj@tail-f.com> <4A099593.5090006@joelhalpern.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] WG last call 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, 12 May 2009 20:35:19 -0000 Hi, "Joel M. Halpern" wrote: > Thanks for the response. Most of them look good. Here are amplifications on a > few points. > > Thank you, > Joel > > Martin Bjorklund wrote: > > Hi, > > "Joel M. Halpern" wrote: > >> Minor: > ... > >> 5) In section 7.5.8 on the use of edit-config with containers, there > >> seem to be a number of pieces that are not described. Some of these > >> are covered by the general description in netconf (for example on the > >> relationship between merge and replace.) Even so, a sentence here > >> saying that would be helpful. > >> However, there is one case where the netconf stuff does not seem to > >> help. > >> On "replace," if the node exists, what happens with regard to child > >> nodes present in the XML and the datastore? (It seems clear that the > >> recursive behavior of "replace" is somewhat different from "replace" > >> on the parent, and for good reasons.) > > 7.5.8 says: > > If the operation is "replace" and the node exists, all child nodes > > not present in the XML are deleted, and child nodes present in the > > XML but not present in the datastore are created. > > Doesn't this cover your question? > > The question is what happens with child nodes present in both the XML and the > datastore. Neither of the two clauses covers that. (Given the subtleties, > even if you think the existing netconf definition covers it, please restate > here.) Ok, I see what you mean. I will get back to you... > >> 6) Should there be some sort of comment in the description of choice > >> that the given rules are not sufficient to ensure that all choice > >> definitions are unambiguous, and it is the model developer's > >> responsibility to ensure that if the distinction matters that the > >> various combinations of possible defaults is unambiguous? (I am > >> thinking about a choice without an explicit default, where two of the > >> branches are such that they can legally exist with with just default > >> values (they have no mandatory components.) > >> I think that the rules as > >> written permit ambiguities, and that the system could not determine > >> which branch was actually the case. > > Could you clarify this, preferably by giving an example which you > > think is ambiguous? > > After looking at this some more, I believe that the intended meaning has no > ambiguity. But this relies on the question of the scope of identifiers under > cases in a choice. Looking back at 6.2.1, leaf and container names are scoped > to their "parent node." If the case is the parent node, then one could get > name duplication across cases within a choice, and all sorts of confusion could > result. > > I believe the intent is that for name scoping purposes, the scope is the entire > choice, not the individual case. Is there somewhere we can say that? (In > 6.2.1. would seem right.) 6.2.1. tries to say that: 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. Note the last two sentences. > >> 7) In the definition of the RPC element, I presume that there are > >> constraints on the use of the "grouping" element? When groupings > >> appear directly in the rpc element, they can not define any data > >> components other than input or output? > > A grouping can never define 'input' or 'output'. Note that the > > grouping statement *defines* the grouping (like typedef defines a > > type), so having a grouping under the rpc just defines a grouping > > which can be reused in the substatements to 'input' and 'output'. > > Sorry, I don't follow. The input and output substatements each explicitly > allow "uses." That's fine. But the rpc element itself allows > "uses." Where do you see that? "uses" is not listed in 7.13.1, and it not listed in the ABNF rule for rpc-stmt. > >> 8) notifications ... > >> I think, if I am reading this right, that > >> the plan in netmod is to simply define the information to be reported, > >> and to use description clauses to indicate where the information > >> really comes from? A little more explanation of this in the > >> notification section would be helpful. > > Could you suggest some text to add? > > "A notification will typically be defined to include the indication of what the > problem is, and any relevant data. The relevant data is defined as leaf > elements in the notification. The semantics that these are copies of other > information in the datastore, for reporting purposes, is captured in the > relevant description clauses." But this seems too restrictive - leafrefs can be used to have a formal reference to config / stats data. An example is given in 9.9.6: notification link-failure { leaf if-name { type leafref { path "/interfaces/interface/name"; } } leaf index { type leafref { path "/interfaces/interface[name = current()/../if-name]" + "/ifIndex"; } } } /martin From Washam.Fan@huaweisymantec.com Tue May 12 18:26: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 3EA513A67D2 for ; Tue, 12 May 2009 18:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 grzb95iotpLl for ; Tue, 12 May 2009 18:26:58 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 01AED3A67CC for ; Tue, 12 May 2009 18:26:57 -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 <0KJK007TQ6R3LB70@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 13 May 2009 09:28:17 +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 <0KJK0052T6R1QM20@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 13 May 2009 09:28:15 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 13 May 2009 09:28:13 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Wed, 13 May 2009 09:28:13 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090512.142928.267840994.mbj@tail-f.com> References: <4A08487D.50007@joelhalpern.com> <20090511.211937.198859624.mbj@tail-f.com> <4A08D77D.8060908@joelhalpern.com> <20090512.142928.267840994.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Confusion about mandatory 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, 13 May 2009 01:26:59 -0000 > I suggest the following change to 7.6.4: > > OLD: > > 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): > > o If this ancestor is a case node, the leaf MUST exist if any other > node from the case exists. > > o Otherwise, the leaf MUST exist if the ancestor node exists. > > NEW: > > 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): ^^^^^^ I assume it was a typo, it should have been "non-presence" instead, right? washam > o If no such ancestor exists, the leaf MUST exist. > > o Otherwise, if this ancestor is a case node, the leaf MUST exist > if any other node from the case exists. > > o Otherwise, the leaf MUST exist if the ancestor node exists. From Washam.Fan@huaweisymantec.com Tue May 12 19:14: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 A97D13A6C54 for ; Tue, 12 May 2009 19:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=-0.272, 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 JykcZSQ-rC1p for ; Tue, 12 May 2009 19:14:43 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id A8B0A3A69C6 for ; Tue, 12 May 2009 19:14:42 -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 <0KJK007CM8YPLB80@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 13 May 2009 10:16:03 +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 <0KJK0053C8YN7O20@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 13 May 2009 10:16:01 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 13 May 2009 10:15:59 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Wed, 13 May 2009 10:15:59 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090512.223646.258818796.mbj@tail-f.com> References: <4A0348EE.2050907@joelhalpern.com> <20090510.231542.108420990.mbj@tail-f.com> <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] WG last call 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: Wed, 13 May 2009 02:14:43 -0000 > > >> 5) In section 7.5.8 on the use of edit-config with containers, there > > >> seem to be a number of pieces that are not described. Some of these > > >> are covered by the general description in netconf (for example > on the > > >> relationship between merge and replace.) Even so, a sentence here > > >> saying that would be helpful. > > >> However, there is one case where the netconf stuff does not seem > to > > >> help. > > >> On "replace," if the node exists, what happens with regard to child > > >> nodes present in the XML and the datastore? (It seems clear > that the > > >> recursive behavior of "replace" is somewhat different from "replace" > > >> on the parent, and for good reasons.) > > > 7.5.8 says: > > > If the operation is "replace" and the node exists, all child nodes > > > not present in the XML are deleted, and child nodes present > in the > > > XML but not present in the datastore are created. IMO, if the operation is "replace" and the node exists, the server should substitute the node in the datastore with the corresponding node in the XML. I.e., all child nodes are deleted, then all child nodes present in the XML are created. Any comments? washam From jmh@joelhalpern.com Tue May 12 19:49: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 88FA93A68E4 for ; Tue, 12 May 2009 19:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.175 X-Spam-Level: X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 l04hHMV5GagM for ; Tue, 12 May 2009 19:49:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EFE0F3A689D for ; Tue, 12 May 2009 19:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3EB74430559 for ; Tue, 12 May 2009 19:50:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 20292430554 for ; Tue, 12 May 2009 19:50:49 -0700 (PDT) Message-ID: <4A0A3585.80103@joelhalpern.com> Date: Tue, 12 May 2009 22:50:45 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <4A0348EE.2050907@joelhalpern.com> <20090510.231542.108420990.mbj@tail-f.com> <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.mbj@tail-f.com> In-Reply-To: <20090512.223646.258818796.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] WG last call 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: Wed, 13 May 2009 02:49:17 -0000 With regard to the two items that you observed there was already text for, you are correct. I am apparently going blind. With regard to the notifications, it may be that I am misudnerstanding what including a leafref in a notification will do. Will it include in the notification the value of the leaf pointed to? If so, that would be perfect and there is no need for the text I sent. I had understood that it would send a reference (an identifier, presumably xpath?) for the leaf. [More depending upon meaning...] With regard to the edit-config on containers, I look forward to the additional clarification. Thank you, Joel From reid@snmp.com Tue May 12 20:08: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 DB12D3A696A for ; Tue, 12 May 2009 20:08:04 -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 GID8baNjywH3 for ; Tue, 12 May 2009 20:08:04 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id D0B293A68D1 for ; Tue, 12 May 2009 20:08:03 -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 XAA05134 for ; Tue, 12 May 2009 23:09:35 -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 XAA01033 for ; Tue, 12 May 2009 23:09:34 -0400 (EDT) Message-Id: <200905130309.XAA01033@adminfs.snmp.com> To: netmod@ietf.org Date: Tue, 12 May 2009 23:09:33 -0400 From: David Reid Subject: [netmod] WGLC comments about notifications 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, 13 May 2009 03:08:04 -0000 I have a few comments and questions about the notification examples. The example in section 4.2.10 defines a leaf of type ifAdminStatus. notification link-failure { description "A link failure has been detected"; leaf if-name { type keyref { path "/interfaces/interface/name"; } } leaf if-admin-status { type ifAdminStatus; } } I find it confusing to use ifAdminStatus as a type since ifAdminStatus is a well known MIB object from MIB-2. I think a different type would be more clear. Would it be better to make this a leafref? This example was originally written when we had keyref but not leafref. Now that we have leafref, I think that would be a better example. -- The notification example in section 9.9.6: notification link-failure { leaf if-name { type leafref { path "/interfaces/interface/name"; } } leaf index { type leafref { path "/interfaces/interface[name = current()/../if-name]" + "/ifIndex"; } } } I find the use of ifIndex confusing because I expect it to be the key for the interfaces table. But in this example, it is not a key. I think it would be better to use a name other than ifIndex. It might also be instructive to show a notification example that includes an object from a list with more than one key. -- If I want to have objects from more than one list in my notification, do I need put the the objects in different containers? -- >From section 9.9.2: The predicates are only used when more than one key reference is needed to uniquely identify a leaf instance. This occurs if a list has multiple keys, or a reference to a leaf other than the key in a list is needed. In these cases, multiple leafrefs are typically specified, and predicates are used to tie them together. This paragraph was not clear to me. I'm not sure that anything in the text needs to be changed, maybe I just need to read an xpath book. Or maybe someone could explain it to me in different words or with an example. -- In SNMP notifications, an agent is allowed to append as many additional objects as it considers useful to the end of the notification. This has proved useful in many implementations. Can I do this in yang? I guess I can augment any notification and add whatever I want. -David Reid From mbj@tail-f.com Tue May 12 23:39: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 97A5F28C0F7 for ; Tue, 12 May 2009 23:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=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 u-FcxJEInZsL for ; Tue, 12 May 2009 23:39:57 -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 A8F273A6E14 for ; Tue, 12 May 2009 23:39: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 68E33616027; Wed, 13 May 2009 08:41:26 +0200 (CEST) Date: Wed, 13 May 2009 08:41:25 +0200 (CEST) Message-Id: <20090513.084125.113691692.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <4A08D77D.8060908@joelhalpern.com> <20090512.142928.267840994.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] Confusion about mandatory 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, 13 May 2009 06:39:58 -0000 WashamFan wrote: > > I suggest the following change to 7.6.4: > > > > OLD: > > > > 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): > > > > o If this ancestor is a case node, the leaf MUST exist if any other > > node from the case exists. > > > > o Otherwise, the leaf MUST exist if the ancestor node exists. > > > > NEW: > > > > 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): > ^^^^^^ > I assume it was a typo, it should have been "non-presence" instead, right? Yes, typo. I copy&pasted from the published draft, but in my sources I have your fix. It should be "non-presence". /martin From mbj@tail-f.com Tue May 12 23:46: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 A48723A6B8A for ; Tue, 12 May 2009 23:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.183, 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 ndCUGAUUBadh for ; Tue, 12 May 2009 23:46: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 C918F3A6AEF for ; Tue, 12 May 2009 23:46: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 8CD56616027; Wed, 13 May 2009 08:48:05 +0200 (CEST) Date: Wed, 13 May 2009 08:48:05 +0200 (CEST) Message-Id: <20090513.084805.140625166.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A0A3585.80103@joelhalpern.com> References: <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.mbj@tail-f.com> <4A0A3585.80103@joelhalpern.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] WG last call 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: Wed, 13 May 2009 06:46:41 -0000 Hi, "Joel M. Halpern" wrote: > With regard to the notifications, it may be that I am misudnerstanding what > including a leafref in a notification will do. > Will it include in the notification the value of the leaf pointed to? If so, > that would be perfect and there is no need for the text I sent. I had > understood that it would send a reference (an identifier, presumably xpath?) > for the leaf. [More depending upon meaning...] Yes, when the leafref is encoded in XML, the value of the leaf pointed to is included. In 9.9.6, there is an example of the XML encoding for the notification I sent in the previous email: 2008-04-01T00:01:00Z eth0 2 <--- This is the leafref /martin From mbj@tail-f.com Wed May 13 00:08: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 430643A6B8A for ; Wed, 13 May 2009 00:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.181, 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 bp0Lw2rJSkA8 for ; Wed, 13 May 2009 00:08: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 27EBD3A68B9 for ; Wed, 13 May 2009 00:08: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 E89A461600B; Wed, 13 May 2009 09:09:37 +0200 (CEST) Date: Wed, 13 May 2009 09:09:37 +0200 (CEST) Message-Id: <20090513.090937.70620022.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200905130309.XAA01033@adminfs.snmp.com> References: <200905130309.XAA01033@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] WGLC comments about notifications 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, 13 May 2009 07:08:07 -0000 Hi David, David Reid wrote: > I have a few comments and questions about the notification examples. > > The example in section 4.2.10 defines a leaf of type ifAdminStatus. > > notification link-failure { > description "A link failure has been detected"; > leaf if-name { > type keyref { > path "/interfaces/interface/name"; > } > } > leaf if-admin-status { > type ifAdminStatus; > } > } > > I find it confusing to use ifAdminStatus as a type since > ifAdminStatus is a well known MIB object from MIB-2. I think a > different type would be more clear. Would it be better to make this > a leafref? This example was originally written when we had keyref > but not leafref. Now that we have leafref, I think that would be a > better example. I want to show also some leafs which are not leafrefs, and I believe we have some other examples of notifications with leafrefs. So I suggest we simply call the type "AdminStatus". > The notification example in section 9.9.6: > > notification link-failure { > leaf if-name { > type leafref { > path "/interfaces/interface/name"; > } > } > leaf index { > type leafref { > path > "/interfaces/interface[name = current()/../if-name]" > + "/ifIndex"; > } > } > } > > I find the use of ifIndex confusing because I expect it to be the key for > the interfaces table. But in this example, it is not a key. I think it would > be better to use a name other than ifIndex. Ok, I will simply remove ifIndex from the examples in this section. > It might also be instructive to show a notification example that includes > an object from a list with more than one key. > > -- > > If I want to have objects from more than one list in my notification, do I > need put the the objects in different containers? No. > From section 9.9.2: > > The predicates are only used when more than one key reference is > needed to uniquely identify a leaf instance. This occurs if a list > has multiple keys, or a reference to a leaf other than the key in a > list is needed. In these cases, multiple leafrefs are typically > specified, and predicates are used to tie them together. > > This paragraph was not clear to me. I'm not sure that anything in the text > needs to be changed, maybe I just need to read an xpath book. Or maybe someone > could explain it to me in different words or with an example. A predicate in the leafref path is the stuff inside the square brackets. There are some examples of using predicates in 9.9.6 (leafref usage examples). If the leafref points to a single-keyed list, you don't use predicates: leaf if-name { type leafref { path "/interfaces/interface/name"; } } But if there's a list 'address' within the interface list, you need to specify the values for both the interface name and the address ip: leaf address { type leafref { path "/interfaces/interface[name = current()/../if-name]" + "/address/ip"; } } The predicate is used to select the interface entry. > In SNMP notifications, an agent is allowed to append as many additional > objects as it considers useful to the end of the notification. This has > proved useful in many implementations. Can I do this in yang? I guess I > can augment any notification and add whatever I want. Yes, you can do this with augment. /martin From j.schoenwaelder@jacobs-university.de Wed May 13 00:14: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 63DC728C1C9 for ; Wed, 13 May 2009 00:14:20 -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 LIkMifmP6C7I for ; Wed, 13 May 2009 00:14:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6A8BF3A6F25 for ; Wed, 13 May 2009 00:14:19 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4814BC0176; Wed, 13 May 2009 09:15:51 +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 0LzWt2WDQDF3; Wed, 13 May 2009 09:15: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 68DEEC0160; Wed, 13 May 2009 09:15:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 92BE4AE9E8F; Wed, 13 May 2009 09:15:29 +0200 (CEST) Date: Wed, 13 May 2009 09:15:29 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090513071529.GA5002@elstar.local> Mail-Followup-To: Martin Bjorklund , "reid@snmp.com" , "netmod@ietf.org" References: <200905130309.XAA01033@adminfs.snmp.com> <20090513.090937.70620022.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090513.090937.70620022.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] WGLC comments about notifications 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, 13 May 2009 07:14:20 -0000 On Wed, May 13, 2009 at 09:09:37AM +0200, Martin Bjorklund wrote: > I want to show also some leafs which are not leafrefs, and I believe > we have some other examples of notifications with leafrefs. So I > suggest we simply call the type "AdminStatus". Or admin-status to be consistent in writing style... /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 Wed May 13 03:04: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 E5B353A6E28 for ; Wed, 13 May 2009 03:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.180, 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 TOnL2uXR4N0a for ; Wed, 13 May 2009 03:04:50 -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 2B10D3A6DB9 for ; Wed, 13 May 2009 03:04: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 EA2F161600B; Wed, 13 May 2009 12:06:20 +0200 (CEST) Date: Wed, 13 May 2009 12:06:20 +0200 (CEST) Message-Id: <20090513.120620.124679032.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <20090513.090937.70620022.mbj@tail-f.com> References: <200905130309.XAA01033@adminfs.snmp.com> <20090513.090937.70620022.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] WGLC comments about notifications 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, 13 May 2009 10:04:51 -0000 Martin Bjorklund wrote: > David Reid wrote: > > The notification example in section 9.9.6: > > > > notification link-failure { > > leaf if-name { > > type leafref { > > path "/interfaces/interface/name"; > > } > > } > > leaf index { > > type leafref { > > path > > "/interfaces/interface[name = current()/../if-name]" > > + "/ifIndex"; > > } > > } > > } > > > > I find the use of ifIndex confusing because I expect it to be the key for > > the interfaces table. But in this example, it is not a key. I > > think it would > > be better to use a name other than ifIndex. > > Ok, I will simply remove ifIndex from the examples in this section. On second thought I changed this leaf to an admin-statues leaf. One example shows how a leafref is used to reference a non-key leaf, and I think we should keep it. So we get: list interface { key "name"; leaf name { type string; } leaf admin-status { type admin-status; } list address { key "ip"; leaf ip { type yang:ip-address; } } } and the notification: notification link-failure { leaf if-name { type leafref { path "/interfaces/interface/name"; } } leaf admin-status { type leafref { path "/interfaces/interface[name = current()/../if-name]" + "/admin-status"; } } } An example of a corresponding XML notification: 2008-04-01T00:01:00Z eth0 up /martin From root@core3.amsl.com Wed May 13 03:30:02 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 0F2C23A6E0A; Wed, 13 May 2009 03:30: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: <20090513103002.0F2C23A6E0A@core3.amsl.com> Date: Wed, 13 May 2009 03:30:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-types-03.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, 13 May 2009 10:30:02 -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 : Common YANG Data Types Author(s) : J. Schoenwaelder Filename : draft-ietf-netmod-yang-types-03.txt Pages : 68 Date : 2009-05-13 This document introduces a collection of common data types to be used with the YANG data modeling language. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-types-03.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-types-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-13032746.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Wed May 13 03:36: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 9D4B93A6988 for ; Wed, 13 May 2009 03:36:29 -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 4j6VdUx0JwqC for ; Wed, 13 May 2009 03:36:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BA8843A690B for ; Wed, 13 May 2009 03:36:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74BE9C019E for ; Wed, 13 May 2009 12:38: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 QAEWeh2eMKi8; Wed, 13 May 2009 12:37: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 6B079C0197; Wed, 13 May 2009 12:37:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E5CF0AEA358; Wed, 13 May 2009 12:37:37 +0200 (CEST) Date: Wed, 13 May 2009 12:37:37 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090513103737.GA6096@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20090513103002.0F2C23A6E0A@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090513103002.0F2C23A6E0A@core3.amsl.com> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-types-03.txt 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, 13 May 2009 10:36:29 -0000 On Wed, May 13, 2009 at 12:30:02PM +0200, Internet-Drafts@ietf.org wrote: > Title : Common YANG Data Types > Author(s) : J. Schoenwaelder > Filename : draft-ietf-netmod-yang-types-03.txt > Pages : 68 > Date : 2009-05-13 > > This document introduces a collection of common data types to be used > with the YANG data modeling language. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-types-03.txt This version should be ready for WG last call. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed May 13 04:47: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 D49EE3A6F6A for ; Wed, 13 May 2009 04:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 xxLpO5kBUhQa for ; Wed, 13 May 2009 04:47:16 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9155D3A6C09 for ; Wed, 13 May 2009 04:47:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,187,1241409600"; d="scan'208";a="170717868" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 May 2009 07:48:48 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 13 May 2009 07:48:47 -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: Wed, 13 May 2009 13:48:46 +0200 Message-ID: In-Reply-To: <20090513103737.GA6096@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] I-D Action:draft-ietf-netmod-yang-types-03.txt Thread-Index: AcnTtuYekZJIRnHXRYSPwFqiL1BBLgABa4sQ References: <20090513103002.0F2C23A6E0A@core3.amsl.com> <20090513103737.GA6096@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-types-03.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, 13 May 2009 11:47:18 -0000 So you may want to consider this as a WGLC comment.=20 The following description (repeated another couple of times) taken from RFC 2579 MacAddress TC is slightly inaccurate:=20 "The mac-address type represents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. This type is in the value set and its semantics equivalent to the MacAddress textual convention of the SMIv2."; 1. s/802 MAC address/IEEE 802 MAC address/ 2. The canonical order is currently defined not in IEEE 802.1a which does not exist any longer but in IEEE Std. 802-2001. The definition of what 'canonical' means is also worded differently there, but we may keep the one used in 2579 as they are equivalent and the one in 2579 is more practical.=20 3. s/802.5/IEEE 802.5/ 4. s/802.x/IEEE 802.x/ 5. We should make clear that what Token Ring (IEEE 802.5) was doing was using the non-canonical order. Also as 802.5 is no longer used and has little chances to be used with NETMOD ever, maybe past tense is more appropriate.=20 So if we are to include all the edits above the description could look like: "The mac-address type represents an IEEE 802 MAC address represented in the `canonical' order defined by IEEE Std. 802-2001, i.e., as if it were transmitted least significant bit first, even though IEEE 802.5 (in contrast to other IEEE 802.x protocols) used the 'non-canonical' order=20 that requires MAC addresses to be transmitted most significant bit first. This type is in the value set and its semantics equivalent to the MacAddress textual convention of the SMIv2."; Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, May 13, 2009 1:38 PM > To: netmod@ietf.org > Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-types-03.txt >=20 > On Wed, May 13, 2009 at 12:30:02PM +0200,=20 > Internet-Drafts@ietf.org wrote: > =20 > > Title : Common YANG Data Types > > Author(s) : J. Schoenwaelder > > Filename : draft-ietf-netmod-yang-types-03.txt > > Pages : 68 > > Date : 2009-05-13 > >=20 > > This document introduces a collection of common data types=20 > to be used=20 > > with the YANG data modeling language. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-types-03.tx > > t >=20 > This version should be ready for WG last call. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From j.schoenwaelder@jacobs-university.de Wed May 13 05:32: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 E5C8F3A6B3D for ; Wed, 13 May 2009 05:32:18 -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 yCkvlNUL3ILC for ; Wed, 13 May 2009 05:32:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A7F6D3A68D9 for ; Wed, 13 May 2009 05:32:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A79AEC01C3; Wed, 13 May 2009 14:33:49 +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 SyWnID23Oa1D; Wed, 13 May 2009 14:33:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 114B7C01C1; Wed, 13 May 2009 14:33:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9A509AEA682; Wed, 13 May 2009 14:33:27 +0200 (CEST) Date: Wed, 13 May 2009 14:33:27 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090513123327.GA6460@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "netmod@ietf.org" References: <20090513103002.0F2C23A6E0A@core3.amsl.com> <20090513103737.GA6096@elstar.local> 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] I-D Action:draft-ietf-netmod-yang-types-03.txt 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, 13 May 2009 12:32:19 -0000 On Wed, May 13, 2009 at 01:48:46PM +0200, Romascanu, Dan (Dan) wrote: > So you may want to consider this as a WGLC comment. > > The following description (repeated another couple of times) taken from > RFC 2579 MacAddress TC is slightly inaccurate: > > "The mac-address type represents an 802 MAC address represented > in the `canonical' order defined by IEEE 802.1a, i.e., as if it > were transmitted least significant bit first, even though 802.5 > (in contrast to other 802.x protocols) requires MAC addresses > to be transmitted most significant bit first. > > This type is in the value set and its semantics equivalent to > the MacAddress textual convention of the SMIv2."; > > 1. s/802 MAC address/IEEE 802 MAC address/ > > 2. The canonical order is currently defined not in IEEE 802.1a which > does not exist any longer but in IEEE Std. 802-2001. The definition of > what 'canonical' means is also worded differently there, but we may keep > the one used in 2579 as they are equivalent and the one in 2579 is more > practical. > > 3. s/802.5/IEEE 802.5/ > > 4. s/802.x/IEEE 802.x/ > > 5. We should make clear that what Token Ring (IEEE 802.5) was doing was > using the non-canonical order. Also as 802.5 is no longer used and has > little chances to be used with NETMOD ever, maybe past tense is more > appropriate. > > So if we are to include all the edits above the description could look > like: > > "The mac-address type represents an IEEE 802 MAC address represented > in the `canonical' order defined by IEEE Std. 802-2001, i.e., as > if it > were transmitted least significant bit first, even though IEEE > 802.5 > (in contrast to other IEEE 802.x protocols) used the > 'non-canonical' order > that requires MAC addresses > to be transmitted most significant bit first. > > This type is in the value set and its semantics equivalent to > the MacAddress textual convention of the SMIv2."; Probably the solution is to not talk about the order since we have a textual representation and so there is no need for this text (which I copied from the SMIv2 definition where it is needed). This leads to: typedef mac-address { type string { pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; } description "The mac-address type represents an IEEE 802 MAC address. This type is in the value set and its semantics equivalent to the MacAddress textual convention of the SMIv2."; reference "RFC 2579: Textual Conventions for SMIv2"; } plus a suitable reference to IEEE Std. 802-2001 if I understand you correctly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed May 13 05: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 DE9B23A6BB7 for ; Wed, 13 May 2009 05:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 KhKHSfwgsRpf for ; Wed, 13 May 2009 05:41:38 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 05E643A683B for ; Wed, 13 May 2009 05:40:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,187,1241409600"; d="scan'208";a="161185518" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 13 May 2009 08:42:18 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 May 2009 08:42:17 -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: Wed, 13 May 2009 14:41:56 +0200 Message-ID: In-Reply-To: <20090513123327.GA6460@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] I-D Action:draft-ietf-netmod-yang-types-03.txt Thread-Index: AcnTxxMOzb4Ssd3xTYOlBbsOvvI4vAAAQdvw References: <20090513103002.0F2C23A6E0A@core3.amsl.com> <20090513103737.GA6096@elstar.local> <20090513123327.GA6460@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-types-03.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, 13 May 2009 12:41:39 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 ... > Probably the solution is to not talk about the order since we=20 > have a textual representation and so there is no need for=20 > this text (which I copied from the SMIv2 definition where it=20 > is needed). This leads to: >=20 > typedef mac-address { > type string { > pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; > } > description > "The mac-address type represents an IEEE 802 MAC address. >=20 > This type is in the value set and its semantics equivalent to > the MacAddress textual convention of the SMIv2."; > reference > "RFC 2579: Textual Conventions for SMIv2"; > } >=20 > plus a suitable reference to IEEE Std. 802-2001 if I=20 > understand you correctly. Agreed.=20 Dan >=20 > /js From jmh@joelhalpern.com Wed May 13 07:41: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 A6D333A68D4 for ; Wed, 13 May 2009 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 3lsKFfhaYoq0 for ; Wed, 13 May 2009 07:41:13 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 593443A6909 for ; Wed, 13 May 2009 07:41:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D6C7C430405; Wed, 13 May 2009 07:42:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AC42B4303D4; Wed, 13 May 2009 07:42:44 -0700 (PDT) Message-ID: <4A0ADC60.20000@joelhalpern.com> Date: Wed, 13 May 2009 10:42:40 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.mbj@tail-f.com> <4A0A3585.80103@joelhalpern.com> <20090513.084805.140625166.mbj@tail-f.com> In-Reply-To: <20090513.084805.140625166.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] WG last call 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: Wed, 13 May 2009 14:41:14 -0000 Perfect. Thanks. Martin Bjorklund wrote: > Hi, > > "Joel M. Halpern" wrote: >> With regard to the notifications, it may be that I am misudnerstanding what >> including a leafref in a notification will do. >> Will it include in the notification the value of the leaf pointed to? If so, >> that would be perfect and there is no need for the text I sent. I had >> understood that it would send a reference (an identifier, presumably xpath?) >> for the leaf. [More depending upon meaning...] > > Yes, when the leafref is encoded in XML, the value of the leaf pointed > to is included. In 9.9.6, there is an example of the XML encoding > for the notification I sent in the previous email: > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2008-04-01T00:01:00Z > > eth0 > 2 <--- This is the leafref > > > > > > /martin > From reid@snmp.com Wed May 13 08:03: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 4004C3A6F57 for ; Wed, 13 May 2009 08:03:07 -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 O9lC2WG-PYhq for ; Wed, 13 May 2009 08:03:06 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 739B53A69EC for ; Wed, 13 May 2009 08:02:48 -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 LAA15519; Wed, 13 May 2009 11:04:19 -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 LAA07121; Wed, 13 May 2009 11:04:19 -0400 (EDT) Message-Id: <200905131504.LAA07121@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 13 May 2009 09:09:37 +0200. <20090513.090937.70620022.mbj@tail-f.com> Date: Wed, 13 May 2009 11:04:18 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about notifications 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, 13 May 2009 15:03:07 -0000 > A predicate in the leafref path is the stuff inside the square > brackets. There are some examples of using predicates in 9.9.6 > (leafref usage examples). If the leafref points to a single-keyed > list, you don't use predicates: > > leaf if-name { > type leafref { > path "/interfaces/interface/name"; > } > } If the leafref points to a leaf that is not the key, such as ifIndex in the example from 9.9.6, do I use predicates? For example: leaf ifIndex { type leafref { path "/interfaces/interface/ifIndex"; } } -David Reid From vaughn@snmp.com Wed May 13 08:04: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 1A80A3A6B0A for ; Wed, 13 May 2009 08:04:48 -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 DjlCI7vX1rtM for ; Wed, 13 May 2009 08:04:47 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 41FD53A6909 for ; Wed, 13 May 2009 08:04:47 -0700 (PDT) Received: from ws5 (IDENT:U2FsdGVkX1/77fZrWCVw/x1GQBPexgf1xAQI/Pqeosg@ws5.snmp.com [192.147.142.193]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA15793 for ; Wed, 13 May 2009 11:06:19 -0400 (EDT) Date: Wed, 13 May 2009 11:06:18 -0400 (EDT) From: Michael Vaughn To: NETMOD Working Group Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [netmod] 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, 13 May 2009 15:04:48 -0000 is identity only allowed in module and submodule? it is not listed in either the module or submodule's substatements but it is listed for body-stmts in the YANG ABNF Grammar section. mike From reid@snmp.com Wed May 13 08:06: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 DAC183A68D4 for ; Wed, 13 May 2009 08:06:14 -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 lT4HC0uo2Jv6 for ; Wed, 13 May 2009 08:06:14 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 8B1FA3A6F99 for ; Wed, 13 May 2009 08:05:59 -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 LAA16160; Wed, 13 May 2009 11:07:31 -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 LAA07188; Wed, 13 May 2009 11:07:31 -0400 (EDT) Message-Id: <200905131507.LAA07188@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 13 May 2009 12:06:20 +0200. <20090513.120620.124679032.mbj@tail-f.com> Date: Wed, 13 May 2009 11:07:30 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about notifications 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, 13 May 2009 15:06:14 -0000 I like this updated version of the example. > On second thought I changed this leaf to an admin-statues leaf. One > example shows how a leafref is used to reference a non-key leaf, and I > think we should keep it. > > So we get: > > list interface { > key "name"; > leaf name { > type string; > } > leaf admin-status { > type admin-status; > } > list address { > key "ip"; > leaf ip { > type yang:ip-address; > } > } > } > > and the notification: > > notification link-failure { > leaf if-name { > type leafref { > path "/interfaces/interface/name"; > } > } > leaf admin-status { > type leafref { > path > "/interfaces/interface[name = current()/../if-name]" > + "/admin-status"; > } > } > } > > An example of a corresponding XML notification: > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2008-04-01T00:01:00Z > > eth0 > up > > > > > > /martin From reid@snmp.com Wed May 13 08: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 5E5863A6B40 for ; Wed, 13 May 2009 08:33: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=[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 SdI2zeKFsTJx for ; Wed, 13 May 2009 08:33:23 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 692153A692C for ; Wed, 13 May 2009 08:33: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 LAA18997; Wed, 13 May 2009 11:34:54 -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 LAA07755; Wed, 13 May 2009 11:34:54 -0400 (EDT) Message-Id: <200905131534.LAA07755@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 13 May 2009 09:09:37 +0200. <20090513.090937.70620022.mbj@tail-f.com> Date: Wed, 13 May 2009 11:34:54 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about notifications 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, 13 May 2009 15:33:24 -0000 > > If I want to have objects from more than one list in my notification, do I > > need put the the objects in different containers? > > No. > I guess my confusion is that I want the keys to always be encoded first. But a leafref type in a notification points to a list entry but is not a list, so the keys don't have to be encoded first. I don't think I'm saying this clearly, let me try an example. Is the following example with items from 2 different lists in a notification correct? module foo { namespace "http://www.example.com/foo"; prefix "foo"; list list1 { key "a"; leaf a { type int32; } leaf b { type string; } } list list2 { key "x"; leaf x { type int32; } leaf y { type string; } } notification test-notification { leaf a { type leafref { path "/list1/a"; } } leaf b { type leafref { path "/list1/[a = current()/../a]/b"; } } leaf x { type leafref { path "/list2/x"; } } leaf y { type leafref { path "/list2[x = current()/../x]/y"; } } } } XML encoding: ... 1 some stuff 2 more stuff -David Reid From reid@snmp.com Wed May 13 08:34: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 265C53A6E7A for ; Wed, 13 May 2009 08:34:46 -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 LSmrT4QK4i80 for ; Wed, 13 May 2009 08:34:45 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 268D03A6DCB for ; Wed, 13 May 2009 08:34:45 -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 LAA19223; Wed, 13 May 2009 11:36:17 -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 LAA07784; Wed, 13 May 2009 11:36:16 -0400 (EDT) Message-Id: <200905131536.LAA07784@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 13 May 2009 09:09:37 +0200. <20090513.090937.70620022.mbj@tail-f.com> Date: Wed, 13 May 2009 11:36:16 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about notifications 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, 13 May 2009 15:34:46 -0000 > I want to show also some leafs which are not leafrefs, and I believe > we have some other examples of notifications with leafrefs. So I > suggest we simply call the type "AdminStatus". Keeping an example with leafs which are not leafrefs is good. I like your suggested change. -David Reid From reid@snmp.com Wed May 13 08:42: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 152DE3A6AF1 for ; Wed, 13 May 2009 08:42:58 -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 cC20pFLQshhS for ; Wed, 13 May 2009 08:42:57 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id E61333A6971 for ; Wed, 13 May 2009 08:42:56 -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 LAA20604; Wed, 13 May 2009 11:44:26 -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 LAA07902; Wed, 13 May 2009 11:44:22 -0400 (EDT) Message-Id: <200905131544.LAA07902@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Sun, 03 May 2009 13:05:14 -0700. <49FDF8FA.3040108@netconfcentral.com> Date: Wed, 13 May 2009 11:44:22 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 13 May 2009 15:42:58 -0000 I was re-reading the decimal64 section and I think David's idea of listing the upper an lower bounds is helpful. Andy's chart makes it even more clear. I think decimal64 is kind of a wierd type that people won't be used to, so any help the document can give is good. -David Reid > David Spakes wrote: > > If I read section 9.3 of draft-ietf-netmod-yang-05.txt correctly, and > > if I didn't punch any incorrect keys on my keyboard, and assuming the > > implementation of Microsoft's calc.exe works correctly on my PC, I > > calculate the largest positive and largest negative values that can be > > represented in a decimal64 as follows: > > > > > > largest int64 = (2^63)-1 = 9223372036854775807 > > smallest int64 = -(2^63) = -9223372036854775808 > > > > 10^-1 = 0.1 > > 10^-18 = 0.000000000000000001 > > > > (largest int64)*(10^-1) = 922337203685477580.7 > > (largest int64)*(10^-18) = 9.223372036854775807 > > (smallest int64)*(10^-18) = -9.223372036854775808 > > (smallest int64)*(10^-1) = -922337203685477580.8 > > > > > > Largest positive value that can be represented in a decimal64: > > 922337203685477580.7 > > > > Largest negative value that can be represented in a decimal64: > > -922337203685477580.8 > > > > > I think the ranges are different for each value of fraction-digits: > > fd min max > --------------------------------------------------------- > 1 -922337203685477580.8 922337203685477580.7 > 2 -92233720368547758.08 92233720368547758.07 > 3 -9223372036854775.808 9223372036854775.807 > 4 -922337203685477.5808 922337203685477.5807 > 5 -92233720368547.75808 92233720368547.75807 > 6 -9223372036854.775808 9223372036854.775807 > 7 -922337203685.4775808 922337203685.4775807 > 8 -92233720368.54775808 92233720368.54775807 > 9 -9223372036.854775808 9223372036.854775807 > 10 -922337203.6854775808 922337203.6854775807 > 11 -92233720.36854775808 92233720.36854775807 > 12 -9223372.036854775808 9223372.036854775807 > 13 -922337.2036854775808 922337.2036854775807 > 14 -92233.72036854775808 92233.72036854775807 > 15 -9223.372036854775808 9223.372036854775807 > 16 -922.3372036854775808 922.3372036854775807 > 17 -92.23372036854775808 92.23372036854775807 > 18 -9.223372036854775808 9.223372036854775807 > > > > > > I think the text in the draft is clear and concise, however, I don't > > believe in the average software developer's ability to arrive at the > > same numbers that I just did. From years ago when I worked in a support > > role, I can still remember having unpleasant conversations with a clients; > > e.g., one who argued that some code was broken, because he insisted that > > a Megabyte is 1,000,000 bytes, not 1,048,576 bytes. As one of Jeff Case's > > down-on-the-farm sayings goes, "Your mileage may vary." > > > > Therefore, before this draft goes to publication, I would like to see the > > following text added for clarity: > > > > The largest positive value that can be represented as a decimal64 > > is 922337203685477580.7. The largest negative value that can be > > represented as a decimal64 is -922337203685477580.8. > > > > > > Regards, > > > > David Spakes > > > > > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Wed May 13 13:10: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 996EA3A6BCD for ; Wed, 13 May 2009 13:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.178, 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 bimgTkCZW8B0 for ; Wed, 13 May 2009 13:10:09 -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 C1FC93A6C92 for ; Wed, 13 May 2009 13:10:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E58B61600B; Wed, 13 May 2009 22:11:41 +0200 (CEST) Date: Wed, 13 May 2009 22:11:41 +0200 (CEST) Message-Id: <20090513.221141.00648823.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <20090512.223646.258818796.mbj@tail-f.com> References: <20090510.231542.108420990.mbj@tail-f.com> <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.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] WG last call 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: Wed, 13 May 2009 20:10:10 -0000 Martin Bjorklund wrote: > "Joel M. Halpern" wrote: > > Martin Bjorklund wrote: > > > "Joel M. Halpern" wrote: > > > 7.5.8 says: > > > If the operation is "replace" and the node exists, all child nodes > > > not present in the XML are deleted, and child nodes present in the > > > XML but not present in the datastore are created. > > > Doesn't this cover your question? > > > > The question is what happens with child nodes present in both the XML and the > > datastore. Neither of the two clauses covers that. (Given the subtleties, > > even if you think the existing netconf definition covers it, please restate > > here.) > > Ok, I see what you mean. I will get back to you... After looking at this section, and the other sections describing NETCONF edit-config processing for the different node types, I think it would be best to simplify this section a bit. I suggest we model it after 7.8.6 (lists), but add the explicit reference you suggested in your first comment on this issue: NEW: 7.5.8. NETCONF Operations Containers can be created, deleted, replaced and modified through , by using the "operation" attribute (See [RFC4741], section 7.2) in the container's XML element. If the container has a "presence" statement, it MAY be implicitly created if it does not exist, even if the operation is "none". If a container has a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container. (I would also add this explicit reference to section 7.2 of 4741 to the other edit-config processing sections.) /martin From mbj@tail-f.com Wed May 13 13:16: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 7657D3A6E4C for ; Wed, 13 May 2009 13:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.176, 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 DcCi3MVpbGa3 for ; Wed, 13 May 2009 13:16: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 4099128C232 for ; Wed, 13 May 2009 13:16:03 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 782E861600B for ; Wed, 13 May 2009 22:17:35 +0200 (CEST) Date: Wed, 13 May 2009 22:17:35 +0200 (CEST) Message-Id: <20090513.221735.27730487.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] WGLC comment on identifier namespace 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, 13 May 2009 20:16:41 -0000 Hi, I received an off-line comment that the text about the namespace for typedefs and groupings is incorrect. The current text from section 6.2.1 says: o All derived type names defined within a parent node or at the top- level of the module or its submodules share the same type identifier namespace. This namespace is scoped to the parent node or module. Consider the following example: container a { typedef t { ... } container b { typedef t { ... } // illegal } } The second typedef is supposed to be illegal, since the type 't' is already defined. I suggest the following replacement text: o All derived type names defined within a parent node or at the top- level of the module or its submodules share the same type identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendent node may use that typedef, and it MUST NOT define a typedef with the same name. (and similar for groupings) /martin From reid@snmp.com Wed May 13 13:26: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 7830D28C225 for ; Wed, 13 May 2009 13:26:17 -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 EuWPLvj-8+Qi for ; Wed, 13 May 2009 13:26:16 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 18D413A6B14 for ; Wed, 13 May 2009 13:26:15 -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 QAA13676 for ; Wed, 13 May 2009 16:27:43 -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 QAA10513 for ; Wed, 13 May 2009 16:27:41 -0400 (EDT) Message-Id: <200905132027.QAA10513@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 13 May 2009 16:27:41 -0400 From: David Reid Subject: [netmod] WGLC very minor nits 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, 13 May 2009 20:26:17 -0000 Here are some very very minor issues in the yang doc: Section 4.1, first paragraph on page 14: so content in YIN can round-tripped back into YANG should be so content in YIN can be round-tripped back into YANG -- Section 5.1, second paragraph Submodule are partial modules that contribute definitions to a should be Submodules are partial modules that contribute definitions to a -- Section 5.2, first paragraph or submodule per file. The name of the file SHOULD be on the form: should be or submodule per file. The name of the file SHOULD be of the form: ^^ -- section 7.1, third paragraph submodule names that will have a low probability of colliding with should be module names that will have a low probability of colliding with -- section 7.7.1 applies to both lists and leaf-lists, but only mentions list. I suggest making it clear that it applies to both. -- section 7.14, paragraph 1 information. The notification "statement" defines a notification should be information. The "notification" statement defines a notification -- section 9.1 paragraph 2 When NETCONF servers sends data, it MUST be in the canonical form. should be When a NETCONF server sends data, it MUST be in the canonical form. -- section 9.4.7, last example 00ABAB // illegal xx00 // illegal it might be helpful to add a note in the comment to explain why it is illegal, something like: 00ABAB // illegal, too long xx00 // illegal, bad characters -- section 9.5, the boolean type does not have a canonical form section. -- section 9.6.4.2, the section on the bit's position statement states that the value is not used by yang or the xml encoding. It might be helpful to use the same wording with the enum's value statement. It also might be helpful to show the xml encoding in the usage example like is done for bits. --- The first sentence in section 1 ("Today, the NETCONF protocol [RFC4741] lacks a standardized way to create data models") will be wrong the day the draft is published as proposed standard. I suggest changing the first paragraph to past tense, or better yet, just remove the whole paragraph. -David Reid From mbj@tail-f.com Wed May 13 13:29: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 AC37B3A6B87 for ; Wed, 13 May 2009 13:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.175, 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 oQTIYSDCICHJ for ; Wed, 13 May 2009 13:29:50 -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 AAFBB3A6B14 for ; Wed, 13 May 2009 13:29:49 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C9E10616045; Wed, 13 May 2009 22:31:21 +0200 (CEST) Date: Wed, 13 May 2009 22:31:21 +0200 (CEST) Message-Id: <20090513.223121.218543975.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200905131504.LAA07121@adminfs.snmp.com> References: <20090513.090937.70620022.mbj@tail-f.com> <200905131504.LAA07121@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] WGLC comments about notifications 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, 13 May 2009 20:29:50 -0000 David Reid wrote: > > A predicate in the leafref path is the stuff inside the square > > brackets. There are some examples of using predicates in 9.9.6 > > (leafref usage examples). If the leafref points to a single-keyed > > list, you don't use predicates: > > > > leaf if-name { > > type leafref { > > path "/interfaces/interface/name"; > > } > > } > > If the leafref points to a leaf that is not the key, such as ifIndex in the > example from 9.9.6, do I use predicates? For example: > > leaf ifIndex { > type leafref { > path "/interfaces/interface/ifIndex"; > } > } Note that the path argument is a normal XPath epression. When this expression is evaluated, it will return all nodes called /interfaces/interface/ifIndex. If multiple 'interface' entries, you will get multiple ifIndex nodes back. In this particular example, ifIndex might actually be unique across all instances, so there might be just one entry with a given ifIndex value, but in general this is not the case. Consider this example: leaf my-admin-status { type leafref { path "/interfaces/interface/admin-status"; } } eth0 up eth1 down lo up Now, the value space for the leaf 'my-admin-status' is [up, down]. (If eth1 has admin-status 'up', the value space would have been [up]). So a valid my-admin-status could be: up Getting just this leaf in a notification isn't very usefulf, so changing it into: leaf my-name { type leafref { path "/interfaces/interface/name"; } } leaf my-admin-status { type leafref { path "/interfaces/interface[name = current()/../my-name]" + "/admin-status"; } } would give: lo up which is more useful. /martin From mbj@tail-f.com Wed May 13 13:39: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 564843A6B77 for ; Wed, 13 May 2009 13:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.173, 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 bnnUP1vdLcZj for ; Wed, 13 May 2009 13:39: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 940A43A6B14 for ; Wed, 13 May 2009 13:39: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 A796461600B; Wed, 13 May 2009 22:41:27 +0200 (CEST) Date: Wed, 13 May 2009 22:41:27 +0200 (CEST) Message-Id: <20090513.224127.144048445.mbj@tail-f.com> To: vaughn@snmp.com From: Martin Bjorklund In-Reply-To: References: 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] 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, 13 May 2009 20:39:56 -0000 Michael Vaughn wrote: > > is identity only allowed in module and submodule? it is not listed in either > the module or submodule's substatements but it is listed for body-stmts in the > YANG ABNF Grammar section. Yes it is only allowed on the top-level in module and submodule. I have added the missing reference to the substatements lists for module and submodule. Thanks /martin From mbj@tail-f.com Wed May 13 13:42: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 7ACE73A6A12 for ; Wed, 13 May 2009 13:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.172, 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 mkdvpp2hcA1Z for ; Wed, 13 May 2009 13:42: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 A6E1D3A6A04 for ; Wed, 13 May 2009 13:42: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 DA08E616046; Wed, 13 May 2009 22:43:32 +0200 (CEST) Date: Wed, 13 May 2009 22:43:32 +0200 (CEST) Message-Id: <20090513.224332.27443084.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200905131534.LAA07755@adminfs.snmp.com> References: <20090513.090937.70620022.mbj@tail-f.com> <200905131534.LAA07755@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] WGLC comments about notifications 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, 13 May 2009 20:42:01 -0000 David Reid wrote: > > > If I want to have objects from more than one list in my notification, do I > > > need put the the objects in different containers? > > > > No. > > > > I guess my confusion is that I want the keys to always be encoded first. But > a leafref type in a notification points to a list entry but is not a list, so > the keys don't have to be encoded first. I don't think I'm saying this clearly, > let me try an example. Is the following example with items from 2 different > lists in a notification correct? Yes, it is correct. /martin > > module foo { > > namespace "http://www.example.com/foo"; > prefix "foo"; > > list list1 { > key "a"; > leaf a { type int32; } > leaf b { type string; } > } > > list list2 { > key "x"; > leaf x { type int32; } > leaf y { type string; } > } > > notification test-notification { > leaf a { > type leafref { > path "/list1/a"; > } > } > leaf b { > type leafref { > path "/list1/[a = current()/../a]/b"; > } > } > leaf x { > type leafref { > path "/list2/x"; > } > } > leaf y { > type leafref { > path "/list2[x = current()/../x]/y"; > } > } > } > } > > XML encoding: > > ... > > 1 > some stuff > 2 > more stuff > > > > -David Reid > From Washam.Fan@huaweisymantec.com Wed May 13 19:51: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 D96133A6AC8 for ; Wed, 13 May 2009 19:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.265, 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 PH4aCsGy-aog for ; Wed, 13 May 2009 19:51:09 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 59A823A67B2 for ; Wed, 13 May 2009 19:50:46 -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 <0KJM00F5F5AQ4T10@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 14 May 2009 10:52:04 +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 <0KJM00G1J5AOIU00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 14 May 2009 10:52:02 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 14 May 2009 10:52:00 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 14 May 2009 10:52:00 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090513.221141.00648823.mbj@tail-f.com> References: <20090510.231542.108420990.mbj@tail-f.com> <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.mbj@tail-f.com> <20090513.221141.00648823.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] WG last call 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: Thu, 14 May 2009 02:51:09 -0000 > NEW: > > 7.5.8. NETCONF Operations > > Containers can be created, deleted, replaced and modified through > , by using the "operation" attribute (See [RFC4741], > section 7.2) in the container's XML element. > > If the container has a "presence" statement, it MAY be implicitly > created if it does not exist, even if the operation is "none". I can envision that, if a P container belongs to default data, when its parent is going to be created, it is going to be created along. I assume it is the case where a P container MAY be implicitly created. But I can't figure out how this is related to operation "none". To my understanding , "none" is for hierarchy level check for incoming configuration data and won't trigger any real action. Can you elaborate? Or maybe a example helps. Thanks, washam > If a container has a "presence" statement and the last child node > is > deleted, the NETCONF server MAY delete the container. > > > (I would also add this explicit reference to section 7.2 of 4741 to > the other edit-config processing sections.) > > > /martin From andy@netconfcentral.com Wed May 13 20:03: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 4635B3A6AE0 for ; Wed, 13 May 2009 20:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 ByloMC+6vrjx for ; Wed, 13 May 2009 20:03:47 -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 65E263A69D7 for ; Wed, 13 May 2009 20:03:47 -0700 (PDT) Received: from [68.142.200.227] by n21.bullet.mail.mud.yahoo.com with NNFMP; 14 May 2009 03:05:18 -0000 Received: from [68.142.201.69] by t8.bullet.mud.yahoo.com with NNFMP; 14 May 2009 03:05:18 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 14 May 2009 03:05:18 -0000 X-Yahoo-Newman-Id: 652165.3158.bm@omp421.mail.mud.yahoo.com Received: (qmail 18162 invoked from network); 14 May 2009 03:05:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 14 May 2009 03:05:17 -0000 X-YMail-OSG: y3aCQmoVM1mmLKMOy4Q81hgcW7lKgW5qT6hJl7H7eqM8XAKAif47Ft974renbBK2R_k_waH1wEVXnO5iOyTNf68YfXXCKAdfaJgZmHV6aePtJHL_kM3wuapQEDen_ILYxRaTn9YrCP7DLu7f1AaEM6OpWt6hpNCKhqMLHGL0chr8uDQTPVVn4IxcaenfnAilqa3xm1AMmGX4P0jdTI37usNOzMIAi2xL.kfjWbjHBhP261HOPUDCWUsWeb7vx5A9Nl_Agp07oVPF.Q7kHIybwtV4NUz2FdxiJZ2oHCb1k71MlenEdyY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0B8A6B.3010400@netconfcentral.com> Date: Wed, 13 May 2009 20:05:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: <20090510.231542.108420990.mbj@tail-f.com> <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.mbj@tail-f.com> <20090513.221141.00648823.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] WG last call 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: Thu, 14 May 2009 03:03:48 -0000 WashamFan wrote: >> NEW: >> >> 7.5.8. NETCONF Operations >> >> Containers can be created, deleted, replaced and modified through >> , by using the "operation" attribute (See [RFC4741], >> section 7.2) in the container's XML element. >> >> If the container has a "presence" statement, it MAY be implicitly >> created if it does not exist, even if the operation is "none". > > I can envision that, if a P container belongs to default data, > when its parent is going to be created, it is going to be created > along. I assume it is the case where a P container MAY be > implicitly created. > > But I can't figure out how this is related to operation "none". To > my understanding , "none" is for hierarchy level check for > incoming configuration data and won't trigger any real action. > > Can you elaborate? Or maybe a example helps. > Thanks for pointing this out. I object to that last sentence you quoted! It goes against the original intent of default-operation = 'none'. If the 'active operation' is 'none' then the node MUST exist in the database already, or a 'data-missing' error is generated. This is by design. The operator should use 'replace' or 'merge' as the default-operation instead of 'none', if they want this behavior. Since 'merge' is the default, there doesn't need to be any special case for 'none' wrt/ NP containers. > Thanks, > washam > >> If a container has a "presence" statement and the last child node >> is >> deleted, the NETCONF server MAY delete the container. >> >> This is backwards. It should be 'does not have a "presence" statement'. The agent never deletes empty P-containers, just NP-containers. >> (I would also add this explicit reference to section 7.2 of 4741 to >> the other edit-config processing sections.) >> >> >> /martin > Andy From jmh@joelhalpern.com Wed May 13 20:18: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 80DE93A68CF for ; Wed, 13 May 2009 20:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 SRYNrxKiSV+x for ; Wed, 13 May 2009 20:18:33 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A0D6B3A67B2 for ; Wed, 13 May 2009 20:18:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8DD20430619 for ; Wed, 13 May 2009 20:20:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 70DE7430608 for ; Wed, 13 May 2009 20:20:06 -0700 (PDT) Message-ID: <4A0B8DE3.6000000@joelhalpern.com> Date: Wed, 13 May 2009 23:20:03 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <20090510.231542.108420990.mbj@tail-f.com> <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.mbj@tail-f.com> <20090513.221141.00648823.mbj@tail-f.com> In-Reply-To: <20090513.221141.00648823.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] WG last call 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: Thu, 14 May 2009 03:18:34 -0000 If the rules for creating, deleting, or replacing parts are exactly those from NETCONF, (which they ought to be) then your proposed text seems the right approach. Yours, Joel Martin Bjorklund wrote: > Martin Bjorklund wrote: >> "Joel M. Halpern" wrote: >>> Martin Bjorklund wrote: >>>> "Joel M. Halpern" wrote: >>>> 7.5.8 says: >>>> If the operation is "replace" and the node exists, all child nodes >>>> not present in the XML are deleted, and child nodes present in the >>>> XML but not present in the datastore are created. >>>> Doesn't this cover your question? >>> The question is what happens with child nodes present in both the XML and the >>> datastore. Neither of the two clauses covers that. (Given the subtleties, >>> even if you think the existing netconf definition covers it, please restate >>> here.) >> Ok, I see what you mean. I will get back to you... > > After looking at this section, and the other sections describing > NETCONF edit-config processing for the different node types, I think > it would be best to simplify this section a bit. I suggest we model > it after 7.8.6 (lists), but add the explicit reference you suggested > in your first comment on this issue: > > NEW: > > 7.5.8. NETCONF Operations > > Containers can be created, deleted, replaced and modified through > , by using the "operation" attribute (See [RFC4741], > section 7.2) in the container's XML element. > > If the container has a "presence" statement, it MAY be implicitly > created if it does not exist, even if the operation is "none". > > If a container has a "presence" statement and the last child node is > deleted, the NETCONF server MAY delete the container. > > > (I would also add this explicit reference to section 7.2 of 4741 to > the other edit-config processing sections.) > > > /martin > From Washam.Fan@huaweisymantec.com Wed May 13 20:19: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 1A6253A67B2 for ; Wed, 13 May 2009 20:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 cyrObK8rl40M for ; Wed, 13 May 2009 20:19:26 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 395453A6B45 for ; Wed, 13 May 2009 20:19:26 -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 <0KJM00AJT6MOCC00@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Thu, 14 May 2009 11:20:48 +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 <0KJM00E516MMGU00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 14 May 2009 11:20:48 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 14 May 2009 11:20:46 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Thu, 14 May 2009 11:20:46 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A0B8A6B.3010400@netconfcentral.com> References: <20090510.231542.108420990.mbj@tail-f.com> <4A099593.5090006@joelhalpern.com> <20090512.223646.258818796.mbj@tail-f.com> <20090513.221141.00648823.mbj@tail-f.com> <4A0B8A6B.3010400@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] WG last call 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: Thu, 14 May 2009 03:19:27 -0000 > WashamFan wrote: > >> NEW: > >> > >> 7.5.8. NETCONF Operations > >> > >> Containers can be created, deleted, replaced and modified through > >> , by using the "operation" attribute (See [RFC4741], > >> section 7.2) in the container's XML element. > >> > >> If the container has a "presence" statement, it MAY be implicitly > >> created if it does not exist, even if the operation is "none". > > > > I can envision that, if a P container belongs to default data, > > when its parent is going to be created, it is going to be created > > along. I assume it is the case where a P container MAY be > > implicitly created. > > > > But I can't figure out how this is related to operation "none". To > > my understanding , "none" is for hierarchy level check for > > incoming configuration data and won't trigger any real action. > > > > Can you elaborate? Or maybe a example helps. > > > > Thanks for pointing this out. > I object to that last sentence you quoted! > > It goes against the original intent of default-operation = 'none'. > If the 'active operation' is 'none' then the node MUST exist > in the database already, or a 'data-missing' error is generated. > This is by design. The operator should use 'replace' or 'merge' > as the default-operation instead of 'none', if they want this > behavior. Since 'merge' is the default, there doesn't need > to be any special case for 'none' wrt/ NP containers. > > > > Thanks, > > washam > > > > > >> If a container has a "presence" statement and the last child > node > >> is > >> deleted, the NETCONF server MAY delete the container. > >> > >> > > > This is backwards. > It should be 'does not have a "presence" statement'. > The agent never deletes empty P-containers, just NP-containers. But if the intent is what you said above, I am afraid it should have been 'MUST' instead of 'MAY' in Martin's text. washam > >> (I would also add this explicit reference to section 7.2 of 4741 > to > >> the other edit-config processing sections.) > >> > >> > >> /martin > > > > > Andy > > > From mbj@tail-f.com Thu May 14 00: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 543C53A6D63 for ; Thu, 14 May 2009 00:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.170, 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 RMJnqVZuHPqk for ; Thu, 14 May 2009 00:41: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 8B9263A6A9A for ; Thu, 14 May 2009 00:41:51 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C157616014; Thu, 14 May 2009 09:43:21 +0200 (CEST) Date: Thu, 14 May 2009 09:43:20 +0200 (CEST) Message-Id: <20090514.094320.213659366.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A0B8A6B.3010400@netconfcentral.com> References: <20090513.221141.00648823.mbj@tail-f.com> <4A0B8A6B.3010400@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] WG last call 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: Thu, 14 May 2009 07:41:52 -0000 Andy Bierman wrote: > WashamFan wrote: > >> NEW: > >> 7.5.8. NETCONF Operations > >> Containers can be created, deleted, replaced and modified through > >> , by using the "operation" attribute (See [RFC4741], > >> section 7.2) in the container's XML element. > >> If the container has a "presence" statement, it MAY be implicitly > >> created if it does not exist, even if the operation is "none". > > I can envision that, if a P container belongs to default data, > > when its parent is going to be created, it is going to be created > > along. I assume it is the case where a P container MAY be implicitly > > created. > > But I can't figure out how this is related to operation "none". To > > my understanding , "none" is for hierarchy level check for incoming > > configuration data and won't trigger any real action. > > Can you elaborate? Or maybe a example helps. > > > > Thanks for pointing this out. > I object to that last sentence you quoted! I agree that this CLR should be removed. So the text would become: NEW: Containers can be created, deleted, replaced and modified through , by using the "operation" attribute (See ^RFC4741^, section 7.2) in the container's XML element. If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container. /martin From lhotka@cesnet.cz Thu May 14 01:29: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 9324B3A7002 for ; Thu, 14 May 2009 01:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, GB_I_LETTER=-2, 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 mgE8Zh3vNDZW for ; Thu, 14 May 2009 01:29:47 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 680433A6D2D for ; Thu, 14 May 2009 01: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 E04A6D800C7 for ; Thu, 14 May 2009 10:31:14 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: multipart/mixed; boundary="=-HZLj4RYS2m57t2KdMWpN" Organization: CESNET Date: Thu, 14 May 2009 10:31:14 +0200 Message-Id: <1242289874.6404.7.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] review of draft-ietf-netmod-yang-05 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, 14 May 2009 08:29:49 -0000 --=-HZLj4RYS2m57t2KdMWpN Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, here is my review of the YANG draft. Apart from the comments in the mail body below, I am also attaching a patch file with corrections of typos and my suggestions for minor formulation changes. Lada ------------------------------------------------------------------------ - The name of the game: "YANG" is used for both the C-like syntax and semantics but "YIN" only for syntax. Perhaps it would be more appropriate to drop "YIN" and use e.g., "standard syntax" and "XML syntax" where necessary. Cf. Sec. 5.6.5: 'Note that the format is "YANG", even if the YIN syntax is used.' - Section 3 defines terms "data node" and "schema node" but quite often the text uses just "node" and it is not immediately clear which one of the two it is. - The word "definition" is used in two meanings: (i) definition of data nodes and (ii) definitions of groupings, typedefs and features. For example, Sec. 7.1.5 says: 'The "import" statement makes definitions from one module available inside another module or submodule.' and it means (ii). Suggestion: use "data node definition" for (i). - Sec. 3.1: Fourth item is missing for "anyxml" node. - Sec. 5.1.1: The spec doesn't ensure that both parties in a NETCONF session always use the same module revisions or that any mismatch is immediately detected, if the revision is not specified. What is the meaning of "current revision" and "available at the time"? An agent may be limited to locally stored modules, so its notion of "current" may be different. Resulting problems are hard to detect unless the exact revision dates are always used in both capability advertisements and imports. - Sec. 5.1.2: is not the only NETCONF element carrying data model XML data. Others are or . - Sec. 5.2: What are "YANG compilers"? Suggestion: "YANG software" - Sec 5.3: XML namespace URIs are globally unique, so the probability of collisions must be zero. Last sentence should be: "Namespace URI MUST be chosen so that it cannot collide with standard ...". - Sec. 5.6.1: Instead of suggesting religious attitudes of implementors, this section should state what basic behavior means: all features that do not depend on a feature must be implemented. - Sec. 5.6.4: * The ABNF is too lax (this has already been discussed in the ML). * The module names and their namespaces are somewhat redundant. I'd suggest to resolve YANG modules using only namespace URI - collisions in module names then wouldn't be a problem and "module" parameter of capability strings can be removed. * How can the capability string for module A declare a feature which module A imports from module B (another namespace)? - Sec. 5.6.4.3: Is it necessary to advertise the module with deviations (my-devs) twice? - Sec. 6.1.3, para 5: "... two strings are concatenated into one quoted string, ...". Does "quoted" mean single- or double-quoted? Example: "Here's " + 'the problem.\n'. Suggestion: State that all escaped characters are substituted before concatenation and then the strings are joined into one (value-space) string. - Sec. 6.4 (sorry, I can't help myself:-): "... the namespace of the current module defined as the null namespace." is wrong. In fact, XPath 1.0 spec never uses the term "null namespace", but only "null namespace URI", for example "The namespace URI is either null or a string." It is beyond any doubt that "null" means "non-existent". - Sec. 7.1.3: The namespace is used not only for XML elements but also for extensions and features. - Sec. 7.1.5: It is not specified which revision is used if the "revision-date" substatement is missing (related to Sec. 5.1.1). - Sec. 7.1.6, para 1: This should be added: "Submodules are only allowed to import other submodules if both importing and imported submodules belong to the same module." - Sec. 7.5.3: * In the description of the evaluation context, the second item is: "The accessible tree is made up of all nodes in the data tree, and ..." However, subsequent items say that the tree actually depends on the content type (config data, RPC, notification). * "... any XPath comparisons are done on the canonical value." Does it mean that 'foo < 5' is always false is foo is decimal64? If so, I strongly disagree, because this is not how it works in XPath. - Sec 7.19.5: Same problem as in 7.5.3 (specification of the accessible tree). - Sec.7.5.7, para 3: NP-container must be sent if it is at the top of a case in a choice, because it may be the selector for the case. (This has already been discussed in the ML.) - Sec. 7.6.5, para 2: Again, a leaf at the top level of a case in a choice must be sent even if it's value is the default. - Sec. 7.9.3: * Suggestion: use 'default-case' keyword here, because both syntax and semantics differs from the 'default' specifying leaf default value. * para 3: Could this clarify how the default case is used? OLD The default values for nodes under the default case are used if none of the nodes under any of the cases are present. NEW If (and only if) none of the nodes under any of the cases are present in the data tree, the contents of the default case effectively replace the entire choice. - Sec. 7.11, last para: * "References from inside the grouping are relative to the scope in which the grouping is defined, not where it is used." I believe this should be "Identifiers appearing inside the grouping are resolved relative to the scope in which ...". References such as 'leafref' or XPath expressions in 'must' are relative to the scope of 'uses'. * In don't understand the last sentence "For extensions, ...". - Sec. 7.13.2, para 2: This is not true if the mandatory leaf is inside a P-container. - Sec. 7.13.3, para 2: Same as in 7.13.2 - Sec. 7.14, para 3: Same as in 7.13.2 - Sec. 7.14, para 4: s/NETCONF server/NETCONF client/ (?) - Sec. 7.15: The shorthand notation for a case cannot be used when augmenting a choice? - Sec 9., para 4: The lexicographic representation is also used for specifying ranges of numeric types. - Sec. 9.2.1: Are octal and hexadecimal values allowed in 'range' restrictions? - Sec. 9.4.1: Encodings that every implementation must support should be specified here, for example UTF-8 or UTF-16. But in an argument of 'default', a string must be always in UTF-8. - Sec. 9.4.2, para 2: The text should mention that multiple adjacent predicates are allowed, as in "foo[key1=3][key2=100]". An example would also be helpful. OLD Each predicate consists of exactly one equality test per key. NEW Each predicate consists of exactly one equality test per key but multiple adjacent predicates may be present, for example if a list has multiple keys. - Sec. 9.9.2: What is the context for XPath evaluation in this case? - Sec. 9.9.3: The case "require-instance false;" should also be specified: 'If "require-instance" is "false", the value of the leaf with "leafref" type must be equal to the referred leaf only if the latter exists.' - Sec. 9.10: I don't understand the semantics of 'identityref' type. How is it different from an enumeration? - Sec. 9.10.5: * Since module "des" is not imported, how can an implementation know that such a module exists and defines the "des3" identity? * Is "crypto:crypto-alg" also a valid value of the "crypto" leaf? - Sec. 9.13.2, para 1: "All node names in an instance-identifier value MUST be qualified with explicit namespace prefixes and these prefixes MUST be declared ..." Editorial comments: ------------------- - Possessive forms with 's are overused and sometimes it is really ugly: "The must's Substatements", "bits's". - In HTML rendering, Sec. 5.6.4 in ToC does not have the hyperlink. - Also in HTML: xml2rfc tries to be too clever and makes phrases like "section 3.1" automatically into a local hyperlink, even if they refer to a section of another document. This happens in Sec. 6.4. Similarly, upper limits of ranges are interpreted as page references (in 9.2.5, 9.4.5) and regular expressions into bibliography refs (9.4.7). -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --=-HZLj4RYS2m57t2KdMWpN Content-Disposition: attachment; filename=draft-ietf-netmod-yang-05.txt.patch Content-Type: text/x-patch; name=draft-ietf-netmod-yang-05.txt.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff --git a/draft-ietf-netmod-yang-05.txt b/draft-ietf-netmod-yang-05.txt index 48e4c31..3240e9f 100644 --- a/draft-ietf-netmod-yang-05.txt +++ b/draft-ietf-netmod-yang-05.txt @@ -397,7 +397,7 @@ Internet-Draft YANG April 2009 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, + solutions. In order for NETCONF to be an 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. @@ -638,7 +638,7 @@ Internet-Draft YANG April 2009 A mandatory node is one of: - o A leaf or choice node with a "mandatory" statement with the value + o A leaf, anyxml or choice node with a "mandatory" statement with the value "true". o A list or leaf-list node with a "min-elements" statement with a @@ -690,7 +690,7 @@ Internet-Draft YANG April 2009 YANG structures data models into modules and submodules. A module can import data from other external modules, and include data from - submodules. The hierarchy can be extended, allowing one module to + submodules. The hierarchy can be augmented, allowing one module to add data nodes to the hierarchy defined in another module. This augmentation can be conditional, with new nodes appearing only if certain conditions are met. @@ -767,7 +767,7 @@ Internet-Draft YANG April 2009 This section introduces some important constructs used in YANG that will aid in the understanding of the language specifics in later sections. This progressive approach handles the inter-related nature - of YANG concepts and statements. Specifics about YANG statements and + of YANG concepts and statements. A detailed description of YANG statements and syntax begins in Section 7. 4.2.1. Modules and Submodules @@ -1350,7 +1350,7 @@ Internet-Draft YANG April 2009 - acmefw-2.3 + acmefw-2.3 @@ -1465,7 +1465,7 @@ Internet-Draft YANG April 2009 a single data model. A module can define a complete, cohesive model, or augment an existing data model with additional nodes. - Submodule are partial modules that contribute definitions to a + Submodules are partial modules that contribute definitions to a module. A module may include any number of submodules, but each submodule may belong to only one module. @@ -1523,8 +1523,8 @@ Internet-Draft YANG April 2009 is unaffected and its contents are unchanged. When the author of the module is prepared to move to the most recently published revision of an imported module, the module is republished with an updated import - statement. By republishing with the new revision, the author is - explicitly indicating their acceptance of any changes in the imported + statement. By republishing with the new revision, the authors + explicitly indicate their acceptance of any changes in the imported module. For submodules, the issue is related but simpler. A module or @@ -1571,9 +1571,10 @@ Internet-Draft YANG April 2009 level nodes are sometimes convenient, and are supported by YANG. - NETCONF is capable of carrying any XML content as the payload in the - element. The top-level nodes of YANG modules are encoded as - child elements within the element. + The NETCONF protocol [RFC4741] defines the encapsulating elements + such as or that contain the top-level nodes of YANG + modules as their child elements. This encapsulation guarantees that + the corresponding NETCONF PDUs are always well-formed XML documents. For example: @@ -1709,7 +1710,7 @@ Internet-Draft YANG April 2009 model. Generally speaking, devices are responsible for implementing the model faithfully, allowing applications to treat devices which implement the model identically. Deviations from the model can - reduce the utility of the model and increase fragility into + reduce the utility of the model and increase fragility of applications that use it. YANG modelers have three mechanisms for conformance: @@ -1725,7 +1726,7 @@ Internet-Draft YANG April 2009 5.6.1. Basic Behavior The model defines a contract between the NETCONF client and server, - which allows both parties to have faith the other knows the syntax + which allows both parties to have faith that the other party knows the syntax and semantics behind the modeled data. The strength of YANG lies in the strength of this contract and the mindless devotion with which implementers follow it. @@ -1760,7 +1761,7 @@ Internet-Draft YANG April 2009 A module may declare any number of features, identified by simple strings, and may make portions of the module optional based on those - feature. If the device supports a feature, then the corresponding + features. If the device supports a feature, then the corresponding portions of the module are valid for that device. If the device doesn't support the feature, those parts of the module are not valid, and applications should behave accordingly. @@ -1776,7 +1777,7 @@ Internet-Draft YANG April 2009 In an ideal world, all devices would be required to implement the model exactly as defined, and deviations from the model would not be allowed. But in the real world, devices are often not able or - willing to implement the model as written. For YANG-based automation + their developers willing to implement the model as written. For YANG-based automation to deal with these device deviations, a mechanism must exist for devices to inform applications of the specifics of such deviations. @@ -2004,7 +2005,8 @@ Internet-Draft YANG April 2009 If the double quoted string contains a line break followed by whitespace which is used to indent the text according to the layout in the YANG file, this leading whitespace is stripped from the - string, up to at most the same column of the double quote character. + string, up to at most the column of the opening double quote character + in a preceding line. If the double quoted string contains whitespace before a line break, this trailing whitespace is stripped from the string. @@ -2075,7 +2077,7 @@ Internet-Draft YANG April 2009 6.2. Identifiers - Identifiers are used to identify different kinds of YANG items by + Identifiers are used to identify different kinds of YANG objects by name. Each identifier starts with an upper-case or lower-case ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. @@ -2387,7 +2389,7 @@ Internet-Draft YANG April 2009 The "yang-version" statement specifies which version of the YANG language was used in developing the module. The statement's argument - contains value "1", which is the current yang version and the default + MUST contain value "1", which is the current yang version and the default value. 7.1.3. The namespace Statement @@ -2413,7 +2415,7 @@ Internet-Draft YANG April 2009 The "prefix" statement is used to define the prefix associated with the module and its namespace. The "prefix" statement's argument is - the prefix string which is used as a prefix to access a module. The + the prefix string which is used as a prefix to access the names defined in a foreign module. The prefix string MAY be used to refer to definitions contained in the module, e.g. "if:ifName". A prefix follows the same rules as an identifier (see Section 6.2). @@ -2483,7 +2485,7 @@ Internet-Draft YANG April 2009 7.1.6. The include Statement The "include" statement is used to make content from a submodule - available to the module. The argument is an identifier which is the + available to the module or another submodule. The argument is an identifier which is the name of the submodule to include. Modules are only allowed to include submodules that belong to that module, as defined by the "belongs-to" statement (see Section 7.2.2). @@ -2614,7 +2616,7 @@ Internet-Draft YANG April 2009 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 + be constructed out of several submodules. Submodules allow 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. @@ -2874,8 +2876,8 @@ Internet-Draft YANG April 2009 used to put further restrictions on the type. The restrictions that can be applied depend on the type being - restricted. The restriction statements are described in subsections - for each built-in type in Section 9. + restricted. The restriction statements for all built-in types are + described in the subsections of Section 9. 7.4.1. The type's Substatements @@ -3029,7 +3031,7 @@ Internet-Draft YANG April 2009 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 Elements without a namespace prefix 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 @@ -3552,7 +3554,7 @@ Internet-Draft YANG April 2009 The "min-elements" statement, which is optional, takes as an argument a non-negative integer which puts a constraint on valid list entries. - A valid leaf-list or list MUST have least min-elements entries. + A valid leaf-list or list MUST have at least min-elements entries. If no "min-elements" statement is present, it defaults to zero. @@ -4568,7 +4570,7 @@ Internet-Draft YANG April 2009 An anyxml node is treated as an opaque chunk of data. This data can be modified in its entirety only. - Any "operation" attributes within the XML value of an anyxml node are + Any "operation" attributes present on subelements of an anyxml node are ignored by the NETCONF server. When a NETCONF server processes an request, the @@ -4695,7 +4697,7 @@ Internet-Draft YANG April 2009 The effect of a "uses" reference to a grouping is that the nodes defined by the grouping are copied into the current schema tree, and - then updated according to the refinement statements. Thus, the + then updated according to the refinement or augment statements. Thus, the identifiers defined in the grouping are copied into the current @@ -4892,7 +4894,7 @@ Internet-Draft YANG April 2009 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. + substatements to "input" define nodes under the RPC's input node. 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. @@ -5124,7 +5126,7 @@ Internet-Draft YANG April 2009 [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 + The notification'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. @@ -6179,7 +6181,7 @@ Internet-Draft YANG April 2009 leaf, including those defined in the type's range, length, and pattern properties, the server MUST reply with an "invalid-value" error-tag in the rpc-error, and with the error-app-tag and error- - message assoicated with the constraint, if any exist. + message associated with the constraint, if any exist. o If all keys of a list entry are not present, the server MUST reply with a "missing-element" error-tag in the rpc-error. @@ -6202,7 +6204,7 @@ Internet-Draft YANG April 2009 o If the attributes "before" and "after" appears in any element that is not a list whose "ordered-by" property is "user", the server - MUST reply with an "unkown-attribute" error-tag in the rpc-error. + MUST reply with an "unknown-attribute" error-tag in the rpc-error. 8.3.2. NETCONF Processing @@ -6311,13 +6313,13 @@ Internet-Draft YANG April 2009 uint16, uint32, and uint64. They represent signed and unsigned integers of different sizes: - int8 represents integer values between -128 and 127, inclusively. + int8 represents integer values between -128 and 127 inclusive. - int16 represents integer values between -32768 and 32767, - inclusively. + int16 represents integer values between -32768 and 32767 + inclusive. - int32 represents integer values between -2147483648 and 2147483647, - inclusively. + int32 represents integer values between -2147483648 and 2147483647 + inclusive. @@ -6330,17 +6332,17 @@ Internet-Draft YANG April 2009 int64 represents integer values between -9223372036854775808 and - 9223372036854775807, inclusively. + 9223372036854775807 inclusive. - uint8 represents integer values between 0 and 255, inclusively. + uint8 represents integer values between 0 and 255 inclusive. - uint16 represents integer values between 0 and 65535, inclusively. + uint16 represents integer values between 0 and 65535 inclusive. - uint32 represents integer values between 0 and 4294967295, - inclusively. + uint32 represents integer values between 0 and 4294967295 + inclusive. - uint64 represents integer values between 0 and 18446744073709551615, - inclusively. + uint64 represents integer values between 0 and 18446744073709551615 + inclusive. 9.2.1. Lexicographic Representation @@ -6409,7 +6411,7 @@ Internet-Draft YANG April 2009 or ranges are given they all MUST be disjoint and MUST be in ascending order. If a range restriction is applied to an already range restricted type, the new restriction MUST be equal or more - limiting, that is raising the lower bounds, reducing the upper + limiting, that is increasing the lower bounds, decreasing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. Each explicit value and range boundary value given in the range expression MUST match the @@ -6472,7 +6474,7 @@ Internet-Draft YANG April 2009 A decimal64 value is lexicographically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits, - optionally followed by a period ('.') as a decmial indicator and a + optionally followed by a period ('.') as a decimal indicator and a sequence of decimal digits. If no sign is specified, "+" is assumed. 9.3.2. Canonical Form @@ -6485,7 +6487,7 @@ Internet-Draft YANG April 2009 9.3.3. Restrictions - A decmial64 type can be restricted with the "range" statement + A decimal64 type can be restricted with the "range" statement (Section 9.2.4). @@ -6515,7 +6517,7 @@ Internet-Draft YANG April 2009 9.4. The string Built-in Type - The string built-in type represents human readable strings in YANG. + The string built-in type represents finite-length character strings in YANG. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]: @@ -6564,8 +6566,8 @@ Internet-Draft YANG April 2009 be negative. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a length restriction is applied to an already length restricted type, the new restriction - MUST be equal or more limiting, that is, raising the lower bounds, - reducing the upper bounds, removing explicit length values or ranges, + MUST be equal or more limiting, that is, increasing the lower bounds, + decreasing the upper bounds, removing explicit length values or ranges, or splitting ranges into multiple ranges with intermediate gaps. A length value is a non-negative integer, or one of the special values "min" or "max". "min" and "max" means the minimum and maximum length @@ -6636,7 +6638,7 @@ Internet-Draft YANG April 2009 matches the pattern. If the type has multiple "pattern" statements, the expressions are - AND:ed together, i.e. all such expressions have to match. + ANDed together, i.e. all such expressions have to match. If a pattern restriction is applied to an already pattern restricted type, values must match all patterns in the base type, in addition to @@ -7358,7 +7360,7 @@ Internet-Draft YANG April 2009 An instance-identifier value is lexicographically represented as a string in the XML encoding. The namespace prefixes used in the encoding MUST be declared in the XML namespace scope in the instance- - idenfitier's XML element. + identifier's XML element. Any prefixes used in the encoding are local to each instance encoding. This means that the same instance-identifier may be @@ -7459,7 +7461,7 @@ Internet-Draft YANG April 2009 For any published change, a new "revision" statement (Section 7.1.9) SHOULD be included in front of the existing revision statements. - Furthermore, any necessary changes MUST be applied to any meta + Furthermore, any necessary changes MUST be applied to any metadata statements, including the "organization" and "contact" statements (Section 7.1.7, Section 7.1.8). @@ -7477,7 +7479,7 @@ Internet-Draft YANG April 2009 o An "enumeration" type may have new enums added, provided the old enums's values do not change. - o A "bits" type may have new bits added, provided the old bits's + o A "bits" type may have new bits added, provided the old bit positions do not change. o A "range", "length", or "pattern" statement may expand the allowed @@ -7546,7 +7548,7 @@ Internet-Draft YANG April 2009 be removed, provided the definitions in the module do not change in any other way than allowed here. - o The "prefix" statment may be changed, provided all local uses of + o The "prefix" statement may be changed, provided all local uses of the prefix also are changed. Otherwise, if the semantics of any previous definition are changed @@ -7632,7 +7634,7 @@ Internet-Draft YANG April 2009 provides a more concise and readable format. The mapping between YANG and YIN does not modify the information - content of the model. Comments and whitespaces are not preserved. + content of the model. Comments and whitespace are not preserved. 11.1. Formal YIN Definition @@ -9302,7 +9304,7 @@ Internet-Draft YANG April 2009 The editor wishes to thank the following individuals, who all provided helpful comments on various versions of this document: Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav - Lhotka, Gerhard Muenz, Tom Petch, Randy Preshun, David Reid, and Bert + Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert Wijnen. --=-HZLj4RYS2m57t2KdMWpN-- From reid@snmp.com Thu May 14 07:59: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 C8C8528C264 for ; Thu, 14 May 2009 07:59: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=[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 U3TE20GAXyKL for ; Thu, 14 May 2009 07:59:09 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id B589E28C24E for ; Thu, 14 May 2009 07:59: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 LAA12643; Thu, 14 May 2009 11:00:38 -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 LAA04906; Thu, 14 May 2009 11:00:38 -0400 (EDT) Message-Id: <200905141500.LAA04906@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 13 May 2009 22:31:21 +0200. <20090513.223121.218543975.mbj@tail-f.com> Date: Thu, 14 May 2009 11:00:37 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about notifications 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: Thu, 14 May 2009 14:59:09 -0000 Thanks Martin, I think I understand this better now. -David Reid > David Reid wrote: > > > A predicate in the leafref path is the stuff inside the square > > > brackets. There are some examples of using predicates in 9.9.6 > > > (leafref usage examples). If the leafref points to a single-keyed > > > list, you don't use predicates: > > > > > > leaf if-name { > > > type leafref { > > > path "/interfaces/interface/name"; > > > } > > > } > > > > If the leafref points to a leaf that is not the key, such as ifIndex in the > > example from 9.9.6, do I use predicates? For example: > > > > leaf ifIndex { > > type leafref { > > path "/interfaces/interface/ifIndex"; > > } > > } > > Note that the path argument is a normal XPath epression. When this > expression is evaluated, it will return all nodes called > /interfaces/interface/ifIndex. If multiple 'interface' entries, you > will get multiple ifIndex nodes back. In this particular example, > ifIndex might actually be unique across all instances, so there might > be just one entry with a given ifIndex value, but in general this is > not the case. Consider this example: > > leaf my-admin-status { > type leafref { > path "/interfaces/interface/admin-status"; > } > } > > > > eth0 > up > > > eth1 > down > > > lo > up > > > > Now, the value space for the leaf 'my-admin-status' is [up, down]. > (If eth1 has admin-status 'up', the value space would have been [up]). > > So a valid my-admin-status could be: > > up > > Getting just this leaf in a notification isn't very usefulf, so > changing it into: > > leaf my-name { > type leafref { > path "/interfaces/interface/name"; > } > } > leaf my-admin-status { > type leafref { > path "/interfaces/interface[name = current()/../my-name]" > + "/admin-status"; > } > } > > would give: > > lo > up > > which is more useful. > > > /martin From reid@snmp.com Thu May 14 08:02: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 EF34028C2BF for ; Thu, 14 May 2009 08:02:50 -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 fRQzyFT1mpZA for ; Thu, 14 May 2009 08:02:50 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id AB80228C2C7 for ; Thu, 14 May 2009 08:01:32 -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 KAA11961 for ; Thu, 14 May 2009 10:53:02 -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 KAA04800 for ; Thu, 14 May 2009 10:53:01 -0400 (EDT) Message-Id: <200905141453.KAA04800@adminfs.snmp.com> To: netmod@ietf.org Date: Thu, 14 May 2009 10:53:01 -0400 From: David Reid Subject: [netmod] XML encoding order 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, 14 May 2009 15:02:51 -0000 At the San Francisco meeting, consensus was to drop the requirement that XML elements are encoded in the same order as defined in the yang module, except for RCP input and output. I have 2 questions: Why is order important for RPC input and output, but not other nodes? This was discussed in S.F., but I can't remember the details. I'm not suggesting we change anything, just trying to understand. The current draft, section 7.14.2., says the child nodes in a notification must be encoded in the same order as they are defined. Was the intent at the S.F. meeting to also drop the order requirement for notifications? I don't think notifications were specifically discussed. -David Reid From mbj@tail-f.com Thu May 14 08:22: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 E10C128C14C for ; Thu, 14 May 2009 08:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.169, 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 mvJmaruTVPqm for ; Thu, 14 May 2009 08:22: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 112423A6F62 for ; Thu, 14 May 2009 08:22:27 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 847A9616054; Thu, 14 May 2009 17:23:28 +0200 (CEST) Date: Thu, 14 May 2009 17:23:28 +0200 (CEST) Message-Id: <20090514.172328.264518240.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200905141453.KAA04800@adminfs.snmp.com> References: <200905141453.KAA04800@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] XML encoding order 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, 14 May 2009 15:22:28 -0000 Hi David, David Reid wrote: > At the San Francisco meeting, consensus was to drop the requirement that > XML elements are encoded in the same order as defined in the yang module, > except for RCP input and output. > > I have 2 questions: > > Why is order important for RPC input and output, but not other nodes? This > was discussed in S.F., but I can't remember the details. I'm not suggesting > we change anything, just trying to understand. The reason is that for some RPCs the order of input parameters may affect how much buffering a NETCONF server must do. The typical example, which has been discussed on the NETCONF ML in the past, is copy-config with inline data. It takes two parameters, target and source. Suppose source was encoded first: A server would in this case be required to buffer the enitre config. However, if target is encoded before source, then servers may take advantage of this fact and optimize the processing of the inline config depending on target. > The current draft, section 7.14.2., says the child nodes in a notification > must be encoded in the same order as they are defined. Was the intent at the > S.F. meeting to also drop the order requirement for notifications? I don't > think notifications were specifically discussed. Andy suggested a nice and simple solution to the ordering problem - we say that order matters on the "operations" layer, but not on the "application" layer. Hmm... I think you are right, according to the latest version of the NETCONF layers diagram (http://tools.ietf.org/html/draft-bierman-netmod-yang-usage-00) the order should not matter in notifications. Andy? /martin From andy@netconfcentral.com Thu May 14 08:41: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 057C728C13E for ; Thu, 14 May 2009 08:41:50 -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.060, 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 9wQI8e57yITh for ; Thu, 14 May 2009 08:41:49 -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 5106428C0CE for ; Thu, 14 May 2009 08:41:49 -0700 (PDT) Received: (qmail 62494 invoked from network); 14 May 2009 15:43:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 14 May 2009 15:43:20 -0000 X-YMail-OSG: xa52AOoVM1kaeUNlxCaooTNwkKH0F6.M2rcFLfPENtY2sWrveu4mYSFvGGjGIs60Ind08fdnoxNY2td6cXmwHHfDnNqsQQD9iwqQsfHi_U3x9eWwsxVN14F8.esAqHrAE7TJYvEcB5FKmTLEla9OeYReZZa6YIJDNQuUNXCWu905h57MooE7Lm5SCBJWbN_u3.jSthb7gpVC9Vw3PFzDVnJ_DxV4b24vGS6F6dEDZ0HZA0Y_E1tKePlAqJV5eqmlMZorBuJz8tMB8IevLdNFtHGbvcW.v8h1TTBo3ho2gl.VIfuWjze_2HtJ6WZlQOtf.QccgnNjQ1TRRjmw8sI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0C3C15.3020704@netconfcentral.com> Date: Thu, 14 May 2009 08:43:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <200905141453.KAA04800@adminfs.snmp.com> <20090514.172328.264518240.mbj@tail-f.com> In-Reply-To: <20090514.172328.264518240.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] XML encoding order 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, 14 May 2009 15:41:50 -0000 Martin Bjorklund wrote: > Hi David, > > David Reid wrote: >> At the San Francisco meeting, consensus was to drop the requirement that >> XML elements are encoded in the same order as defined in the yang module, >> except for RCP input and output. >> >> I have 2 questions: >> >> Why is order important for RPC input and output, but not other nodes? This >> was discussed in S.F., but I can't remember the details. I'm not suggesting >> we change anything, just trying to understand. > > The reason is that for some RPCs the order of input parameters may > affect how much buffering a NETCONF server must do. The typical > example, which has been discussed on the NETCONF ML in the past, is > copy-config with inline data. It takes two parameters, target and > source. Suppose source was encoded first: > > > > > > > > > > > > > A server would in this case be required to buffer the enitre config. > > However, if target is encoded before source, then servers may take > advantage of this fact and optimize the processing of the inline > config depending on target. > >> The current draft, section 7.14.2., says the child nodes in a notification >> must be encoded in the same order as they are defined. Was the intent at the >> S.F. meeting to also drop the order requirement for notifications? I don't >> think notifications were specifically discussed. > > Andy suggested a nice and simple solution to the ordering problem - we > say that order matters on the "operations" layer, but not on the > "application" layer. > > Hmm... I think you are right, according to the latest version of the > NETCONF layers diagram > (http://tools.ietf.org/html/draft-bierman-netmod-yang-usage-00) the > order should not matter in notifications. Andy? > I was just typing a response to the first part of the question, and then I saw your post and stopped. (I wonder if all the RPC operation parameters in 4741 are ordered to minimize buffering requirements? edit-config is the important one. I will put a note in the guidelines draft about designing for minimal buffering.) Notification content order should not matter to the agent or manager, but it seems like a good idea to follow schema order in the reply. It might help visual inspection for 'diff' or other simple applications. (I.e., SHOULD, not MUST) Agent output is usually streamed and does not require any buffering. > > /martin Andy From spakes@snmp.com Thu May 14 10: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 178943A6F48 for ; Thu, 14 May 2009 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, 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 YBH4lWGb22-u for ; Thu, 14 May 2009 10:03:10 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id E5E6428C266 for ; Thu, 14 May 2009 10:02:03 -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 NAA24798; Thu, 14 May 2009 13:03:35 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA08050; Thu, 14 May 2009 13:03:34 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 14 May 2009 13:03:34 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 17:03:12 -0000 Over the past couple of days, I have been working on implementing decimal64. I like the simplicity of the design that it is basically a signed 64-bit integer with the extra bit of information to tell you where the decimal point belongs. I don't particularly like the fact that the decimal point is always located at a fixed position for a leaf. Also, I find it unsettling that the upper and lower bounds of representable values are not nice round numbers (not base-10 boundaries). I have been experimenting with a construct that builds on decimal64 to allow one to represent numbers where the decimal point can move around. I want to propose that it be added to the "yang-types" document. Description follows, below. On Sun, 3 May 2009, Andy Bierman wrote: > David Spakes wrote: > > Largest positive value that can be represented in a decimal64: > > 922337203685477580.7 > > > > Largest negative value that can be represented in a decimal64: > > -922337203685477580.8 > > > I think the ranges are different for each value of fraction-digits: > > fd min max > --------------------------------------------------------- > 1 -922337203685477580.8 922337203685477580.7 > 2 -92233720368547758.08 92233720368547758.07 > 3 -9223372036854775.808 9223372036854775.807 > 4 -922337203685477.5808 922337203685477.5807 > 5 -92233720368547.75808 92233720368547.75807 > 6 -9223372036854.775808 9223372036854.775807 > 7 -922337203685.4775808 922337203685.4775807 > 8 -92233720368.54775808 92233720368.54775807 > 9 -9223372036.854775808 9223372036.854775807 > 10 -922337203.6854775808 922337203.6854775807 > 11 -92233720.36854775808 92233720.36854775807 > 12 -9223372.036854775808 9223372.036854775807 > 13 -922337.2036854775808 922337.2036854775807 > 14 -92233.72036854775808 92233.72036854775807 > 15 -9223.372036854775808 9223.372036854775807 > 16 -922.3372036854775808 922.3372036854775807 > 17 -92.23372036854775808 92.23372036854775807 > 18 -9.223372036854775808 9.223372036854775807 The construct I am proposing is a typedef of a union of eighteen decimal64 types, one for each of the possible values of fraction-digits. I have been calling it a "float", but readers should please jettison the connotation that this word carries about representing arbitrarily large or arbitrarily small positive and negative values via a mantissa and exponent. I only use this word to the extent of the meaning that the decimal point can move around within the value. If the working group chooses to use this construct but call it by another name, another possibility that comes to mind is "real". Here it is: typedef float { type union { type decimal64 { fraction-digits 18; range "-0.999999999999999999 .. 0.999999999999999999"; } type decimal64 { fraction-digits 17; range "-9.99999999999999999 .. 9.99999999999999999"; } type decimal64 { fraction-digits 16; range "-99.9999999999999999 .. 99.9999999999999999"; } type decimal64 { fraction-digits 15; range "-999.999999999999999 .. 999.999999999999999"; } type decimal64 { fraction-digits 14; range "-9999.99999999999999 .. 9999.99999999999999"; } type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } type decimal64 { fraction-digits 12; range "-999999.999999999999 .. 999999.999999999999"; } type decimal64 { fraction-digits 11; range "-9999999.99999999999 .. 9999999.99999999999"; } type decimal64 { fraction-digits 10; range "-99999999.9999999999 .. 99999999.9999999999"; } type decimal64 { fraction-digits 9; range "-999999999.999999999 .. 999999999.999999999"; } type decimal64 { fraction-digits 8; range "-9999999999.99999999 .. 9999999999.99999999"; } type decimal64 { fraction-digits 7; range "-99999999999.9999999 .. 99999999999.9999999"; } type decimal64 { fraction-digits 6; range "-999999999999.999999 .. 999999999999.999999"; } type decimal64 { fraction-digits 5; range "-9999999999999.99999 .. 9999999999999.99999"; } type decimal64 { fraction-digits 4; range "-99999999999999.9999 .. 99999999999999.9999"; } type decimal64 { fraction-digits 3; range "-999999999999999.999 .. 999999999999999.999"; } type decimal64 { fraction-digits 2; range "-9999999999999999.99 .. 9999999999999999.99"; } type decimal64 { fraction-digits 1; range "-99999999999999999.9 .. 99999999999999999.9"; } } } Using this construct, neither application writer nor the author of a YANG document need take into consideration how many fraction digits are needed for a particular leaf. The position of the decimal point is determined implicitly by the number of digits in the whole-number part of the value. The more digits you need to use to represent the magnitude, the fewer digits you have left over for precision. The above definition for a "float" seems cumbersome, but I believe most application writers will find that the semantic is familiar and comfortable. To demonstrate what I mean, here is a simple illustration. The behavior of this construct is very much like that of any common calculator (either a non-scientific calculator or a scientific calculator in non-scientific mode). Mine has a 10-digit LCD display. If I press the key for pi, the screen shows 3.141592654. This is not all of the digits for pi, but the calculator can only hold ten digits. The magnitude requires one digit, leaving nine digits for precision. If I press 'x' '10' '=', now the screen shows 31.41592654. The magnitude now requires two digits, and so we lost one digit of precision. The same digits are on the screen...the decimal point just floated to its new position. One can imagine a leaf that is type "float" as working like a calculator having an 18-digit display. The purpose for the range substatements is also for comfort level. An opinion expressed in conversation both by me and one of my coworkers was that decimal64 feels "weird" because the range of values does not end on a base-10 boundary. The range provides upper and lower bounds on a base-10 boundary by sacrificing one digit of magnitude. For example: The largest positive value that can be represented by a leaf that is a 922337203685477580.7 <--- decimal64 with fraction-digits 1. 99999999999999999.9 <--- The largest positive value that can be represented by the float construct described by this proposal. If this proposal is acceptable to the working group, I would offer to formalize the text of the description unless the document editor would prefer to do that. Regards, David Spakes ------------------------------------------------------------- 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 randy_presuhn@mindspring.com Thu May 14 10:09: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 43FEC3A68AB for ; Thu, 14 May 2009 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=-1.431, BAYES_50=0.001, J_CHICKENPOX_44=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 PI9wQj9ouAUY for ; Thu, 14 May 2009 10:09:17 -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 8E9213A6F15 for ; Thu, 14 May 2009 10:09:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JHDoo3HxbCqUcYKCfP6Io7eQvvGYwTNAHo5+wJ67ZslV3wb1Y4dlSNE/LQhehcB9; 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.130] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M4eSI-0004pr-AU for netmod@ietf.org; Thu, 14 May 2009 13:10:50 -0400 Message-ID: <000e01c9d4b7$62db1b40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Thu, 14 May 2009 10:14: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696878a911a4f875741dba2213583f8c6c23350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.130 Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 17:09:18 -0000 Hi - > From: "David Spakes" > To: > Sent: Thursday, May 14, 2009 10:03 AM > Subject: Re: [netmod] float vs. decimal ... > I have been experimenting with a construct that builds on decimal64 to > allow one to represent numbers where the decimal point can move around. > I want to propose that it be added to the "yang-types" document. .. Care to comment on the pros&cons of this with respect to IEEE float, particularly regarding matching in xpath? Randy From andy@netconfcentral.com Thu May 14 10:25:33 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 651D43A6B4D for ; Thu, 14 May 2009 10:25:33 -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.060, 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 46NJi7dGsEE8 for ; Thu, 14 May 2009 10:25:32 -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 1DA033A703C for ; Thu, 14 May 2009 10:25:32 -0700 (PDT) Received: (qmail 73624 invoked from network); 14 May 2009 17:27:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 14 May 2009 17:27:01 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0C5463.7060605@netconfcentral.com> Date: Thu, 14 May 2009 10:26:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Spakes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 17:25:33 -0000 David Spakes wrote: > Over the past couple of days, I have been working on implementing > decimal64. I like the simplicity of the design that it is basically > a signed 64-bit integer with the extra bit of information to tell you > where the decimal point belongs. I don't particularly like the fact > that the decimal point is always located at a fixed position for a leaf. > Also, I find it unsettling that the upper and lower bounds of > representable values are not nice round numbers (not base-10 boundaries). > > I have been experimenting with a construct that builds on decimal64 to > allow one to represent numbers where the decimal point can move around. > I want to propose that it be added to the "yang-types" document. > Description follows, below. > We already two of those 'decimal point moving around' things, and we took them out. I think decimal64 is good enough, because fixed point is really good enough. It might be better for decimal64 if it did not utilize the entire value-space, so that the clean ranges you defined in your union could be the built-in range limits. I do not think the ranges currently supported are intuitive, but the YANG compiler will catch any error immediately, so it is not a big deal. There is still an issue with the canonical form: with all the fraction-digits or with trailing zeros trimmed. Your union typedef relies on the exact number of fraction digits being used every time for a given object. The current canonical form (remove trailing zeros) breaks your 'float' data type. Andy > > On Sun, 3 May 2009, Andy Bierman wrote: > >> David Spakes wrote: >>> Largest positive value that can be represented in a decimal64: >>> 922337203685477580.7 >>> >>> Largest negative value that can be represented in a decimal64: >>> -922337203685477580.8 >> >> I think the ranges are different for each value of fraction-digits: >> >> fd min max >> --------------------------------------------------------- >> 1 -922337203685477580.8 922337203685477580.7 >> 2 -92233720368547758.08 92233720368547758.07 >> 3 -9223372036854775.808 9223372036854775.807 >> 4 -922337203685477.5808 922337203685477.5807 >> 5 -92233720368547.75808 92233720368547.75807 >> 6 -9223372036854.775808 9223372036854.775807 >> 7 -922337203685.4775808 922337203685.4775807 >> 8 -92233720368.54775808 92233720368.54775807 >> 9 -9223372036.854775808 9223372036.854775807 >> 10 -922337203.6854775808 922337203.6854775807 >> 11 -92233720.36854775808 92233720.36854775807 >> 12 -9223372.036854775808 9223372.036854775807 >> 13 -922337.2036854775808 922337.2036854775807 >> 14 -92233.72036854775808 92233.72036854775807 >> 15 -9223.372036854775808 9223.372036854775807 >> 16 -922.3372036854775808 922.3372036854775807 >> 17 -92.23372036854775808 92.23372036854775807 >> 18 -9.223372036854775808 9.223372036854775807 > > > > The construct I am proposing is a typedef of a union of eighteen > decimal64 types, one for each of the possible values of fraction-digits. > I have been calling it a "float", but readers should please jettison the > connotation that this word carries about representing arbitrarily large > or arbitrarily small positive and negative values via a mantissa and > exponent. I only use this word to the extent of the meaning that the > decimal point can move around within the value. If the working group > chooses to use this construct but call it by another name, another > possibility that comes to mind is "real". Here it is: > > > typedef float { > type union { > type decimal64 { > fraction-digits 18; > range "-0.999999999999999999 .. 0.999999999999999999"; > } > type decimal64 { > fraction-digits 17; > range "-9.99999999999999999 .. 9.99999999999999999"; > } > type decimal64 { > fraction-digits 16; > range "-99.9999999999999999 .. 99.9999999999999999"; > } > type decimal64 { > fraction-digits 15; > range "-999.999999999999999 .. 999.999999999999999"; > } > type decimal64 { > fraction-digits 14; > range "-9999.99999999999999 .. 9999.99999999999999"; > } > type decimal64 { > fraction-digits 13; > range "-99999.9999999999999 .. 99999.9999999999999"; > } > type decimal64 { > fraction-digits 12; > range "-999999.999999999999 .. 999999.999999999999"; > } > type decimal64 { > fraction-digits 11; > range "-9999999.99999999999 .. 9999999.99999999999"; > } > type decimal64 { > fraction-digits 10; > range "-99999999.9999999999 .. 99999999.9999999999"; > } > type decimal64 { > fraction-digits 9; > range "-999999999.999999999 .. 999999999.999999999"; > } > type decimal64 { > fraction-digits 8; > range "-9999999999.99999999 .. 9999999999.99999999"; > } > type decimal64 { > fraction-digits 7; > range "-99999999999.9999999 .. 99999999999.9999999"; > } > type decimal64 { > fraction-digits 6; > range "-999999999999.999999 .. 999999999999.999999"; > } > type decimal64 { > fraction-digits 5; > range "-9999999999999.99999 .. 9999999999999.99999"; > } > type decimal64 { > fraction-digits 4; > range "-99999999999999.9999 .. 99999999999999.9999"; > } > type decimal64 { > fraction-digits 3; > range "-999999999999999.999 .. 999999999999999.999"; > } > type decimal64 { > fraction-digits 2; > range "-9999999999999999.99 .. 9999999999999999.99"; > } > type decimal64 { > fraction-digits 1; > range "-99999999999999999.9 .. 99999999999999999.9"; > } > } > } > > > Using this construct, neither application writer nor the author of a > YANG document need take into consideration how many fraction digits > are needed for a particular leaf. The position of the decimal point > is determined implicitly by the number of digits in the whole-number > part of the value. The more digits you need to use to represent the > magnitude, the fewer digits you have left over for precision. > > The above definition for a "float" seems cumbersome, but I believe most > application writers will find that the semantic is familiar and > comfortable. To demonstrate what I mean, here is a simple illustration. > > The behavior of this construct is very much like that of any common > calculator (either a non-scientific calculator or a scientific > calculator in non-scientific mode). Mine has a 10-digit LCD display. > > If I press the key for pi, the screen shows 3.141592654. This is > not all of the digits for pi, but the calculator can only hold > ten digits. The magnitude requires one digit, leaving nine digits > for precision. > > If I press 'x' '10' '=', now the screen shows 31.41592654. The > magnitude now requires two digits, and so we lost one digit of > precision. The same digits are on the screen...the decimal point > just floated to its new position. > > One can imagine a leaf that is type "float" as working like a > calculator having an 18-digit display. > > > The purpose for the range substatements is also for comfort level. An > opinion expressed in conversation both by me and one of my coworkers > was that decimal64 feels "weird" because the range of values does not > end on a base-10 boundary. The range provides upper and lower bounds > on a base-10 boundary by sacrificing one digit of magnitude. > For example: > > The largest positive value that can > be represented by a leaf that is a > 922337203685477580.7 <--- decimal64 with fraction-digits 1. > > 99999999999999999.9 <--- The largest positive value that can > be represented by the float construct > described by this proposal. > > > If this proposal is acceptable to the working group, I would offer to > formalize the text of the description unless the document editor would > prefer to do that. > > Regards, > > David Spakes > > > ------------------------------------------------------------- > 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 > ------------------------------------------------------------- > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From spakes@snmp.com Thu May 14 10:37: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 0D46028C148 for ; Thu, 14 May 2009 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_44=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 W0z0F5d0LEOQ for ; Thu, 14 May 2009 10:37:05 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id B0A0B28C2D1 for ; Thu, 14 May 2009 10:36:33 -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 NAA28231; Thu, 14 May 2009 13:38:04 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA08369; Thu, 14 May 2009 13:38:04 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 14 May 2009 13:38:03 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org, Randy Presuhn In-Reply-To: <000e01c9d4b7$62db1b40$6801a8c0@oemcomputer> Message-ID: References: <000e01c9d4b7$62db1b40$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 17:37:06 -0000 On Thu, 14 May 2009, Randy Presuhn wrote: > Care to comment on the pros&cons of this with respect to IEEE float, > particularly regarding matching in xpath? > Randy I would defer to others more experienced with XPath to offer their comments. I was just re-reading the conversation between Martin, Andy, and David Parain from early February about the desire to be compatible with existing technology. If there is compelling reason to limit the number of digits after the decimal point to 14 to be friendly with the IEEE representation, then the decimal64 members of the union with fraction-digits values of 15-18 could be deleted, as shown below. Regards, David Spakes typedef float { type union { type decimal64 { fraction-digits 14; range "-9999.99999999999999 .. 9999.99999999999999"; } type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } type decimal64 { fraction-digits 12; range "-999999.999999999999 .. 999999.999999999999"; } type decimal64 { fraction-digits 11; range "-9999999.99999999999 .. 9999999.99999999999"; } type decimal64 { fraction-digits 10; range "-99999999.9999999999 .. 99999999.9999999999"; } type decimal64 { fraction-digits 9; range "-999999999.999999999 .. 999999999.999999999"; } type decimal64 { fraction-digits 8; range "-9999999999.99999999 .. 9999999999.99999999"; } type decimal64 { fraction-digits 7; range "-99999999999.9999999 .. 99999999999.9999999"; } type decimal64 { fraction-digits 6; range "-999999999999.999999 .. 999999999999.999999"; } type decimal64 { fraction-digits 5; range "-9999999999999.99999 .. 9999999999999.99999"; } type decimal64 { fraction-digits 4; range "-99999999999999.9999 .. 99999999999999.9999"; } type decimal64 { fraction-digits 3; range "-999999999999999.999 .. 999999999999999.999"; } type decimal64 { fraction-digits 2; range "-9999999999999999.99 .. 9999999999999999.99"; } type decimal64 { fraction-digits 1; range "-99999999999999999.9 .. 99999999999999999.9"; } } } On Mon, 9 Feb 2009 netmod@ietf.org wrote: > I did some experiments: > - %.14f seems to be safest, although sometimes 15 decimal > places of precision is OK. > - the only glibc option that matches YANG and XPath is %f, > and you have to manually remove trailing zeros and maybe > the decimal point as well. > - strtof is broken in glibc, so float32 is quite problematic. > strtod works fine, so 'double' is not affected, just 'float'. > (try strtof('1.3')). > - I prefer to use the glibc names for inf, -inf, and nan, > instead of inventing new terms. > > Attached is a terse summary of the precision issue (x.c and its output) ... > Andy ------------------------------------------------------------- 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 May 14 10:56: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 956A13A6B62 for ; Thu, 14 May 2009 10:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 4rbAOIshWk1R for ; Thu, 14 May 2009 10:56:25 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 530513A706D for ; Thu, 14 May 2009 10:56:25 -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 NAA00830; Thu, 14 May 2009 13:57:57 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA08742; Thu, 14 May 2009 13:57:56 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 14 May 2009 13:57:56 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4A0C5463.7060605@netconfcentral.com> Message-ID: References: <4A0C5463.7060605@netconfcentral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 17:56:26 -0000 On Thu, 14 May 2009, Andy Bierman wrote: > We already two of those 'decimal point moving around' things, > and we took them out. I think decimal64 is good enough, > because fixed point is really good enough. Earlier this year, I wrote code to implement float32 and float64. For testing and demonstration purposes, I created a simple example which was, in fact, a FLOATING-POINT-CALCULATOR module. When the decision of the group was to eliminate float32 and float64 in favor of decimal64, I changed the code to implement decimal64. However, when I proceeded to update the example for decimal64, I found that it really didn't fit anymore. Instead, I created a new and different example to demonstrate decimal64. However, this exercise got me thinking. If decimal64 wasn't a nice fit for the data in the very first example I created, I figured there were likely to be applications in the field for which decimal64 would also not be a good fit. What I am proposing is just to formalize something that is already completely legal to do in YANG. Anyone can make a union of multiple decimal64 variations. My assertion is that it would be better for everyone to use the same flavor of 'decimal point moving around' thing than for everyone to invent their own. By formalizing the float/real typedef of a union now, any potential XPath concerns can be addressed. > There is still an issue with the canonical form: > with all the fraction-digits or with trailing zeros trimmed. > Your union typedef relies on the exact number of > fraction digits being used every time for a given object. I don't understand what you mean. Since the float/real proposal is just a union of decimal64, the conanical constraints that apply to any individual member of the union would apply to the whole. > The current canonical form (remove trailing zeros) breaks > your 'float' data type. How? If a leaf is defined to be of type float/real, and if the value is "52.3", that value could be assumed by any of the decimal64 members of the union with fraction-digits values between 1 and 17 inclusive, and therefore it would be legal for the leaf. What does it matter that the data could equally fit more than one union member? Regards, David Spakes ------------------------------------------------------------- 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 May 14 11:05: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 438F13A7067 for ; Thu, 14 May 2009 11:05:35 -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 BWPGUAXm-mSt for ; Thu, 14 May 2009 11:05:34 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id BFCAE28C33B for ; Thu, 14 May 2009 11:05:20 -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 OAA03096; Thu, 14 May 2009 14:06:52 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA08902; Thu, 14 May 2009 14:06:52 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 14 May 2009 14:06:52 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: Message-ID: References: <4A0C5463.7060605@netconfcentral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 18:05:35 -0000 On Thu, 14 May 2009, David Spakes wrote: > > The current canonical form (remove trailing zeros) breaks > > your 'float' data type. > > How? If a leaf is defined to be of type float/real, and if the value > is "52.3", that value could be assumed by any of the decimal64 members of > the union with fraction-digits values between 1 and 17 inclusive, and > therefore it would be legal for the leaf. What does it matter that > the data could equally fit more than one union member? Correction: between 1 and 16 inclusive. Regards, David Spakes ------------------------------------------------------------- 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 andy@netconfcentral.com Thu May 14 11:13: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 C756328C2A0 for ; Thu, 14 May 2009 11:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 wf90D39jndTb for ; Thu, 14 May 2009 11:13:22 -0700 (PDT) Received: from n16.bullet.mail.mud.yahoo.com (n16.bullet.mail.mud.yahoo.com [68.142.206.43]) by core3.amsl.com (Postfix) with SMTP id 5009E28C37E for ; Thu, 14 May 2009 11:12:38 -0700 (PDT) Received: from [68.142.200.226] by n16.bullet.mail.mud.yahoo.com with NNFMP; 14 May 2009 18:14:09 -0000 Received: from [68.142.201.242] by t7.bullet.mud.yahoo.com with NNFMP; 14 May 2009 18:14:09 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 14 May 2009 18:14:09 -0000 X-Yahoo-Newman-Id: 627803.7940.bm@omp403.mail.mud.yahoo.com Received: (qmail 55467 invoked from network); 14 May 2009 18:14:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 14 May 2009 18:14:08 -0000 X-YMail-OSG: YMrDoO4VM1lH3OSxaakYrAiepeKSgnkTV00jBlKZXXOnDNWCqCGSdasH3WpIMcFgjha5qC6uGLpXlrfIAK4.laAvgWx4wGSP8.eOkNJZcFkrnVBbcJuP.hgC79j3eSdZ7qKmG3y_qdD5HFY2Dy85QoEnXrSbL7bwv9n1RWvsneaoJsZSaJ3vs6bcYGnX0s.ZmaMjnK_ajzyHqS_IoCBrs6XyKabEQ2r70BXs9zHVr2AOQOT8wWR1Wh1fSSBHsjPvG95Spr2kkOc_fh2W5GkrwCXXSObtk9STLRnr8R3dUj4VLMaFuHg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0C5F6F.1080702@netconfcentral.com> Date: Thu, 14 May 2009 11:14:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Spakes References: <4A0C5463.7060605@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 18:13:22 -0000 David Spakes wrote: > On Thu, 14 May 2009, Andy Bierman wrote: > >> We already two of those 'decimal point moving around' things, >> and we took them out. I think decimal64 is good enough, >> because fixed point is really good enough. > > > Earlier this year, I wrote code to implement float32 and float64. > For testing and demonstration purposes, I created a simple example > which was, in fact, a FLOATING-POINT-CALCULATOR module. > > When the decision of the group was to eliminate float32 and float64 > in favor of decimal64, I changed the code to implement decimal64. > However, when I proceeded to update the example for decimal64, I > found that it really didn't fit anymore. Instead, I created a new > and different example to demonstrate decimal64. However, this > exercise got me thinking. If decimal64 wasn't a nice fit for the > data in the very first example I created, I figured there were > likely to be applications in the field for which decimal64 would > also not be a good fit. > > What I am proposing is just to formalize something that is already > completely legal to do in YANG. Anyone can make a union of multiple > decimal64 variations. My assertion is that it would be better for > everyone to use the same flavor of 'decimal point moving around' thing > than for everyone to invent their own. > > By formalizing the float/real typedef of a union now, any potential > XPath concerns can be addressed. > > >> There is still an issue with the canonical form: >> with all the fraction-digits or with trailing zeros trimmed. >> Your union typedef relies on the exact number of >> fraction digits being used every time for a given object. > > > I don't understand what you mean. Since the float/real proposal > is just a union of decimal64, the conanical constraints that apply > to any individual member of the union would apply to the whole. > > >> The current canonical form (remove trailing zeros) breaks >> your 'float' data type. > > > How? If a leaf is defined to be of type float/real, and if the value > is "52.3", that value could be assumed by any of the decimal64 members of > the union with fraction-digits values between 1 and 17 inclusive, and > therefore it would be legal for the leaf. What does it matter that > the data could equally fit more than one union member? > > If the user enters 99991.00000000000000, will it be detected as an overflow, or not? Will the agent trim the zeros to 99991.0 (canonical form), so it appears valid (99991 within range for fraction-digits 1). What if the user changes the value to 99991.00000000000001? Then it becomes an error, instead of just matching the wrong union type member. If the agent allows the range to keep changing, every time the leaf is modified, just like a float, then we should just use the IEEE 754 data type for that. > Regards, > > David Spakes > Andy From mbj@tail-f.com Thu May 14 12:01: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 0C9923A6D9C for ; Thu, 14 May 2009 12:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.167, 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 NuE4tLBXx+3I for ; Thu, 14 May 2009 12:01:02 -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 B0F0D3A705A for ; Thu, 14 May 2009 12: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 A397661600D; Thu, 14 May 2009 21:02:12 +0200 (CEST) Date: Thu, 14 May 2009 21:02:12 +0200 (CEST) Message-Id: <20090514.210212.27541424.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A0C3C15.3020704@netconfcentral.com> References: <200905141453.KAA04800@adminfs.snmp.com> <20090514.172328.264518240.mbj@tail-f.com> <4A0C3C15.3020704@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] XML encoding order 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, 14 May 2009 19:01:03 -0000 Hi, Andy Bierman wrote: > Notification content order should not matter to the agent or manager, > but it seems like a good idea to follow schema order in the reply. > It might help visual inspection for 'diff' or other simple applications. > (I.e., SHOULD, not MUST) So, I will remove this text from 7.14.3: 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. /martin From spakes@snmp.com Thu May 14 12:19: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 73CE83A705A for ; Thu, 14 May 2009 12:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 9UnWcigjRiPz for ; Thu, 14 May 2009 12:19:43 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id F342D3A6DF3 for ; Thu, 14 May 2009 12:19: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 PAA12176 for ; Thu, 14 May 2009 15:20:53 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA09971; Thu, 14 May 2009 15:11:09 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 14 May 2009 15:11:09 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4A0C5F6F.1080702@netconfcentral.com> Message-ID: References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 19:19:44 -0000 On Thu, 14 May 2009, Andy Bierman wrote: > David Spakes wrote: > > On Thu, 14 May 2009, Andy Bierman wrote: > >> The current canonical form (remove trailing zeros) breaks > >> your 'float' data type. > > > > How? If a leaf is defined to be of type float/real, and if the value > > is "52.3", that value could be assumed by any of the decimal64 members of > > the union with fraction-digits values between 1 and 17 inclusive, and > > therefore it would be legal for the leaf. What does it matter that > > the data could equally fit more than one union member? > > If the user enters 99991.00000000000000, will it > be detected as an overflow, or not? Since there are five digits of magnitude (9-9-9-9-1), there are thirteen digits of precision available. The union member that best fits this data is: type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } You specified fourteen digits after the decimal point, which is greater precision than the type can represent. The choices are to round or truncate. > Will the > agent trim the zeros to 99991.0 (canonical form), > so it appears valid (99991 within range for fraction-digits 1). I am not a participant in the thread discussing the canonical form of decimal64. I would defer to one of the participants in that discussion to answer your question. I will observe that my 10-digit LCD non-scientific calculator prefers the canonical form if I enter 99991.00000 and press '='. :-) > What if the user changes the value to 99991.00000000000001? You specified fourteen digits after the decimal point, which is greater precision than the type can represent when there are five digits of magnitude. The current choices are to round or truncate. > Then it becomes an error, instead of just matching > the wrong union type member. If a module were to define a leaf of type float/real, container numbers { leaf ratio { type yang:float; config true; } } and if the agent were to receive an message with the above value for the leaf, 99991.00000000000001 then I would agree with you this is an error. If the application underlying an agent were to contain a value 99991.00000000000001, that might be fine for the application, but the agent could not represent the value in a float/real leaf with full precision. When the application delivers the value to the agent in response to a or message, the value would need to be rounded or truncated by either the application or the agent. If neither rounding nor truncation were an acceptable operation for the leaf, then I suppose the situation would be an error condition. Are you suggesting that in this case the union should have one additional member, like this? type enumeration { enum overflow; enum underflow; } > If the agent allows the range to keep changing, > every time the leaf is modified, just like a float, > then we should just use the IEEE 754 data type for that. I'm not a proponent of using the IEEE data type. I like the decimal64 concept a lot, I just think there needs to be an option so the decimal point isn't permanently fixed to one position of a leaf. The float/real union is my compromise proposal. If the possibility exists that someone may argue to reintroduce float32/float64 as a built-in type in a future version of YANG, then perhaps it would be best to call the typedef union of decimal64 that I am proposing "real" instead of "float". Regards, David Spakes ------------------------------------------------------------- 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 reid@snmp.com Thu May 14 12:33: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 098723A679C for ; Thu, 14 May 2009 12:33: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 1BX7WdFqRQ3b for ; Thu, 14 May 2009 12:33:08 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 11F463A6899 for ; Thu, 14 May 2009 12:33:07 -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 PAA13178 for ; Thu, 14 May 2009 15:34:40 -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 PAA10347 for ; Thu, 14 May 2009 15:34:40 -0400 (EDT) Message-Id: <200905141934.PAA10347@adminfs.snmp.com> To: netmod@ietf.org Date: Thu, 14 May 2009 15:34:40 -0400 From: David Reid Subject: [netmod] WGLC comments about anyxml 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, 14 May 2009 19:33:09 -0000 A few questions and comments about anyxml: section 3.1: can anyxml be mandatory? section 4.2.2 says "YANG defines four types of nodes for data modeling". Is anyxml a 5th type of node for data modeling or is anyxml a different kind of beast? section 6.2.1: anyxml is not included anywhere. I assume it should be listed with leafs, leaf-lists, etc. sections 7.5.6 and 7.8.4: should anyxml be added as a possible child node? section 7.10 states that the "anyxml" statement defines an interior node in the schema tree. A note about how it affects the data tree might also be useful, much like some of the other parts of section 7. -David Reid From spakes@snmp.com Thu May 14 13:00: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 0966028C1A6 for ; Thu, 14 May 2009 13:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 rBXEvYoFpkAS for ; Thu, 14 May 2009 13:00:17 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id E3E733A68ED for ; Thu, 14 May 2009 13:00:16 -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 QAA15692; Thu, 14 May 2009 16:01:45 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA10684; Thu, 14 May 2009 16:01:45 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 14 May 2009 16:01:45 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org In-Reply-To: <200905132027.QAA10513@adminfs.snmp.com> Message-ID: References: <200905132027.QAA10513@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] WGLC very minor nits 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, 14 May 2009 20:00:18 -0000 A few more minor nits in the yang doc: Section 7.7.3, first paragraph on page 64: A valid leaf-list or list MUST have least min-elements entries. should be A valid leaf-list or list MUST have at least min-elements entries. -- section 7.9.6, first paragraph on page 80: Since only one of the choices cases can be valid at any time, the should be Since only one of the choice's cases can be valid at any time, the Regards, David Spakes ------------------------------------------------------------- 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 Thu May 14 13:26: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 6FBCF28C35E for ; Thu, 14 May 2009 13:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.166, 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 zw2ffNc+fLJn for ; Thu, 14 May 2009 13:26: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 5A1363A6E0C for ; Thu, 14 May 2009 13:26:21 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 80C8261600D; Thu, 14 May 2009 22:27:53 +0200 (CEST) Date: Thu, 14 May 2009 22:27:53 +0200 (CEST) Message-Id: <20090514.222753.105692034.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <200905132027.QAA10513@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] WGLC very minor nits 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, 14 May 2009 20:26:32 -0000 David Spakes wrote: > A few more minor nits in the yang doc: Thanks, fixed. /martin > > > Section 7.7.3, first paragraph on page 64: > > A valid leaf-list or list MUST have least min-elements entries. > > should be > > A valid leaf-list or list MUST have at least min-elements entries. > > -- > > section 7.9.6, first paragraph on page 80: > > Since only one of the choices cases can be valid at any time, the > > should be > > Since only one of the choice's cases can be valid at any time, the > > > > Regards, > > David Spakes > > > ------------------------------------------------------------- > 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 > ------------------------------------------------------------- > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Thu May 14 13:41: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 BCE1E3A67E5 for ; Thu, 14 May 2009 13:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 rCnPvRmJTYcd for ; Thu, 14 May 2009 13:41: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 C6C7C28C145 for ; Thu, 14 May 2009 13:41:16 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95B79C00B1; Thu, 14 May 2009 22:42:49 +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 VhhSlce+tumO; Thu, 14 May 2009 22:42:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84099C009A; Thu, 14 May 2009 22:42:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5888EAEEE0A; Thu, 14 May 2009 22:42:46 +0200 (CEST) Date: Thu, 14 May 2009 22:42:46 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20090514204246.GA1276@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , "netmod@ietf.org" References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.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] float vs. decimal 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, 14 May 2009 20:41:17 -0000 On Thu, May 14, 2009 at 09:11:09PM +0200, David Spakes wrote: > If the possibility exists that someone may argue to reintroduce > float32/float64 as a built-in type in a future version of YANG, then > perhaps it would be best to call the typedef union of decimal64 that > I am proposing "real" instead of "float". For me, this proposal is neither a "real" nor a "float" but a "hack". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From vaughn@snmp.com Thu May 14 14:05: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 122173A7046 for ; Thu, 14 May 2009 14:05:00 -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 S8xJ4dskXZf3 for ; Thu, 14 May 2009 14:04:59 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 496DD3A6D00 for ; Thu, 14 May 2009 14:04:59 -0700 (PDT) Received: from ws5 (IDENT:U2FsdGVkX1+0O22jck+V3i1taYkR9w9vSV7sGZvNFWc@ws5.snmp.com [192.147.142.193]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA21819 for ; Thu, 14 May 2009 17:06:32 -0400 (EDT) Date: Thu, 14 May 2009 17:06:31 -0400 (EDT) From: Michael Vaughn To: NETMOD Working Group Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [netmod] require-instance 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, 14 May 2009 21:05:00 -0000 shouldn't require-instance be listed in the type substatements(7.4.1)? mike From spakes@snmp.com Thu May 14 15:24: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 BAC823A6A4A for ; Thu, 14 May 2009 15:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 MtfzPsLq7hQ1 for ; Thu, 14 May 2009 15:24:07 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 694043A7058 for ; Thu, 14 May 2009 15:24:07 -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 SAA26827; Thu, 14 May 2009 18:25:30 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id SAA12630; Thu, 14 May 2009 18:25:27 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 14 May 2009 18:25:25 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20090514204246.GA1276@elstar.local> Message-ID: References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 14 May 2009 22:24:08 -0000 On Thu, 14 May 2009, Juergen Schoenwaelder wrote: > For me, this proposal is neither a "real" nor a "float" but a "hack". In response to other comments I received both on and off the list, I would like to amend my proposal to call the typedef of the union "real". There is too much baggage associated with "float", and I prefer "real" over "hack", thank you very much. On Thu, 14 May 2009, Andy Bierman wrote: > What if the user changes the value to 99991.00000000000001? Thinking more about the union, I considered this text near the top of Page 131 of draft-ietf-netmod-yang-05.txt: "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." No matter how many more trailing digits the user adds to the end of a number after the decimal point, the whole number part is going to determine which member of the union is the best match because of the range restriction. For the string "99991.0000000000000123456789", the first matching union member will still be: type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } Also, the more I think about it, the more I like the idea of adding the enumeration to the end of the union. For a string containing any positive number larger than 99999999999999999.9 or containing any negative number larger than -99999999999999999.9, the first matching union member would be the enumeration. Here, then, is the revised proposal: typedef real { type union { type decimal64 { fraction-digits 18; range "-0.999999999999999999 .. 0.999999999999999999"; } type decimal64 { fraction-digits 17; range "-9.99999999999999999 .. 9.99999999999999999"; } type decimal64 { fraction-digits 16; range "-99.9999999999999999 .. 99.9999999999999999"; } type decimal64 { fraction-digits 15; range "-999.999999999999999 .. 999.999999999999999"; } type decimal64 { fraction-digits 14; range "-9999.99999999999999 .. 9999.99999999999999"; } type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } type decimal64 { fraction-digits 12; range "-999999.999999999999 .. 999999.999999999999"; } type decimal64 { fraction-digits 11; range "-9999999.99999999999 .. 9999999.99999999999"; } type decimal64 { fraction-digits 10; range "-99999999.9999999999 .. 99999999.9999999999"; } type decimal64 { fraction-digits 9; range "-999999999.999999999 .. 999999999.999999999"; } type decimal64 { fraction-digits 8; range "-9999999999.99999999 .. 9999999999.99999999"; } type decimal64 { fraction-digits 7; range "-99999999999.9999999 .. 99999999999.9999999"; } type decimal64 { fraction-digits 6; range "-999999999999.999999 .. 999999999999.999999"; } type decimal64 { fraction-digits 5; range "-9999999999999.99999 .. 9999999999999.99999"; } type decimal64 { fraction-digits 4; range "-99999999999999.9999 .. 99999999999999.9999"; } type decimal64 { fraction-digits 3; range "-999999999999999.999 .. 999999999999999.999"; } type decimal64 { fraction-digits 2; range "-9999999999999999.99 .. 9999999999999999.99"; } type decimal64 { fraction-digits 1; range "-99999999999999999.9 .. 99999999999999999.9"; } type enumeration { enum overflow; enum underflow; description "Positive numbers larger than 99999999999999999.9 SHALL be represented as an overflow. Negative numbers larger than -99999999999999999.9 SHALL be represented as an underflow."; } } } Regards, David Spakes ------------------------------------------------------------- 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 andy@netconfcentral.com Thu May 14 17:16: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 6873728C146 for ; Thu, 14 May 2009 17:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.066, 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 fAL555i8b5SW for ; Thu, 14 May 2009 17:16:57 -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 87A513A6D44 for ; Thu, 14 May 2009 17:16:57 -0700 (PDT) Received: (qmail 41126 invoked from network); 15 May 2009 00:18:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 15 May 2009 00:18:28 -0000 X-YMail-OSG: Xv2BCF4VM1mifokup_XXc8nbBVu_PqqHtZ8QJJnUZ2avIyTuZoC3fm0PG2T2V8dSRCiuGOyKR.0BNxoQM2mFOvBB6FAdqZqG_lRDVRBojed9T5tS7EZKEBbzPX_.mQXfoRjrSjY9Nb7rRUrTIqtvAm6nzf7HFv9ESmOPQHaSR1XTNoD4Y7MMFY8nMtW4TZTWq18GNJDww191LU.6DRrqsLU8emctO29S1KMqj5Wzt0cv4NMnqXVgFISUfEKMJ7oXroQou0WokHuwiPk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0CB4D1.1070101@netconfcentral.com> Date: Thu, 14 May 2009 17:18:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Spakes References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 00:16:58 -0000 David Spakes wrote: > On Thu, 14 May 2009, Juergen Schoenwaelder wrote: > >> For me, this proposal is neither a "real" nor a "float" but a "hack". > > > In response to other comments I received both on and off the list, I would > like to amend my proposal to call the typedef of the union "real". > > There is too much baggage associated with "float", and I prefer "real" > over "hack", thank you very much. > I don't think Juergen's concern was the name of the data type. Two usual questions that come up for any standards proposal: 1) what problem is being solved? 2) are there any existing standards which could be used instead? I am not convinced either question has been answered yet. It sure looks like we have a need for fixed-point, not for real (or floating point) numbers, and if we did, there is the IEEE 754 spec that a NETCONF needs to implement already for XPath 1.0 support. > > > On Thu, 14 May 2009, Andy Bierman wrote: > >> What if the user changes the value to 99991.00000000000001? > > > Thinking more about the union, I considered this text near the top of > Page 131 of draft-ietf-netmod-yang-05.txt: > > "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." > > > No matter how many more trailing digits the user adds to the end > of a number after the decimal point, the whole number part is going > to determine which member of the union is the best match because of > the range restriction. > > For the string "99991.0000000000000123456789", the first matching union > member will still be: > > type decimal64 { > fraction-digits 13; > range "-99999.9999999999999 .. 99999.9999999999999"; > } > > > Also, the more I think about it, the more I like the idea of adding the > enumeration to the end of the union. For a string containing any > positive number larger than 99999999999999999.9 or containing any > negative number larger than -99999999999999999.9, the first matching > union member would be the enumeration. > Think a bit more. IMO, this 'nan' sort of enum hides real errors. Do you really want to set the leaf to 'overflow' and return for the edit-config request, or just reject the request with an 'invalid-value' error? Unless 'overflow' is a normal, usable value for that leaf then is should not be saved in the configuration. > > Here, then, is the revised proposal: > > typedef real { > type union { > type decimal64 { > fraction-digits 18; > range "-0.999999999999999999 .. 0.999999999999999999"; > } > type decimal64 { > fraction-digits 17; > range "-9.99999999999999999 .. 9.99999999999999999"; > } > type decimal64 { > fraction-digits 16; > range "-99.9999999999999999 .. 99.9999999999999999"; > } > type decimal64 { > fraction-digits 15; > range "-999.999999999999999 .. 999.999999999999999"; > } > type decimal64 { > fraction-digits 14; > range "-9999.99999999999999 .. 9999.99999999999999"; > } > type decimal64 { > fraction-digits 13; > range "-99999.9999999999999 .. 99999.9999999999999"; > } > type decimal64 { > fraction-digits 12; > range "-999999.999999999999 .. 999999.999999999999"; > } > type decimal64 { > fraction-digits 11; > range "-9999999.99999999999 .. 9999999.99999999999"; > } > type decimal64 { > fraction-digits 10; > range "-99999999.9999999999 .. 99999999.9999999999"; > } > type decimal64 { > fraction-digits 9; > range "-999999999.999999999 .. 999999999.999999999"; > } > type decimal64 { > fraction-digits 8; > range "-9999999999.99999999 .. 9999999999.99999999"; > } > type decimal64 { > fraction-digits 7; > range "-99999999999.9999999 .. 99999999999.9999999"; > } > type decimal64 { > fraction-digits 6; > range "-999999999999.999999 .. 999999999999.999999"; > } > type decimal64 { > fraction-digits 5; > range "-9999999999999.99999 .. 9999999999999.99999"; > } > type decimal64 { > fraction-digits 4; > range "-99999999999999.9999 .. 99999999999999.9999"; > } > type decimal64 { > fraction-digits 3; > range "-999999999999999.999 .. 999999999999999.999"; > } > type decimal64 { > fraction-digits 2; > range "-9999999999999999.99 .. 9999999999999999.99"; > } > type decimal64 { > fraction-digits 1; > range "-99999999999999999.9 .. 99999999999999999.9"; > } > type enumeration { > enum overflow; > enum underflow; > description > "Positive numbers larger than 99999999999999999.9 > SHALL be represented as an overflow. > > Negative numbers larger than -99999999999999999.9 > SHALL be represented as an underflow."; > } > } > } > > > > Regards, > > David Spakes > > Andy From j.schoenwaelder@jacobs-university.de Thu May 14 20:53: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 D0A683A6BED for ; Thu, 14 May 2009 20:53:25 -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 Fy9VriCuse-h for ; Thu, 14 May 2009 20:53:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ABD513A69C8 for ; Thu, 14 May 2009 20:53:24 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0900DC00CB; Fri, 15 May 2009 05:54: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 A3Oyc3KA5CkM; Fri, 15 May 2009 05:54: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 CBB5DC00C0; Fri, 15 May 2009 05:54:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9E0B0AEF235; Fri, 15 May 2009 05:54:54 +0200 (CEST) Date: Fri, 15 May 2009 05:54:54 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20090515035454.GA1535@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , "netmod@ietf.org" References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> 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] float vs. decimal 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, 15 May 2009 03:53:25 -0000 On Fri, May 15, 2009 at 12:25:25AM +0200, David Spakes wrote: > There is too much baggage associated with "float", and I prefer "real" > over "hack", thank you very much. Sorry my rather pointed statement. But let me explain myself: If I understand the XSD decimal correctly, then the XSD decimal actually does what you want and only if you use the fractionDigit constraining facet (which is optional), the XSD decimal becomes a fixed point decimal. (Note that this also explains why the canonical format supresses trailing zeros.) What we have currently in YANG is a fixed point decimal (since fraction-digits is mandatory) plus a proposed union to turn a collection of fixed point decimal types back into what XSD considers a decimal. Compared to XSD, I do think this design is somewhat backwards and I prefer the XSD approach. My proposal: Make fraction-digits an optional type restriction in YANG and we align to XSD and do not need the union typedef anymore. /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 May 14 21:19: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 DE5163A69B3 for ; Thu, 14 May 2009 21:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.065, 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 lClI3Z-EWOGB for ; Thu, 14 May 2009 21:19:47 -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 43C2F3A6836 for ; Thu, 14 May 2009 21:19:47 -0700 (PDT) Received: (qmail 66243 invoked from network); 15 May 2009 04:21:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 15 May 2009 04:21:18 -0000 X-YMail-OSG: U0EwgYcVM1ng0cMu.VFPRqfttmjFBpeFNam12rh0y6g_1E5mLI.9D4ryjy2caiQVnjIG9tlXa2xTlWT_jGHnXftm3k0edmcZiH4ryEh2yx8HJzdjoFX5jxmB0a.Z51ufye03F2aSGpdI8J922Hf9ABoZYfHPq7ykgt4JI.COMpyVr5WJFS3.Qbb7o1KZZkCX9o_836zI8J4tk7n1.uzJ_D0lRKQl_nVM.7ZCGqZ3JX_rQNA912zCc0i_thzs5oIVD3p7IYpXzgZfCAKp6o4xMf83YYHCkESmMgJc.yBlauQ_XYNtk1g- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0CEDBC.4020003@netconfcentral.com> Date: Thu, 14 May 2009 21:21:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Spakes , "netmod@ietf.org" References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <20090515035454.GA1535@elstar.local> In-Reply-To: <20090515035454.GA1535@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 04:19:48 -0000 Juergen Schoenwaelder wrote: > On Fri, May 15, 2009 at 12:25:25AM +0200, David Spakes wrote: > >> There is too much baggage associated with "float", and I prefer "real" >> over "hack", thank you very much. > > Sorry my rather pointed statement. But let me explain myself: > > If I understand the XSD decimal correctly, then the XSD decimal > actually does what you want and only if you use the fractionDigit > constraining facet (which is optional), the XSD decimal becomes a > fixed point decimal. (Note that this also explains why the canonical > format supresses trailing zeros.) > > What we have currently in YANG is a fixed point decimal (since > fraction-digits is mandatory) plus a proposed union to turn a > collection of fixed point decimal types back into what XSD considers a > decimal. Compared to XSD, I do think this design is somewhat backwards > and I prefer the XSD approach. > > My proposal: Make fraction-digits an optional type restriction in YANG > and we align to XSD and do not need the union typedef anymore. > We already discussed the optional vs. mandatory fraction-digits field. If the data modeler does not want any fraction-digits, then int64 should be used instead of decimal64. > /js > Andy From j.schoenwaelder@jacobs-university.de Thu May 14 21:35: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 4CBAB28C138 for ; Thu, 14 May 2009 21:35:03 -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 u23XxYQz7Ryv for ; Thu, 14 May 2009 21:34:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 688E33A69DD for ; Thu, 14 May 2009 21:34:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99B57C00CB; Fri, 15 May 2009 06:36:32 +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 eO-cux3r2uNO; Fri, 15 May 2009 06:36:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2687C0008; Fri, 15 May 2009 06:36:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A210CAEF35A; Fri, 15 May 2009 06:36:29 +0200 (CEST) Date: Fri, 15 May 2009 06:36:29 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090515043629.GB1605@elstar.local> Mail-Followup-To: Andy Bierman , David Spakes , "netmod@ietf.org" References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0CEDBC.4020003@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 04:35:03 -0000 On Fri, May 15, 2009 at 06:21:16AM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, May 15, 2009 at 12:25:25AM +0200, David Spakes wrote: > > > >> There is too much baggage associated with "float", and I prefer "real" > >> over "hack", thank you very much. > > > > Sorry my rather pointed statement. But let me explain myself: > > > > If I understand the XSD decimal correctly, then the XSD decimal > > actually does what you want and only if you use the fractionDigit > > constraining facet (which is optional), the XSD decimal becomes a > > fixed point decimal. (Note that this also explains why the canonical > > format supresses trailing zeros.) > > > > What we have currently in YANG is a fixed point decimal (since > > fraction-digits is mandatory) plus a proposed union to turn a > > collection of fixed point decimal types back into what XSD considers a > > decimal. Compared to XSD, I do think this design is somewhat backwards > > and I prefer the XSD approach. > > > > My proposal: Make fraction-digits an optional type restriction in YANG > > and we align to XSD and do not need the union typedef anymore. > > We already discussed the optional vs. mandatory fraction-digits > field. If the data modeler does not want any fraction-digits, > then int64 should be used instead of decimal64. I can subscribe to the last sentence but it does not address what we are talking about here, namely David's proposal to have a "floating" decimal point. Please check how the XSD types work. An XSD decimal without fraction-digits is _not_ the same as an int; an XSD decimal without fraction-digits is what I believe David's union tries to achieve. The fraction-digits constraining facet in XSD fixes the number of decimals after the decimal point, without this constraining facet, you have a decimal without a fixed position of the decimal point and I think this is what David wanted to achieve. To me, the XSD design makes a lot of sense. /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 May 15 01:06: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 A68C43A6CEE for ; Fri, 15 May 2009 01:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=0.292, 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 Fg1XsisinWnd for ; Fri, 15 May 2009 01:06:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 94CC43A6E1D for ; Fri, 15 May 2009 01:06: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 8C2CBD800C0 for ; Fri, 15 May 2009 10:08:14 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200905141934.PAA10347@adminfs.snmp.com> References: <200905141934.PAA10347@adminfs.snmp.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 15 May 2009 10:08:13 +0200 Message-Id: <1242374893.6803.1.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] WGLC comments about anyxml 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, 15 May 2009 08:06:44 -0000 David Reid píše v Čt 14. 05. 2009 v 15:34 -0400: > A few questions and comments about anyxml: Yes, I pointed this out in my review, too. Anyxml has been forgotten in a few places. Lada > > section 3.1: can anyxml be mandatory? > > section 4.2.2 says "YANG defines four types of nodes for data modeling". Is > anyxml a 5th type of node for data modeling or is anyxml a different kind > of beast? > > section 6.2.1: anyxml is not included anywhere. I assume it should be listed > with leafs, leaf-lists, etc. > > sections 7.5.6 and 7.8.4: should anyxml be added as a possible child node? > > section 7.10 states that the "anyxml" statement defines an interior node in > the schema tree. A note about how it affects the data tree might also be > useful, much like some of the other parts of section 7. > > -David Reid > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri May 15 02:02: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 A26983A68FA for ; Fri, 15 May 2009 02:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 F2Ansf0Pg+Zz for ; Fri, 15 May 2009 02:02:40 -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 7B20E3A685F for ; Fri, 15 May 2009 02:02:40 -0700 (PDT) Received: from [209.191.108.97] by n25.bullet.mail.mud.yahoo.com with NNFMP; 15 May 2009 09:04:10 -0000 Received: from [68.142.201.243] by t4.bullet.mud.yahoo.com with NNFMP; 15 May 2009 09:04:10 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 15 May 2009 09:04:10 -0000 X-Yahoo-Newman-Id: 792105.81417.bm@omp404.mail.mud.yahoo.com Received: (qmail 20442 invoked from network); 15 May 2009 09:04:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 15 May 2009 09:04:09 -0000 X-YMail-OSG: nxCkNAsVM1k61aFkApKjh7KtNIpPltQU1ILMpIFd7i5HJrQFTrrtom5wnE6y3yesHmk8o7BdfYYqYjvJh9FkOwfCi_MH_pNMsxRYaf72LqN6GJpqx0.6ar.OP8J2s7LMpsI1MZPGA34hZmcwAh0SW2.x6a2QNQvYrTRIaNgzpCdZ57ql0NriHkmVN680XQy0X8rKEshaayZaqsRyM12gwJri4Fy6Bv.H5zRXy.sFUx5uOdHA.ciu55kIOJ.wbwUoEkJNlMm8uO06wI4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0D3007.2080606@netconfcentral.com> Date: Fri, 15 May 2009 02:04:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , David Spakes , "netmod@ietf.org" References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515043629.GB1605@elstar.local> In-Reply-To: <20090515043629.GB1605@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 09:02:44 -0000 Juergen Schoenwaelder wrote: > On Fri, May 15, 2009 at 06:21:16AM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, May 15, 2009 at 12:25:25AM +0200, David Spakes wrote: >>> >>>> There is too much baggage associated with "float", and I prefer "real" >>>> over "hack", thank you very much. >>> Sorry my rather pointed statement. But let me explain myself: >>> >>> If I understand the XSD decimal correctly, then the XSD decimal >>> actually does what you want and only if you use the fractionDigit >>> constraining facet (which is optional), the XSD decimal becomes a >>> fixed point decimal. (Note that this also explains why the canonical >>> format supresses trailing zeros.) >>> >>> What we have currently in YANG is a fixed point decimal (since >>> fraction-digits is mandatory) plus a proposed union to turn a >>> collection of fixed point decimal types back into what XSD considers a >>> decimal. Compared to XSD, I do think this design is somewhat backwards >>> and I prefer the XSD approach. >>> >>> My proposal: Make fraction-digits an optional type restriction in YANG >>> and we align to XSD and do not need the union typedef anymore. >> We already discussed the optional vs. mandatory fraction-digits >> field. If the data modeler does not want any fraction-digits, >> then int64 should be used instead of decimal64. > > I can subscribe to the last sentence but it does not address what we > are talking about here, namely David's proposal to have a "floating" > decimal point. > > Please check how the XSD types work. An XSD decimal without > fraction-digits is _not_ the same as an int; an XSD decimal without > fraction-digits is what I believe David's union tries to achieve. > > The fraction-digits constraining facet in XSD fixes the number of > decimals after the decimal point, without this constraining facet, you > have a decimal without a fixed position of the decimal point and I > think this is what David wanted to achieve. To me, the XSD design > makes a lot of sense. > XSD decimal is a string type -- an arbitrary length string representing a number with a decimal point. Why is a new data type needed? There are lots of data types in XSD that are not in YANG, so why is this one important? Why can't the data modeler just choose between int64 and decimal64? > /js > Andy From j.schoenwaelder@jacobs-university.de Fri May 15 03:37: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 28D713A69CC for ; Fri, 15 May 2009 03:37:51 -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 5oQa830YTfD5 for ; Fri, 15 May 2009 03:37:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D92D53A692D for ; Fri, 15 May 2009 03:37:49 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDF4DC028E; Fri, 15 May 2009 12:39: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 QlQ3rBWEikAt; Fri, 15 May 2009 12:39: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 629A5C00C6; Fri, 15 May 2009 12:39:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 598DFAEFC2F; Fri, 15 May 2009 12:39:20 +0200 (CEST) Date: Fri, 15 May 2009 12:39:20 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090515103920.GA2670@elstar.local> Mail-Followup-To: Andy Bierman , David Spakes , "netmod@ietf.org" References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515043629.GB1605@elstar.local> <4A0D3007.2080606@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0D3007.2080606@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 10:37:51 -0000 On Fri, May 15, 2009 at 11:04:07AM +0200, Andy Bierman wrote: > XSD decimal is a string type -- an arbitrary length string > representing a number with a decimal point. Lets get rid of all types! Wonderful argument. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From spakes@snmp.com Fri May 15 06:57: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 D31163A6AE6 for ; Fri, 15 May 2009 06:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 7ExRkjSguHdB for ; Fri, 15 May 2009 06:57:11 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 7FCC63A68AC for ; Fri, 15 May 2009 06:57:11 -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 JAA11651; Fri, 15 May 2009 09:58:43 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA20898; Fri, 15 May 2009 09:58:38 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 15 May 2009 09:58:38 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4A0CB4D1.1070101@netconfcentral.com> Message-ID: References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <4A0CB4D1.1070101@netconfcentral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 13:57:12 -0000 On Thu, 14 May 2009, Andy Bierman wrote: > > Also, the more I think about it, the more I like the idea of adding the > > enumeration to the end of the union. For a string containing any > > positive number larger than 99999999999999999.9 or containing any > > negative number larger than -99999999999999999.9, the first matching > > union member would be the enumeration. > > Think a bit more. > IMO, this 'nan' sort of enum hides real errors. > Do you really want to set the leaf to 'overflow' > and return for the edit-config request, > or just reject the request with an 'invalid-value' error? > > Unless 'overflow' is a normal, usable value for that leaf > then is should not be saved in the configuration. I didn't mean to suggest that it would be valid to use one of the enumeration values in an . The enumerations would only be used to represent an out-of-range state in the device; i.e., typedef real { type union { type decimal64 { fraction-digits 18; range "-0.999999999999999999 .. 0.999999999999999999"; } /* ... */ type decimal64 { fraction-digits 1; range "-99999999999999999.9 .. 99999999999999999.9"; } type enumeration { // not valid for configuration enum overflow; enum underflow; } } description "Positive numbers larger than 99999999999999999.9 in state data SHALL be represented as an overflow. Negative numbers larger than -99999999999999999.9 in state data SHALL be represented as an underflow."; } On Fri, 15 May 2009, Juergen Schoenwaelder wrote: > If I understand the XSD decimal correctly, then the XSD decimal > actually does what you want and only if you use the fractionDigit > constraining facet (which is optional), the XSD decimal becomes a > fixed point decimal. (Note that this also explains why the canonical > format supresses trailing zeros.) > > What we have currently in YANG is a fixed point decimal (since > fraction-digits is mandatory) plus a proposed union to turn a > collection of fixed point decimal types back into what XSD considers a > decimal. Compared to XSD, I do think this design is somewhat backwards > and I prefer the XSD approach. > > My proposal: Make fraction-digits an optional type restriction in YANG > and we align to XSD and do not need the union typedef anymore. I agree with Juergen that making the fraction-digits substatement optional for decimal64 would accomplish the same thing as the typedef union, and I would be in favor of that change. Regards, David Spakes ------------------------------------------------------------- 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 andy@netconfcentral.com Fri May 15 07:16: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 8502E3A6D28 for ; Fri, 15 May 2009 07:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.063, 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 CTYtE7ywg4w2 for ; Fri, 15 May 2009 07:16:52 -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 CC2FA3A70D9 for ; Fri, 15 May 2009 07:16:48 -0700 (PDT) Received: (qmail 83657 invoked from network); 15 May 2009 14:18:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 15 May 2009 14:18:20 -0000 X-YMail-OSG: wdSkMz0VM1lMWGWY0BfwHmz6G5maJ3V.oaifUnlyLY1X8ig1IScP3VUg.NuaTLXoQ5J.MQnIRy5PJZo4EM8uElCFtesYeLcdOdAx7shcNJnfKf7lSxqFZVuh2PbBGltzqw2S39cGGO.5JZh.tgMhAjY8j9qa.LJfThID9nCDdxYk0ID_udJOXlrTDnt.k2R6wDkR9lg9mAfkSVjUdLl_8b2t13ee2bNafgqGuNb3j28dlkTCUBBxOmg2u203jXgtB1JNf_HqkM6tq3..5ooiAGb_IVc2wz8lIqhhuQ_vX9rPEPUil9E- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0D79AA.1040403@netconfcentral.com> Date: Fri, 15 May 2009 07:18:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , David Spakes , "netmod@ietf.org" References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515043629.GB1605@elstar.local> <4A0D3007.2080606@netconfcentral.com> <20090515103920.GA2670@elstar.local> In-Reply-To: <20090515103920.GA2670@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 14:16:58 -0000 Juergen Schoenwaelder wrote: > On Fri, May 15, 2009 at 11:04:07AM +0200, Andy Bierman wrote: > >> XSD decimal is a string type -- an arbitrary length string >> representing a number with a decimal point. > > Lets get rid of all types! Wonderful argument. > Nobody is suggesting any lame strawman. I am asking why we need both int64 AND decimal64 with optional decimal point. Isn't a decimal64 with 0 decimal places the same as int64? Why is this overlap needed? > /js > Andy From mbj@tail-f.com Fri May 15 07:35: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 66E653A70E8 for ; Fri, 15 May 2009 07:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.086, 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 tIhGUUyeSS38 for ; Fri, 15 May 2009 07:35:36 -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 47FEC28C3E5 for ; Fri, 15 May 2009 07:35:07 -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 AF22D616018; Fri, 15 May 2009 16:36:39 +0200 (CEST) Date: Fri, 15 May 2009 16:36:39 +0200 (CEST) Message-Id: <20090515.163639.76136550.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A0CEDBC.4020003@netconfcentral.com> References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@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] float vs. decimal 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, 15 May 2009 14:35:37 -0000 Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, May 15, 2009 at 12:25:25AM +0200, David Spakes wrote: > > > >> There is too much baggage associated with "float", and I prefer "real" > >> over "hack", thank you very much. > > Sorry my rather pointed statement. But let me explain myself: > > If I understand the XSD decimal correctly, then the XSD decimal > > actually does what you want and only if you use the fractionDigit > > constraining facet (which is optional), the XSD decimal becomes a > > fixed point decimal. (Note that this also explains why the canonical > > format supresses trailing zeros.) > > What we have currently in YANG is a fixed point decimal (since > > fraction-digits is mandatory) plus a proposed union to turn a > > collection of fixed point decimal types back into what XSD considers a > > decimal. Compared to XSD, I do think this design is somewhat backwards > > and I prefer the XSD approach. > > My proposal: Make fraction-digits an optional type restriction in YANG > > and we align to XSD and do not need the union typedef anymore. > > > > We already discussed the optional vs. mandatory fraction-digits > field. I agree with Andy. Making fraction-digits optional seems to me as a nice-to-have (at best). I don't think this is important enough to make this change now. /martin From andy@netconfcentral.com Fri May 15 07:45: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 4DFE03A7048 for ; Fri, 15 May 2009 07:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.063, 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 yEMwZ7qtZXaA for ; Fri, 15 May 2009 07:45:31 -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 915513A6BDD for ; Fri, 15 May 2009 07:45:31 -0700 (PDT) Received: (qmail 29096 invoked from network); 15 May 2009 14:47:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 15 May 2009 14:47:02 -0000 X-YMail-OSG: nLr.FLUVM1n1gpNrZj6TDCZmC1TFPY1OqM2mAoi7BNztXoEcMNOCWqjqQhY_uHkewuoA9_4nGcm1ayDCCgY4K905fNH4Ni4d80YLi089kH_8BMQVBHeSGWiOViMUHCDUhdolC8QTsqRzUpjfCc5wQGqALjH5QT5U09OiZwRfQDem9BUpHS.ZQOooYKH0wssMiA0mAsHIFctCpYdemMf6QeFSAGkr_mWdnVN6j0t3Ntch_Ag60f9vzUMylstao59ViYFMLzIlEjLdd.vRB4rgNwcWW46ZZ04T3uYEk0jxC.4e69DovXkfVzsgavAhBIRktOlGeRp2C_F1 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0D8064.3030503@netconfcentral.com> Date: Fri, 15 May 2009 07:47:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> In-Reply-To: <20090515.163639.76136550.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] float vs. decimal 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, 15 May 2009 14:45:32 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, May 15, 2009 at 12:25:25AM +0200, David Spakes wrote: >>> >>>> There is too much baggage associated with "float", and I prefer "real" >>>> over "hack", thank you very much. >>> Sorry my rather pointed statement. But let me explain myself: >>> If I understand the XSD decimal correctly, then the XSD decimal >>> actually does what you want and only if you use the fractionDigit >>> constraining facet (which is optional), the XSD decimal becomes a >>> fixed point decimal. (Note that this also explains why the canonical >>> format supresses trailing zeros.) >>> What we have currently in YANG is a fixed point decimal (since >>> fraction-digits is mandatory) plus a proposed union to turn a >>> collection of fixed point decimal types back into what XSD considers a >>> decimal. Compared to XSD, I do think this design is somewhat backwards >>> and I prefer the XSD approach. >>> My proposal: Make fraction-digits an optional type restriction in YANG >>> and we align to XSD and do not need the union typedef anymore. >>> >> We already discussed the optional vs. mandatory fraction-digits >> field. > > I agree with Andy. Making fraction-digits optional seems to me as a > nice-to-have (at best). I don't think this is important enough to > make this change now. > I prefer to keep the built-in types as simple as possible and let users create more sophisticated data types with the typedef-stmt. IMO, overlap in the built-in types leads to confusion. > > /martin > > Andy From spakes@snmp.com Fri May 15 07:48: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 A0D983A6889 for ; Fri, 15 May 2009 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 8gnnqnp90B1p for ; Fri, 15 May 2009 07:48:30 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 39E653A6EFD for ; Fri, 15 May 2009 07:48:26 -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 KAA16703; Fri, 15 May 2009 10:49:58 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA21424; Fri, 15 May 2009 10:49:57 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 15 May 2009 10:49:57 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: Message-ID: References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <4A0CB4D1.1070101@netconfcentral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 14:48:31 -0000 On Fri, 15 May 2009, Andy Bierman wrote: > I am asking why we need both int64 AND decimal64 with optional > decimal point. Isn't a decimal64 with 0 decimal places the > same as int64? Why is this overlap needed? How do you represent "52.3" or "99991.000001" with floating precision as an int64 and tell where the decimal point goes? On Fri, 15 May 2009, David Spakes wrote: > I agree with Juergen that making the fraction-digits substatement > optional for decimal64 would accomplish the same thing as the typedef > union, and I would be in favor of that change. I have one additional thought about Juergen's proposal. A secondary goal of the typedef was to apply a range on each decimal64 in the union so the possible values begin and end on a base-10 boundary. The range for each value of fraction-digits in the union is different but all share one common property: the number of digits is always the same (if you exclude the leading zero for fraction-digits 18). The same goal could be accomplished with Juergen's proposal if we added that decimal64 type could be restricted with the "length" statement. Section 9.3.3 would need to be changed with new text like this: 9.3.3. Restrictions A decmial64 type can be restricted with the "range" statement (Section 9.2.4). A decmial64 type can be restricted with the "length" statement (Section 9.4.4) to limit the number of valid digits. If specified, the length limitation applies neither to the sign nor to the leading zero for values between -1 and 1 (not inclusive). Regards, David Spakes On Thu, 14 May 2009, David Spakes wrote: > The above definition for a "float" seems cumbersome, but I believe most > application writers will find that the semantic is familiar and > comfortable. To demonstrate what I mean, here is a simple illustration. > > The behavior of this construct is very much like that of any common > calculator (either a non-scientific calculator or a scientific > calculator in non-scientific mode). Mine has a 10-digit LCD display. > > If I press the key for pi, the screen shows 3.141592654. This is > not all of the digits for pi, but the calculator can only hold > ten digits. The magnitude requires one digit, leaving nine digits > for precision. > > If I press 'x' '10' '=', now the screen shows 31.41592654. The > magnitude now requires two digits, and so we lost one digit of > precision. The same digits are on the screen...the decimal point > just floated to its new position. > > One can imagine a leaf that is type "float" as working like a > calculator having an 18-digit display. > > > The purpose for the range substatements is also for comfort level. An > opinion expressed in conversation both by me and one of my coworkers > was that decimal64 feels "weird" because the range of values does not > end on a base-10 boundary. The range provides upper and lower bounds > on a base-10 boundary by sacrificing one digit of magnitude. > For example: > > The largest positive value that can > be represented by a leaf that is a > 922337203685477580.7 <--- decimal64 with fraction-digits 1. > > 99999999999999999.9 <--- The largest positive value that can > be represented by the float construct > described by this proposal. > > > If this proposal is acceptable to the working group, I would offer to > formalize the text of the description unless the document editor would > prefer to do that. > > Regards, > > David Spakes ------------------------------------------------------------- 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 andy@netconfcentral.com Fri May 15 07: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 DB2D33A6784 for ; Fri, 15 May 2009 07:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 Tn2RmD+6izJD for ; Fri, 15 May 2009 07:56:14 -0700 (PDT) Received: from n23.bullet.mail.mud.yahoo.com (n23.bullet.mail.mud.yahoo.com [68.142.206.162]) by core3.amsl.com (Postfix) with SMTP id 7AEDE3A6992 for ; Fri, 15 May 2009 07:55:42 -0700 (PDT) Received: from [68.142.200.225] by n23.bullet.mail.mud.yahoo.com with NNFMP; 15 May 2009 14:57:14 -0000 Received: from [68.142.201.242] by t6.bullet.mud.yahoo.com with NNFMP; 15 May 2009 14:57:14 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 15 May 2009 14:57:14 -0000 X-Yahoo-Newman-Id: 548707.63199.bm@omp403.mail.mud.yahoo.com Received: (qmail 19184 invoked from network); 15 May 2009 14:57:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 15 May 2009 14:57:13 -0000 X-YMail-OSG: .CqqJeYVM1k9oclX8hWmSJcNq2Wtxa8LQLpahbgOkeag76iE5xA23RzR9SCAB9eKrwAXlqI4yErxKlSyChw0yPn49D1XvfyhAu8kYizGNi5MEza88BHZXGvLyRtcEYtX94TTMIlVjb3MVPMF5mRebobYCNINfKkioyJ4xwmmzvhBKVG7SSgw6azUg4RZcPP2lzZEkMNhT5dvcAnRQxD6VYuYBZ9D7hAkQc6fDZVopzM60Fe_q6wqrRbRgtYwCu8DaLzbSGrjRB6sCskWyy1uQkStrJTCsCSGyNiKMAZW35tFp_PUgUrCjkkDsAEvQZYZgmfluEiLab9YreW6P5lYZEmLvocvKGCyHg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0D82C6.2020208@netconfcentral.com> Date: Fri, 15 May 2009 07:57:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Spakes References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <4A0CB4D1.1070101@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 14:56:15 -0000 David Spakes wrote: > On Fri, 15 May 2009, Andy Bierman wrote: > >> I am asking why we need both int64 AND decimal64 with optional >> decimal point. Isn't a decimal64 with 0 decimal places the >> same as int64? Why is this overlap needed? > > > How do you represent "52.3" or "99991.000001" with floating precision > as an int64 and tell where the decimal point goes? > IEEE 754 (float64) Why do we need floating precision in NETCONF? If we really need it, then let's add float64 back to the built-in types. I do not think it is needed. Andy > > > On Fri, 15 May 2009, David Spakes wrote: > >> I agree with Juergen that making the fraction-digits substatement >> optional for decimal64 would accomplish the same thing as the typedef >> union, and I would be in favor of that change. > > > I have one additional thought about Juergen's proposal. > > A secondary goal of the typedef was to apply a range on each decimal64 in > the union so the possible values begin and end on a base-10 boundary. > The range for each value of fraction-digits in the union is different but > all share one common property: the number of digits is always the same (if > you exclude the leading zero for fraction-digits 18). The same goal could > be accomplished with Juergen's proposal if we added that decimal64 type > could be restricted with the "length" statement. Section 9.3.3 would need > to be changed with new text like this: > > > 9.3.3. Restrictions > > A decmial64 type can be restricted with the "range" statement > (Section 9.2.4). > > A decmial64 type can be restricted with the "length" statement > (Section 9.4.4) to limit the number of valid digits. If specified, > the length limitation applies neither to the sign nor to the > leading zero for values between -1 and 1 (not inclusive). > > > > Regards, > > David Spakes > > > > On Thu, 14 May 2009, David Spakes wrote: > >> The above definition for a "float" seems cumbersome, but I believe most >> application writers will find that the semantic is familiar and >> comfortable. To demonstrate what I mean, here is a simple illustration. >> >> The behavior of this construct is very much like that of any common >> calculator (either a non-scientific calculator or a scientific >> calculator in non-scientific mode). Mine has a 10-digit LCD display. >> >> If I press the key for pi, the screen shows 3.141592654. This is >> not all of the digits for pi, but the calculator can only hold >> ten digits. The magnitude requires one digit, leaving nine digits >> for precision. >> >> If I press 'x' '10' '=', now the screen shows 31.41592654. The >> magnitude now requires two digits, and so we lost one digit of >> precision. The same digits are on the screen...the decimal point >> just floated to its new position. >> >> One can imagine a leaf that is type "float" as working like a >> calculator having an 18-digit display. >> >> >> The purpose for the range substatements is also for comfort level. An >> opinion expressed in conversation both by me and one of my coworkers >> was that decimal64 feels "weird" because the range of values does not >> end on a base-10 boundary. The range provides upper and lower bounds >> on a base-10 boundary by sacrificing one digit of magnitude. >> For example: >> >> The largest positive value that can >> be represented by a leaf that is a >> 922337203685477580.7 <--- decimal64 with fraction-digits 1. >> >> 99999999999999999.9 <--- The largest positive value that can >> be represented by the float construct >> described by this proposal. >> >> >> If this proposal is acceptable to the working group, I would offer to >> formalize the text of the description unless the document editor would >> prefer to do that. >> >> Regards, >> >> David Spakes > > > > ------------------------------------------------------------- > 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 Fri May 15 08:36:33 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 AC3D53A6D19 for ; Fri, 15 May 2009 08:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 ovMjI6eNAgMO for ; Fri, 15 May 2009 08:36:33 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id D216228C221 for ; Fri, 15 May 2009 08:36:06 -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 LAA20751; Fri, 15 May 2009 11:37:39 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA22150; Fri, 15 May 2009 11:37:38 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 15 May 2009 11:37:38 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4A0D82C6.2020208@netconfcentral.com> Message-ID: References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <4A0CB4D1.1070101@netconfcentral.com> <4A0D82C6.2020208@netconfcentral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 15:36:33 -0000 On Fri, 15 May 2009, Andy Bierman wrote: > David Spakes wrote: > > How do you represent "52.3" or "99991.000001" with floating precision > > as an int64 and tell where the decimal point goes? > > > > IEEE 754 (float64) > > Why do we need floating precision in NETCONF? > > If we really need it, then let's add float64 back to > the built-in types. I do not think it is needed. > Andy I am of the opinion that some users will need to represent ratios, but in the real world few if any applications will ever need the full power of IEEE 754 floats. A decimal64 with fraction-digits 1 can represent numbers as large as 99,999,999,999,999,999.9 (ninty-nine quadrillion). That's astronomically large. What real world application would need a number larger than this? A decimal64 with fraction-digits 18 can represent numbers as small as 0.000000000000000001 (10^-18). That's infinitesimally small. What real world application would need something more precise than this? If this group were to decide to reintroduce float64, I'd go along with that decision, but personally I think it's overkill. Regards, David Spakes > >> > >> 99999999999999999.9 <--- The largest positive value that can > >> be represented by the float construct > >> described by this proposal. ------------------------------------------------------------- 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 andy@netconfcentral.com Fri May 15 09:04: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 94FB43A6E04 for ; Fri, 15 May 2009 09:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 UrUsaUMG1DO7 for ; Fri, 15 May 2009 09:04:29 -0700 (PDT) Received: from n5a.bullet.mud.yahoo.com (n5a.bullet.mud.yahoo.com [209.191.126.232]) by core3.amsl.com (Postfix) with SMTP id B2B683A70E9 for ; Fri, 15 May 2009 09:04:29 -0700 (PDT) Received: from [68.142.200.227] by n5.bullet.mud.yahoo.com with NNFMP; 15 May 2009 16:06:01 -0000 Received: from [68.142.201.240] by t8.bullet.mud.yahoo.com with NNFMP; 15 May 2009 16:06:01 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 15 May 2009 16:06:01 -0000 X-Yahoo-Newman-Id: 826133.570.bm@omp401.mail.mud.yahoo.com Received: (qmail 99070 invoked from network); 15 May 2009 16:06:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 15 May 2009 16:06:00 -0000 X-YMail-OSG: Drc6Q8kVM1nw.sBNYV0NvP3CR8940qrVtmip7aVXPjNvNlN9xDyWFkpgQ8VwU_n3LsrnX9epOty5JpljyRpAvfO5iRi6qIwrnkaxJWJTCVRA7fEHHarrXLTqovFbcCKxEbKWdY2kmGwryUB1XJyKYIOShepJ0_L3kbPnxvtUykHIboHrKguKpE4fjYEzSHjEMcGcneLMzgDXzJypiraEKG8N4g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0D92E6.5020006@netconfcentral.com> Date: Fri, 15 May 2009 09:05:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Spakes References: <4A0C5463.7060605@netconfcentral.com> <4A0C5F6F.1080702@netconfcentral.com> <20090514204246.GA1276@elstar.local> <4A0CB4D1.1070101@netconfcentral.com> <4A0D82C6.2020208@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 15 May 2009 16:04:30 -0000 David Spakes wrote: > On Fri, 15 May 2009, Andy Bierman wrote: > >> David Spakes wrote: >>> How do you represent "52.3" or "99991.000001" with floating precision >>> as an int64 and tell where the decimal point goes? >>> >> IEEE 754 (float64) >> >> Why do we need floating precision in NETCONF? >> >> If we really need it, then let's add float64 back to >> the built-in types. I do not think it is needed. >> Andy > > > > I am of the opinion that some users will need to represent ratios, > but in the real world few if any applications will ever need the full > power of IEEE 754 floats. > > A decimal64 with fraction-digits 1 can represent numbers as large as > 99,999,999,999,999,999.9 (ninty-nine quadrillion). That's astronomically > large. What real world application would need a number larger than this? > > A decimal64 with fraction-digits 18 can represent numbers as small as > 0.000000000000000001 (10^-18). That's infinitesimally small. What real > world application would need something more precise than this? > A data modeler will choose the fraction-digits value that is best-suited for their intended use. Choosing 1 or 18 depends on the semantics. The most common value seems to be 2. > If this group were to decide to reintroduce float64, I'd go along with > that decision, but personally I think it's overkill. > I was not suggesting that. I was pointing out that the WG already had float64 and replaced it with decimal64. I still do not see (except for your calculator MIB) why a NETCONF agent needs floating precision numbers. I think the survey Phil did showed that fixed-point numbers are needed in NM, not floating-point. > Regards, > > David Spakes > Andy From j.schoenwaelder@jacobs-university.de Sat May 16 04:46: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 06B8D3A6A97 for ; Sat, 16 May 2009 04:46:19 -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.152, 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 pyagaRXbfPRl for ; Sat, 16 May 2009 04:46:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CB6BC3A6C07 for ; Sat, 16 May 2009 04:46:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5CF3C0292; Sat, 16 May 2009 13:47:51 +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 T6-i7sNBxmig; Sat, 16 May 2009 13:47: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 9400CC02F8; Sat, 16 May 2009 13:47:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A89B3B180D0; Sat, 16 May 2009 13:47:49 +0200 (CEST) Date: Sat, 16 May 2009 13:47:49 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090516114749.GD2388@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> <4A0D8064.3030503@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0D8064.3030503@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 16 May 2009 11:46:19 -0000 On Fri, May 15, 2009 at 04:47:00PM +0200, Andy Bierman wrote: > I prefer to keep the built-in types as simple as possible > and let users create more sophisticated data types with > the typedef-stmt. The problem is that we do not agree what "simple" means. To me, the proposed "real" union was an indication that we might have got the built-in types not simple enough. A decimal64 represented internally by an int64_t value plus the information about the number of fraction decimals seems to be what Dave wanted to achieve with his union. A decimal64 with the fraction-digits statement essentially fixes the fraction part at data model design time - so you can optimize your internal storage to just the int64_t value. For me, all this seems clean and pretty simple. /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 May 16 06:36: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 653DF3A6A24 for ; Sat, 16 May 2009 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=-0.966, 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 KC7z3Nm39PC7 for ; Sat, 16 May 2009 06:36:44 -0700 (PDT) Received: from n8.bullet.mail.mud.yahoo.com (n8.bullet.mail.mud.yahoo.com [209.191.86.156]) by core3.amsl.com (Postfix) with SMTP id 2DED73A6DC8 for ; Sat, 16 May 2009 06:36:34 -0700 (PDT) Received: from [209.191.108.96] by n8.bullet.mail.mud.yahoo.com with NNFMP; 16 May 2009 13:38:07 -0000 Received: from [68.142.201.242] by t3.bullet.mud.yahoo.com with NNFMP; 16 May 2009 13:38:07 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 16 May 2009 13:38:07 -0000 X-Yahoo-Newman-Id: 723003.84017.bm@omp403.mail.mud.yahoo.com Received: (qmail 41943 invoked from network); 16 May 2009 13:38:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 16 May 2009 13:38:06 -0000 X-YMail-OSG: 1VNu5RwVM1m_Bl3ekYKOMv5VCbCY4_fAUclE0pK8Z0TH6HjF300cuR6xIepNYVeBv7B9jTVcpXVlxPtyKuNxrWJ.EXZ6nYOsjHmV4cYGq7k_1BbO1cbyQUSG2KbjACeWnvUwAXdXW6EhNlw7wpPyUJVGoSrlIuD3Qj5rGH70iv1R7aErDGQMT_Tsn8kl7Q8xJfSo9DA7aLDuPgZcML3GA1Ft8l_r9nb3gv_192Ntr7bOwZdGiDk59d_AO21sPgwkb44TVbjsf94kmSk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0EC1BC.6010301@netconfcentral.com> Date: Sat, 16 May 2009 06:38:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> <4A0D8064.3030503@netconfcentral.com> <20090516114749.GD2388@elstar.local> In-Reply-To: <20090516114749.GD2388@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal 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, 16 May 2009 13:36:45 -0000 Juergen Schoenwaelder wrote: > On Fri, May 15, 2009 at 04:47:00PM +0200, Andy Bierman wrote: > >> I prefer to keep the built-in types as simple as possible >> and let users create more sophisticated data types with >> the typedef-stmt. > > The problem is that we do not agree what "simple" means. To me, the > proposed "real" union was an indication that we might have got the > built-in types not simple enough. > > A decimal64 represented internally by an int64_t value plus the > information about the number of fraction decimals seems to be what > Dave wanted to achieve with his union. A decimal64 with the > fraction-digits statement essentially fixes the fraction part at data > model design time - so you can optimize your internal storage to just > the int64_t value. For me, all this seems clean and pretty simple. > Here's the litmus test: - If you can build the desired data type out of existing built-in types, then there is no need for a new built-in type. Just use typedef instead. > /js > Andy From andy@netconfcentral.com Sat May 16 06:48: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 62C6328C0F8 for ; Sat, 16 May 2009 06:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.081, 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 imLvqKcl-nxO for ; Sat, 16 May 2009 06:48:27 -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 AA38028C0F6 for ; Sat, 16 May 2009 06:48:27 -0700 (PDT) Received: (qmail 49020 invoked from network); 16 May 2009 13:50:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 16 May 2009 13:49:59 -0000 X-YMail-OSG: AueqW6kVM1mBNyaBCcXZ.veRPENUTw0U7IZwB5KecpteUkC8HANs2Qw45KZUF5jjDvP6sDl5.v0mabAZVK.ouCMQJipNYh8nsWVxDZfg1SFxH_gjw7IZIm2xTkf1GdLVZwOhXltdO6NysYJ4Ym1UFHl_tDFGlADaclJZl9I5tXmQ2obzSazFfjlZl2IrrSIWvvc2AU2wheR7YE0nYC1AK9Cpvrx2ItZ5jo9cgPoiFjJE0oq2wUNHbPZ8qIgI0F8F722ZIGtzbzHLLXc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0EC485.2010207@netconfcentral.com> Date: Sat, 16 May 2009 06:49:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> <4A0D8064.3030503@netconfcentral.com> <20090516114749.GD2388@elstar.local> In-Reply-To: <20090516114749.GD2388@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal 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, 16 May 2009 13:48:28 -0000 Juergen Schoenwaelder wrote: > On Fri, May 15, 2009 at 04:47:00PM +0200, Andy Bierman wrote: > >> I prefer to keep the built-in types as simple as possible >> and let users create more sophisticated data types with >> the typedef-stmt. > > The problem is that we do not agree what "simple" means. To me, the > proposed "real" union was an indication that we might have got the > built-in types not simple enough. > > A decimal64 represented internally by an int64_t value plus the > information about the number of fraction decimals seems to be what > Dave wanted to achieve with his union. A decimal64 with the > fraction-digits statement essentially fixes the fraction part at data > model design time - so you can optimize your internal storage to just > the int64_t value. For me, all this seems clean and pretty simple. > It seems like reinventing the IEEE 754 standard to me. If I want a 64-bit number that represents a floating-point number, then I am going to use this existing standard. There is plenty of existing free code to support it, and no need to reinvent it. Storing floating-point in an int64 is not a valid problem statement. Storing FP in 64 bits of space *is* a valid problem statement. If there is a need for this data type, then a standard already exists. > /js > Andy From j.schoenwaelder@jacobs-university.de Sat May 16 07: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 5DF763A6EC1 for ; Sat, 16 May 2009 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, 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 KV8yTShf2AXk for ; Sat, 16 May 2009 07:18:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 59D793A67A6 for ; Sat, 16 May 2009 07:18:34 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91544C032A; Sat, 16 May 2009 16:20: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 hOrQfsE4EbSz; Sat, 16 May 2009 16:20: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 4BC30C02FE; Sat, 16 May 2009 16:20:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5904DB1838E; Sat, 16 May 2009 16:20:06 +0200 (CEST) Date: Sat, 16 May 2009 16:20:06 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090516142006.GB2645@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> <4A0D8064.3030503@netconfcentral.com> <20090516114749.GD2388@elstar.local> <4A0EC1BC.6010301@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0EC1BC.6010301@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 16 May 2009 14:18:35 -0000 On Sat, May 16, 2009 at 03:38:04PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, May 15, 2009 at 04:47:00PM +0200, Andy Bierman wrote: > > > >> I prefer to keep the built-in types as simple as possible > >> and let users create more sophisticated data types with > >> the typedef-stmt. > > > > The problem is that we do not agree what "simple" means. To me, the > > proposed "real" union was an indication that we might have got the > > built-in types not simple enough. > > > > A decimal64 represented internally by an int64_t value plus the > > information about the number of fraction decimals seems to be what > > Dave wanted to achieve with his union. A decimal64 with the > > fraction-digits statement essentially fixes the fraction part at data > > model design time - so you can optimize your internal storage to just > > the int64_t value. For me, all this seems clean and pretty simple. > > > > Here's the litmus test: > > - If you can build the desired data type out of > existing built-in types, then there is no need > for a new built-in type. Just use typedef instead. So you propose to remove several of the existing builtin types? /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 Sat May 16 07:26: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 6E42A3A6D3F for ; Sat, 16 May 2009 07:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 mKbDE3tj4rOR for ; Sat, 16 May 2009 07:26:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7B17C3A67A6 for ; Sat, 16 May 2009 07:26:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3BA5C032A; Sat, 16 May 2009 16:28:01 +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 mEXCWQcV5KC2; Sat, 16 May 2009 16:28:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0ECC9C02FE; Sat, 16 May 2009 16:28:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2A1AFB183D3; Sat, 16 May 2009 16:28:00 +0200 (CEST) Date: Sat, 16 May 2009 16:28:00 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090516142800.GC2645@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> <4A0D8064.3030503@netconfcentral.com> <20090516114749.GD2388@elstar.local> <4A0EC485.2010207@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0EC485.2010207@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 16 May 2009 14:26:28 -0000 On Sat, May 16, 2009 at 03:49:57PM +0200, Andy Bierman wrote: > It seems like reinventing the IEEE 754 standard to me. > If I want a 64-bit number that represents a floating-point > number, then I am going to use this existing standard. > There is plenty of existing free code to support it, > and no need to reinvent it. A decimal is not an IEEE 754 float. If people want to bring back floats, then they should indeed use IEEE 754 floats. Having a decimal type which requires a fraction-digits statement that people then put into a big union in order to achieve a decimal without a fraction-digits statement just smells so badly. > Storing floating-point in an int64 is not a valid problem statement. > Storing FP in 64 bits of space *is* a valid problem statement. For me, none of these two are a problem statements. /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 May 16 08:32: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 5F5EE3A6864 for ; Sat, 16 May 2009 08:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, 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 YKd6Wweu45xo for ; Sat, 16 May 2009 08:32:05 -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 AE2383A67A7 for ; Sat, 16 May 2009 08:32:05 -0700 (PDT) Received: (qmail 5430 invoked from network); 16 May 2009 15:33:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 16 May 2009 15:33:37 -0000 X-YMail-OSG: bzqYmPIVM1m4trsfX1Xv0Q205G1Ddc2RhoCS7JCMoUqn2Z4v45xr7frXWPvAS.zhhf4kjeMTC1zvFtTqyLP9deB.fh2DrTaQbkblU3TLS.K23mry2LKfSjtaBBoWlh4u6aXKafWbEpTzeaWyeTnMiwRwDc2uUqn4esFIOzezEFv.Uhm18RJ_bTenismI6jom7v6uYJv1rYfz.vaTESswcJqvS9dWC7A.BwFQLFLohbPmvcQXZlRUgaRZwFdSGwL7uVnHVCEhBO.GWDWGHjAmVwHh5AaFsu8JodwSQ2irG6zqxD4CRao- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0EDCD0.9020806@netconfcentral.com> Date: Sat, 16 May 2009 08:33:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> <4A0D8064.3030503@netconfcentral.com> <20090516114749.GD2388@elstar.local> <4A0EC1BC.6010301@netconfcentral.com> <20090516142006.GB2645@elstar.local> In-Reply-To: <20090516142006.GB2645@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal 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, 16 May 2009 15:32:06 -0000 Juergen Schoenwaelder wrote: > On Sat, May 16, 2009 at 03:38:04PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, May 15, 2009 at 04:47:00PM +0200, Andy Bierman wrote: >>> >>>> I prefer to keep the built-in types as simple as possible >>>> and let users create more sophisticated data types with >>>> the typedef-stmt. >>> The problem is that we do not agree what "simple" means. To me, the >>> proposed "real" union was an indication that we might have got the >>> built-in types not simple enough. >>> >>> A decimal64 represented internally by an int64_t value plus the >>> information about the number of fraction decimals seems to be what >>> Dave wanted to achieve with his union. A decimal64 with the >>> fraction-digits statement essentially fixes the fraction part at data >>> model design time - so you can optimize your internal storage to just >>> the int64_t value. For me, all this seems clean and pretty simple. >>> >> Here's the litmus test: >> >> - If you can build the desired data type out of >> existing built-in types, then there is no need >> for a new built-in type. Just use typedef instead. > > So you propose to remove several of the existing builtin types? > My preference would be to remove the 8 and 16 bit numeric types and put them in the yang types draft, but it is not a big deal. The extra types can save memory, if the developer cares about that. > /js > Andy From andy@netconfcentral.com Sat May 16 08:36: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 3B9353A68B6 for ; Sat, 16 May 2009 08:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 0DsBOzvpnUPl for ; Sat, 16 May 2009 08:36:44 -0700 (PDT) Received: from n11a.bullet.mail.mud.yahoo.com (n11a.bullet.mail.mud.yahoo.com [209.191.125.176]) by core3.amsl.com (Postfix) with SMTP id CBFDC28C103 for ; Sat, 16 May 2009 08:36:44 -0700 (PDT) Received: from [68.142.200.221] by n11.bullet.mail.mud.yahoo.com with NNFMP; 16 May 2009 15:38:17 -0000 Received: from [68.142.201.243] by t9.bullet.mud.yahoo.com with NNFMP; 16 May 2009 15:38:17 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 16 May 2009 15:38:17 -0000 X-Yahoo-Newman-Id: 96381.21703.bm@omp404.mail.mud.yahoo.com Received: (qmail 62498 invoked from network); 16 May 2009 15:38:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 16 May 2009 15:38:16 -0000 X-YMail-OSG: b1JqnuIVM1k.pjT9WIOe14..K2qmDC6JppIMOMpWQrCDNa65DTGBFN2gL1VJkf2a7L83QfKPlD9niFVg6IK4xjPAr4Bm0QE9Vk7oXKpVsxTYiG5YxzEVj5aqbLlllIY3Qt.pMg6mgyIM775_n.52roBSsmnt6oZLLFi2VV7uIucYxts3n6zwNHpMVLRLoaagtA.8EseCCnJnShLCQaoRPmfi3T4IFQgCcRNllLrrH6XfIIFRC2NDsmlAC1R1QuAaJPsZIVoaOFc9mdR8JiZPxW9IVWMZ4hAWSc1ixa3.fvuABiGAtwo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0EDDE6.5080009@netconfcentral.com> Date: Sat, 16 May 2009 08:38:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> <4A0D8064.3030503@netconfcentral.com> <20090516114749.GD2388@elstar.local> <4A0EC485.2010207@netconfcentral.com> <20090516142800.GC2645@elstar.local> In-Reply-To: <20090516142800.GC2645@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal 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, 16 May 2009 15:36:49 -0000 Juergen Schoenwaelder wrote: > On Sat, May 16, 2009 at 03:49:57PM +0200, Andy Bierman wrote: > >> It seems like reinventing the IEEE 754 standard to me. >> If I want a 64-bit number that represents a floating-point >> number, then I am going to use this existing standard. >> There is plenty of existing free code to support it, >> and no need to reinvent it. > > A decimal is not an IEEE 754 float. If people want to bring back > floats, then they should indeed use IEEE 754 floats. Having a decimal > type which requires a fraction-digits statement that people then put > into a big union in order to achieve a decimal without a > fraction-digits statement just smells so badly. > >> Storing floating-point in an int64 is not a valid problem statement. >> Storing FP in 64 bits of space *is* a valid problem statement. > > For me, none of these two are a problem statements. > Please provide the problem statement then. It is really unclear why the standard needs to bother with this at all. Put the union typedef in your YANG module if you want that derived data type. > /js > Andy From reid@snmp.com Sat May 16 13: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 9C39A3A6BA2 for ; Sat, 16 May 2009 13:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, 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 LqPdljN1ZmyZ for ; Sat, 16 May 2009 13:14:32 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id B67833A68D2 for ; Sat, 16 May 2009 13:14:31 -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 QAA14130 for ; Sat, 16 May 2009 16:16:03 -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 QAA12179 for ; Sat, 16 May 2009 16:16:03 -0400 (EDT) Message-Id: <200905162016.QAA12179@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Sat, 16 May 2009 08:33:36 -0700. <4A0EDCD0.9020806@netconfcentral.com> Date: Sat, 16 May 2009 16:16:02 -0400 Sender: reid@snmp.com Subject: Re: [netmod] float vs. decimal 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: Sat, 16 May 2009 20:14:32 -0000 > > So you propose to remove several of the existing builtin types? > > > > My preference would be to remove the 8 and 16 bit numeric types > and put them in the yang types draft, but it is not a big deal. > The extra types can save memory, if the developer cares about that. I agree with Andy about moving the 8 and 16 bit types to the yang types draft. -David Reid From bertietf@bwijnen.net Sun May 17 15:34: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 372C53A6878 for ; Sun, 17 May 2009 15:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.172 X-Spam-Level: * X-Spam-Status: No, score=1.172 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=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 QY8EPCOxcWK8 for ; Sun, 17 May 2009 15:34:08 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id C1D103A682A for ; Sun, 17 May 2009 15:34:07 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1M5oxJ-0004cK-Kl; Mon, 18 May 2009 00:35:41 +0200 Message-ID: <1AA2CBFAAA0E4DCE84D78AD892DAC459@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "David Partain" , "NETMOD Working Group" References: <200904300904.21808.david.partain@ericsson.com> In-Reply-To: <200904300904.21808.david.partain@ericsson.com> Date: Mon, 18 May 2009 00:34:46 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0291_01C9D750.71E94BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 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: Sun, 17 May 2009 22:34:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0291_01C9D750.71E94BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sofar (I have reviewed the document up to (and including) page 109, I = have not seen any showstoppers. In general, this is a well written document. My review comments, none of them are fatal or showstoppers: - I suspect (but am not sure) that either IESG members or RFC-Editor may want us to expand acronyms like YANG and YIN when we first use them. In fact that applies to all acronyms we use. =20 - In the abstract, I would leave out the 1st par. Certainly, in a year or so, the statement is (hopefully) no longer = true. Besides, it is more of a "sales" statement than anything else. In the second para it states: YANG models the operations and content layers of NETCONF ... I guess you/we mean: YANG is used to model the ..... - Page 11: o MIB: A Management Information Base, traditionally referring to a management information defined using SNMP's SMI. I would say either "A Management Information Base Module" or = "Management Information Base" And "a management information defined" probly should be "a management = information model defined.." ?? Or maybe just remove the "a". - Page 12 o A container node without a "presence" statement, which has has at least one mandatory node as a child. s/has has/has/ - Page 13 scripts to operate on the models. The conversion from YANG to YIN is loss-less, so content in YIN can round-tripped back into YANG. s/can round-tripped/can be round-tripped/ ?? - Page 21 Not that it matters much, but when I see: typedef percent { type uint16 { range "0 .. 100"; } description "Percentage"; } I always wonder: why is this s uint16 and not a uint8 ?? - Page 25 The name of the example notification "link-failure" is a bit strange Specifically since the example notification informs about a "link UP" = condition, so that is recovery from a failure. Maybe better to name it = "link-status-change" or some such? - Page 29, sect 5.2 The name of the file SHOULD be on the form: s/on the form/of the form/ - Page 47, section 7.1.10 states/uses: Phone: +1 800 555 0815 According to www.ietf.org/ID-Checklist.html section 3.6.D I think we = better use Phone: +1 800 555 0100 - Same in section 7.2.3 - Page 64, section 7.7.3, 3rd line A valid leaf-list or list MUST have least min-elements entries. s/have least/have at least/ I have reviewed up to (and including) page 109. Bert ----- Original Message -----=20 From: David Partain=20 To: netmod@ietf.org=20 Sent: Thursday, April 30, 2009 9:04 AM Subject: [netmod] Working Group Last Call: = draft-ietf-netmod-yang-05.txt Dear all, This is the working group last call on the current working group = document: - YANG - A data modeling language for NETCONF:=20 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. =20 This WGLC will last until May 15, 2009. Please review and send comments to this list. Thanks. David^2 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0291_01C9D750.71E94BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sofar (I have reviewed the document up to (and = including) page=20 109, I have
not seen any showstoppers. In general, this is a = well written=20 document.
 
My review comments, none of them are fatal or=20 showstoppers:
 
- I suspect (but am not sure) that either IESG = members or=20 RFC-Editor may
  want us to expand acronyms like YANG and YIN = when we=20 first use them.
  In fact that applies to all acronyms we=20 use.
 
- In the abstract, I would leave out the 1st = par.
  Certainly, in a year or so, the statement is=20 (hopefully) no longer true.
  Besides, it is more of a "sales" statement = than=20 anything else.
  In the second para it states:
    YANG models the operations and content = layers of=20 NETCONF ...
  I guess you/we mean: YANG is used to model = the=20 .....
 
- Page 11:
  o  MIB: A Management Information Base,=20 traditionally referring to a
     management = information=20 defined using SNMP's SMI.
  I would say either "A Management Information = Base=20 Module" or "Management Information Base"
  And "a management information defined" probly = should be=20 "a management information model defined.." ??
  Or maybe just remove the "a".
 
- Page 12
   o  A container node without a = "presence"=20 statement, which has has at
      least one=20 mandatory node as a child.
  s/has has/has/
 
- Page 13
   scripts to operate on the models.  = The=20 conversion from YANG to YIN is
   loss-less, so content in = YIN can=20 round-tripped back into YANG.
  s/can round-tripped/can be round-tripped/=20 ??
 
- Page 21
  Not that it matters much, but when I = see:
     typedef percent=20 {
         type uint16=20 {
           &n= bsp;=20 range "0 .. 100";
        =20 }
         description=20 "Percentage";
     }
  I always wonder: why is this s uint16 and not = a uint8=20 ??
 
- Page 25
  The name of the example notification = "link-failure" is=20 a bit strange
  Specifically since the example notification = informs=20 about a "link UP" condition,
  so that is recovery from a failure. Maybe = better to=20 name it "link-status-change"
  or some such?
 
- Page 29, sect 5.2
    The name of the file SHOULD be on = the=20 form:
  s/on the form/of the form/
 
- Page 47, section 7.1.10 states/uses:
          &nbs= p;  =20 Phone: +1 800 555 0815
  According to www.ietf.org/ID-Checklist.= html=20 section 3.6.D I think we better use
          &nbs= p;  =20 Phone: +1 800 555 0100
 
- Same in section 7.2.3
 
- Page 64, section 7.7.3, 3rd line
       A valid leaf-list or = list MUST=20 have least min-elements entries.
  s/have least/have at least/
 
I have reviewed up to (and including) page = 109.
 
Bert
----- Original Message -----
From:=20 David Partain
Sent: Thursday, April 30, 2009 = 9:04=20 AM
Subject: [netmod] Working Group = Last=20 Call: draft-ietf-netmod-yang-05.txt

Dear all,

This is the working group last call on = the=20 current working group document:

- YANG - A data modeling = language for=20 NETCONF:
http://= tools.ietf.org/html/draft-ietf-netmod-yang-05.txt

The=20 authors and the chairs think that this document is mature enough for=20 WGLC. 
This WGLC will last until May 15, 2009.

Please = review=20 and send comments to this=20 = list.

Thanks.

David^2
__________________________________= _____________
netmod=20 mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod
------=_NextPart_000_0291_01C9D750.71E94BC0-- From mbj@tail-f.com Mon May 18 00:54: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 C5D453A6F6B for ; Mon, 18 May 2009 00:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.581 X-Spam-Level: X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_50=0.001, 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 15DdrPkGxGc3 for ; Mon, 18 May 2009 00:54:34 -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 1E07D3A6FA9 for ; Mon, 18 May 2009 00:54:33 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 938D7616041; Mon, 18 May 2009 09:56:06 +0200 (CEST) Date: Mon, 18 May 2009 09:56:05 +0200 (CEST) Message-Id: <20090518.095605.45155468.mbj@tail-f.com> To: vaughn@snmp.com From: Martin Bjorklund In-Reply-To: References: 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] require-instance 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, 18 May 2009 07:54:34 -0000 Michael Vaughn wrote: > > shouldn't require-instance be listed in the type substatements(7.4.1)? Yes. Fixed, thanks. /martin From bertietf@bwijnen.net Mon May 18 01:56: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 9B56C28C16A for ; Mon, 18 May 2009 01:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.194 X-Spam-Level: * X-Spam-Status: No, score=1.194 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=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 Gxsh-a+sN-Aj for ; Mon, 18 May 2009 01:56:44 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id E08BF28C276 for ; Mon, 18 May 2009 01:56:42 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1M5yfm-00080y-9Y; Mon, 18 May 2009 10:58:14 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "David Partain" , "NETMOD Working Group" Date: Mon, 18 May 2009 10:57:23 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0339_01C9D7A7.6C5ACC90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 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: Mon, 18 May 2009 08:56:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0339_01C9D7A7.6C5ACC90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Continued my review from page 110 onwards. Again, I see no showstoppers. Following are more or less nits/editorial comments, except for maybe the comment on section 15 (security considerations). - page 110, sect 8.2 2nd para: In this example, the mandatory constraints on the "longitude" leaf = is not enforced on devices that lack the the "has-gps" feature: s/the the/the/ - page 113, section 9.1 When NETCONF servers sends data, it MUST be in the canonical form. s/sends/send/ or s/NETCONF servers/a NETCONF server/ - page 135, last bullet o The "prefix" statment may be changed, provided all local uses of the prefix also are changed. s/statment/statement/ - section 13 The subsections have a title that ends in a colon (:). Not sure the RFC editor will accept that? Any reason why we do not use a period? - section 15 YANG is dependent upon: Is it indeed YANG that depends on it? Or is it any data that is modeled in the YANG language that depends on = it? Bert ----- Original Message -----=20 From: Bert Wijnen (IETF)=20 To: David Partain ; NETMOD Working Group=20 Sent: Monday, May 18, 2009 12:34 AM Subject: Re: [netmod] Working Group Last Call: = draft-ietf-netmod-yang-05.txt Sofar (I have reviewed the document up to (and including) page 109, I = have not seen any showstoppers. In general, this is a well written = document. My review comments, none of them are fatal or showstoppers: - I suspect (but am not sure) that either IESG members or RFC-Editor = may want us to expand acronyms like YANG and YIN when we first use them. In fact that applies to all acronyms we use. =20 - In the abstract, I would leave out the 1st par. Certainly, in a year or so, the statement is (hopefully) no longer = true. Besides, it is more of a "sales" statement than anything else. In the second para it states: YANG models the operations and content layers of NETCONF ... I guess you/we mean: YANG is used to model the ..... - Page 11: o MIB: A Management Information Base, traditionally referring to a management information defined using SNMP's SMI. I would say either "A Management Information Base Module" or = "Management Information Base" And "a management information defined" probly should be "a = management information model defined.." ?? Or maybe just remove the "a". - Page 12 o A container node without a "presence" statement, which has has = at least one mandatory node as a child. s/has has/has/ - Page 13 scripts to operate on the models. The conversion from YANG to YIN = is loss-less, so content in YIN can round-tripped back into YANG. s/can round-tripped/can be round-tripped/ ?? - Page 21 Not that it matters much, but when I see: typedef percent { type uint16 { range "0 .. 100"; } description "Percentage"; } I always wonder: why is this s uint16 and not a uint8 ?? - Page 25 The name of the example notification "link-failure" is a bit strange Specifically since the example notification informs about a "link = UP" condition, so that is recovery from a failure. Maybe better to name it = "link-status-change" or some such? - Page 29, sect 5.2 The name of the file SHOULD be on the form: s/on the form/of the form/ - Page 47, section 7.1.10 states/uses: Phone: +1 800 555 0815 According to www.ietf.org/ID-Checklist.html section 3.6.D I think we = better use Phone: +1 800 555 0100 - Same in section 7.2.3 - Page 64, section 7.7.3, 3rd line A valid leaf-list or list MUST have least min-elements entries. s/have least/have at least/ I have reviewed up to (and including) page 109. Bert ----- Original Message -----=20 From: David Partain=20 To: netmod@ietf.org=20 Sent: Thursday, April 30, 2009 9:04 AM Subject: [netmod] Working Group Last Call: = draft-ietf-netmod-yang-05.txt Dear all, This is the working group last call on the current working group = document: - YANG - A data modeling language for NETCONF:=20 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. =20 This WGLC will last until May 15, 2009. Please review and send comments to this list. Thanks. David^2 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0339_01C9D7A7.6C5ACC90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Continued my review from page 110 onwards. Again, I = see no=20 showstoppers.
Following are more or less nits/editorial comments, = except for=20 maybe the
comment on section 15 (security = considerations).
 
- page 110, sect 8.2 2nd para:
     In this example, the mandatory = constraints=20 on the "longitude" leaf is
     not enforced on = devices=20 that lack the the "has-gps" feature:
  s/the the/the/
 
- page 113, section 9.1
     When NETCONF servers sends data, = it MUST=20 be in the canonical form.
  s/sends/send/
  or s/NETCONF servers/a NETCONF = server/
 
- page 135, last bullet
     o  The "prefix" statment = may be=20 changed, provided all local uses of
    =20     the prefix also are changed.
  s/statment/statement/
 
- section 13
  The subsections have a title that ends in a = colon=20 (:).
  Not sure the RFC editor will accept = that?
  Any reason why we do not use a = period?
 
- section 15
         YANG is = dependent=20 upon:
  Is it indeed YANG that depends on = it?
  Or is it any data that is modeled in the YANG = language=20 that depends on it?
 
Bert
 
 
----- Original Message -----
From:=20 Bert Wijnen=20 (IETF)
To: David Partain ; NETMOD Working = Group=20
Sent: Monday, May 18, 2009 = 12:34 AM
Subject: Re: [netmod] Working = Group Last=20 Call: draft-ietf-netmod-yang-05.txt

Sofar (I have reviewed the document up to (and = including)=20 page 109, I have
not seen any showstoppers. In general, this is a = well=20 written document.
 
My review comments, none of them are fatal or=20 showstoppers:
 
- I suspect (but am not sure) that either IESG = members or=20 RFC-Editor may
  want us to expand acronyms like YANG and = YIN when we=20 first use them.
  In fact that applies to all acronyms we=20 use.
 
- In the abstract, I would leave out the 1st=20 par.
  Certainly, in a year or so, the statement = is=20 (hopefully) no longer true.
  Besides, it is more of a "sales" statement = than=20 anything else.
  In the second para it states:
    YANG models the operations and = content layers=20 of NETCONF ...
  I guess you/we mean: YANG is used to model = the=20 .....
 
- Page 11:
  o  MIB: A Management Information Base, = traditionally referring to a
     management=20 information defined using SNMP's SMI.
  I would say either "A Management = Information Base=20 Module" or "Management Information Base"
  And "a management information defined" = probly should=20 be "a management information model defined.." ??
  Or maybe just remove the "a".
 
- Page 12
   o  A container node without a = "presence"=20 statement, which has has at
      least = one=20 mandatory node as a child.
  s/has has/has/
 
- Page 13
   scripts to operate on the = models.  The=20 conversion from YANG to YIN is
   loss-less, so content = in YIN=20 can round-tripped back into YANG.
  s/can round-tripped/can be round-tripped/=20 ??
 
- Page 21
  Not that it matters much, but when I=20 see:
     typedef percent=20 {
         type uint16=20 = {
           &n= bsp;=20 range "0 .. 100";
        =20 }
         description=20 "Percentage";
     }
  I always wonder: why is this s uint16 and = not a uint8=20 ??
 
- Page 25
  The name of the example notification = "link-failure"=20 is a bit strange
  Specifically since the example notification = informs=20 about a "link UP" condition,
  so that is recovery from a failure. Maybe = better to=20 name it "link-status-change"
  or some such?
 
- Page 29, sect 5.2
    The name of the file SHOULD be = on the=20 form:
  s/on the form/of the form/
 
- Page 47, section 7.1.10 = states/uses:
          &nbs= p;  =20 Phone: +1 800 555 0815
  According to www.ietf.org/ID-Checklist.= html=20 section 3.6.D I think we better use
          &nbs= p;  =20 Phone: +1 800 555 0100
 
- Same in section 7.2.3
 
- Page 64, section 7.7.3, 3rd line
       A valid leaf-list = or list=20 MUST have least min-elements entries.
  s/have least/have at least/
 
I have reviewed up to (and including) page = 109.
 
Bert
----- Original Message -----
From:=20 David Partain
Sent: Thursday, April 30, = 2009 9:04=20 AM
Subject: [netmod] Working = Group Last=20 Call: draft-ietf-netmod-yang-05.txt

Dear all,

This is the working group last call = on the=20 current working group document:

- YANG - A data modeling = language for=20 NETCONF:
http://= tools.ietf.org/html/draft-ietf-netmod-yang-05.txt

The=20 authors and the chairs think that this document is mature enough for = WGLC. 
This WGLC will last until May 15, = 2009.

Please review=20 and send comments to this=20 = list.

Thanks.

David^2
__________________________________= _____________
netmod=20 mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod
= ------=_NextPart_000_0339_01C9D7A7.6C5ACC90-- From mbj@tail-f.com Mon May 18 02:06: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 6E21B3A6B9E for ; Mon, 18 May 2009 02:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[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 itV0oPEwMhcH for ; Mon, 18 May 2009 02:06: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 952683A6C1D for ; Mon, 18 May 2009 02:06:16 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 266B861600E; Mon, 18 May 2009 11:07:51 +0200 (CEST) Date: Mon, 18 May 2009 11:07:52 +0200 (CEST) Message-Id: <20090518.110752.126120989.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200905132027.QAA10513@adminfs.snmp.com> References: <200905132027.QAA10513@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] WGLC very minor nits 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, 18 May 2009 09:06:17 -0000 Hi, I applied all your suggested changes. For details, see below. David Reid wrote: > section 7.7.1 applies to both lists and leaf-lists, but only mentions list. > I suggest making it clear that it applies to both. I just added explicit leaf-list to the first sentence: YANG supports two styles for ordering the entries within lists and leaf-lists. But it would be cumbersome to repeat it in all places. Hopefully this is enough. > section 9.5, the boolean type does not have a canonical form section. Added: *** Canonical Form The canonical form is the same as the lexicographical representation. > section 9.6.4.2, the section on the bit's position statement states that the > value is not used by yang or the xml encoding. It might be helpful to use > the same wording with the enum's value statement. Done. > It also might be helpful > to show the xml encoding in the usage example like is done for bits. I added: leaf myenum { type enumeration { enum zero; enum one; enum seven { value 7; } } } The lexicographic representation of the leaf "myenum" with value "seven" is: seven > The first sentence in section 1 ("Today, the NETCONF protocol [RFC4741] lacks > a standardized way to create data models") will be wrong the day the draft > is published as proposed standard. I suggest changing the first paragraph to > past tense, or better yet, just remove the whole paragraph. Bert had the same comment, and I agree. I have removed this paragraph. /martin From mbj@tail-f.com Mon May 18 04:19: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 851DF3A698D for ; Mon, 18 May 2009 04:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, 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 qFU69FtuCQcw for ; Mon, 18 May 2009 04:19:29 -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 949F228C187 for ; Mon, 18 May 2009 04:19:28 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 6FD4A61600E; Mon, 18 May 2009 13:21:00 +0200 (CEST) Date: Mon, 18 May 2009 13:21:00 +0200 (CEST) Message-Id: <20090518.132100.185744005.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200905141934.PAA10347@adminfs.snmp.com> References: <200905141934.PAA10347@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] WGLC comments about anyxml 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, 18 May 2009 11:19:30 -0000 Hi, David Reid wrote: > A few questions and comments about anyxml: > > section 3.1: can anyxml be mandatory? Yes, fixed. > section 4.2.2 says "YANG defines four types of nodes for data modeling". Is > anyxml a 5th type of node for data modeling or is anyxml a different kind > of beast? Technically speaking I guess it is a 5th type of node, but I would prefer to not mention it in this section. Phil, do you have any comments? > section 6.2.1: anyxml is not included anywhere. I assume it should be listed > with leafs, leaf-lists, etc. Yes, fixed. > sections 7.5.6 and 7.8.4: should anyxml be added as a possible child node? Yes, fixed. > section 7.10 states that the "anyxml" statement defines an interior node in > the schema tree. A note about how it affects the data tree might also be > useful, much like some of the other parts of section 7. I suggest a simple sentence: An anyxml node exists in zero or one instances in the data tree. Should we say something about its value and child nodes? If so, can we say that it's value is the unknown chunk of XML, and it has no child nodes. /martin From mbj@tail-f.com Mon May 18 04:23: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 A3C413A6D50 for ; Mon, 18 May 2009 04:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_40=-0.185, 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 ss3IgJbYZ8VK for ; Mon, 18 May 2009 04:23: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 B472E28C120 for ; Mon, 18 May 2009 04:23:40 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 0828161600E; Mon, 18 May 2009 13:25:15 +0200 (CEST) Date: Mon, 18 May 2009 13:25:16 +0200 (CEST) Message-Id: <20090518.132516.63152516.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <1AA2CBFAAA0E4DCE84D78AD892DAC459@BertLaptop> References: <200904300904.21808.david.partain@ericsson.com> <1AA2CBFAAA0E4DCE84D78AD892DAC459@BertLaptop> 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] 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: Mon, 18 May 2009 11:23:41 -0000 Hi Bert, "Bert Wijnen \(IETF\)" wrote: > Sofar (I have reviewed the document up to (and including) page 109, I have > not seen any showstoppers. In general, this is a well written document. > > My review comments, none of them are fatal or showstoppers: > > - I suspect (but am not sure) that either IESG members or RFC-Editor may > want us to expand acronyms like YANG and YIN when we first use them. > In fact that applies to all acronyms we use. I will check all the acronyms. > - In the abstract, I would leave out the 1st par. > Certainly, in a year or so, the statement is (hopefully) no longer true. > Besides, it is more of a "sales" statement than anything else. Removed. > In the second para it states: > YANG models the operations and content layers of NETCONF ... > I guess you/we mean: YANG is used to model the ..... Fixed. > - Page 11: > o MIB: A Management Information Base, traditionally referring to a > management information defined using SNMP's SMI. > > I would say either "A Management Information Base Module" or "Management > Information Base" > And "a management information defined" probly should be "a management > information model defined.." ?? > Or maybe just remove the "a". Removed both 'a's: - MIB: Management Information Base, traditionally referring to management information defined using SNMP's SMI. > - Page 12 > o A container node without a "presence" statement, which has has at > least one mandatory node as a child. > s/has has/has/ Fixed. > - Page 13 > scripts to operate on the models. The conversion from YANG to YIN is > loss-less, so content in YIN can round-tripped back into YANG. > s/can round-tripped/can be round-tripped/ ?? Fixed. > - Page 21 > Not that it matters much, but when I see: > typedef percent { > type uint16 { > range "0 .. 100"; > } > description "Percentage"; > } > > I always wonder: why is this s uint16 and not a uint8 ?? Fixed. > - Page 25 > The name of the example notification "link-failure" is a bit strange > Specifically since the example notification informs about a "link UP" > condition, > so that is recovery from a failure. Maybe better to name it > "link-status-change" > or some such? Actually it is the if-admin-status that is included (just as ifAdminStatus is included in the linkDown SNMP notification). > - Page 29, sect 5.2 > The name of the file SHOULD be on the form: > s/on the form/of the form/ > > - Page 47, section 7.1.10 states/uses: > Phone: +1 800 555 0815 > According to www.ietf.org/ID-Checklist.html section 3.6.D I think we better > use > Phone: +1 800 555 0100 > > - Same in section 7.2.3 > > - Page 64, section 7.7.3, 3rd line > A valid leaf-list or list MUST have least min-elements entries. > s/have least/have at least/ All of the above fixed. /martin From mbj@tail-f.com Mon May 18 04:28: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 8902528C2AB for ; Mon, 18 May 2009 04:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[AWL=1.114, 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 mDJa6vJec-39 for ; Mon, 18 May 2009 04:28:19 -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 3E8F728C29A for ; Mon, 18 May 2009 04:28:19 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id A0B0061600E; Mon, 18 May 2009 13:29:54 +0200 (CEST) Date: Mon, 18 May 2009 13:29:55 +0200 (CEST) Message-Id: <20090518.132955.168803376.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: References: 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] 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: Mon, 18 May 2009 11:28:24 -0000 Hi, "Bert Wijnen \(IETF\)" wrote: > Continued my review from page 110 onwards. Again, I see no showstoppers. > Following are more or less nits/editorial comments, except for maybe the > comment on section 15 (security considerations). I applied all your patches. > - section 15 > YANG is dependent upon: > Is it indeed YANG that depends on it? > Or is it any data that is modeled in the YANG language that depends on it? I think it should be "Data modeled in YANG is dependent upon:". /martin From bertietf@bwijnen.net Mon May 18 04:31: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 446443A6A92 for ; Mon, 18 May 2009 04:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[AWL=-0.943, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=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 R7r-hPsMXhDh for ; Mon, 18 May 2009 04:31:39 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 3E6AA28C2B8 for ; Mon, 18 May 2009 04:31:39 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1M615l-0007FL-F7; Mon, 18 May 2009 13:33:13 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Martin Bjorklund" References: <20090518.132955.168803376.mbj@tail-f.com> In-Reply-To: <20090518.132955.168803376.mbj@tail-f.com> Date: Mon, 18 May 2009 13:32:27 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_042E_01C9D7BD.16498EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 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: Mon, 18 May 2009 11:31:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_042E_01C9D7BD.16498EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That would address my comment. Bert ----- Original Message -----=20 From: Martin Bjorklund=20 To: bertietf@bwijnen.net=20 Cc: david.partain@ericsson.com ; netmod@ietf.org=20 Sent: Monday, May 18, 2009 1:29 PM Subject: Re: [netmod] Working Group Last Call: = draft-ietf-netmod-yang-05.txt > - section 15 > YANG is dependent upon: > Is it indeed YANG that depends on it? > Or is it any data that is modeled in the YANG language that = depends on it? I think it should be "Data modeled in YANG is dependent upon:". /martin ------=_NextPart_000_042E_01C9D7BD.16498EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That would address my comment.
 
Bert
----- Original Message -----
From:=20 Martin = Bjorklund=20
Cc: david.partain@ericsson.com= ; netmod@ietf.org
Sent: Monday, May 18, 2009 1:29 = PM
Subject: Re: [netmod] Working = Group Last=20 Call: draft-ietf-netmod-yang-05.txt

> - section=20 15
>          YANG = is=20 dependent upon:
>   Is it indeed YANG that depends on=20 it?
>   Or is it any data that is modeled in the YANG = language=20 that depends on it?

I think it should be "Data modeled in YANG = is=20 dependent upon:".


/martin

------=_NextPart_000_042E_01C9D7BD.16498EC0-- From reid@snmp.com Mon May 18 05:51: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 5C0173A6ABF for ; Mon, 18 May 2009 05:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.892, 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 HkgjQy0MsoaE for ; Mon, 18 May 2009 05:51:18 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 500973A6358 for ; Mon, 18 May 2009 05:51:18 -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 IAA21126; Mon, 18 May 2009 08:52:50 -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 IAA28387; Mon, 18 May 2009 08:52:50 -0400 (EDT) Message-Id: <200905181252.IAA28387@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Mon, 18 May 2009 13:21:00 +0200. <20090518.132100.185744005.mbj@tail-f.com> Date: Mon, 18 May 2009 08:52:50 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about anyxml 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: Mon, 18 May 2009 12:51:19 -0000 > > section 4.2.2 says "YANG defines four types of nodes for data modeling". Is > > anyxml a 5th type of node for data modeling or is anyxml a different kind > > of beast? > > Technically speaking I guess it is a 5th type of node, but I would > prefer to not mention it in this section. I don't think we want to encourage the use of anyxml, so not mentioning it here is fine with me. Part of the reason for my question was just to make sure I was understanding anyxml correctly. > > section 7.10 states that the "anyxml" statement defines an interior node in > > the schema tree. A note about how it affects the data tree might also be > > useful, much like some of the other parts of section 7. > > I suggest a simple sentence: > > An anyxml node exists in zero or one instances in the data tree. Sounds good. > > Should we say something about its value and child nodes? If so, can > we say that it's value is the unknown chunk of XML, and it has no > child nodes. > I think that would be helpful. -David Reid From lhotka@cesnet.cz Mon May 18 05:58: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 5970628C29A for ; Mon, 18 May 2009 05:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[AWL=-1.011, 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 bZXoUjAdiXmI for ; Mon, 18 May 2009 05:58:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6414E28C2D9 for ; Mon, 18 May 2009 05:58:43 -0700 (PDT) Received: from [195.113.219.177] (eduroam-177.cesnet.cz [195.113.219.177]) by office2.cesnet.cz (Postfix) with ESMTP id BE4C9D800C8 for ; Mon, 18 May 2009 15:00:18 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090518.132100.185744005.mbj@tail-f.com> References: <200905141934.PAA10347@adminfs.snmp.com> <20090518.132100.185744005.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 18 May 2009 15:00:17 +0200 Message-Id: <1242651617.3542.5.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] WGLC comments about anyxml 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, 18 May 2009 12:58:44 -0000 Martin Bjorklund píše v Po 18. 05. 2009 v 13:21 +0200: > Technically speaking I guess it is a 5th type of node, but I would > prefer to not mention it in this section. Phil, do you have any > comments? > An alternative would be to define "anyxml" as "any XML content" rather than a special container. So what is now written as anyxml foo; would be container foo { anyxml; } Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E 8C0C From mbj@tail-f.com Mon May 18 06: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 5D4A83A689C for ; Mon, 18 May 2009 06:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_50=0.001, 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 biuU29QJX66y for ; Mon, 18 May 2009 06:03:57 -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 9322A3A6A63 for ; Mon, 18 May 2009 06:03: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 4ED7361600E; Mon, 18 May 2009 15:05:32 +0200 (CEST) Date: Mon, 18 May 2009 15:05:31 +0200 (CEST) Message-Id: <20090518.150531.49276846.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242651617.3542.5.camel@nomad> References: <200905141934.PAA10347@adminfs.snmp.com> <20090518.132100.185744005.mbj@tail-f.com> <1242651617.3542.5.camel@nomad> 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] WGLC comments about anyxml 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, 18 May 2009 13:04:04 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQbyAxOC4gMDUuIDIwMDkgdiAxMzoyMSArMDIwMDoNCj4gDQo+ID4gVGVj aG5pY2FsbHkgc3BlYWtpbmcgSSBndWVzcyBpdCBpcyBhIDV0aCB0eXBlIG9mIG5vZGUsIGJ1dCBJ IHdvdWxkDQo+ID4gcHJlZmVyIHRvIG5vdCBtZW50aW9uIGl0IGluIHRoaXMgc2VjdGlvbi4gIFBo aWwsIGRvIHlvdSBoYXZlIGFueQ0KPiA+IGNvbW1lbnRzPw0KPiA+IA0KPiANCj4gQW4gYWx0ZXJu YXRpdmUgd291bGQgYmUgdG8gZGVmaW5lICJhbnl4bWwiIGFzICJhbnkgWE1MIGNvbnRlbnQiIHJh dGhlcg0KPiB0aGFuIGEgc3BlY2lhbCBjb250YWluZXIuIFNvIHdoYXQgaXMgbm93IHdyaXR0ZW4g YXMNCj4gDQo+IGFueXhtbCBmb287DQo+IA0KPiB3b3VsZCBiZQ0KPiANCj4gY29udGFpbmVyIGZv byB7DQo+ICAgICBhbnl4bWw7DQo+IH0NCg0KSSBkb24ndCBzZWUgaG93IHRoaXMgd291bGQgaGVs cCB0aGUgZGVzY3JpcHRpb24gb2YgJ2FueXhtbCcuDQoNCg0KVGhpcyBjaGFuZ2Ugd291bGQgb3Bl biBmb3Igc29tZSBxdWVzdGlvbnM6DQoNCklzIHRoaXMgbGVnYWw6DQoNCiAgY29udGFpbmVyIGZv byB7DQogICAgICBsZWFmIGJhciB7IHR5cGUgaW50MzI7IH0NCiAgICAgIGFueXhtbDsNCiAgfQ0K DQpJZiBpdCBpcywgaXMgdGhpcyBhIGxlZ2FsIDxmb28+Og0KDQogIDxmb28+DQogICAgIDxiYXI+ aGVsbG88L2Jhcj4NCiAgPC9mb28+DQoNCmFuZCBzbyBvbi4uLg0KDQoNCi9tYXJ0aW4NCg== From lhotka@cesnet.cz Mon May 18 06:17: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 AE44428C2ED for ; Mon, 18 May 2009 06:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_40=-0.185, 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 1V7kEePTmJy7 for ; Mon, 18 May 2009 06:17:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7D24528C308 for ; Mon, 18 May 2009 06:17:10 -0700 (PDT) Received: from [195.113.219.177] (eduroam-177.cesnet.cz [195.113.219.177]) by office2.cesnet.cz (Postfix) with ESMTP id 3055DD800CC; Mon, 18 May 2009 15:18:46 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090518.150531.49276846.mbj@tail-f.com> References: <200905141934.PAA10347@adminfs.snmp.com> <20090518.132100.185744005.mbj@tail-f.com> <1242651617.3542.5.camel@nomad> <20090518.150531.49276846.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 18 May 2009 15:18:44 +0200 Message-Id: <1242652724.3542.17.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about anyxml 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, 18 May 2009 13:17:44 -0000 Martin Bjorklund píše v Po 18. 05. 2009 v 15:05 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Po 18. 05. 2009 v 13:21 +0200: > > > > > Technically speaking I guess it is a 5th type of node, but I would > > > prefer to not mention it in this section. Phil, do you have any > > > comments? > > > > > > > An alternative would be to define "anyxml" as "any XML content" rather > > than a special container. So what is now written as > > > > anyxml foo; > > > > would be > > > > container foo { > > anyxml; > > } > > I don't see how this would help the description of 'anyxml'. anyxml would no more be among YANG structural building blocks, just an anonymous (and optional) XML blob. In particular, it will not influence whether container foo is or isn't mandatory. Lada > > > This change would open for some questions: > > Is this legal: > > container foo { > leaf bar { type int32; } > anyxml; > } It could be. > > If it is, is this a legal : > > > hello > Yes, IMO. > > and so on... > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E 8C0C From spakes@snmp.com Mon May 18 06:50: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 6B65A3A6D9F for ; Mon, 18 May 2009 06:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 1ARANir9llQ5 for ; Mon, 18 May 2009 06:50:11 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 055A43A703E for ; Mon, 18 May 2009 06:50:10 -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 JAA25847 for ; Mon, 18 May 2009 09:51:46 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA29006; Mon, 18 May 2009 09:41:13 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 18 May 2009 09:41:12 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4A0EDCD0.9020806@netconfcentral.com> Message-ID: References: <20090515035454.GA1535@elstar.local> <4A0CEDBC.4020003@netconfcentral.com> <20090515.163639.76136550.mbj@tail-f.com> <4A0D8064.3030503@netconfcentral.com> <20090516114749.GD2388@elstar.local> <4A0EC1BC.6010301@netconfcentral.com> <20090516142006.GB2645@elstar.local> <4A0EDCD0.9020806@netconfcentral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal 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, 18 May 2009 13:50:12 -0000 On Sat, 16 May 2009, Andy Bierman wrote: > Here's the litmus test: > - If you can build the desired data type out of > existing built-in types, then there is no need > for a new built-in type. Just use typedef instead. In general, I agree with this line of thinking. That's why my proposal was to add the typedef for "real" to draft-ietf-netmod-yang-types-03.txt. However, I also believe in simplicity. Why make it necessary to define a typedef at all when a tiny change of semantic on the base type elegantly does the same thing? If fraction-digits were made an optional substatement for decimal64 as Juergen suggested, then anyone needing a decimal-point-moves-around type could have it, and anyone needing a fixed-position-decimal-point type could have it. Regards, David Spakes ------------------------------------------------------------- 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 Mon May 18 07:08: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 90E063A6DBA for ; Mon, 18 May 2009 07:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[AWL=-0.561, 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 Y4kcmWFYkKvE for ; Mon, 18 May 2009 07:08:15 -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 CB99B3A6824 for ; Mon, 18 May 2009 07:08: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 936D4616066; Mon, 18 May 2009 16:09:47 +0200 (CEST) Date: Mon, 18 May 2009 16:09:47 +0200 (CEST) Message-Id: <20090518.160947.204829148.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <20090516142006.GB2645@elstar.local> <4A0EDCD0.9020806@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] float vs. decimal 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, 18 May 2009 14:08:15 -0000 Hi, David Spakes wrote: > However, I also believe in simplicity. Why make it necessary to define a > typedef at all when a tiny change of semantic on the base type elegantly > does the same thing? If fraction-digits were made an optional > substatement for decimal64 as Juergen suggested, then anyone needing a > decimal-point-moves-around type could have it We can probably add many simple types. The question is if we see a use case for them. I don't think a floating point calculator is representative. You mentioned "ratios" as a use case, could you elaborate a bit? What kind of ratios did you have in mind that could not be modeled with the current decimal64 type? /martin From reid@snmp.com Mon May 18 12:11: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 1FE0A3A684B for ; Mon, 18 May 2009 12:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 u1370d9CPDMH for ; Mon, 18 May 2009 12:11:48 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 2A99B3A69DE for ; Mon, 18 May 2009 12:11:48 -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 PAA26289; Mon, 18 May 2009 15:13:23 -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 PAA05503; Mon, 18 May 2009 15:13:22 -0400 (EDT) Message-Id: <200905181913.PAA05503@adminfs.snmp.com> To: Ladislav Lhotka From: David Reid In-reply-to: Your message of Mon, 18 May 2009 15:00:17 +0200. <1242651617.3542.5.camel@nomad> Date: Mon, 18 May 2009 15:13:22 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about anyxml 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: Mon, 18 May 2009 19:11:49 -0000 > An alternative would be to define "anyxml" as "any XML content" rather > than a special container. So what is now written as > > anyxml foo; > > would be > > container foo { > anyxml; > } Could we change anyxml to be a type? So the example above would become leaf foo { type anyxml; } -David Reid From jmh@joelhalpern.com Mon May 18 12:28: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 0114C3A6D25 for ; Mon, 18 May 2009 12:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 gHwjmQ9Lmm-d for ; Mon, 18 May 2009 12:28:12 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4B4D53A6A80 for ; Mon, 18 May 2009 12:28:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A67294303E8; Mon, 18 May 2009 12:29:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-141.clppva.btas.verizon.net [71.161.52.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id F0A7D4303CE; Mon, 18 May 2009 12:29:47 -0700 (PDT) Message-ID: <4A11B72A.7080805@joelhalpern.com> Date: Mon, 18 May 2009 15:29:46 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200905181913.PAA05503@adminfs.snmp.com> In-Reply-To: <200905181913.PAA05503@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about anyxml 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, 18 May 2009 19:28:13 -0000 It seems that having a specific wrapper, in which any xml is permitted, is a good idea. Otherwise, it appears that any XML envelop in which anyxml is permitted would be unable to ever generate any errors. Yours, Joel David Reid wrote: >> An alternative would be to define "anyxml" as "any XML content" rather >> than a special container. So what is now written as >> >> anyxml foo; >> >> would be >> >> container foo { >> anyxml; >> } > > Could we change anyxml to be a type? So the example above would become > > leaf foo { > type anyxml; > } > > -David Reid > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Mon May 18 12:53: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 DDA0A3A6CDD for ; Mon, 18 May 2009 12:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.085, 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 a+gKzlad6GU3 for ; Mon, 18 May 2009 12:53:13 -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 3BCA23A6B00 for ; Mon, 18 May 2009 12:53:13 -0700 (PDT) Received: (qmail 91806 invoked from network); 18 May 2009 19:54:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 18 May 2009 19:54:47 -0000 X-YMail-OSG: av9VYT4VM1kq49HrwXpU0F4TsayOL.CHcPNYRq4JcrxXF0E_lfacTk92XOg56efl6ecpTy.cCRkYC3sJ_8pHniLHXAFeXOQSmzP1Fwau4CkJX29mLXz639edwOQ9M5._V5vpRGS_Jc5TxM6DY4WukkYBH.4MyEGICAQqDm.bvd.aX57Wk1PKSol62RkTvL3iEKzyFLIp44d_miWbHWQB3vbnQAUe4zIUJyAmkexBTTE9Z940aabZNSI64.eQ4OWM6P0SaZaAQrWI2oE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A11BD06.9010802@netconfcentral.com> Date: Mon, 18 May 2009 12:54:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200905181913.PAA05503@adminfs.snmp.com> In-Reply-To: <200905181913.PAA05503@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about anyxml 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, 18 May 2009 19:53:14 -0000 David Reid wrote: >> An alternative would be to define "anyxml" as "any XML content" rather >> than a special container. So what is now written as >> >> anyxml foo; >> >> would be >> >> container foo { >> anyxml; >> } > > Could we change anyxml to be a type? So the example above would become > > leaf foo { > type anyxml; > } > It started out that way. The problem is that anyxml is not a leaf. Let's leave anyxml alone. e.g.: anyxml foo { when "..."; if-feature "bar"; // X N must "..."; // X N config false; mandatory false; status current; description "..."; reference "..."; } > -David Reid Andy From lhotka@cesnet.cz Mon May 18 13:24: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 47E553A6D8F for ; Mon, 18 May 2009 13:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.434, 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 38tNGzCVZr89 for ; Mon, 18 May 2009 13:24:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 655C23A6D75 for ; Mon, 18 May 2009 13:24:15 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C4984D800EF; Mon, 18 May 2009 22:25:50 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A11BD06.9010802@netconfcentral.com> References: <200905181913.PAA05503@adminfs.snmp.com> <4A11BD06.9010802@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 18 May 2009 22:25:49 +0200 Message-Id: <1242678349.3379.4.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about anyxml 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, 18 May 2009 20:24:16 -0000 Andy Bierman píše v Po 18. 05. 2009 v 12:54 -0700: > David Reid wrote: > >> An alternative would be to define "anyxml" as "any XML content" rather > >> than a special container. So what is now written as > >> > >> anyxml foo; > >> > >> would be > >> > >> container foo { > >> anyxml; > >> } > > > > Could we change anyxml to be a type? So the example above would become > > > > leaf foo { > > type anyxml; > > } > > > > It started out that way. > The problem is that anyxml is not a leaf. Why is it a problem? The contents of current anyxml needn't be a leaf either. > Let's leave anyxml alone. e.g.: I am not against it, but then anyxml has to be added in a few places as the fifth possible building block. Lada > > anyxml foo { > when "..."; > if-feature "bar"; // X N > must "..."; // X N > config false; > mandatory false; > status current; > description "..."; > reference "..."; > } > > > -David Reid > > Andy > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E 8C0C From root@core3.amsl.com Tue May 19 02: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 5BA253A6B7C; Tue, 19 May 2009 02: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: <20090519094501.5BA253A6B7C@core3.amsl.com> Date: Tue, 19 May 2009 02:45:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-00.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: Tue, 19 May 2009 09: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 : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-00.txt Pages : 22 Date : 2009-05-18 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-00.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-usage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-19023357.I-D@ietf.org> --NextPart-- From spakes@snmp.com Tue May 19 07:54: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 0DFC13A6A94 for ; Tue, 19 May 2009 07:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 jDv06l90XtyO for ; Tue, 19 May 2009 07:54:46 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id CBB083A6A93 for ; Tue, 19 May 2009 07:54:45 -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 KAA15303; Tue, 19 May 2009 10:56:19 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA17901; Tue, 19 May 2009 10:56:18 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 19 May 2009 10:56:17 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Martin Bjorklund In-Reply-To: <20090518.160947.204829148.mbj@tail-f.com> Message-ID: References: <20090516142006.GB2645@elstar.local> <4A0EDCD0.9020806@netconfcentral.com> <20090518.160947.204829148.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal 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, 19 May 2009 14:54:47 -0000 Martin, I didn't have anything specific in mind when I talked about the ratios. My tenacity comes from my first years at SNMP Research when I worked the technical support desk (early 1990s). I remember fielding more than a few calls from customers who wanted to encode floating point numbers in SNMP messages but don't recall the specifics. If the group decision is not in favor of Juergen's proposal to make the fraction-digits substatement optional, I would still like to see the typedef of union find a place in draft-ietf-netmod-yang-types-03.txt as originally proposed. Regards, David Spakes On Mon, 18 May 2009, Martin Bjorklund wrote: > Hi, > > David Spakes wrote: > > However, I also believe in simplicity. Why make it necessary to define a > > typedef at all when a tiny change of semantic on the base type elegantly > > does the same thing? If fraction-digits were made an optional > > substatement for decimal64 as Juergen suggested, then anyone needing a > > decimal-point-moves-around type could have it > > We can probably add many simple types. The question is if we see a > use case for them. I don't think a floating point calculator is > representative. You mentioned "ratios" as a use case, could you > elaborate a bit? What kind of ratios did you have in mind that could > not be modeled with the current decimal64 type? > > > /martin > ------------------------------------------------------------- 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 reid@snmp.com Tue May 19 10:22: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 511413A6ECC for ; Tue, 19 May 2009 10:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 i0cLsAFsHZS5 for ; Tue, 19 May 2009 10:22:16 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 63B963A6857 for ; Tue, 19 May 2009 10:22:16 -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 NAA02444; Tue, 19 May 2009 13:23:52 -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 NAA23715; Tue, 19 May 2009 13:23:47 -0400 (EDT) Message-Id: <200905191723.NAA23715@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Mon, 18 May 2009 12:54:46 -0700. <4A11BD06.9010802@netconfcentral.com> Date: Tue, 19 May 2009 13:23:47 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about anyxml 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: Tue, 19 May 2009 17:22:17 -0000 > >> An alternative would be to define "anyxml" as "any XML content" rather > >> than a special container. So what is now written as > >> > >> anyxml foo; > >> > >> would be > >> > >> container foo { > >> anyxml; > >> } > > > > Could we change anyxml to be a type? So the example above would become > > > > leaf foo { > > type anyxml; > > } > > > > It started out that way. > The problem is that anyxml is not a leaf. How would anyxml typically be used? Why would it not work to make it a leaf? -David Reid From andy@netconfcentral.com Tue May 19 10:39: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 A459E28C153 for ; Tue, 19 May 2009 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 gwfZr87I-P04 for ; Tue, 19 May 2009 10:39:13 -0700 (PDT) Received: from n9.bullet.mail.mud.yahoo.com (n9.bullet.mail.mud.yahoo.com [209.191.86.157]) by core3.amsl.com (Postfix) with SMTP id C810028C14B for ; Tue, 19 May 2009 10:39:12 -0700 (PDT) Received: from [68.142.194.244] by n9.bullet.mail.mud.yahoo.com with NNFMP; 19 May 2009 17:40:47 -0000 Received: from [68.142.201.252] by t2.bullet.mud.yahoo.com with NNFMP; 19 May 2009 17:40:47 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 19 May 2009 17:40:47 -0000 X-Yahoo-Newman-Id: 833700.74379.bm@omp413.mail.mud.yahoo.com Received: (qmail 70863 invoked from network); 19 May 2009 17:40:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 19 May 2009 17:40:46 -0000 X-YMail-OSG: Xe6zc2YVM1khQj2ojqKfUFCTN4J1DQumC_IqFXwH8Vc6iod2moWqV5qJbjST_IY9q4RR0P68lh2Pr5YfIYRJJCBydIaToe1MrWeFTkLbKeKaCKc5AZpBkg5GmSX70nht6I9U.qWggMBxtEEjxZl9Cidua6WIZGvQuYZE._UBGcbQpBOt9fKjEKOlFkVNGrXghjA8tr37M9W7dmRvYgGjLK_khporEde2Whw65JmmnVTH50g8gJ3qxv7P8BjKaVP4wwrcRZb9ucnngnIowmgCkWqHa0U.ZuVGNmEzeGWeE1DDVs_fst4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A12EF1D.4020009@netconfcentral.com> Date: Tue, 19 May 2009 10:40:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200905191723.NAA23715@adminfs.snmp.com> In-Reply-To: <200905191723.NAA23715@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] WGLC comments about anyxml 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, 19 May 2009 17:39:13 -0000 David Reid wrote: >>>> An alternative would be to define "anyxml" as "any XML content" rather >>>> than a special container. So what is now written as >>>> >>>> anyxml foo; >>>> >>>> would be >>>> >>>> container foo { >>>> anyxml; >>>> } >>> Could we change anyxml to be a type? So the example above would become >>> >>> leaf foo { >>> type anyxml; >>> } >>> >> It started out that way. >> The problem is that anyxml is not a leaf. > > How would anyxml typically be used? Why would it not work to make it a leaf? > The element in NETCONF is an example of anyxml. There are 3 forms of anyxml accepted: 1) empty 2) leaf string 3) complex string Due to form (3), leaf is not appropriate. > -David Reid > > Andy From lhotka@cesnet.cz Wed May 20 04:34: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 46EA03A6B14 for ; Wed, 20 May 2009 04:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.005 X-Spam-Level: X-Spam-Status: No, score=-0.005 tagged_above=-999 required=5 tests=[AWL=-0.614, 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 wkcaqdGkUUw5 for ; Wed, 20 May 2009 04:34:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 73F373A6835 for ; Wed, 20 May 2009 04:34:29 -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 913B7D800C7 for ; Wed, 20 May 2009 13:36:05 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Wed, 20 May 2009 13:36:05 +0200 Message-Id: <1242819365.16094.21.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] edit-config 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, 20 May 2009 11:34:30 -0000 Hi, in Sec. 7.6.6 on edit-config operations for leafs, the two sentences describing the procedure for "merge" and "replace" operations are exactly identical, which should lead to the conclusion that the agent behaviour is the same for both operations. However, RFC 4741 says that for the "replace" operation "only the configuration actually present in the config parameter is affected", so the node should NOT be created if it doesn't exist, if I understand it correctly. So how is it actually? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed May 20 05:03: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 8F3833A6BE4 for ; Wed, 20 May 2009 05:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.661, 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 Nwf3SjuOTFtw for ; Wed, 20 May 2009 05:03: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 AEB783A6B10 for ; Wed, 20 May 2009 05:03:28 -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 EC3E761600E; Wed, 20 May 2009 14:05:04 +0200 (CEST) Date: Wed, 20 May 2009 14:05:04 +0200 (CEST) Message-Id: <20090520.140504.159744594.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242819365.16094.21.camel@missotis> References: <1242819365.16094.21.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] edit-config 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, 20 May 2009 12:03:29 -0000 Ladislav Lhotka wrote: > Hi, > > in Sec. 7.6.6 on edit-config operations for leafs, the two sentences > describing the procedure for "merge" and "replace" operations are > exactly identical, which should lead to the conclusion that the agent > behaviour is the same for both operations. However, RFC 4741 says that > for the "replace" operation "only the configuration actually present in > the config parameter is affected", so the node should NOT be created if > it doesn't exist, if I understand it correctly. So how is it actually? There is no difference between merge and replace for a leaf. In general, replace does not give an error if the item to replace does not exist. (This has been discussed several times on the ML) /martin From lhotka@cesnet.cz Wed May 20 05:13: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 CC0E83A6C17 for ; Wed, 20 May 2009 05:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_40=-0.185, 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 2e3JiGQLwYPZ for ; Wed, 20 May 2009 05:13:25 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 800CA28C22C for ; Wed, 20 May 2009 05:13:25 -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 8533DD800C7 for ; Wed, 20 May 2009 14:15:02 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Wed, 20 May 2009 14:15:02 +0200 Message-Id: <1242821702.16094.37.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] edit-config for lists 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, 20 May 2009 12:13:32 -0000 Hi, if I slightly extend the example near the end of Sec. 7.7.8: ... blowfish-cbc aes-cbc ... What will be the resulting order of list entries: "3des-cbc, blowfish-cbc, aes-cbc" or "3des-cbc, aes-cbc, blowfish-cbc"? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed May 20 05:25: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 386EF28C365 for ; Wed, 20 May 2009 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[AWL=-0.412, 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 nqD2l8vvltPz for ; Wed, 20 May 2009 05:25:02 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 40D1728C305 for ; Wed, 20 May 2009 05:25:02 -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 4D10BD800C7; Wed, 20 May 2009 14:26:39 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.140504.159744594.mbj@tail-f.com> References: <1242819365.16094.21.camel@missotis> <20090520.140504.159744594.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 20 May 2009 14:26:39 +0200 Message-Id: <1242822399.16094.44.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] edit-config 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, 20 May 2009 12:25:03 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 14:05 +0200: > Ladislav Lhotka wrote: > > Hi, > > > > in Sec. 7.6.6 on edit-config operations for leafs, the two sentences > > describing the procedure for "merge" and "replace" operations are > > exactly identical, which should lead to the conclusion that the agent > > behaviour is the same for both operations. However, RFC 4741 says that > > for the "replace" operation "only the configuration actually present in > > the config parameter is affected", so the node should NOT be created if > > it doesn't exist, if I understand it correctly. So how is it actually? > > There is no difference between merge and replace for a leaf. > > In general, replace does not give an error if the item to replace does > not exist. (This has been discussed several times on the ML) OK, but the item also should not be created, should it? Or how do you explain the above sentence from RFC 4741? BTW, the subsequent paragraphs on "create" and "delete" should mention that rpc-error is returned if the item exists or doesn't exist, respectively. Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Wed May 20 06:16: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 179793A6CD9 for ; Wed, 20 May 2009 06:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 mMY8kOmj4WwT for ; Wed, 20 May 2009 06:16: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 2BA3A3A6D26 for ; Wed, 20 May 2009 06:16:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C746A4306B0 for ; Wed, 20 May 2009 06:18:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-141.clppva.btas.verizon.net [71.161.52.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 4D9704306A5 for ; Wed, 20 May 2009 06:18:35 -0700 (PDT) Message-ID: <4A140329.5040302@joelhalpern.com> Date: Wed, 20 May 2009 09:18:33 -0400 From: "Joel M. Halpern" 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] Intended status of the yang-usage draft? 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, 20 May 2009 13:16:59 -0000 After reading draft-ietf-netmod-yang-usage-00.txt, I really would like to see that published along with the base Yang draft (or, to be realistic, I suppose as soon thereafter as possible.) But I got confused when I looked at the charter for the status of the document. The draft is clearly intended to tell other groups (and this group itself) how modules are supposed to be written. Unless there is a very good reason to do otherwise, one would expect module writers to comply with the document. That is about as good a definition of how we use BCP documents as there really is. (Like "RFC" itself, the acronym expansion for "BCP" is somewhat misleading. We have published many BCPs on new things.) Publishing the document as Informational does not seem likely to communicate the desired impact to other communities. After talking with other folks, I was told that if there was a clear consensus from the WG, then the document could be a BCP. I realize this was discussed before, and that this is a topic on which reasonable folks can differ. But I would like to see some discussion. The "downside" i have heard of this choice is that other similar documents have taken a long time to finish. If changing the status will increase the time significantly, then that would be a bad outcome. But I don't see why that is so. Either we intend other folks to follow the document, or we don't. If we expect folks to follow it, then we should be clear about that. If we don't, then the wording should be much weaker, and I doubt it is worth the effort. Yours, Joel M. Halpern From bertietf@bwijnen.net Wed May 20 06:22: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 4E9343A691D for ; Wed, 20 May 2009 06:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.227 X-Spam-Level: * X-Spam-Status: No, score=1.227 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=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 C3G3nAE-aCjm for ; Wed, 20 May 2009 06:22:29 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id AE1593A6A62 for ; Wed, 20 May 2009 06:22:28 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1M6lm8-0007pr-EK; Wed, 20 May 2009 15:24:04 +0200 Message-ID: <0972AC16141C4FE6B4EDC3A780B4BE5C@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Joel M. Halpern" , "NETMOD Working Group" References: <4A140329.5040302@joelhalpern.com> In-Reply-To: <4A140329.5040302@joelhalpern.com> Date: Wed, 20 May 2009 15:23:33 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F79_01C9D95E.F01F8300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 13:22:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0F79_01C9D95E.F01F8300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, when we did a similar thing for SMI (now RFC4181), it DID take a = looooong time. We in fact took an I-D that we used for a while as MIB doctors to see = how well it was written and if it was workable. So doing an informational, with the intention to do a bis as BCP in a = year (after we gain experience), or with the intention to just advance it to BCP if = we find no problems would be the quickest approach (I would think). We could = even make=20 an introductuion section explains why it starts as informational and = that we plan to make it (or its successor) a BCP in a year or 2 years after we gain = more experience. my 2 cents. Bert ----- Original Message -----=20 From: Joel M. Halpern=20 To: NETMOD Working Group=20 Sent: Wednesday, May 20, 2009 3:18 PM Subject: [netmod] Intended status of the yang-usage draft? After reading draft-ietf-netmod-yang-usage-00.txt, I really would like = to see that published along with the base Yang draft (or, to be=20 realistic, I suppose as soon thereafter as possible.) But I got confused when I looked at the charter for the status of the=20 document. The draft is clearly intended to tell other groups (and this group=20 itself) how modules are supposed to be written. Unless there is a = very=20 good reason to do otherwise, one would expect module writers to comply = with the document. That is about as good a definition of how we use BCP documents as = there=20 really is. (Like "RFC" itself, the acronym expansion for "BCP" is=20 somewhat misleading. We have published many BCPs on new things.) Publishing the document as Informational does not seem likely to=20 communicate the desired impact to other communities. After talking with other folks, I was told that if there was a clear=20 consensus from the WG, then the document could be a BCP. I realize = this=20 was discussed before, and that this is a topic on which reasonable = folks=20 can differ. But I would like to see some discussion. The "downside" i have heard of this choice is that other similar=20 documents have taken a long time to finish. If changing the status = will=20 increase the time significantly, then that would be a bad outcome. But I don't see why that is so. Either we intend other folks to = follow=20 the document, or we don't. If we expect folks to follow it, then we=20 should be clear about that. If we don't, then the wording should be=20 much weaker, and I doubt it is worth the effort. Yours, Joel M. Halpern _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -------------------------------------------------------------------------= ----- No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.339 / Virus Database: 270.12.35/2123 - Release Date: = 05/19/09 17:59:00 ------=_NextPart_000_0F79_01C9D95E.F01F8300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Well, when we did a similar thing for SMI (now = RFC4181), it=20 DID take a looooong time.
We in fact took an I-D that we used for a while as = MIB doctors=20 to see how well it
was written and if it was workable.
 
So doing an informational, with the intention to do = a bis as=20 BCP in a year (after
we gain experience), or with the intention to just = advance it=20 to BCP if we find
no problems would be the quickest approach (I would = think). We=20 could even make
an introductuion section explains why it starts as=20 informational and that we plan
to make it (or its successor) a BCP in a year or 2 = years after=20 we gain more
experience.
 
my 2 cents.
Bert
----- Original Message -----
From:=20 Joel M.=20 Halpern
Sent: Wednesday, May 20, 2009 = 3:18=20 PM
Subject: [netmod] Intended = status of the=20 yang-usage draft?

After reading draft-ietf-netmod-yang-usage-00.txt, I = really=20 would like
to see that published along with the base Yang draft = (or, to be=20
realistic, I suppose as soon thereafter as possible.)

But I = got=20 confused when I looked at the charter for the status of the=20
document.
The draft is clearly intended to tell other groups = (and this=20 group
itself) how modules are supposed to be written.  Unless = there=20 is a very
good reason to do otherwise, one would expect module = writers to=20 comply
with the document.
That is about as good a definition of = how we=20 use BCP documents as there
really is.  (Like "RFC" itself, = the=20 acronym expansion for "BCP" is
somewhat misleading.  We have=20 published many BCPs on new things.)

Publishing the document as=20 Informational does not seem likely to
communicate the desired = impact to=20 other communities.

After talking with other folks, I was told = that if=20 there was a clear
consensus from the WG, then the document could = be a=20 BCP.  I realize this
was discussed before, and that this is a = topic=20 on which reasonable folks
can differ.  But I would like to = see some=20 discussion.
The "downside" i have heard of this choice is that = other=20 similar
documents have taken a long time to finish.  If = changing the=20 status will
increase the time significantly, then that would be a = bad=20 outcome.

But I don't see why that is so.  Either we intend = other=20 folks to follow
the document, or we don't.  If we expect = folks to=20 follow it, then we
should be clear about that.  If we don't, = then the=20 wording should be
much weaker, and I doubt it is worth the=20 effort.

Yours,
Joel M.=20 Halpern
_______________________________________________
netmod = mailing=20 list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod


No virus found in this incoming message.
Checked by AVG = - www.avg.com
Version: 8.5.339 / = Virus=20 Database: 270.12.35/2123 - Release Date: 05/19/09=20 17:59:00
------=_NextPart_000_0F79_01C9D95E.F01F8300-- From dromasca@avaya.com Wed May 20 06:45: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 D7C013A6D59 for ; Wed, 20 May 2009 06:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 Ec3ZLewjvBSx for ; Wed, 20 May 2009 06:45:15 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 8B1FC3A6C92 for ; Wed, 20 May 2009 06:45:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,221,1241409600"; d="scan'208";a="161900126" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 20 May 2009 09:46:52 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 May 2009 09:46:52 -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: Wed, 20 May 2009 15:46:55 +0200 Message-ID: In-Reply-To: <4A140329.5040302@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Intended status of the yang-usage draft? Thread-Index: AcnZTX4P3k7iArEyR7aerpeUHOtEfQAAiHeQ References: <4A140329.5040302@joelhalpern.com> From: "Romascanu, Dan (Dan)" To: "Joel M. Halpern" , "NETMOD Working Group" Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 13:45:16 -0000 Joel, > After talking with other folks, I was told that if there was=20 > a clear consensus from the WG, then the document could be a=20 > BCP This does not seem to be the case. My reading at the meeting in SF was that there is no clear consensus. We know we should get sooner or later to a BCP but we are not sure whether to jump directly into this with a new modeling data language.=20 Then the WG chairs proposed a rechartering with this document as Informational=20 http://www.ietf.org/mail-archive/web/netmod/current/msg02330.html As no comments were received the chairs concluded Informational as consensus and this is how the item was added to the list of deliverables in the charter. =20 As a contributor, I support doing this as Informational first. I believe it is important to have this document together or as close as possible to the release of YANG, so that the guidelines for editing and checking YANG modules are a public reference. I do not believe that with almost zero experience in editing and zero experience in reviewing we have enough information to reach consensus at a BCP level on what is believed to be the best way to perform some edits or reviews of YANG modules or on the corresponding IETF process functions (I am paraphrasing from RFC 2026 - section 5).=20 I also basing my opinion on the similar experience in OPS with SNMP, RADIUS, or DIAMETER where BCP documents appeared many years after the protocol was approved and it took other years of debates to fine-tune the text of the RFC. Some are actually still work-in-progress. I do not want the same thing to happen with YANG. I prefer in this case running code at rougher Informational consensus level to be available and tested sooner and do the BCP later.=20 This being my contributor position, as an AD I would not block the option of doing a BCP if I am proved that my opinion is in a clear minority by the rest of the WG. Dan > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, May 20, 2009 4:19 PM > To: NETMOD Working Group > Subject: [netmod] Intended status of the yang-usage draft? >=20 > After reading draft-ietf-netmod-yang-usage-00.txt, I really=20 > would like to see that published along with the base Yang=20 > draft (or, to be realistic, I suppose as soon thereafter as possible.) >=20 > But I got confused when I looked at the charter for the=20 > status of the document. > The draft is clearly intended to tell other groups (and this group > itself) how modules are supposed to be written. Unless there=20 > is a very good reason to do otherwise, one would expect=20 > module writers to comply with the document. > That is about as good a definition of how we use BCP=20 > documents as there really is. (Like "RFC" itself, the=20 > acronym expansion for "BCP" is somewhat misleading. We have=20 > published many BCPs on new things.) >=20 > Publishing the document as Informational does not seem likely=20 > to communicate the desired impact to other communities. >=20 > After talking with other folks, I was told that if there was=20 > a clear consensus from the WG, then the document could be a=20 > BCP. I realize this was discussed before, and that this is a=20 > topic on which reasonable folks can differ. But I would like=20 > to see some discussion. > The "downside" i have heard of this choice is that other=20 > similar documents have taken a long time to finish. If=20 > changing the status will increase the time significantly,=20 > then that would be a bad outcome. >=20 > But I don't see why that is so. Either we intend other folks=20 > to follow the document, or we don't. If we expect folks to=20 > follow it, then we should be clear about that. If we don't,=20 > then the wording should be much weaker, and I doubt it is=20 > worth the effort. >=20 > Yours, > Joel M. Halpern > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From jmh@joelhalpern.com Wed May 20 07:11: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 368463A6C30 for ; Wed, 20 May 2009 07:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 bTJivhpqSATt for ; Wed, 20 May 2009 07:11:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3D3EF3A6B5A for ; Wed, 20 May 2009 07:11:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D655B430240 for ; Wed, 20 May 2009 07:13:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-141.clppva.btas.verizon.net [71.161.52.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 22516430264 for ; Wed, 20 May 2009 07:13:14 -0700 (PDT) Message-ID: <4A140FF8.1040103@joelhalpern.com> Date: Wed, 20 May 2009 10:13:12 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group References: <4A140329.5040302@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 14:11:38 -0000 I must be misssing something. Yes, it took a long time to write some of the earlier documents. But, when those documents were being drafted folks treated them as "ideas to consider." Other WGs were only expected to abide by them when they were completed. As I understand it, we are expecting other WGs to abide by this document when it is published. It seems to me that if that is so, then we are publishing a BCP, whether we call it that or not. The alternative is to slap a big warning on the front of the document that says "we are not sure, but we think this is good advice. We use MUST language only to keep clear what kinds of advice we are giving. Use at your own risk." Yours, Joel M. Halpern Romascanu, Dan (Dan) wrote: > Joel, > >> After talking with other folks, I was told that if there was >> a clear consensus from the WG, then the document could be a >> BCP > > This does not seem to be the case. My reading at the meeting in SF was > that there is no clear consensus. We know we should get sooner or later > to a BCP but we are not sure whether to jump directly into this with a > new modeling data language. > > Then the WG chairs proposed a rechartering with this document as > Informational > > http://www.ietf.org/mail-archive/web/netmod/current/msg02330.html > > As no comments were received the chairs concluded Informational as > consensus and this is how the item was added to the list of deliverables > in the charter. > > As a contributor, I support doing this as Informational first. I believe > it is important to have this document together or as close as possible > to the release of YANG, so that the guidelines for editing and checking > YANG modules are a public reference. I do not believe that with almost > zero experience in editing and zero experience in reviewing we have > enough information to reach consensus at a BCP level on what is believed > to be the best way to perform some edits or reviews of YANG modules or > on the corresponding IETF process functions (I am paraphrasing from RFC > 2026 - section 5). > > I also basing my opinion on the similar experience in OPS with SNMP, > RADIUS, or DIAMETER where BCP documents appeared many years after the > protocol was approved and it took other years of debates to fine-tune > the text of the RFC. Some are actually still work-in-progress. I do not > want the same thing to happen with YANG. I prefer in this case running > code at rougher Informational consensus level to be available and tested > sooner and do the BCP later. > > This being my contributor position, as an AD I would not block the > option of doing a BCP if I am proved that my opinion is in a clear > minority by the rest of the WG. > > Dan > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, May 20, 2009 4:19 PM >> To: NETMOD Working Group >> Subject: [netmod] Intended status of the yang-usage draft? >> >> After reading draft-ietf-netmod-yang-usage-00.txt, I really >> would like to see that published along with the base Yang >> draft (or, to be realistic, I suppose as soon thereafter as possible.) >> >> But I got confused when I looked at the charter for the >> status of the document. >> The draft is clearly intended to tell other groups (and this group >> itself) how modules are supposed to be written. Unless there >> is a very good reason to do otherwise, one would expect >> module writers to comply with the document. >> That is about as good a definition of how we use BCP >> documents as there really is. (Like "RFC" itself, the >> acronym expansion for "BCP" is somewhat misleading. We have >> published many BCPs on new things.) >> >> Publishing the document as Informational does not seem likely >> to communicate the desired impact to other communities. >> >> After talking with other folks, I was told that if there was >> a clear consensus from the WG, then the document could be a >> BCP. I realize this was discussed before, and that this is a >> topic on which reasonable folks can differ. But I would like >> to see some discussion. >> The "downside" i have heard of this choice is that other >> similar documents have taken a long time to finish. If >> changing the status will increase the time significantly, >> then that would be a bad outcome. >> >> But I don't see why that is so. Either we intend other folks >> to follow the document, or we don't. If we expect folks to >> follow it, then we should be clear about that. If we don't, >> then the wording should be much weaker, and I doubt it is >> worth the effort. >> >> Yours, >> Joel M. Halpern >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From dromasca@avaya.com Wed May 20 07:33: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 8FFF63A693A for ; Wed, 20 May 2009 07:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 JJnktUy3MsNq for ; Wed, 20 May 2009 07:33:01 -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 D91D73A6822 for ; Wed, 20 May 2009 07:33:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,221,1241409600"; d="scan'208";a="146334262" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 May 2009 10:34:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 May 2009 10:34:34 -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: Wed, 20 May 2009 16:34:36 +0200 Message-ID: In-Reply-To: <4A140FF8.1040103@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Intended status of the yang-usage draft? Thread-Index: AcnZVSFBCjX/0WB7TDmlFv0HCYo3MQAAnsHw References: <4A140329.5040302@joelhalpern.com> <4A140FF8.1040103@joelhalpern.com> From: "Romascanu, Dan (Dan)" To: "Joel M. Halpern" , "NETMOD Working Group" Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 14:33:02 -0000 It did not take that much time to write the documents as it took in debating some of the painful details. I believe that this risks to be the case here as well with almost no experience in writing YANG modules and zero experience in reviewing. I think it is better to present this as what it is - a proposal for code that has informational status at this point in time, that we recommend other WGs to follow but we shall not block approval if they do not follow. And one or two years later we shall come with the BCP code based on the accumulated experience.=20 Dan (speaking as contributor) =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, May 20, 2009 5:13 PM > To: NETMOD Working Group > Subject: Re: [netmod] Intended status of the yang-usage draft? >=20 > I must be misssing something. > Yes, it took a long time to write some of the earlier documents. > But, when those documents were being drafted folks treated=20 > them as "ideas to consider." Other WGs were only expected to=20 > abide by them when they were completed. > As I understand it, we are expecting other WGs to abide by=20 > this document when it is published. >=20 > It seems to me that if that is so, then we are publishing a=20 > BCP, whether we call it that or not. >=20 > The alternative is to slap a big warning on the front of the=20 > document that says "we are not sure, but we think this is=20 > good advice. We use MUST language only to keep clear what=20 > kinds of advice we are giving.=20 > Use at your own risk." >=20 > Yours, > Joel M. Halpern >=20 > Romascanu, Dan (Dan) wrote: > > Joel, > >=20 > >> After talking with other folks, I was told that if there=20 > was a clear=20 > >> consensus from the WG, then the document could be a BCP > >=20 > > This does not seem to be the case. My reading at the=20 > meeting in SF was=20 > > that there is no clear consensus. We know we should get sooner or=20 > > later to a BCP but we are not sure whether to jump directly=20 > into this=20 > > with a new modeling data language. > >=20 > > Then the WG chairs proposed a rechartering with this document as=20 > > Informational > >=20 > > http://www.ietf.org/mail-archive/web/netmod/current/msg02330.html > >=20 > > As no comments were received the chairs concluded Informational as=20 > > consensus and this is how the item was added to the list of=20 > > deliverables in the charter. > >=20 > > As a contributor, I support doing this as Informational first. I=20 > > believe it is important to have this document together or=20 > as close as=20 > > possible to the release of YANG, so that the guidelines for editing=20 > > and checking YANG modules are a public reference. I do not believe=20 > > that with almost zero experience in editing and zero experience in=20 > > reviewing we have enough information to reach consensus at=20 > a BCP level=20 > > on what is believed to be the best way to perform some edits or=20 > > reviews of YANG modules or on the corresponding IETF=20 > process functions=20 > > (I am paraphrasing from RFC > > 2026 - section 5).=20 > >=20 > > I also basing my opinion on the similar experience in OPS=20 > with SNMP,=20 > > RADIUS, or DIAMETER where BCP documents appeared many years=20 > after the=20 > > protocol was approved and it took other years of debates to=20 > fine-tune=20 > > the text of the RFC. Some are actually still work-in-progress. I do=20 > > not want the same thing to happen with YANG. I prefer in this case=20 > > running code at rougher Informational consensus level to be=20 > available=20 > > and tested sooner and do the BCP later. > >=20 > > This being my contributor position, as an AD I would not block the=20 > > option of doing a BCP if I am proved that my opinion is in a clear=20 > > minority by the rest of the WG. > >=20 > > Dan > >=20 > >=20 > >> -----Original Message----- > >> From: netmod-bounces@ietf.org > >> [mailto:netmod-bounces@ietf.org] On Behalf Of Joel M. Halpern > >> Sent: Wednesday, May 20, 2009 4:19 PM > >> To: NETMOD Working Group > >> Subject: [netmod] Intended status of the yang-usage draft? > >> > >> After reading draft-ietf-netmod-yang-usage-00.txt, I really would=20 > >> like to see that published along with the base Yang draft=20 > (or, to be=20 > >> realistic, I suppose as soon thereafter as possible.) > >> > >> But I got confused when I looked at the charter for the=20 > status of the=20 > >> document. > >> The draft is clearly intended to tell other groups (and this group > >> itself) how modules are supposed to be written. Unless there is a=20 > >> very good reason to do otherwise, one would expect module=20 > writers to=20 > >> comply with the document. > >> That is about as good a definition of how we use BCP documents as=20 > >> there really is. (Like "RFC" itself, the acronym=20 > expansion for "BCP"=20 > >> is somewhat misleading. We have published many BCPs on=20 > new things.) > >> > >> Publishing the document as Informational does not seem likely to=20 > >> communicate the desired impact to other communities. > >> > >> After talking with other folks, I was told that if there=20 > was a clear=20 > >> consensus from the WG, then the document could be a BCP. =20 > I realize=20 > >> this was discussed before, and that this is a topic on which=20 > >> reasonable folks can differ. But I would like to see some=20 > >> discussion. > >> The "downside" i have heard of this choice is that other similar=20 > >> documents have taken a long time to finish. If changing=20 > the status=20 > >> will increase the time significantly, then that would be a bad=20 > >> outcome. > >> > >> But I don't see why that is so. Either we intend other folks to=20 > >> follow the document, or we don't. If we expect folks to=20 > follow it,=20 > >> then we should be clear about that. If we don't, then the wording=20 > >> should be much weaker, and I doubt it is worth the effort. > >> > >> Yours, > >> Joel M. Halpern > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From wes@hardakers.net Wed May 20 07:39: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 9D41A28C10E for ; Wed, 20 May 2009 07:39:18 -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 OoE5wH7BIEPF for ; Wed, 20 May 2009 07:39:18 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id CB88D28C0DF for ; Wed, 20 May 2009 07:39:17 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id D879F981C9 for ; Wed, 20 May 2009 07:40:47 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id C377D399B28 for ; Wed, 20 May 2009 07:40:47 -0700 (PDT) From: Wes Hardaker To: netmod@ietf.org Organization: Sparta Date: Wed, 20 May 2009 07:40:47 -0700 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 X-Mailman-Approved-At: Wed, 20 May 2009 07:40:13 -0700 Subject: [netmod] WG LC 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: Wed, 20 May 2009 14:39:18 -0000 I'm a bit late with my LC comments (mostly in part because 2 weeks to review such a huge document is quite an undertaking when other work requires my attention too). In short, I think the document is quite well written (well above the IETF average), so congratulations on and thank you for that! Since WGLC ended last Friday and I'm writing this on Wednesday, I'm not going to type up my misc comments (none of them critical) unless they're still desired. Let me know if you still want them, and I'll type up what I have. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From jmh@joelhalpern.com Wed May 20 07:46: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 C4BC43A6C5A for ; Wed, 20 May 2009 07:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 MnKfiufcdIf6 for ; Wed, 20 May 2009 07:46:17 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9E1723A6E7E for ; Wed, 20 May 2009 07:45:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 32525430504 for ; Wed, 20 May 2009 07:46:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-141.clppva.btas.verizon.net [71.161.52.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 158A3430081 for ; Wed, 20 May 2009 07:46:14 -0700 (PDT) Message-ID: <4A1417B4.4060007@joelhalpern.com> Date: Wed, 20 May 2009 10:46:12 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group References: <4A140329.5040302@joelhalpern.com> <4A140FF8.1040103@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 14:46:18 -0000 if the intended or expected usage is as Dan describes below, then somewhat more text in the introduction of the document is needed to provide context for the use of MUST and SHOULD in the document. I actually think the "advice" in the document is clear enough and simple enough that it should have stronger standing than Dan describes. Yes, we could argue extensively about additional advice we can give. But if we keep it simple (as the document does currently) we can make a much stronger statement. Yours, Joel Romascanu, Dan (Dan) wrote: > It did not take that much time to write the documents as it took in > debating some of the painful details. I believe that this risks to be > the case here as well with almost no experience in writing YANG modules > and zero experience in reviewing. I think it is better to present this > as what it is - a proposal for code that has informational status at > this point in time, that we recommend other WGs to follow but we shall > not block approval if they do not follow. And one or two years later we > shall come with the BCP code based on the accumulated experience. > > Dan > > (speaking as contributor) > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, May 20, 2009 5:13 PM >> To: NETMOD Working Group >> Subject: Re: [netmod] Intended status of the yang-usage draft? >> >> I must be misssing something. >> Yes, it took a long time to write some of the earlier documents. >> But, when those documents were being drafted folks treated >> them as "ideas to consider." Other WGs were only expected to >> abide by them when they were completed. >> As I understand it, we are expecting other WGs to abide by >> this document when it is published. >> >> It seems to me that if that is so, then we are publishing a >> BCP, whether we call it that or not. >> >> The alternative is to slap a big warning on the front of the >> document that says "we are not sure, but we think this is >> good advice. We use MUST language only to keep clear what >> kinds of advice we are giving. >> Use at your own risk." >> >> Yours, >> Joel M. Halpern >> >> Romascanu, Dan (Dan) wrote: >>> Joel, >>> >>>> After talking with other folks, I was told that if there >> was a clear >>>> consensus from the WG, then the document could be a BCP >>> This does not seem to be the case. My reading at the >> meeting in SF was >>> that there is no clear consensus. We know we should get sooner or >>> later to a BCP but we are not sure whether to jump directly >> into this >>> with a new modeling data language. >>> >>> Then the WG chairs proposed a rechartering with this document as >>> Informational >>> >>> http://www.ietf.org/mail-archive/web/netmod/current/msg02330.html >>> >>> As no comments were received the chairs concluded Informational as >>> consensus and this is how the item was added to the list of >>> deliverables in the charter. >>> >>> As a contributor, I support doing this as Informational first. I >>> believe it is important to have this document together or >> as close as >>> possible to the release of YANG, so that the guidelines for editing >>> and checking YANG modules are a public reference. I do not believe >>> that with almost zero experience in editing and zero experience in >>> reviewing we have enough information to reach consensus at >> a BCP level >>> on what is believed to be the best way to perform some edits or >>> reviews of YANG modules or on the corresponding IETF >> process functions >>> (I am paraphrasing from RFC >>> 2026 - section 5). >>> >>> I also basing my opinion on the similar experience in OPS >> with SNMP, >>> RADIUS, or DIAMETER where BCP documents appeared many years >> after the >>> protocol was approved and it took other years of debates to >> fine-tune >>> the text of the RFC. Some are actually still work-in-progress. I do >>> not want the same thing to happen with YANG. I prefer in this case >>> running code at rougher Informational consensus level to be >> available >>> and tested sooner and do the BCP later. >>> >>> This being my contributor position, as an AD I would not block the >>> option of doing a BCP if I am proved that my opinion is in a clear >>> minority by the rest of the WG. >>> >>> Dan >>> >>> >>>> -----Original Message----- >>>> From: netmod-bounces@ietf.org >>>> [mailto:netmod-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Wednesday, May 20, 2009 4:19 PM >>>> To: NETMOD Working Group >>>> Subject: [netmod] Intended status of the yang-usage draft? >>>> >>>> After reading draft-ietf-netmod-yang-usage-00.txt, I really would >>>> like to see that published along with the base Yang draft >> (or, to be >>>> realistic, I suppose as soon thereafter as possible.) >>>> >>>> But I got confused when I looked at the charter for the >> status of the >>>> document. >>>> The draft is clearly intended to tell other groups (and this group >>>> itself) how modules are supposed to be written. Unless there is a >>>> very good reason to do otherwise, one would expect module >> writers to >>>> comply with the document. >>>> That is about as good a definition of how we use BCP documents as >>>> there really is. (Like "RFC" itself, the acronym >> expansion for "BCP" >>>> is somewhat misleading. We have published many BCPs on >> new things.) >>>> Publishing the document as Informational does not seem likely to >>>> communicate the desired impact to other communities. >>>> >>>> After talking with other folks, I was told that if there >> was a clear >>>> consensus from the WG, then the document could be a BCP. >> I realize >>>> this was discussed before, and that this is a topic on which >>>> reasonable folks can differ. But I would like to see some >>>> discussion. >>>> The "downside" i have heard of this choice is that other similar >>>> documents have taken a long time to finish. If changing >> the status >>>> will increase the time significantly, then that would be a bad >>>> outcome. >>>> >>>> But I don't see why that is so. Either we intend other folks to >>>> follow the document, or we don't. If we expect folks to >> follow it, >>>> then we should be clear about that. If we don't, then the wording >>>> should be much weaker, and I doubt it is worth the effort. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From andy@netconfcentral.com Wed May 20 07:46: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 E7E0B3A6801 for ; Wed, 20 May 2009 07:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 rWEhSlEuCjYW for ; Wed, 20 May 2009 07:46:18 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id AA79028C38B for ; Wed, 20 May 2009 07:45:52 -0700 (PDT) Received: (qmail 87818 invoked from network); 20 May 2009 14:46:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 20 May 2009 14:46:36 -0000 X-YMail-OSG: UJGvAw4VM1mpGo0aB3N1sS4NQ8zno3YbUayUcMOTgGd2bpTboD3Hx.E3vZKWWa1UE4gfsueUMynFgnStxJdY3pm_9fH5.hg76.6NoJz.pWK0AgTedCnKppHAm7EV8Er5uEKAcYJrtq668tBzmW.CKItkYvXfqNUuqk86iNd61p0yOyIHEgZqqb1UJkmVzmRi3Bi3GLpn.znTFr5bb8bKxLiazF4g X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1417C9.1020909@netconfcentral.com> Date: Wed, 20 May 2009 07:46:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A140329.5040302@joelhalpern.com> <4A140FF8.1040103@joelhalpern.com> In-Reply-To: <4A140FF8.1040103@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 14:46:20 -0000 Joel M. Halpern wrote: > I must be misssing something. me too. I wrote this draft because the YANG standard is very weak wrt/ promoting inter-operability. A valid YANG module does not need to contain one word of documentation. Every single form of descriptive annotation is optional to use. It is not clear to me why agreement on the contents of this document will go faster if the resulting status is Informational instead of BCP. By the time RFC 4181 was written, there were so many bad practices and bad MIB modules in play, that it was a monster effort. Waiting 5 - 10 years to offer any guidance on the usage of YANG will produce the same result. We know enough about NM to make some decisions about how the IETF is going to use YANG. We know that YANG modules are going to be reviewed for RFC publication, and the reviewers are going to use some sort of review criteria. Removing all the RFC 2119 text (MUST, SHOULD, MAY) seems like a really bad idea. I do not see any point to publishing a guidelines draft that has watered down advice like "description strings are good. You might want to use them." Andy > Yes, it took a long time to write some of the earlier documents. > But, when those documents were being drafted folks treated them as > "ideas to consider." Other WGs were only expected to abide by them when > they were completed. > As I understand it, we are expecting other WGs to abide by this document > when it is published. > > It seems to me that if that is so, then we are publishing a BCP, whether > we call it that or not. > > The alternative is to slap a big warning on the front of the document > that says "we are not sure, but we think this is good advice. We use > MUST language only to keep clear what kinds of advice we are giving. Use > at your own risk." > > Yours, > Joel M. Halpern > > Romascanu, Dan (Dan) wrote: >> Joel, >> >>> After talking with other folks, I was told that if there was a clear >>> consensus from the WG, then the document could be a BCP >> >> This does not seem to be the case. My reading at the meeting in SF was >> that there is no clear consensus. We know we should get sooner or later >> to a BCP but we are not sure whether to jump directly into this with a >> new modeling data language. >> Then the WG chairs proposed a rechartering with this document as >> Informational >> http://www.ietf.org/mail-archive/web/netmod/current/msg02330.html >> >> As no comments were received the chairs concluded Informational as >> consensus and this is how the item was added to the list of deliverables >> in the charter. >> As a contributor, I support doing this as Informational first. I believe >> it is important to have this document together or as close as possible >> to the release of YANG, so that the guidelines for editing and checking >> YANG modules are a public reference. I do not believe that with almost >> zero experience in editing and zero experience in reviewing we have >> enough information to reach consensus at a BCP level on what is believed >> to be the best way to perform some edits or reviews of YANG modules or >> on the corresponding IETF process functions (I am paraphrasing from RFC >> 2026 - section 5). >> I also basing my opinion on the similar experience in OPS with SNMP, >> RADIUS, or DIAMETER where BCP documents appeared many years after the >> protocol was approved and it took other years of debates to fine-tune >> the text of the RFC. Some are actually still work-in-progress. I do not >> want the same thing to happen with YANG. I prefer in this case running >> code at rougher Informational consensus level to be available and tested >> sooner and do the BCP later. >> This being my contributor position, as an AD I would not block the >> option of doing a BCP if I am proved that my opinion is in a clear >> minority by the rest of the WG. >> >> Dan >> >> >>> -----Original Message----- >>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >>> Behalf Of Joel M. Halpern >>> Sent: Wednesday, May 20, 2009 4:19 PM >>> To: NETMOD Working Group >>> Subject: [netmod] Intended status of the yang-usage draft? >>> >>> After reading draft-ietf-netmod-yang-usage-00.txt, I really would >>> like to see that published along with the base Yang draft (or, to be >>> realistic, I suppose as soon thereafter as possible.) >>> >>> But I got confused when I looked at the charter for the status of the >>> document. >>> The draft is clearly intended to tell other groups (and this group >>> itself) how modules are supposed to be written. Unless there is a >>> very good reason to do otherwise, one would expect module writers to >>> comply with the document. >>> That is about as good a definition of how we use BCP documents as >>> there really is. (Like "RFC" itself, the acronym expansion for "BCP" >>> is somewhat misleading. We have published many BCPs on new things.) >>> >>> Publishing the document as Informational does not seem likely to >>> communicate the desired impact to other communities. >>> >>> After talking with other folks, I was told that if there was a clear >>> consensus from the WG, then the document could be a BCP. I realize >>> this was discussed before, and that this is a topic on which >>> reasonable folks can differ. But I would like to see some discussion. >>> The "downside" i have heard of this choice is that other similar >>> documents have taken a long time to finish. If changing the status >>> will increase the time significantly, then that would be a bad outcome. >>> >>> But I don't see why that is so. Either we intend other folks to >>> follow the document, or we don't. If we expect folks to follow it, >>> then we should be clear about that. If we don't, then the wording >>> should be much weaker, and I doubt it is worth the effort. >>> >>> Yours, >>> Joel M. Halpern >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From andy@netconfcentral.com Wed May 20 08:14: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 9CF4B3A6E7E for ; Wed, 20 May 2009 08:14:10 -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 Pgxn48eESieu for ; Wed, 20 May 2009 08:14: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 CC3803A6D49 for ; Wed, 20 May 2009 08:14:09 -0700 (PDT) Received: from [209.191.108.97] by n24.bullet.mail.mud.yahoo.com with NNFMP; 20 May 2009 15:15:45 -0000 Received: from [68.142.201.70] by t4.bullet.mud.yahoo.com with NNFMP; 20 May 2009 15:15:45 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 20 May 2009 15:15:45 -0000 X-Yahoo-Newman-Id: 441318.57427.bm@omp422.mail.mud.yahoo.com Received: (qmail 88166 invoked from network); 20 May 2009 15:15:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 20 May 2009 15:15:44 -0000 X-YMail-OSG: IOP8P7kVM1nn7_VXTfl997E7rHZ2GSKR4OmClbqYXyVFGAsuG2eDe0Q7vudT45yaAmSKzAvuskk5Z3f1N_GLYAUQIxnHKpMNDmaItli4Ij7nMtXgMG6IoeLVbqh9kuOou8lMa.ndUFkfl9WZLoi0J7AgbuLQWekWDEqyE2R8h8O4Lx9kXBkECy76LnYjsqrkN9llxgusNgIvOwSUmKPGEo6c7YMnkMNSE224.69qSBPt17qqtPhdsvrS0dZK6kDZmfZadZ.WpMq9KrM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A141E9E.6050507@netconfcentral.com> Date: Wed, 20 May 2009 08:15:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A140329.5040302@joelhalpern.com> <4A140FF8.1040103@joelhalpern.com> <4A1417B4.4060007@joelhalpern.com> In-Reply-To: <4A1417B4.4060007@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 15:14:10 -0000 Joel M. Halpern wrote: > if the intended or expected usage is as Dan describes below, then > somewhat more text in the introduction of the document is needed to > provide context for the use of MUST and SHOULD in the document. > I actually think the "advice" in the document is clear enough and simple > enough that it should have stronger standing than Dan describes. > Yes, we could argue extensively about additional advice we can give. But > if we keep it simple (as the document does currently) we can make a much > stronger statement. > What if there aren't any big debates over the content? I purposely avoided mentioning anything that I thought would lead to deadlock (like camelCase vs. cli-case, NP vs. P containers, augment, modules vs. submodules, etc.) There is a baked-in assumption that agreement on the details of this draft will take forever. That would be true if we tried to add a guideline for every possible detail (no matter how small) that anybody can possibly imagine. > Yours, > Joel Andy From mbj@tail-f.com Wed May 20 10:12: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 3F95A28C0E1 for ; Wed, 20 May 2009 10:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.186, 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 88xMtTuCbJCy for ; Wed, 20 May 2009 10:12:09 -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 6B84E3A6D1C for ; Wed, 20 May 2009 10:12:03 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 00CDF61600E; Wed, 20 May 2009 19:13:26 +0200 (CEST) Date: Wed, 20 May 2009 19:13:26 +0200 (CEST) Message-Id: <20090520.191326.45933567.mbj@tail-f.com> To: wes@hardakers.net From: Martin Bjorklund In-Reply-To: References: 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] WG LC 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: Wed, 20 May 2009 17:12:10 -0000 Hi Wes, Wes Hardaker wrote: > Since WGLC ended last Friday and I'm writing this on Wednesday, I'm > not going to type up my misc comments (none of them critical) unless > they're still desired. Let me know if you still want them, and I'll > type up what I have. I would very much like to get your comments, unless the chairs have another opinion. I'm still working through the list of other comments, and I haven't responded to all of them yet. /martin From andy@netconfcentral.com Wed May 20 10:43: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 613D23A6E19 for ; Wed, 20 May 2009 10:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.079, 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 9C-Y0mlmsUsD for ; Wed, 20 May 2009 10:43:38 -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 BC32F3A6D02 for ; Wed, 20 May 2009 10:43:38 -0700 (PDT) Received: (qmail 83707 invoked from network); 20 May 2009 17:45:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 20 May 2009 17:45:13 -0000 X-YMail-OSG: qy_M0GUVM1nvh7Aq84iy7_0ZA8ib98fjhzqV3VF.cpHP4O40awR4f3O6PjoCQm836EglHWT7i4lEqEddy6IeUel7kmltf1BGN4yn3PR_5FGmNIBQUcvff1RKvjH6Vj2B8TVpicYyrBKawcfk1evnROERy_TvZQ5bAZmukMnOnGc8YpIbYheBUSX2iXRd62vsRyd6.D8O58QMAmG26qwlK.PVBXK4ChaZEdQNvinsMiBaBsDhKwGJqdsMHzc.9dWNPCUovP.swXhOvPLPEdP0KI9.1aMoKv2W3PNil27tgrD8wri_bP_vtkBVOqmTEp4RVBfOebA830Q_9akMM7Rw5Y9XBs7W5ebjaj6t53Vq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1441A7.9020108@netconfcentral.com> Date: Wed, 20 May 2009 10:45:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090520.191326.45933567.mbj@tail-f.com> In-Reply-To: <20090520.191326.45933567.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: wes@hardakers.net, netmod@ietf.org Subject: Re: [netmod] WG LC 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: Wed, 20 May 2009 17:43:39 -0000 Martin Bjorklund wrote: > Hi Wes, > > Wes Hardaker wrote: >> Since WGLC ended last Friday and I'm writing this on Wednesday, I'm >> not going to type up my misc comments (none of them critical) unless >> they're still desired. Let me know if you still want them, and I'll >> type up what I have. > > I would very much like to get your comments, unless the chairs have > another opinion. I'm still working through the list of other > comments, and I haven't responded to all of them yet. > me too. IMO, WGLC deadlines are not that important because you can just raise the same comments in IETF Last Call anyway. Any problems with the draft should be identified and resolved ASAP (not ALAP ;-). > > /martin Andy From david.kessens@nsn.com Wed May 20 12:03: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 714A33A69E1 for ; Wed, 20 May 2009 12:03: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 mJBOJCDD4wty for ; Wed, 20 May 2009 12:03:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 1E03C28C394 for ; Wed, 20 May 2009 12:01:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n4KJ2efS013111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 May 2009 21:02:40 +0200 Received: from localhost.localdomain ([10.138.48.152]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n4KJ2dBu028784; Wed, 20 May 2009 21:02:40 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id n4KJ2xaQ018916; Wed, 20 May 2009 12:02:59 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id n4KJ2wYT018914; Wed, 20 May 2009 12:02:58 -0700 Date: Wed, 20 May 2009 12:02:58 -0700 From: David Kessens To: "Joel M. Halpern" Message-ID: <20090520190258.GJ6459@nsn.com> References: <4A140329.5040302@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A140329.5040302@joelhalpern.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 19:03:16 -0000 Joel, On Wed, May 20, 2009 at 09:18:33AM -0400, Joel M. Halpern wrote: > After reading draft-ietf-netmod-yang-usage-00.txt, I really would like > to see that published along with the base Yang draft (or, to be > realistic, I suppose as soon thereafter as possible.) As a working group chair, I prefer that we first focus our attention on the document itself as opposed to administrative matters like the precise status of the document. It is pretty clear that there is something to be said for either informational or bcp status but when we adopted the document the decision was made to go for informational. I don't believe it is very productive to reopen the discussion on the status of this document until we are a bit closer to the finish line and we all have a better idea on how strong the consensus behind this document is. There is nothing in the way for proposing a status change to our Area Director later down the line when we are getting closer to submitting this document to the IESG and lets consider that at that time. David Kessens --- From david.kessens@nsn.com Wed May 20 12:06: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 1E08528C3CB for ; Wed, 20 May 2009 12:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 RpHHXP2xRWzw for ; Wed, 20 May 2009 12:06:19 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id DEBDA28C394 for ; Wed, 20 May 2009 12:06:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n4KJ7g9B013899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 May 2009 21:07:42 +0200 Received: from localhost.localdomain ([10.138.48.152]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n4KJ7e2S019081; Wed, 20 May 2009 21:07:41 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id n4KJ81oQ018950; Wed, 20 May 2009 12:08:01 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id n4KJ80Li018949; Wed, 20 May 2009 12:08:00 -0700 Date: Wed, 20 May 2009 12:08:00 -0700 From: David Kessens To: Andy Bierman Message-ID: <20090520190800.GK6459@nsn.com> References: <20090520.191326.45933567.mbj@tail-f.com> <4A1441A7.9020108@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1441A7.9020108@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: wes@hardakers.net, netmod@ietf.org Subject: Re: [netmod] WG LC 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: Wed, 20 May 2009 19:06:20 -0000 Andy, On Wed, May 20, 2009 at 10:45:11AM -0700, Andy Bierman wrote: > > IMO, WGLC deadlines are not that important because you > can just raise the same comments in IETF Last Call anyway. While you can do that, you run the risk that the working group will tell you that you have had your chance as an active participant of the working group. As for this particular last call, it was clear that a revision is necessary and comments that the last call period was a bit short for such a long document did not go unnoticed so I don't see any reason why we should not welcome any comments at this point. > Any problems with the draft should be identified and > resolved ASAP (not ALAP ;-). And with this I fully agree ;-). David Kessens --- From wjhns1@hardakers.net Wed May 20 12:32: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 67EFB3A6B5A for ; Wed, 20 May 2009 12:32:52 -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 D3tbfWK-4ruO for ; Wed, 20 May 2009 12:32:51 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 9E01F3A68A8 for ; Wed, 20 May 2009 12:32:51 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id D7BAA98179; Wed, 20 May 2009 12:34:28 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 7BC0439A344; Wed, 20 May 2009 12:34:28 -0700 (PDT) From: Wes Hardaker To: David Kessens Organization: Sparta References: <20090520.191326.45933567.mbj@tail-f.com> <4A1441A7.9020108@netconfcentral.com> <20090520190800.GK6459@nsn.com> Date: Wed, 20 May 2009 12:34:27 -0700 In-Reply-To: <20090520190800.GK6459@nsn.com> (David Kessens's message of "Wed, 20 May 2009 12:08:00 -0700") 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] WG LC 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: Wed, 20 May 2009 19:32:52 -0000 >>>>> On Wed, 20 May 2009 12:08:00 -0700, David Kessens said: DK> While you can do that, you run the risk that the working group will DK> tell you that you have had your chance as an active participant of the DK> working group. And that's what I was worried about :-) I'll go type them up though now... -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From andy@netconfcentral.com Wed May 20 12:40: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 17E6D28C196 for ; Wed, 20 May 2009 12:40:29 -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 RvteTn-a42lT for ; Wed, 20 May 2009 12:40:28 -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 58B2928C0EC for ; Wed, 20 May 2009 12:40:28 -0700 (PDT) Received: (qmail 22290 invoked from network); 20 May 2009 19:42:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 20 May 2009 19:42:02 -0000 X-YMail-OSG: 1hnbNecVM1nDwZ6XxIp1zQndVavjRaUdW9GQuc7iedIWb2IOLe7AvxbZ_H3hOA_1.jMDpIbF8VBFRUTLiKn_zcbRw5A5b6teHYXB.CNTYodOXhmk5adc6nGjCimu6VEc4bJ3iKujSnFF5OEtXmeC7YQBo5QpJLhjrGkb..ARFe_kNrCfTLXkv9.nFxMHe0E797xr40w7pAuwFaCi2f51uMttyi_U9rLkGz0evdnU4owYUircwjswU1nrUN.u8bt081d2Q6IFtRpGNAs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A145D09.9050009@netconfcentral.com> Date: Wed, 20 May 2009 12:42:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Kessens References: <4A140329.5040302@joelhalpern.com> <20090520190258.GJ6459@nsn.com> In-Reply-To: <20090520190258.GJ6459@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 19:40:29 -0000 David Kessens wrote: > Joel, > > On Wed, May 20, 2009 at 09:18:33AM -0400, Joel M. Halpern wrote: >> After reading draft-ietf-netmod-yang-usage-00.txt, I really would like >> to see that published along with the base Yang draft (or, to be >> realistic, I suppose as soon thereafter as possible.) > > As a working group chair, I prefer that we first focus our attention > on the document itself as opposed to administrative matters like the > precise status of the document. It is pretty clear that there is > something to be said for either informational or bcp status but when > we adopted the document the decision was made to go for informational. > > I don't believe it is very productive to reopen the discussion on the > status of this document until we are a bit closer to the finish line > and we all have a better idea on how strong the consensus behind this > document is. > > There is nothing in the way for proposing a status change to our Area > Director later down the line when we are getting closer to submitting > this document to the IESG and lets consider that at that time. > What about the concern Joel raised wrt/ RFC 2119 text? If the intended status (BCP vs. Informational) has an impact on the content of the document, then it matters. I did not object to Informational because I thought it would not impact the content. The obvious issue is whether this paragraph can appear in Informational RFCs: 2.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. So, does the intended status impact the content or not? I suppose I should look it up myself, but maybe somebody on the list already knows the relevant RFC section with the answer. My re-read of RFC 2119 seems to support Joel's concern that this RFC applies to standards-track documents, because non-standards-track documents are not explicitly mentioned. > David Kessens Andy From mbj@tail-f.com Wed May 20 13:40: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 CF61F3A6CE1 for ; Wed, 20 May 2009 13:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.185, 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 ckL31+3ALjQ5 for ; Wed, 20 May 2009 13:40:15 -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 C70A93A6ABE for ; Wed, 20 May 2009 13:40: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 2417A616018; Wed, 20 May 2009 22:41:47 +0200 (CEST) Date: Wed, 20 May 2009 22:41:46 +0200 (CEST) Message-Id: <20090520.224146.220136501.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242289874.6404.7.camel@missotis> References: <1242289874.6404.7.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] review of draft-ietf-netmod-yang-05 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, 20 May 2009 20:40:16 -0000 Hi, Ladislav Lhotka wrote: > here is my review of the YANG draft. Apart from the comments in the mail > body below, I am also attaching a patch file with corrections of typos > and my suggestions for minor formulation changes. Thanks, I applied most of them. > - The name of the game: "YANG" is used for both the C-like syntax and > semantics but "YIN" only for syntax. Perhaps it would be more > appropriate to drop "YIN" and use e.g., "standard syntax" and "XML > syntax" where necessary. Cf. Sec. 5.6.5: 'Note that the format is > "YANG", even if the YIN syntax is used.' I think the names are pretty well-known by now and already used by others, so I'd be hesitant to change this now. > - Section 3 defines terms "data node" and "schema node" but quite > often the text uses just "node" and it is not immediately clear > which one of the two it is. I will have a look at this. > - The word "definition" is used in two meanings: (i) definition of > data nodes and (ii) definitions of groupings, typedefs and > features. For example, Sec. 7.1.5 says: 'The "import" statement > makes definitions from one module available inside another module or > submodule.' and it means (ii). Suggestion: use "data node > definition" for (i). Actually, it refers to both meanings. E.g. you need to import a module in order to augment it. > - Sec. 3.1: Fourth item is missing for "anyxml" node. Fixed. > - Sec. 5.1.1: The spec doesn't ensure that both parties in a NETCONF > session always use the same module revisions This is by design. We cannot assume that all clients always have the latest version of a particular module. > or that any mismatch > is immediately detected, if the revision is not specified. What is > the meaning of "current revision" and "available at the time"? An > agent may be limited to locally stored modules, so its notion of > "current" may be different. Resulting problems are hard to detect > unless the exact revision dates are always used in both capability > advertisements and imports. The full sentence is: When a module is written, it uses the current revisions of other modules, based on what is available at the time. This is design time, not run-time. The text argues for why import by revision is needed. > - Sec. 5.1.2: is not the only NETCONF element carrying data > model XML data. Others are or . I added as well. Nothing in 4741 encodes data model XML directly under rpc-reply. > - Sec. 5.2: What are "YANG compilers"? Suggestion: "YANG software" I changed this to "YANG tools". > - Sec 5.3: XML namespace URIs are globally unique, so the probability > of collisions must be zero. Last sentence should be: "Namespace URI > MUST be chosen so that it cannot collide with standard ...". Fixed. > - Sec. 5.6.1: Instead of suggesting religious attitudes of > implementors, this section should state what basic behavior means: > all features that do not depend on a feature must be implemented. I suggest we remove the last part of the last sentence, to get: The strength of YANG lies in the strength of this contract. > - Sec. 5.6.4: > * The ABNF is too lax (this has already been discussed in the ML). Fixed (as discussed in the other thread). > * The module names and their namespaces are somewhat redundant. I'd > suggest to resolve YANG modules using only namespace URI - > collisions in module names then wouldn't be a problem and "module" > parameter of capability strings can be removed. If it is not there, we would have to use the URI for the deviation parameter. The module name is easier to work with. > * How can the capability string for module A declare a feature which > module A imports from module B (another namespace)? It cannot. The device must advertise module B and its features. > - Sec. 5.6.4.3: Is it necessary to advertise the module with > deviations (my-devs) twice? It is advertised once. The first is for a module called 'syslog'. > - Sec. 6.1.3, para 5: "... two strings are concatenated into one > quoted string, ...". Does "quoted" mean single- or double-quoted? > Example: "Here's " + 'the problem.\n'. Suggestion: State that all > escaped characters are substituted before concatenation and then > the strings are joined into one (value-space) string. Would this work: If a quoted string is followed by a plus character ("+"), followed by another quoted string, the two strings are concatenated into one string, allowing multiple concatenations to build one string. Whitespace trimming and substition of backslash-escaped characters in double quoted strings is done before concatenation. (this paragraph would be moved after the backslash-special character text). > - Sec. 7.1.3: The namespace is used not only for XML elements but also > for extensions and features. Extensions and features never show up in the XML. The namespace does not affect them. > - Sec. 7.1.5: It is not specified which revision is used if the > "revision-date" substatement is missing (related to Sec. 5.1.1). I will get back on this. If anyone has a suggestion for text, please let me know. > - Sec. 7.1.6, para 1: This should be added: "Submodules are only > allowed to import other submodules if both importing and imported > submodules belong to the same module." Yes, but s/import/include. I added: Submodules are only allowed to include other submodules belonging to the same module. > - Sec. 7.5.3: > * In the description of the evaluation context, the second item is: > "The accessible tree is made up of all nodes in the data tree, and > ..." However, subsequent items say that the tree actually depends > on the content type (config data, RPC, notification). The idea is that the first sentence says that all nodes including default values are there, and the next list specifies which nodes are there, depending on context. If this is unclear, could you suggest a change? > * "... any XPath comparisons are done on the canonical value." Does > it mean that 'foo < 5' is always false is foo is decimal64? No, XPath comparison is NOT modified (of course). It just specifies what the value passed to the XPath expression will be. > - Sec. 7.11, last para: > * "References from inside the grouping are relative to the scope in > which the grouping is defined, not where it is used." I believe > this should be "Identifiers appearing inside the grouping are > resolved relative to the scope in which ...". Fixed. > * In don't understand the last sentence "For extensions, ...". It means that if you have an extention in a grouping, it applies to the grouping itself, the extension statement is not expanded to the uses. I have fixed the typo "use node" --> "uses node". > - Sec. 7.13.2, para 2: This is not true if the mandatory leaf is > inside a P-container. > > - Sec. 7.13.3, para 2: Same as in 7.13.2 > > - Sec. 7.14, para 3: Same as in 7.13.2 > > - Sec. 7.14, para 4: s/NETCONF server/NETCONF client/ (?) Fixed. > > - Sec. 7.15: The shorthand notation for a case cannot be used when > augmenting a choice? Yes, it should be allowed. OLD: If the target node is a choice node, the "case" statement can be used within the "augment" statement. NEW: If the target node is a choice node, the "case" statement, or a case shorthand statement (see ^case^) can be used within the "augment" statement. > - Sec 9., para 4: The lexicographic representation is also used for > specifying ranges of numeric types. Fixed. > - Sec. 9.2.1: Are octal and hexadecimal values allowed in 'range' > restrictions? No. Just for defaults. > - Sec. 9.4.1: Encodings that every implementation must support should > be specified here, for example UTF-8 or UTF-16. But in an argument of > 'default', a string must be always in UTF-8. YANG modules are written in UTF-8, isn't that enough? If not, could you propose some text? > - Sec. 9.4.2, para 2: The text should mention that multiple > adjacent predicates are allowed, as in "foo[key1=3][key2=100]". An > example would also be helpful. > OLD > Each predicate consists of exactly one equality test per key. > NEW > Each predicate consists of exactly one equality test per key but > multiple adjacent predicates may be present, for example if a list > has multiple keys. I added: Each predicate consists of exactly one equality test per key, and multiple adjacent predicates MAY be present if a list has multiple keys. > - Sec. 9.9.2: What is the context for XPath evaluation in this case? Hmm.. do you think we need a list such as the ones in 7.5.3 and 7.19.5? > - Sec. 9.9.3: The case "require-instance false;" should also be > specified: Ok. > 'If "require-instance" is "false", the value of the leaf > with "leafref" type must be equal to the referred leaf only if the > latter exists.' I don't think this propsed text makes much sense - if they are equal it means that the referred leaf exist! I suggest: NEW: If "require-instance" is "false", it means that the instance being referred MAY exist in valid data. > - Sec. 9.10: I don't understand the semantics of 'identityref' > type. How is it different from an enumeration? It is extensible. The module designer should carefully think about each enumeration in a module - should it be a type enumeration or type identityref? (This discussion should go into the yang guidelines). > - Sec. 9.10.5: > * Since module "des" is not imported, how can an > implementation know that such a module exists and defines the > "des3" identity? des:des3 will only be valid on the device if the device implements (and adertises) the des module. > * Is "crypto:crypto-alg" also a valid value of the "crypto" leaf? No, the text says: Valid values for an identityref are any identities derived from the identityref's base identity. > - Sec. 9.13.2, para 1: "All node names in an instance-identifier value > MUST be qualified with explicit namespace prefixes and these > prefixes MUST be declared ..." Fixed. > Editorial comments: > ------------------- > > - Possessive forms with 's are overused and sometimes it is really ugly: > "The must's Substatements", "bits's". Not changed. > - In HTML rendering, Sec. 5.6.4 in ToC does not have the hyperlink. I never posted the HTML, it was automatically generated from the text by the IETF tools. (Phil's tool does generate HTML from the source, available at: http://www.yang-central.org/twiki/pub/Main/YangDocuments/draft-ietf-netmod-yang-05.html) /martin From mbj@tail-f.com Wed May 20 13:44: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 51C7F3A6EF9 for ; Wed, 20 May 2009 13:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.183, 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 NZjvKbD6zbVN for ; Wed, 20 May 2009 13:44:09 -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 7D11D3A6EF8 for ; Wed, 20 May 2009 13:44:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C0BCF616018; Wed, 20 May 2009 22:45:46 +0200 (CEST) Date: Wed, 20 May 2009 22:45:46 +0200 (CEST) Message-Id: <20090520.224546.69592473.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <20090518.132516.63152516.mbj@tail-f.com> References: <200904300904.21808.david.partain@ericsson.com> <1AA2CBFAAA0E4DCE84D78AD892DAC459@BertLaptop> <20090518.132516.63152516.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] 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: Wed, 20 May 2009 20:44:10 -0000 Hi, Martin Bjorklund wrote: > "Bert Wijnen \(IETF\)" wrote: > > - I suspect (but am not sure) that either IESG members or RFC-Editor may > > want us to expand acronyms like YANG and YIN when we first use them. > > In fact that applies to all acronyms we use. > > I will check all the acronyms. I found http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt and I think it makes sense to follow it. I suggest we remove the defintion of MIB from our terminology list (it's well known according to the ref above, and we just use it in one location), and I expanded NETCONF and YIN. I would like to keep YANG as being just a name. /martin From mbj@tail-f.com Wed May 20 13:51: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 026E53A6ED1 for ; Wed, 20 May 2009 13:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.182, 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 wPVMeuPVdQxH for ; Wed, 20 May 2009 13:51:15 -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 569FB3A6EF8 for ; Wed, 20 May 2009 13:51:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DE79616018; Wed, 20 May 2009 22:52:46 +0200 (CEST) Date: Wed, 20 May 2009 22:52:46 +0200 (CEST) Message-Id: <20090520.225246.237098168.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242821702.16094.37.camel@missotis> References: <1242821702.16094.37.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] edit-config for lists 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, 20 May 2009 20:51:16 -0000 Ladislav Lhotka wrote: > Hi, > > if I slightly extend the example near the end of Sec. 7.7.8: > > ... > > yang:insert="after" > yang:value="3des-cbc">blowfish-cbc > yang:insert="after" > yang:value="3des-cbc">aes-cbc > > ... > > What will be the resulting order of list entries: "3des-cbc, blowfish-cbc, > aes-cbc" or > "3des-cbc, aes-cbc, blowfish-cbc"? Since each operation is applied in order, it will be the latter. If this needs to be clarified,, I'm note sure if it should be done in 4741bis or the yang draft. /martin From david.kessens@nsn.com Wed May 20 13:54: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 112FE3A6ABE for ; Wed, 20 May 2009 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 9UnaD+W8BbLB for ; Wed, 20 May 2009 13:53:59 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id F42253A6CF4 for ; Wed, 20 May 2009 13:53:58 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n4KKtYsp004589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 May 2009 22:55:34 +0200 Received: from localhost.localdomain ([10.138.48.152]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n4KKtWAT027884; Wed, 20 May 2009 22:55:33 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id n4KKtqWf019398; Wed, 20 May 2009 13:55:52 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id n4KKtpso019396; Wed, 20 May 2009 13:55:51 -0700 Date: Wed, 20 May 2009 13:55:51 -0700 From: David Kessens To: Andy Bierman Message-ID: <20090520205551.GA19326@nsn.com> References: <4A140329.5040302@joelhalpern.com> <20090520190258.GJ6459@nsn.com> <4A145D09.9050009@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A145D09.9050009@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 20:54:00 -0000 Andy, On Wed, May 20, 2009 at 12:42:01PM -0700, Andy Bierman wrote: > > What about the concern Joel raised wrt/ RFC 2119 text? > If the intended status (BCP vs. Informational) has an > impact on the content of the document, then it matters. > I did not object to Informational because I thought it > would not impact the content. Again, let's not get hung up on things like the document status. Just use the terms that you want to use in this document and we as a working group decide whether we like the outcome and give you feedback on possible improvements. We will then figure out whether informational status is still appropriate or whether BCP makes more sense. David Kessens --- From mbj@tail-f.com Wed May 20 13:55: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 B8FEC3A6ED1 for ; Wed, 20 May 2009 13:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[AWL=-0.564, 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 3T0tIm8RRjTp for ; Wed, 20 May 2009 13:55:11 -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 5F0D93A6CF4 for ; Wed, 20 May 2009 13:55:10 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B1B9616018; Wed, 20 May 2009 22:56:48 +0200 (CEST) Date: Wed, 20 May 2009 22:56:47 +0200 (CEST) Message-Id: <20090520.225647.86102208.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242822399.16094.44.camel@missotis> References: <1242819365.16094.21.camel@missotis> <20090520.140504.159744594.mbj@tail-f.com> <1242822399.16094.44.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] edit-config 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, 20 May 2009 20:55:12 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAxNDowNSArMDIwMDoNCj4gPiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gSGksDQo+ID4gPiANCj4g PiA+IGluIFNlYy4gNy42LjYgb24gZWRpdC1jb25maWcgb3BlcmF0aW9ucyBmb3IgbGVhZnMsIHRo ZSB0d28gc2VudGVuY2VzDQo+ID4gPiBkZXNjcmliaW5nIHRoZSBwcm9jZWR1cmUgZm9yICJtZXJn ZSIgYW5kICJyZXBsYWNlIiBvcGVyYXRpb25zIGFyZQ0KPiA+ID4gZXhhY3RseSBpZGVudGljYWws IHdoaWNoIHNob3VsZCBsZWFkIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhlIGFnZW50DQo+ID4g PiBiZWhhdmlvdXIgaXMgdGhlIHNhbWUgZm9yIGJvdGggb3BlcmF0aW9ucy4gSG93ZXZlciwgUkZD IDQ3NDEgc2F5cyB0aGF0DQo+ID4gPiBmb3IgdGhlICJyZXBsYWNlIiBvcGVyYXRpb24gIm9ubHkg dGhlIGNvbmZpZ3VyYXRpb24gYWN0dWFsbHkgcHJlc2VudCBpbg0KPiA+ID4gdGhlIGNvbmZpZyBw YXJhbWV0ZXIgaXMgYWZmZWN0ZWQiLCBzbyB0aGUgbm9kZSBzaG91bGQgTk9UIGJlIGNyZWF0ZWQg aWYNCj4gPiA+IGl0IGRvZXNuJ3QgZXhpc3QsIGlmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHku IFNvIGhvdyBpcyBpdCBhY3R1YWxseT8NCj4gPiANCj4gPiBUaGVyZSBpcyBubyBkaWZmZXJlbmNl IGJldHdlZW4gbWVyZ2UgYW5kIHJlcGxhY2UgZm9yIGEgbGVhZi4NCj4gPiANCj4gPiBJbiBnZW5l cmFsLCByZXBsYWNlIGRvZXMgbm90IGdpdmUgYW4gZXJyb3IgaWYgdGhlIGl0ZW0gdG8gcmVwbGFj ZSBkb2VzDQo+ID4gbm90IGV4aXN0LiAgKFRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIHNldmVyYWwg dGltZXMgb24gdGhlIE1MKQ0KPiANCj4gT0ssIGJ1dCB0aGUgaXRlbSBhbHNvIHNob3VsZCBub3Qg YmUgY3JlYXRlZCwgc2hvdWxkIGl0PyBPciBob3cgZG8geW91DQo+IGV4cGxhaW4gdGhlIGFib3Zl IHNlbnRlbmNlIGZyb20gUkZDIDQ3NDE/DQoNClRoZSBjb21wbGV0ZSB0ZXh0IGlzOg0KDQogICAg ICAgICAgICBVbmxpa2UgYSA8Y29weS1jb25maWc+IG9wZXJhdGlvbiwgd2hpY2ggcmVwbGFjZXMN CiAgICAgICAgICAgIHRoZSBlbnRpcmUgdGFyZ2V0IGNvbmZpZ3VyYXRpb24sIG9ubHkgdGhlIGNv bmZpZ3VyYXRpb24NCiAgICAgICAgICAgIGFjdHVhbGx5IHByZXNlbnQgaW4gdGhlIGNvbmZpZyBw YXJhbWV0ZXIgaXMgYWZmZWN0ZWQuDQoNClRoaXMgbWVhbnMgdGhhdCA8Y29weS1jb25maWc+IHdp bGwgZG8gYSBjb21wbGV0ZSByZXBsYWNlIG9mIHRoZSBlbnRpcmUNCmRhdGEgc3RvcmUsIGJ1dCB0 aGUgcmVwbGFjZSBvcGVyYXRpb24ganVzdCByZXBsYWNlcyB0aGUgZGF0YSBpbiB0aGUNCmVkaXQt Y29uZmlnIFBEVS4NCg0KDQovbWFydGluDQo= From mbj@tail-f.com Wed May 20 14:13: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 2AE7F3A6A65 for ; Wed, 20 May 2009 14:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.185, 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 VqIy4QCX9QRT for ; Wed, 20 May 2009 14:13: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 447FA3A6ABE for ; Wed, 20 May 2009 14:13:45 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 030FE61600E; Wed, 20 May 2009 23:15:20 +0200 (CEST) Date: Wed, 20 May 2009 23:15:19 +0200 (CEST) Message-Id: <20090520.231519.150160427.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49FDFC79.8080108@netconfcentral.com> References: <49FDF8FA.3040108@netconfcentral.com> <20090503.221554.167790073.mbj@tail-f.com> <49FDFC79.8080108@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] float vs. decimal 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, 20 May 2009 21:13:48 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I think the ranges are different for each value of fraction-digits: > > [table deleted] > > Exactly. It is important to note that the full type is decimal64 + a > > fixed value for fraction-digits. > > > > Do you think the table should go in the draft? I have added the table to the draft: The following table lists the minimum and maximum value for each fraction-digit value: +----------------+-----------------------+----------------------+ | fraction-digit | min | max | +----------------+-----------------------+----------------------+ | 1 | -922337203685477580.8 | 922337203685477580.7 | | 2 | -92233720368547758.08 | 92233720368547758.07 | | 3 | -9223372036854775.808 | 9223372036854775.807 | | 4 | -922337203685477.5808 | 922337203685477.5807 | | 5 | -92233720368547.75808 | 92233720368547.75807 | | 6 | -9223372036854.775808 | 9223372036854.775807 | | 7 | -922337203685.4775808 | 922337203685.4775807 | | 8 | -92233720368.54775808 | 92233720368.54775807 | | 9 | -9223372036.854775808 | 9223372036.854775807 | | 10 | -922337203.6854775808 | 922337203.6854775807 | | 11 | -92233720.36854775808 | 92233720.36854775807 | | 12 | -9223372.036854775808 | 9223372.036854775807 | | 13 | -922337.2036854775808 | 922337.2036854775807 | | 14 | -92233.72036854775808 | 92233.72036854775807 | | 15 | -9223.372036854775808 | 9223.372036854775807 | | 16 | -922.3372036854775808 | 922.3372036854775807 | | 17 | -92.23372036854775808 | 92.23372036854775807 | | 18 | -9.223372036854775808 | 9.223372036854775807 | +----------------+-----------------------+----------------------+ /martin From bertietf@bwijnen.net Wed May 20 15:39: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 9F9243A6957 for ; Wed, 20 May 2009 15:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.691 X-Spam-Level: X-Spam-Status: No, score=0.691 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_05=-1.11, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=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 Cyqr-CdjRAyq for ; Wed, 20 May 2009 15:38:59 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 2D6403A6E1D for ; Wed, 20 May 2009 15:38:59 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1M6uSe-0005Oj-Fw; Thu, 21 May 2009 00:40:32 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" , "David Kessens" References: <4A140329.5040302@joelhalpern.com> <20090520190258.GJ6459@nsn.com> <4A145D09.9050009@netconfcentral.com> In-Reply-To: <4A145D09.9050009@netconfcentral.com> Date: Thu, 21 May 2009 00:40:13 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D5_01C9D9AC.B4364E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: NETMOD Working Group Subject: Re: [netmod] Intended status of the yang-usage draft? 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, 20 May 2009 22:39:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02D5_01C9D9AC.B4364E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Again, add some introductory text that this document is wriotten with = the intent=20 to make it a BCP at a later stage and explain that that is why we use = the RFC2119 language. Easy as far as I am concerned. Bert ----- Original Message -----=20 From: Andy Bierman=20 To: David Kessens=20 Cc: NETMOD Working Group=20 Sent: Wednesday, May 20, 2009 9:42 PM Subject: Re: [netmod] Intended status of the yang-usage draft? David Kessens wrote: > Joel, >=20 > On Wed, May 20, 2009 at 09:18:33AM -0400, Joel M. Halpern wrote: >> After reading draft-ietf-netmod-yang-usage-00.txt, I really would = like =20 >> to see that published along with the base Yang draft (or, to be =20 >> realistic, I suppose as soon thereafter as possible.) >=20 > As a working group chair, I prefer that we first focus our attention > on the document itself as opposed to administrative matters like the > precise status of the document. It is pretty clear that there is > something to be said for either informational or bcp status but when > we adopted the document the decision was made to go for = informational. >=20 > I don't believe it is very productive to reopen the discussion on = the > status of this document until we are a bit closer to the finish line > and we all have a better idea on how strong the consensus behind = this > document is. >=20 > There is nothing in the way for proposing a status change to our = Area > Director later down the line when we are getting closer to = submitting > this document to the IESG and lets consider that at that time. >=20 What about the concern Joel raised wrt/ RFC 2119 text? If the intended status (BCP vs. Informational) has an impact on the content of the document, then it matters. I did not object to Informational because I thought it would not impact the content. The obvious issue is whether this paragraph can appear in Informational RFCs: 2.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this document are to be interpreted as described in [RFC2119]. So, does the intended status impact the content or not? I suppose I should look it up myself, but maybe somebody on the list already knows the relevant RFC section with the answer. My re-read of RFC 2119 seems to support Joel's concern that this RFC applies to standards-track documents, because non-standards-track documents are not explicitly mentioned. > David Kessens Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -------------------------------------------------------------------------= ----- No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.339 / Virus Database: 270.12.35/2124 - Release Date: = 05/20/09 06:22:00 ------=_NextPart_000_02D5_01C9D9AC.B4364E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Again, add some introductory text that this document = is=20 wriotten with the intent
to make it a BCP at a later stage and explain that that is why we use the RFC2119 = language.
 
Easy as far as I am concerned.
 
Bert
----- Original Message -----
From:=20 Andy=20 Bierman
Sent: Wednesday, May 20, 2009 = 9:42=20 PM
Subject: Re: [netmod] Intended = status of=20 the yang-usage draft?

David Kessens wrote:
> Joel,
>
> On = Wed, May=20 20, 2009 at 09:18:33AM -0400, Joel M. Halpern wrote:
>> After = reading=20 draft-ietf-netmod-yang-usage-00.txt, I really would like  =
>> to=20 see that published along with the base Yang draft (or, to be =20
>> realistic, I suppose as soon thereafter as = possible.)
>=20
> As a working group chair, I prefer that we first focus our=20 attention
> on the document itself as opposed to administrative = matters=20 like the
> precise status of the document. It is pretty clear = that there=20 is
> something to be said for either informational or bcp status = but=20 when
> we adopted the document the decision was made to go for=20 informational.
>
> I don't believe it is very productive = to=20 reopen the discussion on the
> status of this document until we = are a=20 bit closer to the finish line
> and we all have a better idea on = how=20 strong the consensus behind this
> document is.
>
> = There=20 is nothing in the way for proposing a status change to our = Area
>=20 Director later down the line when we are getting closer to = submitting
>=20 this document to the IESG and lets consider that at that time.
> =

What about the concern Joel raised wrt/ RFC 2119 text?
If = the=20 intended status (BCP vs. Informational) has an
impact on the = content of the=20 document, then it matters.
I did not object to Informational = because I=20 thought it
would not impact the content.

The obvious issue = is=20 whether this paragraph can appear
in Informational=20 RFCs:

    2.1.  Requirements=20 Notation

       The key words = "MUST",=20 "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 NOT",
       "SHOULD", "SHOULD NOT",=20 "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this
       document are to be = interpreted as=20 described in [RFC2119].

So, does the intended status impact the = content=20 or not?
I suppose I should look it up myself, but maybe = somebody
on the=20 list already knows the relevant RFC section with
the = answer.

My=20 re-read of RFC 2119 seems to support Joel's concern that
this RFC = applies=20 to standards-track documents, because
non-standards-track documents = are not=20 explicitly mentioned.

> David=20 = Kessens

Andy


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


No virus found in this incoming message.
Checked by AVG = - www.avg.com
Version: 8.5.339 / = Virus=20 Database: 270.12.35/2124 - Release Date: 05/20/09=20 06:22:00
------=_NextPart_000_02D5_01C9D9AC.B4364E70-- From lhotka@cesnet.cz Thu May 21 01:02: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 E01723A6C2D for ; Thu, 21 May 2009 01:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[AWL=0.333, 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 XjINS6aIxeRj for ; Thu, 21 May 2009 01:02:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2029E3A6AF7 for ; Thu, 21 May 2009 01:02: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 B4337D800BD; Thu, 21 May 2009 10:03:17 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.225246.237098168.mbj@tail-f.com> References: <1242821702.16094.37.camel@missotis> <20090520.225246.237098168.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 21 May 2009 10:03:18 +0200 Message-Id: <1242892998.6931.49.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] edit-config for lists 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, 21 May 2009 08:02:02 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:52 +0200: > Ladislav Lhotka wrote: > > Hi, > > > > if I slightly extend the example near the end of Sec. 7.7.8: > > > > ... > > > > > yang:insert="after" > > yang:value="3des-cbc">blowfish-cbc > > > yang:insert="after" > > yang:value="3des-cbc">aes-cbc > > > > ... > > > > What will be the resulting order of list entries: "3des-cbc, blowfish-cbc, > > aes-cbc" or > > "3des-cbc, aes-cbc, blowfish-cbc"? > > Since each operation is applied in order, it will be the latter. Where is this specified? I'd actually prefer if the entire edit-config was atomic. > > If this needs to be clarified,, I'm note sure if it should be done in > 4741bis or the yang draft. The attributes "insert", "value" and "key" are specific to YANG, so I guess it should be in the yang draft. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Thu May 21 01:05: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 1E2B93A6E54 for ; Thu, 21 May 2009 01:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_20=-0.74, 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 b8iWt2UcwQz0 for ; Thu, 21 May 2009 01:05:29 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 226CD3A67B7 for ; Thu, 21 May 2009 01:05:28 -0700 (PDT) X-AuditID: c1b4fb3c-b7b87ae000000ec5-1a-4a150ba4e4c2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 05.54.03781.4AB051A4; Thu, 21 May 2009 10:07:00 +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, 21 May 2009 10:06:59 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 10:06:59 +0200 Message-ID: <4A150BA3.1060704@ericsson.com> Date: Thu, 21 May 2009 10:06:59 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2009 08:06:59.0713 (UTC) FILETIME=[1DCA9F10:01C9D9EB] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] choices config statement 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, 21 May 2009 08:05:30 -0000 Hello, Is the following valid YANG? choice snack { config true; case sports-arena { config true; // ??? leaf pretzel { type int32; } } case late-night { leaf chocolate { type string; config false; // ??? } } } By the way in '7.9.2.1. The case's Substatements' config is not listed as an allowed sub-statement while in '7.9.2.1. The case's Substatements' we have "If "config" is not specified, the default is the same as the parent schema node's "config" value. If the parent node is a "case" node, ..." which implies that you can put config under a case node. One of them should be corrected. Balazs From lhotka@cesnet.cz Thu May 21 01:22: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 63F063A6A50 for ; Thu, 21 May 2009 01:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[AWL=-0.415, 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 4FQBcBox27d0 for ; Thu, 21 May 2009 01:22:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 90FCF3A6A0B for ; Thu, 21 May 2009 01:22: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 379C3D800BD; Thu, 21 May 2009 10:23:39 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 10:23:39 +0200 Message-Id: <1242894219.6931.59.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] definitions [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 08:22:02 -0000 Hi, I think it is more effective to discuss the issues in separate threads, so I will divide my responses into multiple messages. Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > - The word "definition" is used in two meanings: (i) definition of > > data nodes and (ii) definitions of groupings, typedefs and > > features. For example, Sec. 7.1.5 says: 'The "import" statement > > makes definitions from one module available inside another module > or > > submodule.' and it means (ii). Suggestion: use "data node > > definition" for (i). > > Actually, it refers to both meanings. E.g. you need to import a > module > in order to augment it. A data node definition such as "container" changes the schema but it is not the case with "import". This is also different behaviour when compared to other common languages like Python or RELAX NG, so it probably needs a more detailed explanation. I remember it was quite confusing for me, too. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 01:31: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 1DF5E3A6AE2 for ; Thu, 21 May 2009 01:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=-0.596, 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 0NhWHSmL0X6W for ; Thu, 21 May 2009 01:31:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D80BD3A6AF7 for ; Thu, 21 May 2009 01:31: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 8DFF3D800BD; Thu, 21 May 2009 10:33:15 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 10:33:16 +0200 Message-Id: <1242894796.6931.65.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] revision mismatch [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 08:31:40 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > - Sec. 5.1.1: The spec doesn't ensure that both parties in a NETCONF > > session always use the same module revisions > > This is by design. We cannot assume that all clients always have the > latest version of a particular module. It is a strange contract where each party may work with a different text. I didn't get this was a feature, so I disagree now. Lada > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 01:37: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 1A6823A6B21 for ; Thu, 21 May 2009 01:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=0.340, 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 iRDakkf6chUs for ; Thu, 21 May 2009 01:37:14 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 55CFD3A67B7 for ; Thu, 21 May 2009 01:37:14 -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 E309ED800BD; Thu, 21 May 2009 10:38:51 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 10:38:52 +0200 Message-Id: <1242895132.6931.67.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] rpc-reply [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 08:37:15 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > - Sec. 5.1.2: is not the only NETCONF element carrying data > > model XML data. Others are or . > > I added as well. Nothing in 4741 encodes data model XML > directly under rpc-reply. Sec. 7.13.4: If output parameters are returned, they are encoded as child elements to the element defined in [RFC4741], in the same order as they are defined within the output statement. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 02:18: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 CDE153A6F59 for ; Thu, 21 May 2009 02:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-0.408, 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 u00fH8MFasvb for ; Thu, 21 May 2009 02:18:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 18D9228C0CF for ; Thu, 21 May 2009 02:18: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 5D8F8D800BD; Thu, 21 May 2009 11:20:09 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 21 May 2009 11:20:10 +0200 Message-Id: <1242897610.6931.74.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-yang-05 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, 21 May 2009 09:18:32 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > * The module names and their namespaces are somewhat redundant. > I'd > > suggest to resolve YANG modules using only namespace URI - > > collisions in module names then wouldn't be a problem and > "module" > > parameter of capability strings can be removed. > > If it is not there, we would have to use the URI for the deviation > parameter. The module name is easier to work with. URIs are required to be globally unique and also there are established procedures for resolving them. Neither is true for module names. It is machine-to-machine communication, so ease of use shouldn't be a top priority. Lada > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 02:19: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 9B4DB28C0E8 for ; Thu, 21 May 2009 02:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_40=-0.185, 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 gECbVN+99L9i for ; Thu, 21 May 2009 02:19:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C50D328C0CF for ; Thu, 21 May 2009 02:19:27 -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 6B346D800C7; Thu, 21 May 2009 11:21:05 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 11:21:06 +0200 Message-Id: <1242897666.6931.76.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] string concatenation [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 09:19:28 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > - Sec. 6.1.3, para 5: "... two strings are concatenated into one > > quoted string, ...". Does "quoted" mean single- or double-quoted? > > Example: "Here's " + 'the problem.\n'. Suggestion: State that all > > escaped characters are substituted before concatenation and then > > the strings are joined into one (value-space) string. > > Would this work: > > If a quoted string is followed by a plus character ("+"), followed > by > another quoted string, the two strings are concatenated into one > string, allowing multiple concatenations to build one string. > Whitespace trimming and substition of backslash-escaped characters > in > double quoted strings is done before concatenation. > > (this paragraph would be moved after the backslash-special character > text). Looks good. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 02:23: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 72B3028C0F3 for ; Thu, 21 May 2009 02:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.029 X-Spam-Level: X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[AWL=-0.580, 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 sVu2WCHIbX9E for ; Thu, 21 May 2009 02:23:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9CDF828C0E1 for ; Thu, 21 May 2009 02:23: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 4E441D800C7; Thu, 21 May 2009 11:24:56 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 11:24:57 +0200 Message-Id: <1242897897.6931.80.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] namespace stmt [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 09:23:19 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > - Sec. 7.1.3: The namespace is used not only for XML elements but > also > > for extensions and features. > > Extensions and features never show up in the XML. The namespace does > not affect them. The 'namespace' statements defines the namespace and prefix for objects within the YANG module, too. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 02:31: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 0DB773A6B63 for ; Thu, 21 May 2009 02:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.035 X-Spam-Level: X-Spam-Status: No, score=0.035 tagged_above=-999 required=5 tests=[AWL=-0.574, 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 Vw1ZMjB4AAIJ for ; Thu, 21 May 2009 02:31:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 306293A6C66 for ; Thu, 21 May 2009 02:31: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 E40ACD800C5; Thu, 21 May 2009 11:33:31 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 11:33:32 +0200 Message-Id: <1242898412.6931.86.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] defaults in accessible tree [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 09:31:55 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > - Sec. 7.5.3: > > * In the description of the evaluation context, the second item > is: > > "The accessible tree is made up of all nodes in the data tree, > and > > ..." However, subsequent items say that the tree actually > depends > > on the content type (config data, RPC, notification). > > The idea is that the first sentence says that all nodes including > default values are there, and the next list specifies which nodes are > there, depending on context. If this is unclear, could you suggest a > change? o Default values are substituted for all missing leafs in the accessible data tree for which the default value is defined. Perhaps the specification of the accessible data tree could be moved before this list. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 02:47: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 16B5428C119 for ; Thu, 21 May 2009 02:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[AWL=-0.383, 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 zMVyx7hj7QTS for ; Thu, 21 May 2009 02:47:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A1A2528C10F for ; Thu, 21 May 2009 02:46: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 7FD55D800C7; Thu, 21 May 2009 11:48:27 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 11:48:28 +0200 Message-Id: <1242899308.6931.95.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] character encoding [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 09:47:04 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > - Sec. 9.4.1: Encodings that every implementation must support > should > > be specified here, for example UTF-8 or UTF-16. But in an argument > of > > 'default', a string must be always in UTF-8. > > YANG modules are written in UTF-8, isn't that enough? If not, could > you propose some text? Encoding of PDUs follows XML rules, so I suggest to have the same requirements as the XML spec: "All implementations MUST accept the UTF-8 and UTF-16 encodings of ISO/IEC 10646 specified according to [XML], section 4.3.3." Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 02:54: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 4157D3A6F07 for ; Thu, 21 May 2009 02:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.322 X-Spam-Level: X-Spam-Status: No, score=0.322 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_40=-0.185, 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 79nRR4-8aKnC for ; Thu, 21 May 2009 02:54:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 717493A6DF5 for ; Thu, 21 May 2009 02:54:26 -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 2D257D800BD; Thu, 21 May 2009 11:56:04 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 11:56:04 +0200 Message-Id: <1242899764.6931.99.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] path stmt [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 09:54:27 -0000 A. Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > - Sec. 9.9.2: What is the context for XPath evaluation in this case? > > Hmm.. do you think we need a list such as the ones in 7.5.3 and > 7.19.5? Yes, something similar. The accessible data tree is apparently different from the one used for "must" and "when". Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 03:58: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 0F4353A69E6 for ; Thu, 21 May 2009 03:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.423 X-Spam-Level: X-Spam-Status: No, score=0.423 tagged_above=-999 required=5 tests=[AWL=-0.927, 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 KnpOZejyDBXD for ; Thu, 21 May 2009 03:58:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 403553A685F for ; Thu, 21 May 2009 03:58:35 -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 0BC58D800BD; Thu, 21 May 2009 13:00:11 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090520.224146.220136501.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 21 May 2009 13:00:11 +0200 Message-Id: <1242903611.6931.103.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] require-instance false [Was: review of draft-ietf-netmod-yang-05] 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, 21 May 2009 10:58:37 -0000 Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > 'If "require-instance" is "false", the value of the leaf > > with "leafref" type must be equal to the referred leaf only if the > > latter exists.' > > I don't think this propsed text makes much sense - if they are equal > it means that the referred leaf exist! I suggest: > > NEW: > > If "require-instance" is "false", it means that the instance being > referred MAY exist in valid data. ... and if it exists, its value MUST be equal to the value of the referring leaf. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Thu May 21 05:43: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 96AB93A68E0 for ; Thu, 21 May 2009 05:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.153, 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 xuJEERIjK-NS for ; Thu, 21 May 2009 05:43:42 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A8B163A68B2 for ; Thu, 21 May 2009 05:43:41 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-df-4a154cdd6af9 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F6.8C.02630.DDC451A4; Thu, 21 May 2009 14:45:17 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 14:45:17 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 14:45:17 +0200 Message-ID: <4A154CDC.4050105@ericsson.com> Date: Thu, 21 May 2009 14:45:16 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2009 12:45:17.0283 (UTC) FILETIME=[FE519B30:01C9DA11] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Empty deviation 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, 21 May 2009 12:43:42 -0000 Hello, What does an empty deviation statement mean? deviation /base:system/base:name-server ; According to the draft this is legal. Is this just stupid and we don't care or should we prohibit it? Maybe we should make the cardinality of the deviate statement 1..n instead of 0..n. Balazs From randy_presuhn@mindspring.com Thu May 21 09:29: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 B62003A6FCD for ; Thu, 21 May 2009 09:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-0.924, 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 KRl60KtfUty6 for ; Thu, 21 May 2009 09:29:58 -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 E0B543A69FC for ; Thu, 21 May 2009 09:29:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SHkDM4jPG4vYI2uRAhq7rkVcL/FB1cv0p6UsBu4wei6lL14dhIJKVQWXgKqWhlG7; 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 [68.166.188.105] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M7BB9-0003fY-Qg for netmod@ietf.org; Thu, 21 May 2009 12:31:36 -0400 Message-ID: <003501c9da32$12205aa0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <1242289874.6404.7.camel@missotis><20090520.224146.220136501.mbj@tail-f.com> <1242899308.6931.95.camel@missotis> Date: Thu, 21 May 2009 09:34:52 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69689ac8cccfa8120af07a89a47ea41056e8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.105 Subject: Re: [netmod] character encoding [Was: review ofdraft-ietf-netmod-yang-05] 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, 21 May 2009 16:29:58 -0000 Hi - > From: "Ladislav Lhotka" > To: "Martin Bjorklund" > Cc: > Sent: Thursday, May 21, 2009 2:48 AM > Subject: [netmod] character encoding [Was: review ofdraft-ietf-netmod-yang-05] > > Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > > - Sec. 9.4.1: Encodings that every implementation must support > > should > > > be specified here, for example UTF-8 or UTF-16. But in an argument > > of > > > 'default', a string must be always in UTF-8. > > > > YANG modules are written in UTF-8, isn't that enough? If not, could > > you propose some text? > > Encoding of PDUs follows XML rules, so I suggest to have the same > requirements as the XML spec: > > "All implementations MUST accept the UTF-8 and UTF-16 encodings of > ISO/IEC 10646 specified according to [XML], section 4.3.3." ... There is little or no value to having two mandatory encodings. Having two options increases the chances of error, and the code points requiring multiple words to encode in UTF-16 are sufficiently uncommon that it's likely that those code paths will not be properly tested. UTF-8 is the clear winner in the encoding wars. That should be the sole mandatory encoding, IMO. RAndy From spakes@snmp.com Thu May 21 11:39: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 951333A6C90 for ; Thu, 21 May 2009 11:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=-0.677, 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 WX2JOkr+JoWC for ; Thu, 21 May 2009 11:39:04 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id A1BA03A6C55 for ; Thu, 21 May 2009 11:39:04 -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 OAA05649; Thu, 21 May 2009 14:40:33 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA00302; Thu, 21 May 2009 14:40:33 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 21 May 2009 14:40:32 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org In-Reply-To: <20090518.095605.45155468.mbj@tail-f.com> Message-ID: References: <20090518.095605.45155468.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] require-instance 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, 21 May 2009 18:39:06 -0000 In Section 9.13.4 (Usage Example for instance-indentifier), the first example is: /* instance-identifier for a container */ /ex:system/ex:services/ex:ssh Would someone clarify my understanding? I have these questions: 1. Can the instance-identifier refer to a container that exists "only for organizing the hierarchy of data nodes"? Or, must the instance-identifier refer only to a "presence container"? 2. If the instance-identifier has a require-instance substatement, must it refer only to a "presence container" that presently exists? Regards, David Spakes ------------------------------------------------------------- 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 Thu May 21 12:31: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 2BC7A3A6C55 for ; Thu, 21 May 2009 12:31:46 -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.836, 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 An5B+e1XrruT for ; Thu, 21 May 2009 12:31: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 5609B3A6A92 for ; Thu, 21 May 2009 12:31:45 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 0B1C7616004; Thu, 21 May 2009 21:33:20 +0200 (CEST) Date: Thu, 21 May 2009 21:33:19 +0200 (CEST) Message-Id: <20090521.213319.238033374.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A150BA3.1060704@ericsson.com> References: <4A150BA3.1060704@ericsson.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] choices config statement 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, 21 May 2009 19:31:46 -0000 Balazs Lengyel wrote: > Hello, > Is the following valid YANG? > > choice snack { > config true; > case sports-arena { > config true; // ??? No, config is not allowed under case. > By the way in '7.9.2.1. The case's Substatements' config is not listed as an > allowed sub-statement while in '7.9.2.1. The case's Substatements' we have > > "If "config" is not specified, the default is the same as the parent > schema node's "config" value. If the parent node is a "case" node, ..." > > which implies that you can put config under a case node. One of them should be > corrected. The last sentence reads: If the parent node is a "case" node, the value is the same as the "case" node's parent "choice" node. I.e. you inherit from the choice, not from case. /martin From mbj@tail-f.com Thu May 21 12:35: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 8775E3A6C55 for ; Thu, 21 May 2009 12:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.669, 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 jA-7ugJebXcl for ; Thu, 21 May 2009 12:35:39 -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 A81523A6A4C for ; Thu, 21 May 2009 12:35:39 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 89F6E616004; Thu, 21 May 2009 21:37:17 +0200 (CEST) Date: Thu, 21 May 2009 21:37:17 +0200 (CEST) Message-Id: <20090521.213717.193017582.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242894219.6931.59.camel@missotis> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242894219.6931.59.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] definitions 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, 21 May 2009 19:35:40 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSGksDQo+IA0KPiBJ IHRoaW5rIGl0IGlzIG1vcmUgZWZmZWN0aXZlIHRvIGRpc2N1c3MgdGhlIGlzc3VlcyBpbiBzZXBh cmF0ZSB0aHJlYWRzLA0KPiBzbyBJIHdpbGwgZGl2aWRlIG15IHJlc3BvbnNlcyBpbnRvIG11bHRp cGxlIG1lc3NhZ2VzLg0KPiANCj4gTWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyMC4gMDUu IDIwMDkgdiAyMjo0MSArMDIwMDoNCj4gPiA+IC0gVGhlIHdvcmQgImRlZmluaXRpb24iIGlzIHVz ZWQgaW4gdHdvIG1lYW5pbmdzOiAoaSkgZGVmaW5pdGlvbiBvZg0KPiA+ID4gICBkYXRhIG5vZGVz IGFuZCAoaWkpIGRlZmluaXRpb25zIG9mIGdyb3VwaW5ncywgdHlwZWRlZnMgYW5kDQo+ID4gPiAg IGZlYXR1cmVzLiBGb3IgZXhhbXBsZSwgU2VjLiA3LjEuNSBzYXlzOiAnVGhlICJpbXBvcnQiIHN0 YXRlbWVudA0KPiA+ID4gICBtYWtlcyBkZWZpbml0aW9ucyBmcm9tIG9uZSBtb2R1bGUgYXZhaWxh YmxlIGluc2lkZSBhbm90aGVyIG1vZHVsZQ0KPiA+IG9yDQo+ID4gPiAgIHN1Ym1vZHVsZS4nIGFu ZCBpdCBtZWFucyAoaWkpLiBTdWdnZXN0aW9uOiB1c2UgImRhdGEgbm9kZQ0KPiA+ID4gICBkZWZp bml0aW9uIiBmb3IgKGkpLg0KPiA+IA0KPiA+IEFjdHVhbGx5LCBpdCByZWZlcnMgdG8gYm90aCBt ZWFuaW5ncy4gIEUuZy4geW91IG5lZWQgdG8gaW1wb3J0IGENCj4gPiBtb2R1bGUNCj4gPiBpbiBv cmRlciB0byBhdWdtZW50IGl0Lg0KPiANCj4gQSBkYXRhIG5vZGUgZGVmaW5pdGlvbiBzdWNoIGFz ICJjb250YWluZXIiIGNoYW5nZXMgdGhlIHNjaGVtYSBidXQgaXQgaXMNCj4gbm90IHRoZSBjYXNl IHdpdGggImltcG9ydCIuIFRoaXMgaXMgYWxzbyBkaWZmZXJlbnQgYmVoYXZpb3VyIHdoZW4NCj4g Y29tcGFyZWQgdG8gb3RoZXIgY29tbW9uIGxhbmd1YWdlcyBsaWtlIFB5dGhvbiBvciBSRUxBWCBO Rywgc28gaXQNCj4gcHJvYmFibHkgbmVlZHMgYSBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9uLiBJ IHJlbWVtYmVyIGl0IHdhcyBxdWl0ZQ0KPiBjb25mdXNpbmcgZm9yIG1lLCB0b28uDQoNClRoZSB0 ZXh0IHNheXM6DQoNCiAgVGhlICJpbXBvcnQiIHN0YXRlbWVudCBtYWtlcyBkZWZpbml0aW9ucyBm cm9tIG9uZSBtb2R1bGUgYXZhaWxhYmxlDQogIGluc2lkZSBhbm90aGVyIG1vZHVsZSBvciBzdWJt b2R1bGUuIA0KDQpDb3VsZCB5b3UgcHJvcG9zZSB0ZXh0IHRvIG1ha2UgaXQgbW9yZSBjbGVhcj8N Cg0KQlRXLCBSTkcgZG9lc24ndCBoYXZlICdpbXBvcnQnIGRvZXMgaXQ/DQoNCg0KL21hcnRpbg0K From mbj@tail-f.com Thu May 21 12:36: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 011613A68FB for ; Thu, 21 May 2009 12:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=0.557, 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 pTeaSUB3NNTV for ; Thu, 21 May 2009 12:36: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 130E83A6A4C for ; Thu, 21 May 2009 12:36:44 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 94CEA616004; Thu, 21 May 2009 21:38:10 +0200 (CEST) Date: Thu, 21 May 2009 21:38:10 +0200 (CEST) Message-Id: <20090521.213810.264286251.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242894796.6931.65.camel@missotis> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242894796.6931.65.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] revision mismatch 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, 21 May 2009 19:36:46 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAyMjo0MSArMDIwMDoNCj4gPiA+IC0gU2Vj LiA1LjEuMTogVGhlIHNwZWMgZG9lc24ndCBlbnN1cmUgdGhhdCBib3RoIHBhcnRpZXMgaW4gYSBO RVRDT05GDQo+ID4gPiAgIHNlc3Npb24gYWx3YXlzIHVzZSB0aGUgc2FtZSBtb2R1bGUgcmV2aXNp b25zDQo+ID4gDQo+ID4gVGhpcyBpcyBieSBkZXNpZ24uICBXZSBjYW5ub3QgYXNzdW1lIHRoYXQg YWxsIGNsaWVudHMgYWx3YXlzIGhhdmUgdGhlDQo+ID4gbGF0ZXN0IHZlcnNpb24gb2YgYSBwYXJ0 aWN1bGFyIG1vZHVsZS4NCj4gDQo+IEl0IGlzIGEgc3RyYW5nZSBjb250cmFjdCB3aGVyZSBlYWNo IHBhcnR5IG1heSB3b3JrIHdpdGggYSBkaWZmZXJlbnQNCj4gdGV4dC4gSSBkaWRuJ3QgZ2V0IHRo aXMgd2FzIGEgZmVhdHVyZSwgc28gSSBkaXNhZ3JlZSBub3cuDQoNCkFyZSB5b3Ugc3VnZ2VzdGlu ZyB0aGF0IGlmIGEgc2VydmVyIGFkdmVydGlzZXMgbW9kdWxlIEEsIHJldmlzaW9uIFgsDQphbmQg dGhlIGNsaWVudCBkb2VzIG5vdCB1bmRlcnN0YW5kIEEgcmV2IFgsIHRoZW4gdGhlIGNsaWVudCBN VVNUIGNsb3NlDQp0aGUgc2Vzc2lvbj8NCg0KDQovbWFydGluDQo= From mbj@tail-f.com Thu May 21 12:42: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 6145C3A6E4A for ; Thu, 21 May 2009 12:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=0.478, 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 DqK+3ZogM4-Y for ; Thu, 21 May 2009 12:42: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 8E1503A6A80 for ; Thu, 21 May 2009 12:42:14 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 2206F616004; Thu, 21 May 2009 21:43:44 +0200 (CEST) Date: Thu, 21 May 2009 21:43:43 +0200 (CEST) Message-Id: <20090521.214343.46115981.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242895132.6931.67.camel@missotis> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242895132.6931.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] rpc-reply 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, 21 May 2009 19:42:15 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAyMjo0MSArMDIwMDoNCj4gPiA+IC0gU2Vj LiA1LjEuMjogPGNvbmZpZz4gaXMgbm90IHRoZSBvbmx5IE5FVENPTkYgZWxlbWVudCBjYXJyeWlu ZyBkYXRhDQo+ID4gPiAgIG1vZGVsIFhNTCBkYXRhLiBPdGhlcnMgYXJlIDxkYXRhPiBvciA8cnBj LXJlcGx5Pi4NCj4gPiANCj4gPiBJIGFkZGVkIDxkYXRhPiBhcyB3ZWxsLiAgTm90aGluZyBpbiA0 NzQxIGVuY29kZXMgZGF0YSBtb2RlbCBYTUwNCj4gPiBkaXJlY3RseSB1bmRlciBycGMtcmVwbHku DQo+IA0KPiBTZWMuIDcuMTMuNDoNCj4gSWYgb3V0cHV0IHBhcmFtZXRlcnMgYXJlIHJldHVybmVk LCB0aGV5IGFyZSBlbmNvZGVkIGFzDQo+IGNoaWxkIGVsZW1lbnRzIHRvIHRoZSA8cnBjLXJlcGx5 PiBlbGVtZW50IGRlZmluZWQgaW4gW1JGQzQ3NDFdLCBpbg0KPiB0aGUgc2FtZSBvcmRlciBhcyB0 aGV5IGFyZSBkZWZpbmVkIHdpdGhpbiB0aGUgb3V0cHV0IHN0YXRlbWVudC4NCg0KUmlnaHQuICBU aGUgdGV4dCBpbiA1LjEuMiBub3cgcmVhZHM6DQoNCiAgIE5FVENPTkYgaXMgY2FwYWJsZSBvZiBj YXJyeWluZyBhbnkgWE1MIGNvbnRlbnQgYXMgdGhlIHBheWxvYWQgaW4gdGhlDQogICA8Y29uZmln PiBhbmQgPGRhdGE+IGVsZW1lbnRzLiAgVGhlIHRvcC1sZXZlbCBub2RlcyBvZiBZQU5HIG1vZHVs ZXMNCiAgIGFyZSBlbmNvZGVkIGFzIGNoaWxkIGVsZW1lbnRzIHdpdGhpbiB0aGVzZSBlbGVtZW50 cy4gDQoNClRoZSB0b3AtbGV2ZWwgbm9kZXMgb2YgWUFORyBtb2R1bGVzIHdpbGwgbm90IGJlIHNl bnQgZGlyZWN0bHkgYXMNCmNoaWxkcmVuIHRvIDxycGMtcmVwbHk+Lg0KDQooVGhlIHRleHQgZG9l cyBub3Qgc2F5ICJORVRDT05GIGlzIGNhcGFibGUgb2YgY2FycnlpbmcgYW55IFhNTCBjb250ZW50 DQoqb25seSogYXMgdGhlIHBheWxvYWQuLi4iKQ0KDQoNCi9tYXJ0aW4NCg== From mbj@tail-f.com Thu May 21 12:44: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 556653A6E4A for ; Thu, 21 May 2009 12:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.418, 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 BqFMxn4Vn77M for ; Thu, 21 May 2009 12:44:11 -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 813023A6A80 for ; Thu, 21 May 2009 12:44:11 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 6613E616004; Thu, 21 May 2009 21:45:34 +0200 (CEST) Date: Thu, 21 May 2009 21:45:34 +0200 (CEST) Message-Id: <20090521.214534.229898853.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242897897.6931.80.camel@missotis> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242897897.6931.80.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] namespace stmt 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, 21 May 2009 19:44:12 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAyMjo0MSArMDIwMDoNCj4gPiA+IC0gU2Vj LiA3LjEuMzogVGhlIG5hbWVzcGFjZSBpcyB1c2VkIG5vdCBvbmx5IGZvciBYTUwgZWxlbWVudHMg YnV0DQo+ID4gYWxzbw0KPiA+ID4gICBmb3IgZXh0ZW5zaW9ucyBhbmQgZmVhdHVyZXMuDQo+ID4g DQo+ID4gRXh0ZW5zaW9ucyBhbmQgZmVhdHVyZXMgbmV2ZXIgc2hvdyB1cCBpbiB0aGUgWE1MLiAg VGhlIG5hbWVzcGFjZSBkb2VzDQo+ID4gbm90IGFmZmVjdCB0aGVtLg0KPiANCj4gVGhlICduYW1l c3BhY2UnIHN0YXRlbWVudHMgZGVmaW5lcyB0aGUgbmFtZXNwYWNlIGFuZCBwcmVmaXggZm9yIG9i amVjdHMNCj4gd2l0aGluIHRoZSBZQU5HIG1vZHVsZSwgdG9vLg0KDQpJJ20gc29ycnksIEkgZG9u J3QgdW5kZXJzdGFuZCB5b3VyIHBvaW50LiAgQ291bGQgeW91IHN1Z2dlc3Qgc29tZSB0ZXh0DQp0 aGF0IHdvdWxkIGdvIGludG8gNy4xLjM/DQoNCg0KL21hcnRpbg0K From mbj@tail-f.com Thu May 21 12:47: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 D737C3A6892 for ; Thu, 21 May 2009 12:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.371, 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 GWMOuabushhy for ; Thu, 21 May 2009 12:47: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 18EC13A684B for ; Thu, 21 May 2009 12:47:41 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id CEB8E616004; Thu, 21 May 2009 21:49:13 +0200 (CEST) Date: Thu, 21 May 2009 21:49:13 +0200 (CEST) Message-Id: <20090521.214913.98386188.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242898412.6931.86.camel@missotis> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242898412.6931.86.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] defaults in accessible tree 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, 21 May 2009 19:47:41 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAyMjo0MSArMDIwMDoNCj4gPiA+IC0gU2Vj LiA3LjUuMzoNCj4gPiA+ICAgKiBJbiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGV2YWx1YXRpb24g Y29udGV4dCwgdGhlIHNlY29uZCBpdGVtDQo+ID4gaXM6DQo+ID4gPiAgICAgIlRoZSBhY2Nlc3Np YmxlIHRyZWUgaXMgbWFkZSB1cCBvZiBhbGwgbm9kZXMgaW4gdGhlIGRhdGEgdHJlZSwNCj4gPiBh bmQNCj4gPiA+ICAgICAuLi4iIEhvd2V2ZXIsIHN1YnNlcXVlbnQgaXRlbXMgc2F5IHRoYXQgdGhl IHRyZWUgYWN0dWFsbHkNCj4gPiBkZXBlbmRzDQo+ID4gPiAgICAgb24gdGhlIGNvbnRlbnQgdHlw ZSAoY29uZmlnIGRhdGEsIFJQQywgbm90aWZpY2F0aW9uKS4NCj4gPiANCj4gPiBUaGUgaWRlYSBp cyB0aGF0IHRoZSBmaXJzdCBzZW50ZW5jZSBzYXlzIHRoYXQgYWxsIG5vZGVzIGluY2x1ZGluZw0K PiA+IGRlZmF1bHQgdmFsdWVzIGFyZSB0aGVyZSwgYW5kIHRoZSBuZXh0IGxpc3Qgc3BlY2lmaWVz IHdoaWNoIG5vZGVzIGFyZQ0KPiA+IHRoZXJlLCBkZXBlbmRpbmcgb24gY29udGV4dC4gIElmIHRo aXMgaXMgdW5jbGVhciwgY291bGQgeW91IHN1Z2dlc3QgYQ0KPiA+IGNoYW5nZT8NCj4gDQo+IG8g RGVmYXVsdCB2YWx1ZXMgYXJlIHN1YnN0aXR1dGVkIGZvciBhbGwgbWlzc2luZyBsZWFmcyBpbiB0 aGUNCj4gICBhY2Nlc3NpYmxlIGRhdGEgdHJlZSBmb3Igd2hpY2ggdGhlIGRlZmF1bHQgdmFsdWUg aXMgZGVmaW5lZC4NCj4gDQo+IFBlcmhhcHMgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIGFjY2Vz c2libGUgZGF0YSB0cmVlIGNvdWxkIGJlIG1vdmVkDQo+IGJlZm9yZSB0aGlzIGxpc3QuDQoNCk9y IG1heWJlIHdlIGNhbiByZW1vdmUgdGhlIGJ1bGxldCAiVGhlIGFjY2Vzc2libGUgdHJlZSBpcyBt YWRlIHVwDQpvZi4uLiIsIGFuZCBhZGQgeW91ciBuZXcgYnVsbGV0IGFzIHRoZSBsYXN0IGJ1bGxl dCBpbiB0aGUgc2Vjb25kIGxpc3QNCiJUaGUgYWNjZXNzaWJsZSBkYXRhIHRyZWUgZGVwZW5kcyBv biB0aGUgY29udGV4dCBub2RlOiIuDQoNCg0KL21hcnRpbg0K From mbj@tail-f.com Thu May 21 13: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 C3E073A6C0C for ; Thu, 21 May 2009 13:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=0.334, 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 lm+u7gc-4KW1 for ; Thu, 21 May 2009 13:00:04 -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 EBDDA3A6B97 for ; Thu, 21 May 2009 13:00:03 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id C1BD1616004; Thu, 21 May 2009 22:01:41 +0200 (CEST) Date: Thu, 21 May 2009 22:01:41 +0200 (CEST) Message-Id: <20090521.220141.04392268.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242903611.6931.103.camel@missotis> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242903611.6931.103.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] require-instance false 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, 21 May 2009 20:00:04 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAyMjo0MSArMDIwMDoNCj4gPiA+ICdJZiAi cmVxdWlyZS1pbnN0YW5jZSIgaXMgImZhbHNlIiwgdGhlIHZhbHVlIG9mIHRoZSBsZWFmDQo+ID4g PiAgIHdpdGggImxlYWZyZWYiIHR5cGUgbXVzdCBiZSBlcXVhbCB0byB0aGUgcmVmZXJyZWQgbGVh ZiBvbmx5IGlmIHRoZQ0KPiA+ID4gICBsYXR0ZXIgZXhpc3RzLicNCj4gPiANCj4gPiBJIGRvbid0 IHRoaW5rIHRoaXMgcHJvcHNlZCB0ZXh0IG1ha2VzIG11Y2ggc2Vuc2UgLSBpZiB0aGV5IGFyZSBl cXVhbA0KPiA+IGl0IG1lYW5zIHRoYXQgdGhlIHJlZmVycmVkIGxlYWYgZXhpc3QhICBJIHN1Z2dl c3Q6DQo+ID4gDQo+ID4gTkVXOg0KPiA+IA0KPiA+IElmICJyZXF1aXJlLWluc3RhbmNlIiBpcyAi ZmFsc2UiLCBpdCBtZWFucyB0aGF0IHRoZSBpbnN0YW5jZSBiZWluZw0KPiA+IHJlZmVycmVkIE1B WSBleGlzdCBpbiB2YWxpZCBkYXRhLg0KPiANCj4gLi4uIGFuZCBpZiBpdCBleGlzdHMsIGl0cyB2 YWx1ZSBNVVNUIGJlIGVxdWFsIHRvIHRoZSB2YWx1ZSBvZiB0aGUNCj4gcmVmZXJyaW5nIGxlYWYu DQoNClRoaXMgZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlLiAgSG93IGNhbiBpdCBleGlzdCAqd2l0 aG91dCogaXRzIHZhbHVlDQpiZWluZyBlcXVhbCB0byB0aGUgdmFsdWUgb2YgdGhlIHJlZmVycmlu ZyBsZWFmPyAgQ29uc2lkZXIgdGhlIGV4YW1wbGUNCmluIDkuOS42Lg0KDQogICAgIDxpbnRlcmZh Y2U+DQogICAgICAgPG5hbWU+ZXRoMDwvbmFtZT4NCiAgICAgPC9pbnRlcmZhY2U+DQogICAgIDxp bnRlcmZhY2U+DQogICAgICAgPG5hbWU+bG88L25hbWU+DQogICAgIDwvaW50ZXJmYWNlPg0KDQpU aGUgZm9sbG93aW5nIGxlYWZlZiBpcyB2YWxpZDoNCg0KICAgICA8bWdtdC1pbnRlcmZhY2U+ZXRo MDwvbWdtdC1pbnRlcmZhY2U+DQoNCmJlY2F1c2UgdGhlIGludGVyZmFjZSAnZXRoMCcgZXhpc3Rz LiAgVGhlIGZvbGxvd2luZyBpcyBpbnZhbGlkOg0KDQogICAgIDxtZ210LWludGVyZmFjZT5ldGgx PC9tZ210LWludGVyZmFjZT4NCg0KYmVjYXVzZSB0aGUgaW50ZXJmYWNlICdldGgxJyBkb2VzIG5v dCBleGlzdC4NCg0KDQovbWFydGluDQoNCiAgDQo= From mbj@tail-f.com Thu May 21 13:03: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 CF9953A6768 for ; Thu, 21 May 2009 13:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.304, 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 Z-H2u2erb9y8 for ; Thu, 21 May 2009 13:03:29 -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 1439B3A68FA for ; Thu, 21 May 2009 13:03:29 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 4CF59616053; Thu, 21 May 2009 22:05:04 +0200 (CEST) Date: Thu, 21 May 2009 22:05:04 +0200 (CEST) Message-Id: <20090521.220504.34770197.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A154CDC.4050105@ericsson.com> References: <4A154CDC.4050105@ericsson.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] Empty deviation 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, 21 May 2009 20:03:29 -0000 Balazs Lengyel wrote: > Hello, > What does an empty deviation statement mean? > > deviation /base:system/base:name-server ; > > According to the draft this is legal. Is this just stupid and we don't care or > should we prohibit it? Maybe we should make the cardinality of the deviate > statement 1..n instead of 0..n. Yes, this is a bug. The ABNF grammar is correct though - it requires at least one deviate statement. I will change the text to 1..n as you suggested. /martin From spakes@snmp.com Thu May 21 13: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 56CFB3A6845 for ; Thu, 21 May 2009 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 qLa4C8btpoPm for ; Thu, 21 May 2009 13:06:15 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id E73763A6D85 for ; Thu, 21 May 2009 13:06: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 QAA14671; Thu, 21 May 2009 16:07:47 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA01155; Thu, 21 May 2009 16:07:46 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 21 May 2009 16:07:46 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org In-Reply-To: Message-ID: References: <20090518.095605.45155468.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] require-instance 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, 21 May 2009 20:06:16 -0000 On Thu, 21 May 2009, David Spakes wrote: > In Section 9.13.4 (Usage Example for instance-indentifier), the first > example is: > > /* instance-identifier for a container */ > /ex:system/ex:services/ex:ssh > > Would someone clarify my understanding? I have these questions: > > 1. Can the instance-identifier refer to a container that exists "only > for organizing the hierarchy of data nodes"? Or, must the > instance-identifier refer only to a "presence container"? > > 2. If the instance-identifier has a require-instance substatement, must > it refer only to a "presence container" that presently exists? Let me rephrase question 2: 2. If the instance-identifier has the substatement "require-instance true", must it refer only to a "presence container" that presently exists? Regards, David Spakes ------------------------------------------------------------- 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 andy@netconfcentral.com Thu May 21 13:18: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 3E5273A6D48 for ; Thu, 21 May 2009 13:18:18 -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 N1fFqStTFraP for ; Thu, 21 May 2009 13:18:17 -0700 (PDT) Received: from n23.bullet.mail.mud.yahoo.com (n23.bullet.mail.mud.yahoo.com [68.142.206.162]) by core3.amsl.com (Postfix) with SMTP id 663F53A6CDD for ; Thu, 21 May 2009 13:18:17 -0700 (PDT) Received: from [68.142.200.226] by n23.bullet.mail.mud.yahoo.com with NNFMP; 21 May 2009 20:19:54 -0000 Received: from [68.142.201.69] by t7.bullet.mud.yahoo.com with NNFMP; 21 May 2009 20:19:54 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 21 May 2009 20:19:54 -0000 X-Yahoo-Newman-Id: 26576.87775.bm@omp421.mail.mud.yahoo.com Received: (qmail 22294 invoked from network); 21 May 2009 20:19:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 21 May 2009 20:19:52 -0000 X-YMail-OSG: pfxFjzUVM1nrCRzoBm45_PNp9OG64STjuE9p_C9R_EfVQ8BekY1ECfxtWuAAGeDPbTkyFw8Zdye1Rcw1oIwsklN6ywyheOLSUTd0P6MA3TxOPqgh3sMiAnj6506RGUQjdsgRm1Ff06YanmDPq52vPjPEFgD488m3V5sOcYCXbOftVdtfoIJ_tFopI3bQ8rTiDKKKpP8PoC41Uly5ovjwspvovHkg9IfG__n2vyTMtkIe_BCkP4UnlQQ93j0FYeuDAemUsS51RnSiy1HeRslh3riOT4TbOKck.T0c8XXp15u9YKn089I6SKvBj6UhjaiGhAyJ2hGBaF1NPspILCuGmGZyQ1pl9zZPY1B_YIY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A15B752.8050602@netconfcentral.com> Date: Thu, 21 May 2009 13:19:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242894796.6931.65.camel@missotis> <20090521.213810.264286251.mbj@tail-f.com> In-Reply-To: <20090521.213810.264286251.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] revision mismatch 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, 21 May 2009 20:18:18 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: >>>> - Sec. 5.1.1: The spec doesn't ensure that both parties in a NETCONF >>>> session always use the same module revisions >>> This is by design. We cannot assume that all clients always have the >>> latest version of a particular module. >> It is a strange contract where each party may work with a different >> text. I didn't get this was a feature, so I disagree now. > > Are you suggesting that if a server advertises module A, revision X, > and the client does not understand A rev X, then the client MUST close > the session? > don't do that! what if get-schema() is supported? what if the manager auto-magically uses get-schema() to fill in the missing modules? This is the best part of the ietf-netconf-state module, so let's use it! It is up to the application/operator to decide how to handle this problem. > > /martin Andy From mbj@tail-f.com Thu May 21 13:18: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 3B5493A6D48 for ; Thu, 21 May 2009 13:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.279, 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 9PU9bF0OpPXd for ; Thu, 21 May 2009 13:18: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 833923A6D25 for ; Thu, 21 May 2009 13:18:51 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 33E2D616004; Thu, 21 May 2009 22:20:25 +0200 (CEST) Date: Thu, 21 May 2009 22:20:24 +0200 (CEST) Message-Id: <20090521.222024.246864779.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <003501c9da32$12205aa0$6801a8c0@oemcomputer> References: <20090520.224146.220136501.mbj@tail-f.com> <1242899308.6931.95.camel@missotis> <003501c9da32$12205aa0$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=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] character encoding 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, 21 May 2009 20:18:57 -0000 IlJhbmR5IFByZXN1aG4iIDxyYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tPiB3cm90ZToNCj4g SGkgLQ0KPiANCj4gPiBGcm9tOiAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQGNlc25ldC5jej4N Cj4gPiBUbzogIk1hcnRpbiBCam9ya2x1bmQiIDxtYmpAdGFpbC1mLmNvbT4NCj4gPiBDYzogPG5l dG1vZEBpZXRmLm9yZz4NCj4gPiBTZW50OiBUaHVyc2RheSwgTWF5IDIxLCAyMDA5IDI6NDggQU0N Cj4gPiBTdWJqZWN0OiBbbmV0bW9kXSBjaGFyYWN0ZXIgZW5jb2RpbmcgW1dhczogcmV2aWV3DQo+ ID4gb2ZkcmFmdC1pZXRmLW5ldG1vZC15YW5nLTA1XQ0KPiA+DQo+ID4gTWFydGluIEJqb3JrbHVu ZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAyMjo0MSArMDIwMDoNCj4gPiA+ID4gLSBTZWMu IDkuNC4xOiBFbmNvZGluZ3MgdGhhdCBldmVyeSBpbXBsZW1lbnRhdGlvbiBtdXN0IHN1cHBvcnQN Cj4gPiA+IHNob3VsZA0KPiA+ID4gPiAgIGJlIHNwZWNpZmllZCBoZXJlLCBmb3IgZXhhbXBsZSBV VEYtOCBvciBVVEYtMTYuIEJ1dCBpbiBhbiBhcmd1bWVudA0KPiA+ID4gb2YNCj4gPiA+ID4gICAn ZGVmYXVsdCcsIGEgc3RyaW5nIG11c3QgYmUgYWx3YXlzIGluIFVURi04Lg0KPiA+ID4NCj4gPiA+ IFlBTkcgbW9kdWxlcyBhcmUgd3JpdHRlbiBpbiBVVEYtOCwgaXNuJ3QgdGhhdCBlbm91Z2g/ICBJ ZiBub3QsIGNvdWxkDQo+ID4gPiB5b3UgcHJvcG9zZSBzb21lIHRleHQ/DQo+ID4NCj4gPiBFbmNv ZGluZyBvZiBQRFVzIGZvbGxvd3MgWE1MIHJ1bGVzLCBzbyBJIHN1Z2dlc3QgdG8gaGF2ZSB0aGUg c2FtZQ0KPiA+IHJlcXVpcmVtZW50cyBhcyB0aGUgWE1MIHNwZWM6DQo+ID4NCj4gPiAiQWxsIGlt cGxlbWVudGF0aW9ucyBNVVNUIGFjY2VwdCB0aGUgVVRGLTggYW5kIFVURi0xNiBlbmNvZGluZ3Mg b2YNCj4gPiBJU08vSUVDIDEwNjQ2IHNwZWNpZmllZCBhY2NvcmRpbmcgdG8gW1hNTF0sIHNlY3Rp b24gNC4zLjMuIg0KPiAuLi4NCj4gDQo+IFRoZXJlIGlzIGxpdHRsZSBvciBubyB2YWx1ZSB0byBo YXZpbmcgdHdvIG1hbmRhdG9yeSBlbmNvZGluZ3MuDQo+IA0KPiBIYXZpbmcgdHdvIG9wdGlvbnMg aW5jcmVhc2VzIHRoZSBjaGFuY2VzIG9mIGVycm9yLCBhbmQgdGhlIGNvZGUgcG9pbnRzDQo+IHJl cXVpcmluZyBtdWx0aXBsZSB3b3JkcyB0byBlbmNvZGUgaW4gVVRGLTE2IGFyZSBzdWZmaWNpZW50 bHkgdW5jb21tb24NCj4gdGhhdCBpdCdzIGxpa2VseSB0aGF0IHRob3NlIGNvZGUgcGF0aHMgd2ls bCBub3QgYmUgcHJvcGVybHkgdGVzdGVkLg0KPiANCj4gVVRGLTggaXMgdGhlIGNsZWFyIHdpbm5l ciBpbiB0aGUgZW5jb2Rpbmcgd2Fycy4gIFRoYXQgc2hvdWxkIGJlIHRoZSBzb2xlDQo+IG1hbmRh dG9yeSBlbmNvZGluZywgSU1PLg0KDQorMQ0KDQpCdXQgSSBkb24ndCB0aGluayB0aGlzIHNob3Vs ZCBiZSBzcGVjaWZpZWQgaW4gdGhlIFlBTkcgZHJhZnQuICBZQU5HDQp3aWxsIHdvcmsgd2l0aCBh bnkgZW5jb2RpbmdzIG9mIHRoZSBYTUwgaW4gdGhlIE5FVENPTkYgcHJvdG9jb2wuICBTbw0KaWYg d2Ugd2FudCB0byB0YWxrIGFib3V0IHRoZXNlIGVuY29kaW5ncywgaXQgc2hvdWxkIGJlIGluIDQ3 NDFiaXMuDQoNCg0KL21hcnRpbg0K From mbj@tail-f.com Thu May 21 13:26: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 8A49D3A6EE8 for ; Thu, 21 May 2009 13:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=0.257, 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 XrrnIoHo-WFw for ; Thu, 21 May 2009 13:26:57 -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 AD3283A6DF7 for ; Thu, 21 May 2009 13:26:57 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 3D967616004; Thu, 21 May 2009 22:28:17 +0200 (CEST) Date: Thu, 21 May 2009 22:28:17 +0200 (CEST) Message-Id: <20090521.222817.21625953.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A15B752.8050602@netconfcentral.com> References: <1242894796.6931.65.camel@missotis> <20090521.213810.264286251.mbj@tail-f.com> <4A15B752.8050602@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=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] revision mismatch 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, 21 May 2009 20:26:58 -0000 QW5keSBCaWVybWFuIDxhbmR5QG5ldGNvbmZjZW50cmFsLmNvbT4gd3JvdGU6DQo+IE1hcnRpbiBC am9ya2x1bmQgd3JvdGU6DQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3 cm90ZToNCj4gPj4gTWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAy Mjo0MSArMDIwMDoNCj4gPj4+PiAtIFNlYy4gNS4xLjE6IFRoZSBzcGVjIGRvZXNuJ3QgZW5zdXJl IHRoYXQgYm90aCBwYXJ0aWVzIGluIGEgTkVUQ09ORg0KPiA+Pj4+ICAgc2Vzc2lvbiBhbHdheXMg dXNlIHRoZSBzYW1lIG1vZHVsZSByZXZpc2lvbnMNCj4gPj4+IFRoaXMgaXMgYnkgZGVzaWduLiAg V2UgY2Fubm90IGFzc3VtZSB0aGF0IGFsbCBjbGllbnRzIGFsd2F5cyBoYXZlIHRoZQ0KPiA+Pj4g bGF0ZXN0IHZlcnNpb24gb2YgYSBwYXJ0aWN1bGFyIG1vZHVsZS4NCj4gPj4gSXQgaXMgYSBzdHJh bmdlIGNvbnRyYWN0IHdoZXJlIGVhY2ggcGFydHkgbWF5IHdvcmsgd2l0aCBhIGRpZmZlcmVudA0K PiA+PiB0ZXh0LiBJIGRpZG4ndCBnZXQgdGhpcyB3YXMgYSBmZWF0dXJlLCBzbyBJIGRpc2FncmVl IG5vdy4NCj4gPiBBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCBpZiBhIHNlcnZlciBhZHZlcnRpc2Vz IG1vZHVsZSBBLCByZXZpc2lvbiBYLA0KPiA+IGFuZCB0aGUgY2xpZW50IGRvZXMgbm90IHVuZGVy c3RhbmQgQSByZXYgWCwgdGhlbiB0aGUgY2xpZW50IE1VU1QgY2xvc2UNCj4gPiB0aGUgc2Vzc2lv bj8NCj4gPiANCj4gDQo+IGRvbid0IGRvIHRoYXQhDQoNCkkgZGVmaW5pdGVseSBhZ3JlZTsgSSdt IGp1c3QgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCBMYWRhIGlzIHNheWluZy4NCklNTywgcmVx dWlyaW5nIHRoYXQgYm90aCBzaWRlcyBoYXZlIHRoZSBzYW1lIHJldmlzaW9ucyB3b3VsZCBzaW1w bHkNCm5vdCB3b3JrIGluIHJlYWwgbGlmZS4gIFdlIGNhbiBub3QgcmVxdWlyZSB0aGF0IGFsbCBj bGllbnRzIGFyZQ0KdXBkYXRlZCBpbiBzeWNoIHdpdGggdGhlIHNlcnZlcnMuICBUaGUgbW9kdWxl IHVwZGF0aW5nIHJ1bGVzIGFyZQ0Kd3JpdHRlbiBzcGVjaWZpY2FsbHkgdG8gc3VwcG9ydCByZXZp c2lvbiBtaXNtYXRjaCAtIHRoZSBmaXJzdCBydWxlIGlzOg0KDQogIC0gUHJvdGVjdCBvbGQgY2xp ZW50cw0KICAgIFdlIHdhbnQgYSBjbGllbnQgdGhhdCB1c2VzIHZlcnNpb24geCBvZiBhIG1vZHVs ZSB0byBiZSBhYmxlIHRvDQogICAgZnVuY3Rpb24gd2hlbiB0YWxraW5nIHRvIGEgc2VydmVyIGlt cGxlbWVudGluZyB2ZXJzaW9uIHgrMS4NCg0KDQovbWFydGluDQo= From mbj@tail-f.com Thu May 21 13:41: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 EA4353A6C41 for ; Thu, 21 May 2009 13:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.239, 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 c-qh9EPj7dOf for ; Thu, 21 May 2009 13:41: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 756D43A6EDA for ; Thu, 21 May 2009 13:40:56 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 59F1C616004; Thu, 21 May 2009 22:42:25 +0200 (CEST) Date: Thu, 21 May 2009 22:42:25 +0200 (CEST) Message-Id: <20090521.224225.252682078.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <20090518.095605.45155468.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] require-instance 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, 21 May 2009 20:41:15 -0000 Hi, David Spakes wrote: > On Thu, 21 May 2009, David Spakes wrote: > > > In Section 9.13.4 (Usage Example for instance-indentifier), the first > > example is: > > > > /* instance-identifier for a container */ > > /ex:system/ex:services/ex:ssh > > > > Would someone clarify my understanding? I have these questions: > > > > 1. Can the instance-identifier refer to a container that exists "only > > for organizing the hierarchy of data nodes"? Good question - my first reaction was that this would not make much sense. But suppose you designed an access control module, where you specify access to subtrees. Each such subtree could be an instance-identifier, and it could be useful to point to a NP-container. > > Or, must the > > instance-identifier refer only to a "presence container"? > > > > 2. If the instance-identifier has a require-instance substatement, must > > it refer only to a "presence container" that presently exists? > > > Let me rephrase question 2: > > 2. If the instance-identifier has the substatement > "require-instance true", must it refer only to a > "presence container" that presently exists? First of all, an instance-identifier can also refer to leafs and list instances. As for NP-containers, I don't think we should rule them out. A leaf of type instance-identifier with require-instance true will probably have some description of its semantics, and some may have no restrictions what so ever, and some may say that the instance-identifier must refer to a list instance in list X or list Y, etc. /martin From andy@netconfcentral.com Thu May 21 14:01: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 C20753A6A72 for ; Thu, 21 May 2009 14:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.074, 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 ciAfDogLCXEj for ; Thu, 21 May 2009 14:01:53 -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 213A03A69BA for ; Thu, 21 May 2009 14:01:53 -0700 (PDT) Received: (qmail 69875 invoked from network); 21 May 2009 21:03:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 21 May 2009 21:03:28 -0000 X-YMail-OSG: OveMpSkVM1m1g2Wx0pyQgYTHltc_upG3jRAu8pou5a0rNc58sOgIlVHv4l6YBQNouyLdZZvfvt8UwQON0449CsMGbGcoMitthzlbGZ.IsQ4kzr_mk.XfA76macRrQ3Mah2rmVN2lYc6hNV2MQjznTUtTTXx5QySd60hR_bTNGSLDA8sJd2qvhmjsl.U8uQFrfmjHUFEfr.wIwvIpYyTsS4Q1Y0vRrj3neKtYcObUs9ny0Sj3_fcCTuz4gb5WZs3GwDTV7DtGCkOgo2in1ReUvdlnEfWHppgZcyQhew3Tkeb1cafpNavaUCNYJsYWTmun6U1L_hAlzaVSC0G3H4bUztHuSGK8XIb2ebMgRg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A15C19F.6010909@netconfcentral.com> Date: Thu, 21 May 2009 14:03:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090518.095605.45155468.mbj@tail-f.com> <20090521.224225.252682078.mbj@tail-f.com> In-Reply-To: <20090521.224225.252682078.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] require-instance 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, 21 May 2009 21:01:53 -0000 Martin Bjorklund wrote: > Hi, > > David Spakes wrote: >> On Thu, 21 May 2009, David Spakes wrote: >> >>> In Section 9.13.4 (Usage Example for instance-indentifier), the first >>> example is: >>> >>> /* instance-identifier for a container */ >>> /ex:system/ex:services/ex:ssh >>> >>> Would someone clarify my understanding? I have these questions: >>> >>> 1. Can the instance-identifier refer to a container that exists "only >>> for organizing the hierarchy of data nodes"? > > Good question - my first reaction was that this would not make much > sense. But suppose you designed an access control module, where you > specify access to subtrees. Each such subtree could be an > instance-identifier, and it could be useful to point to a > NP-container. IMO, it is fine to point at any real XML node in the database. I think error-path should be clarified to contain an instance-identifier (*). * -- except sometimes the keys are missing or there are too many container instances, etc. Then the node is identified by position (foo[2]) in the error-path. (remember that foo == foo[1]) Consider an access control rule, where you want to make sure the user cannot even create the NP container, let alone any of the sensitive data within it. > >>> Or, must the >>> instance-identifier refer only to a "presence container"? >>> >>> 2. If the instance-identifier has a require-instance substatement, must >>> it refer only to a "presence container" that presently exists? >> >> Let me rephrase question 2: >> >> 2. If the instance-identifier has the substatement >> "require-instance true", must it refer only to a >> "presence container" that presently exists? > > First of all, an instance-identifier can also refer to leafs and list > instances. As for NP-containers, I don't think we should rule them > out. A leaf of type instance-identifier with require-instance true > will probably have some description of its semantics, and some may > have no restrictions what so ever, and some may say that the > instance-identifier must refer to a list instance in list X or list Y, > etc. > > > /martin Andy From lhotka@cesnet.cz Thu May 21 23:12: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 032313A68AA for ; Thu, 21 May 2009 23:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=0.382, 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 eBTVZSl-xtIy for ; Thu, 21 May 2009 23:12:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BD1503A689F for ; Thu, 21 May 2009 23:12:06 -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 4258CD800C7 for ; Fri, 22 May 2009 08:13:23 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <003501c9da32$12205aa0$6801a8c0@oemcomputer> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242899308.6931.95.camel@missotis> <003501c9da32$12205aa0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 08:13:22 +0200 Message-Id: <1242972802.6374.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] character encoding [Was: review ofdraft-ietf-netmod-yang-05] 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, 22 May 2009 06:12:08 -0000 Randy Presuhn píše v Čt 21. 05. 2009 v 09:34 -0700: > > > > "All implementations MUST accept the UTF-8 and UTF-16 encodings of > > ISO/IEC 10646 specified according to [XML], section 4.3.3." > ... > > There is little or no value to having two mandatory encodings. Maybe, but then the XML in NETCONF PDUs would be more restricted than general XML. From the XML 1.0 spec: "All XML processors must accept the UTF-8 and UTF-16 encodings of 10646; ..." > > Having two options increases the chances of error, and the code points > requiring multiple words to encode in UTF-16 are sufficiently uncommon > that it's likely that those code paths will not be properly tested. > > UTF-8 is the clear winner in the encoding wars. That should be the sole > mandatory encoding, IMO. >From http://en.wikipedia.org/wiki/UTF-16: "UTF-16 is the native internal representation of text in the Microsoft Windows 2000/XP/2003/Vista/CE; Qualcomm BREW operating systems; the Java and .NET bytecode environments; Mac OS X's Cocoa and Core Foundation frameworks; and the Qt cross-platform graphical widget toolkit." Lada > > RAndy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 23:26: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 C715F3A6AA0 for ; Thu, 21 May 2009 23:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.378, 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 sPS3HkZpHezR for ; Thu, 21 May 2009 23:26:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0768D3A689F for ; Thu, 21 May 2009 23:26: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 ADB7AD800BD; Fri, 22 May 2009 08:28:05 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090521.213717.193017582.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242894219.6931.59.camel@missotis> <20090521.213717.193017582.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 08:28:05 +0200 Message-Id: <1242973685.6374.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] definitions 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, 22 May 2009 06:26:39 -0000 Martin Bjorklund píše v Čt 21. 05. 2009 v 21:37 +0200: > The text says: > > The "import" statement makes definitions from one module available > inside another module or submodule. > > Could you propose text to make it more clear? The "import" statement makes identifiers from the namespace of the imported module available in the importing module. In particular, the importing module may o use groupings and typedefs defined at the top level of the imported module; o refer to features defined in the imported module; o use any data node of the imported module as the target node for the "augment" statement. Unlike "include", the "import" statement doesn't contribute the data tree from the imported to the importing module. > > BTW, RNG doesn't have 'import' does it? It's called "include". Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 23:41: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 E03793A6D94 for ; Thu, 21 May 2009 23:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=0.375, 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 AN7RXTtHhpSS for ; Thu, 21 May 2009 23:41:20 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2CFA13A6934 for ; Thu, 21 May 2009 23:41:20 -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 87D18D800C5; Fri, 22 May 2009 08:42:57 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090521.214534.229898853.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242897897.6931.80.camel@missotis> <20090521.214534.229898853.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 08:42:56 +0200 Message-Id: <1242974576.6374.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] namespace stmt 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, 22 May 2009 06:41:21 -0000 Martin Bjorklund píše v Čt 21. 05. 2009 v 21:45 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > > > - Sec. 7.1.3: The namespace is used not only for XML elements but > > > also > > > > for extensions and features. > > > > > > Extensions and features never show up in the XML. The namespace does > > > not affect them. > > > > The 'namespace' statements defines the namespace and prefix for objects > > within the YANG module, too. > > I'm sorry, I don't understand your point. Could you suggest some text > that would go into 7.1.3? The "namespace" statement defines the XML namespace to which all identifiers defined by the module belong, with the exception of data node identifiers defined inside a grouping (see Section 7.12 for details). Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu May 21 23: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 E06DE3A6C48 for ; Thu, 21 May 2009 23:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=0.371, 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 wFxQ2uotcQQ7 for ; Thu, 21 May 2009 23:54:40 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1DBDA3A6AA0 for ; Thu, 21 May 2009 23:54:40 -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 05D1BD800CC; Fri, 22 May 2009 08:56:09 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090521.220141.04392268.mbj@tail-f.com> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242903611.6931.103.camel@missotis> <20090521.220141.04392268.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 08:56:08 +0200 Message-Id: <1242975368.6374.42.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] require-instance false 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, 22 May 2009 06:54:41 -0000 Martin Bjorklund píše v Čt 21. 05. 2009 v 22:01 +0200: > > > If "require-instance" is "false", it means that the instance being > > > referred MAY exist in valid data. > > > > ... and if it exists, its value MUST be equal to the value of the > > referring leaf. > > This does not make much sense. How can it exist *without* its value > being equal to the value of the referring leaf? leafref needn't refer to a list key: leaf foo { type string; } leaf fooref { type leafref { path "../foo"; } } Then the following is made illegal by the requirement: foo bar Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri May 22 00:17: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 D30A43A6781 for ; Fri, 22 May 2009 00:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=0.368, 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 oq+KXVKMRmq1 for ; Fri, 22 May 2009 00:17:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 05EBF3A6860 for ; Fri, 22 May 2009 00:17:19 -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 9ED6AD800C5; Fri, 22 May 2009 09:18:43 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090521.222024.246864779.mbj@tail-f.com> References: <20090520.224146.220136501.mbj@tail-f.com> <1242899308.6931.95.camel@missotis> <003501c9da32$12205aa0$6801a8c0@oemcomputer> <20090521.222024.246864779.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 09:18:43 +0200 Message-Id: <1242976723.6374.54.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] character encoding 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, 22 May 2009 07:17:19 -0000 Martin Bjorklund píše v Čt 21. 05. 2009 v 22:20 +0200: > But I don't think this should be specified in the YANG draft. YANG > will work with any encodings of the XML in the NETCONF protocol. So > if we want to talk about these encodings, it should be in 4741bis. > True, but sec. 9.4.1 says "A string value is lexicographically represented as character data in the XML encoding." There is no unique "XML encoding". Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri May 22 00:34: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 431283A6B33 for ; Fri, 22 May 2009 00:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.183, 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 WAyWqjq-T883 for ; Fri, 22 May 2009 00:34: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 6F7663A6860 for ; Fri, 22 May 2009 00:34: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 4AA50616004; Fri, 22 May 2009 09:36:15 +0200 (CEST) Date: Fri, 22 May 2009 09:36:14 +0200 (CEST) Message-Id: <20090522.093614.158857696.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242976723.6374.54.camel@missotis> References: <003501c9da32$12205aa0$6801a8c0@oemcomputer> <20090521.222024.246864779.mbj@tail-f.com> <1242976723.6374.54.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] character encoding 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, 22 May 2009 07:34:41 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMjEuIDA1LiAyMDA5IHYgMjI6MjAgKzAyMDA6DQo+ID4gQnV0IEkg ZG9uJ3QgdGhpbmsgdGhpcyBzaG91bGQgYmUgc3BlY2lmaWVkIGluIHRoZSBZQU5HIGRyYWZ0LiAg WUFORw0KPiA+IHdpbGwgd29yayB3aXRoIGFueSBlbmNvZGluZ3Mgb2YgdGhlIFhNTCBpbiB0aGUg TkVUQ09ORiBwcm90b2NvbC4gIFNvDQo+ID4gaWYgd2Ugd2FudCB0byB0YWxrIGFib3V0IHRoZXNl IGVuY29kaW5ncywgaXQgc2hvdWxkIGJlIGluIDQ3NDFiaXMuDQo+ID4gDQo+IA0KPiBUcnVlLCBi dXQgc2VjLiA5LjQuMSBzYXlzDQo+IA0KPiAiQSBzdHJpbmcgdmFsdWUgaXMgbGV4aWNvZ3JhcGhp Y2FsbHkgcmVwcmVzZW50ZWQgYXMgY2hhcmFjdGVyIGRhdGEgaW4NCj4gICAgdGhlIFhNTCBlbmNv ZGluZy4iDQo+IA0KPiBUaGVyZSBpcyBubyB1bmlxdWUgIlhNTCBlbmNvZGluZyIuDQoNCldlIHRh bGsgYWJvdXQgWE1MIGVuY29kaW5nIGluIG1hbnkgcGxhY2VzLiAgVGhpcyBtZWFucyBob3cgZGF0 YSBpcw0KZW5jb2RlZCBpbnRvIFhNTDsgaXQgZG9lcyBub3QgcmVmZXIgdG8gd2hpY2ggY2hhcmFj dGVyIGVuY29kaW5nIHNjaGVtZQ0KdGhlIE5FVENPTkYgUERVcyB1c2UuDQoNCg0KL21hcnRpbg0K From cfinss@dial.pipex.com Fri May 22 02:15: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 DB9EE3A6831 for ; Fri, 22 May 2009 02:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, 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 UplG1kGk9qgI for ; Fri, 22 May 2009 02:15:16 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id B65B73A6DAA for ; Fri, 22 May 2009 02:15:15 -0700 (PDT) X-Trace: 250151855/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.176/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.176 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: AqwEAAEKFko+vBGw/2dsb2JhbACDKItQw0AIhAMF X-IronPort-AV: E=Sophos;i="4.41,232,1241391600"; d="scan'208";a="250151855" X-IP-Direction: IN Received: from 1cust176.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.176]) by smtp.pipex.tiscali.co.uk with SMTP; 22 May 2009 10:16:00 +0100 Message-ID: <001201c9dab5$6f681e40$0601a8c0@allison> From: "tom.petch" To: "Randy Presuhn" , "Martin Bjorklund" References: <20090520.224146.220136501.mbj@tail-f.com><1242899308.6931.95.camel@missotis><003501c9da32$12205aa0$6801a8c0@oemcomputer> <20090521.222024.246864779.mbj@tail-f.com> Date: Fri, 22 May 2009 10:06:14 +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 Cc: netmod@ietf.org Subject: Re: [netmod] character encoding 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: Fri, 22 May 2009 09:15:16 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Thursday, May 21, 2009 10:20 PM > "Randy Presuhn" wrote: > > > From: "Ladislav Lhotka" > > > To: "Martin Bjorklund" > > > Cc: > > > Sent: Thursday, May 21, 2009 2:48 AM > > > Subject: [netmod] character encoding [Was: review > > > ofdraft-ietf-netmod-yang-05] > > > > > > Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > > > > - Sec. 9.4.1: Encodings that every implementation must support > > > > should > > > > > be specified here, for example UTF-8 or UTF-16. But in an argument > > > > of > > > > > 'default', a string must be always in UTF-8. > > > > > > > > YANG modules are written in UTF-8, isn't that enough? If not, could > > > > you propose some text? > > > > > > Encoding of PDUs follows XML rules, so I suggest to have the same > > > requirements as the XML spec: > > > > > > "All implementations MUST accept the UTF-8 and UTF-16 encodings of > > > ISO/IEC 10646 specified according to [XML], section 4.3.3." > > ... > > > > There is little or no value to having two mandatory encodings. > > > > Having two options increases the chances of error, and the code points > > requiring multiple words to encode in UTF-16 are sufficiently uncommon > > that it's likely that those code paths will not be properly tested. > > > > UTF-8 is the clear winner in the encoding wars. That should be the sole > > mandatory encoding, IMO. > > +1 > > But I don't think this should be specified in the YANG draft. YANG > will work with any encodings of the XML in the NETCONF protocol. So > if we want to talk about these encodings, it should be in 4741bis. > Um. Does 6. YANG syntax still say " YANG modules are written in the UTF-8 [RFC3629] character set." ? I have problems with this because UTF-8 is not a character set but a transformation format or character (en)coding syntax or ... (depending on your SDO:-( And do we really mean that YANG modules can be written in a mixture of Han and Katakana and ... because that is what it seems to tell me? Tom Petch > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Fri May 22 02:20: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 DCF683A6D46 for ; Fri, 22 May 2009 02:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.182, 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 gLW20fKv3fsr for ; Fri, 22 May 2009 02:20:50 -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 F334A3A6D94 for ; Fri, 22 May 2009 02:20:43 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DA49C616004; Fri, 22 May 2009 11:21:50 +0200 (CEST) Date: Fri, 22 May 2009 11:21:50 +0200 (CEST) Message-Id: <20090522.112150.238702753.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <001201c9dab5$6f681e40$0601a8c0@allison> References: <003501c9da32$12205aa0$6801a8c0@oemcomputer> <20090521.222024.246864779.mbj@tail-f.com> <001201c9dab5$6f681e40$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=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] character encoding 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, 22 May 2009 09:20:51 -0000 "tom.petch" wrote: > Um. Does > > 6. YANG syntax > > still say > > " YANG modules are written in the UTF-8 [RFC3629] character set." > ? > > I have problems with this because UTF-8 is not a character set but a > transformation format or character (en)coding syntax or ... (depending on your > SDO:-( What should we write instead? > And do we really mean that YANG modules can be written in a mixture of Han and > Katakana and ... because that is what it seems to tell me? Would this be a problem? /martin From lhotka@cesnet.cz Fri May 22 02:27: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 5B6C53A6E36 for ; Fri, 22 May 2009 02:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=0.364, 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 VONesRQhz+My for ; Fri, 22 May 2009 02:27:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8B6793A68AA for ; Fri, 22 May 2009 02:27:27 -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 ED417D800BD; Fri, 22 May 2009 11:28:59 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090522.093614.158857696.mbj@tail-f.com> References: <003501c9da32$12205aa0$6801a8c0@oemcomputer> <20090521.222024.246864779.mbj@tail-f.com> <1242976723.6374.54.camel@missotis> <20090522.093614.158857696.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 11:28:59 +0200 Message-Id: <1242984539.6374.59.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] character encoding 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, 22 May 2009 09:27:28 -0000 Martin Bjorklund píše v Pá 22. 05. 2009 v 09:36 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Čt 21. 05. 2009 v 22:20 +0200: > > > But I don't think this should be specified in the YANG draft. YANG > > > will work with any encodings of the XML in the NETCONF protocol. So > > > if we want to talk about these encodings, it should be in 4741bis. > > > > > > > True, but sec. 9.4.1 says > > > > "A string value is lexicographically represented as character data in > > the XML encoding." > > > > There is no unique "XML encoding". > > We talk about XML encoding in many places. This means how data is > encoded into XML; it does not refer to which character encoding scheme > the NETCONF PDUs use. The word "encoding" denotes (in the XML spec at least) the process of mapping characters to byte sequences. I propose to add the following term to Sec. 3: o character: atomic unit of text as specified by [ISO/IEC10646]. And then use just "character". Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri May 22 02:34: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 4AEB03A6BBC for ; Fri, 22 May 2009 02:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.411 X-Spam-Level: X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[AWL=-0.939, 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 xC+bD29iraOu for ; Fri, 22 May 2009 02:34:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2B7253A6A33 for ; Fri, 22 May 2009 02:34:15 -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 A4818D800BD for ; Fri, 22 May 2009 11:35:53 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <001201c9dab5$6f681e40$0601a8c0@allison> References: <20090520.224146.220136501.mbj@tail-f.com> <1242899308.6931.95.camel@missotis> <003501c9da32$12205aa0$6801a8c0@oemcomputer> <20090521.222024.246864779.mbj@tail-f.com> <001201c9dab5$6f681e40$0601a8c0@allison> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 11:35:53 +0200 Message-Id: <1242984953.6374.65.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] character encoding 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, 22 May 2009 09:34:16 -0000 tom.petch píše v Pá 22. 05. 2009 v 10:06 +0200: > Um. Does > > 6. YANG syntax > > still say > > " YANG modules are written in the UTF-8 [RFC3629] character set." > ? > > I have problems with this because UTF-8 is not a character set but a > transformation format or character (en)coding syntax or ... (depending > on your > SDO:-( It specifies the encoding of YANG modules in text files. > > And do we really mean that YANG modules can be written in a mixture of > Han and > Katakana and ... because that is what it seems to tell me? IMO, yes. Lada (Láďa, actually :-) -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Fri May 22 03:07:33 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 6D0D83A63EB for ; Fri, 22 May 2009 03:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.146, 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 vznszdgzsOfr for ; Fri, 22 May 2009 03:07:32 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4FB403A6B1B for ; Fri, 22 May 2009 03:07:32 -0700 (PDT) X-AuditID: c1b4fb3c-b7b94ae000000eff-42-4a1679c5b8fd Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E1.D5.03839.5C9761A4; Fri, 22 May 2009 12:09:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 May 2009 12:09:09 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 May 2009 12:09:08 +0200 Message-ID: <4A1679C5.2080801@ericsson.com> Date: Fri, 22 May 2009 12:09:09 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2009 10:09:09.0005 (UTC) FILETIME=[58CD93D0:01C9DAC5] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] leaf-ref questions 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, 22 May 2009 10:07:33 -0000 Hello, I am trying to understand leafref purely from the draft. I had a very hard time. I have some questions that the draft does not answer: 1) Does path point to a leaf node in the datastore or just a potential leaf node? The draft says about path: "It takes as an argument a string which MUST refer to a leaf node." However I think if require-instance is false, path only points to a potential leaf. 2) Does a leafref has it's own value or is it just a second way of accessing the referenced leaf? Can the value of the leafref and the referenced leaf be different? This is a potentially critical clarification. (I assume it is just a second handle, so state it does NOT have an own value.) 3) Can I write to a leaf of type leafref? Will that modify the value of the referenced leaf? 4) What does it mean if path's nodeset is empty? What happens if we read/write to this leafref? 5) What does it mean if path's nodeset consists of multiple nodes? What if they contain different values? What will we get at a read? If we write to such a leafref will we set all referenced leafs? Why do we have to allow multiple node nodesets? Balazs PS> Sorry if the questions have already been asked, I am lost in the many mail. From lhotka@cesnet.cz Fri May 22 04:00: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 817483A6CB4 for ; Fri, 22 May 2009 04:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=0.370, 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 tBzK5nok4mYp for ; Fri, 22 May 2009 04:00:08 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7A5543A6BFB for ; Fri, 22 May 2009 04:00:08 -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 050AAD800BD; Fri, 22 May 2009 13:01:47 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090521.222817.21625953.mbj@tail-f.com> References: <1242894796.6931.65.camel@missotis> <20090521.213810.264286251.mbj@tail-f.com> <4A15B752.8050602@netconfcentral.com> <20090521.222817.21625953.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 13:01:47 +0200 Message-Id: <1242990107.6374.97.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] revision mismatch 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, 22 May 2009 11:00:09 -0000 Martin Bjorklund píše v Čt 21. 05. 2009 v 22:28 +0200: > Andy Bierman wrote: > > Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > >> Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: > > >>>> - Sec. 5.1.1: The spec doesn't ensure that both parties in a NETCONF > > >>>> session always use the same module revisions > > >>> This is by design. We cannot assume that all clients always have the > > >>> latest version of a particular module. > > >> It is a strange contract where each party may work with a different > > >> text. I didn't get this was a feature, so I disagree now. > > > Are you suggesting that if a server advertises module A, revision X, > > > and the client does not understand A rev X, then the client MUST close > > > the session? > > > > > > > don't do that! > > I definitely agree; I'm just trying to understand what Lada is saying. Examples for two revisions of the same module, X0 is used by the server and X1 by the client, where X0 < X1: * Revision X1 adds a new enum value and the client tries to set the leaf to this value. For the server the value is invalid, so it returns an error message. * Even worse: Leaf "mtu" has no default value defined in X0 (but is not mandatory either), so the server uses a specific operational value, say 296, perhaps hardwired. Revision X1 adds a default value of 1500 for "mtu". When "mtu" is not in the configuration obtained from the server, the client concludes MTU is set to 1500, which is not the case. Are these not interoperability problems? Lada > IMO, requiring that both sides have the same revisions would simply > not work in real life. We can not require that all clients are > updated in sych with the servers. The module updating rules are > written specifically to support revision mismatch - the first rule is: > > - Protect old clients > We want a client that uses version x of a module to be able to > function when talking to a server implementing version x+1. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri May 22 04:27: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 9B88C3A6B00 for ; Fri, 22 May 2009 04:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.181, 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 kpis9isA638S for ; Fri, 22 May 2009 04:27: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 C3C403A6A9B for ; Fri, 22 May 2009 04:27: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 4E60A616004; Fri, 22 May 2009 13:29:16 +0200 (CEST) Date: Fri, 22 May 2009 13:29:15 +0200 (CEST) Message-Id: <20090522.132915.36538182.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242984539.6374.59.camel@missotis> References: <1242976723.6374.54.camel@missotis> <20090522.093614.158857696.mbj@tail-f.com> <1242984539.6374.59.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] character encoding 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, 22 May 2009 11:27:41 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQw6EgMjIuIDA1LiAyMDA5IHYgMDk6MzYgKzAyMDA6DQo+ID4gTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+IE1hcnRpbiBCam9ya2x1 bmQgcMOtxaFlIHYgxIx0IDIxLiAwNS4gMjAwOSB2IDIyOjIwICswMjAwOg0KPiA+ID4gPiBCdXQg SSBkb24ndCB0aGluayB0aGlzIHNob3VsZCBiZSBzcGVjaWZpZWQgaW4gdGhlIFlBTkcgZHJhZnQu ICBZQU5HDQo+ID4gPiA+IHdpbGwgd29yayB3aXRoIGFueSBlbmNvZGluZ3Mgb2YgdGhlIFhNTCBp biB0aGUgTkVUQ09ORiBwcm90b2NvbC4gIFNvDQo+ID4gPiA+IGlmIHdlIHdhbnQgdG8gdGFsayBh Ym91dCB0aGVzZSBlbmNvZGluZ3MsIGl0IHNob3VsZCBiZSBpbiA0NzQxYmlzLg0KPiA+ID4gPiAN Cj4gPiA+IA0KPiA+ID4gVHJ1ZSwgYnV0IHNlYy4gOS40LjEgc2F5cw0KPiA+ID4gDQo+ID4gPiAi QSBzdHJpbmcgdmFsdWUgaXMgbGV4aWNvZ3JhcGhpY2FsbHkgcmVwcmVzZW50ZWQgYXMgY2hhcmFj dGVyIGRhdGEgaW4NCj4gPiA+ICAgIHRoZSBYTUwgZW5jb2RpbmcuIg0KPiA+ID4gDQo+ID4gPiBU aGVyZSBpcyBubyB1bmlxdWUgIlhNTCBlbmNvZGluZyIuDQo+ID4gDQo+ID4gV2UgdGFsayBhYm91 dCBYTUwgZW5jb2RpbmcgaW4gbWFueSBwbGFjZXMuICBUaGlzIG1lYW5zIGhvdyBkYXRhIGlzDQo+ ID4gZW5jb2RlZCBpbnRvIFhNTDsgaXQgZG9lcyBub3QgcmVmZXIgdG8gd2hpY2ggY2hhcmFjdGVy IGVuY29kaW5nIHNjaGVtZQ0KPiA+IHRoZSBORVRDT05GIFBEVXMgdXNlLg0KPiANCj4gVGhlIHdv cmQgImVuY29kaW5nIiBkZW5vdGVzIChpbiB0aGUgWE1MIHNwZWMgYXQgbGVhc3QpIHRoZSBwcm9j ZXNzIG9mDQo+IG1hcHBpbmcgY2hhcmFjdGVycyB0byBieXRlIHNlcXVlbmNlcy4NCg0KSSB3aWxs IGNoYW5nZSB0aGUgd29yZHMgIlhNTCBlbmNvZGluZyIgdG8gc29tZXRoaW5nIGVsc2UuICANCg0K Ik5FVENPTkYgWE1MIEVuY29kaW5nOiINCg0Kd2lsbCBiZToNCg0KIk5FVENPTkYgWE1MIEV4YW1w bGU6Ig0KDQoNCiJBIGNvcnJlc3BvbmRpbmcgWE1MIGVuY29kaW5nOiINCg0Kd2lsbCBiZQ0KDQoi QSBjb3JyZXNwb25kaW5nIFhNTCBpbnN0YW5jZSBleGFtcGxlOiINCg0KYW5kIHNvIG9uLg0KDQoN Ci9tYXJ0aW4NCg0K From mbj@tail-f.com Fri May 22 05:58: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 0AE193A6D92 for ; Fri, 22 May 2009 05:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.179, 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 fNi86R6jhpjn for ; Fri, 22 May 2009 05:58: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 3EE3E3A6B24 for ; Fri, 22 May 2009 05:58:44 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4FD93616004; Fri, 22 May 2009 15:00:14 +0200 (CEST) Date: Fri, 22 May 2009 15:00:13 +0200 (CEST) Message-Id: <20090522.150013.53806852.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242975368.6374.42.camel@missotis> References: <1242903611.6931.103.camel@missotis> <20090521.220141.04392268.mbj@tail-f.com> <1242975368.6374.42.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] require-instance false 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, 22 May 2009 12:58:46 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMjEuIDA1LiAyMDA5IHYgMjI6MDEgKzAyMDA6DQo+ID4gPiA+IElm ICJyZXF1aXJlLWluc3RhbmNlIiBpcyAiZmFsc2UiLCBpdCBtZWFucyB0aGF0IHRoZSBpbnN0YW5j ZSBiZWluZw0KPiA+ID4gPiByZWZlcnJlZCBNQVkgZXhpc3QgaW4gdmFsaWQgZGF0YS4NCj4gPiA+ IA0KPiA+ID4gLi4uIGFuZCBpZiBpdCBleGlzdHMsIGl0cyB2YWx1ZSBNVVNUIGJlIGVxdWFsIHRv IHRoZSB2YWx1ZSBvZiB0aGUNCj4gPiA+IHJlZmVycmluZyBsZWFmLg0KPiA+IA0KPiA+IFRoaXMg ZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlLiAgSG93IGNhbiBpdCBleGlzdCAqd2l0aG91dCogaXRz IHZhbHVlDQo+ID4gYmVpbmcgZXF1YWwgdG8gdGhlIHZhbHVlIG9mIHRoZSByZWZlcnJpbmcgbGVh Zj8NCj4gDQo+IGxlYWZyZWYgbmVlZG4ndCByZWZlciB0byBhIGxpc3Qga2V5Og0KDQpEdWghICBP ZiBjb3Vyc2UuICBJdCBpcyBhICpsZWFmKiByZWYgbm93LiAgTm90IGp1c3Qga2V5cmVmLg0KDQpJ IGhhdmUgYWRkZWQgeW91ciBzdWdnZXN0ZWQgY2xhcmZpY2F0aW9uLg0KDQoNCi9tYXJ0aW4NCg== From mbj@tail-f.com Fri May 22 06:07: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 AEBB83A7018 for ; Fri, 22 May 2009 06:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.178, 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 HxrM0uSZd9gF for ; Fri, 22 May 2009 06:07:52 -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 E42B03A6B8C for ; Fri, 22 May 2009 06:07:51 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3D723616004; Fri, 22 May 2009 15:09:30 +0200 (CEST) Date: Fri, 22 May 2009 15:09:29 +0200 (CEST) Message-Id: <20090522.150929.01646103.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A1679C5.2080801@ericsson.com> References: <4A1679C5.2080801@ericsson.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] leaf-ref questions 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, 22 May 2009 13:07:52 -0000 Balazs Lengyel wrote: > Hello, > I am trying to understand leafref purely from the draft. I had a very hard > time. I have some questions that the draft does not answer: > > 1) Does path point to a leaf node in the datastore or just a potential leaf > node? The draft says about path: > "It takes as an argument a string which MUST refer to a leaf node." > However I think if require-instance is false, path only points to a potential > leaf. I think this is clear from the text on require-instance, which has been clarified as suggested by Lada. > 2) Does a leafref has it's own value or is it just a second way of accessing > the referenced leaf? It has it's own value. If not, 'require-instance false' would not make much sense. > 3) Can I write to a leaf of type leafref? Of course. Is there anything in the text that suggest otherwise? > Will that modify the value of the > referenced leaf? No. Is there anything in the text that suggest this? > 4) What does it mean if path's nodeset is empty? What happens if we read/write > to this leafref? If it is a require-instance true, then it will not be valid (at validate / commit time). > 5) What does it mean if path's nodeset consists of multiple nodes? What if they > contain different values? This is fine; it is also necessary if a list has multiple keys, e.g.: list server { key "ip port"; ... } leaf my-srv-ip { type leafref { path "../server/ip"; // this xpath may return mulitple nodes } } ... /martin From mbj@tail-f.com Fri May 22 06:11: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 AD38B3A6D0A for ; Fri, 22 May 2009 06:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.177, 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 VthAUYZVD8CL for ; Fri, 22 May 2009 06:11:43 -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 D3DB73A6ECE for ; Fri, 22 May 2009 06:11:13 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B5DA616004; Fri, 22 May 2009 15:12:52 +0200 (CEST) Date: Fri, 22 May 2009 15:12:51 +0200 (CEST) Message-Id: <20090522.151251.98986253.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242974576.6374.35.camel@missotis> References: <1242897897.6931.80.camel@missotis> <20090521.214534.229898853.mbj@tail-f.com> <1242974576.6374.35.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] namespace stmt 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, 22 May 2009 13:11:43 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMjEuIDA1LiAyMDA5IHYgMjE6NDUgKzAyMDA6DQo+ID4gTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+IE1hcnRpbiBCam9ya2x1 bmQgcMOtxaFlIHYgU3QgMjAuIDA1LiAyMDA5IHYgMjI6NDEgKzAyMDA6DQo+ID4gPiA+ID4gLSBT ZWMuIDcuMS4zOiBUaGUgbmFtZXNwYWNlIGlzIHVzZWQgbm90IG9ubHkgZm9yIFhNTCBlbGVtZW50 cyBidXQNCj4gPiA+ID4gYWxzbw0KPiA+ID4gPiA+ICAgZm9yIGV4dGVuc2lvbnMgYW5kIGZlYXR1 cmVzLg0KPiA+ID4gPiANCj4gPiA+ID4gRXh0ZW5zaW9ucyBhbmQgZmVhdHVyZXMgbmV2ZXIgc2hv dyB1cCBpbiB0aGUgWE1MLiAgVGhlIG5hbWVzcGFjZSBkb2VzDQo+ID4gPiA+IG5vdCBhZmZlY3Qg dGhlbS4NCj4gPiA+IA0KPiA+ID4gVGhlICduYW1lc3BhY2UnIHN0YXRlbWVudHMgZGVmaW5lcyB0 aGUgbmFtZXNwYWNlIGFuZCBwcmVmaXggZm9yIG9iamVjdHMNCj4gPiA+IHdpdGhpbiB0aGUgWUFO RyBtb2R1bGUsIHRvby4NCj4gPiANCj4gPiBJJ20gc29ycnksIEkgZG9uJ3QgdW5kZXJzdGFuZCB5 b3VyIHBvaW50LiAgQ291bGQgeW91IHN1Z2dlc3Qgc29tZSB0ZXh0DQo+ID4gdGhhdCB3b3VsZCBn byBpbnRvIDcuMS4zPw0KPiANCj4gVGhlICJuYW1lc3BhY2UiIHN0YXRlbWVudCBkZWZpbmVzIHRo ZSBYTUwgbmFtZXNwYWNlIHRvIHdoaWNoIGFsbA0KPiBpZGVudGlmaWVycyBkZWZpbmVkIGJ5IHRo ZSBtb2R1bGUgYmVsb25nLCB3aXRoIHRoZSBleGNlcHRpb24gb2YgZGF0YQ0KPiBub2RlIGlkZW50 aWZpZXJzIGRlZmluZWQgaW5zaWRlIGEgZ3JvdXBpbmcgKHNlZSBTZWN0aW9uIDcuMTIgZm9yDQo+ IGRldGFpbHMpLg0KDQpUaGFua3MsIEkgaGF2ZSByZXBsYWNlcyB0aGUgY3VycmVudCB0ZXh0IHdp dGggdGhpcyBvbmUuDQoNCg0KL21hcnRpbg0K From mbj@tail-f.com Fri May 22 06:13: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 4ECCD3A6EA4 for ; Fri, 22 May 2009 06:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.175, 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 dZE92j7nF5H1 for ; Fri, 22 May 2009 06:13:49 -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 7F58D3A7030 for ; Fri, 22 May 2009 06:13:49 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2338B616004; Fri, 22 May 2009 15:15:27 +0200 (CEST) Date: Fri, 22 May 2009 15:15:26 +0200 (CEST) Message-Id: <20090522.151526.32995613.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242973685.6374.27.camel@missotis> References: <1242894219.6931.59.camel@missotis> <20090521.213717.193017582.mbj@tail-f.com> <1242973685.6374.27.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] definitions 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, 22 May 2009 13:13:50 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMjEuIDA1LiAyMDA5IHYgMjE6MzcgKzAyMDA6DQo+ID4gVGhlIHRl eHQgc2F5czoNCj4gPiANCj4gPiAgIFRoZSAiaW1wb3J0IiBzdGF0ZW1lbnQgbWFrZXMgZGVmaW5p dGlvbnMgZnJvbSBvbmUgbW9kdWxlIGF2YWlsYWJsZQ0KPiA+ICAgaW5zaWRlIGFub3RoZXIgbW9k dWxlIG9yIHN1Ym1vZHVsZS4gDQo+ID4gDQo+ID4gQ291bGQgeW91IHByb3Bvc2UgdGV4dCB0byBt YWtlIGl0IG1vcmUgY2xlYXI/DQo+IA0KPiBUaGUgImltcG9ydCIgc3RhdGVtZW50IG1ha2VzIGlk ZW50aWZpZXJzIGZyb20gdGhlIG5hbWVzcGFjZSBvZiB0aGUNCj4gaW1wb3J0ZWQgbW9kdWxlIGF2 YWlsYWJsZSBpbiB0aGUgaW1wb3J0aW5nIG1vZHVsZS4gSW4gcGFydGljdWxhciwgdGhlDQo+IGlt cG9ydGluZyBtb2R1bGUgbWF5DQo+IA0KPiBvIHVzZSBncm91cGluZ3MgYW5kIHR5cGVkZWZzIGRl ZmluZWQgYXQgdGhlIHRvcCBsZXZlbCBvZiB0aGUgaW1wb3J0ZWQgDQo+ICAgbW9kdWxlOw0KPiAN Cj4gbyByZWZlciB0byBmZWF0dXJlcyBkZWZpbmVkIGluIHRoZSBpbXBvcnRlZCBtb2R1bGU7DQo+ IA0KPiBvIHVzZSBhbnkgZGF0YSBub2RlIG9mIHRoZSBpbXBvcnRlZCBtb2R1bGUgYXMgdGhlIHRh cmdldCBub2RlIGZvciB0aGUgDQo+ICAgImF1Z21lbnQiIHN0YXRlbWVudC4NCj4gDQo+IFVubGlr ZSAiaW5jbHVkZSIsIHRoZSAiaW1wb3J0IiBzdGF0ZW1lbnQgZG9lc24ndCBjb250cmlidXRlIHRo ZSBkYXRhDQo+IHRyZWUgZnJvbSB0aGUgaW1wb3J0ZWQgdG8gdGhlIGltcG9ydGluZyBtb2R1bGUu DQoNCkknbSBub3Qgc3VyZSB0aGlzIHRleHQgaXMgYmV0dGVyIHRoYW4gdGhlIGN1cnJlbnQgdGV4 dC4gIERvZXMgYW55b25lDQplbHNlIGhhdmUgYW4gb3Bpbmlvbj8NCg0KDQo+ID4gQlRXLCBSTkcg ZG9lc24ndCBoYXZlICdpbXBvcnQnIGRvZXMgaXQ/DQo+IA0KPiBJdCdzIGNhbGxlZCAiaW5jbHVk ZSIuDQoNCkV4YWN0bHkuICBZQU5HJ3MgaW5jbHVkZSBpcyBtb3JlIGxpa2UgUk5HJ3MgaW5jbHVk ZS4gIFNvIEkgZG9uJ3Qgc2VlDQp3aHkgUk5HIHVzZXJzIHdvdWxkIGJlIGNvbmZ1c2VkIHdoZW4g WUFORydzIGltcG9ydCBkb2VzIG5vdCBiZWhhdmUNCmxpa2UgUk5HJ3MgaW5jbHVkZS4NCg0KDQov bWFydGluDQo= From mbj@tail-f.com Fri May 22 06:17: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 B37F63A7034 for ; Fri, 22 May 2009 06:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.174, 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 esfY4Ea1j2sr for ; Fri, 22 May 2009 06:17: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 C03293A6D13 for ; Fri, 22 May 2009 06:17:26 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9CE74616004; Fri, 22 May 2009 15:18:54 +0200 (CEST) Date: Fri, 22 May 2009 15:18:54 +0200 (CEST) Message-Id: <20090522.151854.168444343.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242990107.6374.97.camel@missotis> References: <4A15B752.8050602@netconfcentral.com> <20090521.222817.21625953.mbj@tail-f.com> <1242990107.6374.97.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] revision mismatch 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, 22 May 2009 13:17:27 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMjEuIDA1LiAyMDA5IHYgMjI6MjggKzAyMDA6DQo+ID4gQW5keSBC aWVybWFuIDxhbmR5QG5ldGNvbmZjZW50cmFsLmNvbT4gd3JvdGU6DQo+ID4gPiBNYXJ0aW4gQmpv cmtsdW5kIHdyb3RlOg0KPiA+ID4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+ IHdyb3RlOg0KPiA+ID4gPj4gTWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIw MDkgdiAyMjo0MSArMDIwMDoNCj4gPiA+ID4+Pj4gLSBTZWMuIDUuMS4xOiBUaGUgc3BlYyBkb2Vz bid0IGVuc3VyZSB0aGF0IGJvdGggcGFydGllcyBpbiBhIE5FVENPTkYNCj4gPiA+ID4+Pj4gICBz ZXNzaW9uIGFsd2F5cyB1c2UgdGhlIHNhbWUgbW9kdWxlIHJldmlzaW9ucw0KPiA+ID4gPj4+IFRo aXMgaXMgYnkgZGVzaWduLiAgV2UgY2Fubm90IGFzc3VtZSB0aGF0IGFsbCBjbGllbnRzIGFsd2F5 cyBoYXZlIHRoZQ0KPiA+ID4gPj4+IGxhdGVzdCB2ZXJzaW9uIG9mIGEgcGFydGljdWxhciBtb2R1 bGUuDQo+ID4gPiA+PiBJdCBpcyBhIHN0cmFuZ2UgY29udHJhY3Qgd2hlcmUgZWFjaCBwYXJ0eSBt YXkgd29yayB3aXRoIGEgZGlmZmVyZW50DQo+ID4gPiA+PiB0ZXh0LiBJIGRpZG4ndCBnZXQgdGhp cyB3YXMgYSBmZWF0dXJlLCBzbyBJIGRpc2FncmVlIG5vdy4NCj4gPiA+ID4gQXJlIHlvdSBzdWdn ZXN0aW5nIHRoYXQgaWYgYSBzZXJ2ZXIgYWR2ZXJ0aXNlcyBtb2R1bGUgQSwgcmV2aXNpb24gWCwN Cj4gPiA+ID4gYW5kIHRoZSBjbGllbnQgZG9lcyBub3QgdW5kZXJzdGFuZCBBIHJldiBYLCB0aGVu IHRoZSBjbGllbnQgTVVTVCBjbG9zZQ0KPiA+ID4gPiB0aGUgc2Vzc2lvbj8NCj4gPiA+ID4gDQo+ ID4gPiANCj4gPiA+IGRvbid0IGRvIHRoYXQhDQo+ID4gDQo+ID4gSSBkZWZpbml0ZWx5IGFncmVl OyBJJ20ganVzdCB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0IExhZGEgaXMgc2F5aW5nLg0KPiAN Cj4gRXhhbXBsZXMgZm9yIHR3byByZXZpc2lvbnMgb2YgdGhlIHNhbWUgbW9kdWxlLCBYMCBpcyB1 c2VkIGJ5IHRoZSBzZXJ2ZXINCj4gYW5kIFgxIGJ5IHRoZSBjbGllbnQsIHdoZXJlIFgwIDwgWDE6 DQo+IA0KPiAqIFJldmlzaW9uIFgxIGFkZHMgYSBuZXcgZW51bSB2YWx1ZSBhbmQgdGhlIGNsaWVu dCB0cmllcyB0byBzZXQgdGhlIA0KPiAgIGxlYWYgdG8gdGhpcyB2YWx1ZS4gRm9yIHRoZSBzZXJ2 ZXIgdGhlIHZhbHVlIGlzIGludmFsaWQsIHNvIGl0DQo+ICAgcmV0dXJucyBhbiBlcnJvciBtZXNz YWdlLg0KPiANCj4gKiBFdmVuIHdvcnNlOiBMZWFmICJtdHUiIGhhcyBubyBkZWZhdWx0IHZhbHVl IGRlZmluZWQgaW4gWDAgKGJ1dCBpcyBub3QgDQo+ICAgbWFuZGF0b3J5IGVpdGhlciksIHNvIHRo ZSBzZXJ2ZXIgdXNlcyBhIHNwZWNpZmljIG9wZXJhdGlvbmFsIHZhbHVlLCANCj4gICBzYXkgMjk2 LCBwZXJoYXBzIGhhcmR3aXJlZC4gUmV2aXNpb24gWDEgYWRkcyBhIGRlZmF1bHQgdmFsdWUgb2Yg MTUwMCANCj4gICBmb3IgIm10dSIuIFdoZW4gIm10dSIgaXMgbm90IGluIHRoZSBjb25maWd1cmF0 aW9uIG9idGFpbmVkIGZyb20gdGhlIA0KPiAgIHNlcnZlciwgdGhlIGNsaWVudCBjb25jbHVkZXMg TVRVIGlzIHNldCB0byAxNTAwLCB3aGljaCBpcyBub3QgdGhlIA0KPiAgIGNhc2UuDQo+IA0KPiBB cmUgdGhlc2Ugbm90IGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXM/DQoNCkkgdGhpbmsgdGhlc2Ug c2l0dWF0aW9ucyBzaG91bGQgYmUgdXAgdG8gdGhlIGNsaWVudCB0byBoYW5kbGUNCnByb3Blcmx5 LiAgSSBkb24ndCB0aGluayB0aGUgc29sdXRpb24gaXMgdG8gc2F5IHRoYXQgc3VjaCBhIGNsaWVu dA0KTVVTVCBjbG9zZSB0aGUgc2Vzc2lvbi4gIFN1cHBvc2UgdGhlIGNsaWVudCBzaW1wbHkgZG9l cyBhDQo8Z2V0LWNvbmZpZy8+IGZvciBhcmNoaXZhbCByZWFzb25zIC0gc2hvdWxkIGl0IG5vdCBi ZSBhbGxvd2VkIHRvIGRvDQp0aGlzPw0KDQoNCi9tYXJ0aW4NCg== From andy@netconfcentral.com Fri May 22 06:38: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 877C73A6B8C for ; Fri, 22 May 2009 06:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 l+SrEOF2kKbW for ; Fri, 22 May 2009 06:38:01 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 960CE3A6ACB for ; Fri, 22 May 2009 06:38:01 -0700 (PDT) Received: (qmail 27612 invoked from network); 22 May 2009 13:39:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 22 May 2009 13:39:38 -0000 X-YMail-OSG: hDXwgfEVM1n4pNdUhNEpuaiBC3wbGCQ_Ze1Xnw4WzgsOR57uAq7gdqnprTfBkQuCgCJQka38ODVU9SxzeWfGFqU9h_tDeuKmKTrf09yx6zo_w_u7ln2cOsGsE6CJ3r8B2XWmBnNsV5klrwhVX109hA4o9RMXokeZZnnj5Y8siyZUTlxkd_UYhNasy5sh5TMT3glXqFkUl5.EzPJEyeDhPW3UsgjHhhchInn7kUsPGkgEUod4c8kwRb9_tEy6jYBTdv1t3WcwVO7RYhI_RMnHDbIwSZ7Elo3zKAXs8MvuMHzBJDFLt6mKHy1IHaubcRnk1dciKNeuci2cuA6YBd10QRJyyxRKgp_Kd31.PKFg X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A16AB17.6090905@netconfcentral.com> Date: Fri, 22 May 2009 06:39:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A15B752.8050602@netconfcentral.com> <20090521.222817.21625953.mbj@tail-f.com> <1242990107.6374.97.camel@missotis> <20090522.151854.168444343.mbj@tail-f.com> In-Reply-To: <20090522.151854.168444343.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] revision mismatch 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, 22 May 2009 13:38:02 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund píše v Čt 21. 05. 2009 v 22:28 +0200: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Ladislav Lhotka wrote: >>>>>> Martin Bjorklund píše v St 20. 05. 2009 v 22:41 +0200: >>>>>>>> - Sec. 5.1.1: The spec doesn't ensure that both parties in a NETCONF >>>>>>>> session always use the same module revisions >>>>>>> This is by design. We cannot assume that all clients always have the >>>>>>> latest version of a particular module. >>>>>> It is a strange contract where each party may work with a different >>>>>> text. I didn't get this was a feature, so I disagree now. >>>>> Are you suggesting that if a server advertises module A, revision X, >>>>> and the client does not understand A rev X, then the client MUST close >>>>> the session? >>>>> >>>> don't do that! >>> I definitely agree; I'm just trying to understand what Lada is saying. >> Examples for two revisions of the same module, X0 is used by the server >> and X1 by the client, where X0 < X1: >> >> * Revision X1 adds a new enum value and the client tries to set the >> leaf to this value. For the server the value is invalid, so it >> returns an error message. >> >> * Even worse: Leaf "mtu" has no default value defined in X0 (but is not >> mandatory either), so the server uses a specific operational value, >> say 296, perhaps hardwired. Revision X1 adds a default value of 1500 >> for "mtu". When "mtu" is not in the configuration obtained from the >> server, the client concludes MTU is set to 1500, which is not the >> case. >> >> Are these not interoperability problems? > > I think these situations should be up to the client to handle > properly. I don't think the solution is to say that such a client > MUST close the session. Suppose the client simply does a > for archival reasons - should it not be allowed to do > this? > Agreed. It should be common in manager code to treat an unexpected node as 'anyxml', not to blow up and stop working. > > /martin Andy From lhotka@cesnet.cz Fri May 22 07:04: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 88FE13A6B9C for ; Fri, 22 May 2009 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=0.366, 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 Jvl5COWD6WHe for ; Fri, 22 May 2009 07:04:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9E7CA3A6808 for ; Fri, 22 May 2009 07:04:27 -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 190F5D800CE; Fri, 22 May 2009 16:06:06 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090522.151854.168444343.mbj@tail-f.com> References: <4A15B752.8050602@netconfcentral.com> <20090521.222817.21625953.mbj@tail-f.com> <1242990107.6374.97.camel@missotis> <20090522.151854.168444343.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 22 May 2009 16:06:06 +0200 Message-Id: <1243001166.6374.117.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] revision mismatch 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, 22 May 2009 14:04:28 -0000 Martin Bjorklund píše v Pá 22. 05. 2009 v 15:18 +0200: > > Examples for two revisions of the same module, X0 is used by the > server > > and X1 by the client, where X0 < X1: > > > > * Revision X1 adds a new enum value and the client tries to set the > > leaf to this value. For the server the value is invalid, so it > > returns an error message. > > > > * Even worse: Leaf "mtu" has no default value defined in X0 (but is > not > > mandatory either), so the server uses a specific operational > value, > > say 296, perhaps hardwired. Revision X1 adds a default value of > 1500 > > for "mtu". When "mtu" is not in the configuration obtained from > the > > server, the client concludes MTU is set to 1500, which is not the > > case. > > > > Are these not interoperability problems? > > I think these situations should be up to the client to handle > properly. I don't think the solution is to say that such a client > MUST close the session. Suppose the client simply does a > for archival reasons - should it not be allowed to do > this? In the first case, the edit-config operation fails, and the second is an undetected mismatch in the client and server data. Both situations are abnormal. Rather than closing the session, the client could learn about the revision advertised by the server and switch to server's revision, and abort the session only if it is not possible. This would induce a modification in NETCONF hello negotiation, though. Lada > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri May 22 07:08: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 C9A233A6DE8 for ; Fri, 22 May 2009 07:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.173, 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 dr17bBmerj7o for ; Fri, 22 May 2009 07:08:19 -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 07AF43A6D12 for ; Fri, 22 May 2009 07:08:18 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A3C21616004; Fri, 22 May 2009 16:09:53 +0200 (CEST) Date: Fri, 22 May 2009 16:09:53 +0200 (CEST) Message-Id: <20090522.160953.49891463.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1243001166.6374.117.camel@missotis> References: <1242990107.6374.97.camel@missotis> <20090522.151854.168444343.mbj@tail-f.com> <1243001166.6374.117.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] revision mismatch 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, 22 May 2009 14:08:19 -0000 Ladislav Lhotka wrote: > Rather than closing the session, the client could learn about the > revision advertised by the server and switch to server's revision, and > abort the session only if it is not possible. This is certainly possible today, and entirely up to the client to do it it wants to. /martin From wjhns1@hardakers.net Fri May 22 08:43: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 59DB93A6CF0 for ; Fri, 22 May 2009 08:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_62=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 66sL1IpJYfLN for ; Fri, 22 May 2009 08:43:37 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id B87DB3A6C6E for ; Fri, 22 May 2009 08:43:36 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id CE8CF980A4 for ; Fri, 22 May 2009 08:45:13 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id AD514399B20 for ; Fri, 22 May 2009 08:45:13 -0700 (PDT) From: Wes Hardaker To: netmod@ietf.org Organization: Sparta Date: Fri, 22 May 2009 08:45:13 -0700 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 Subject: [netmod] comments on netmod-yang-05 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, 22 May 2009 15:43:38 -0000 As promised: (my earlier comments about the draft being of great quality still apply, of course) I didn't get as far as I'd have liked (boy it's long) as 2 weeks just wasn't enough to let me get all the way through it. General: - Many rules don't have MUSTs and SHOULDs and many do. The wording seems to be fairly inconsistent with respect to this. There are many points in the document where it's stated flatly that something is allowed or disallowed, and other points where the use of the word MUST is included. I'm confused as to why MUSTs are present sometimes and not others. - Much of the document seems to be written with the mindset of the (sub)module authors but don't discuss things in terms of implementations. In fact many of the MUSTs/SHOULDs/MAYs seem to be directed at module authors rather than parser authors. Maybe this is intentional. - The substatement tables are *extremely* helpful. Thanks for doing those. Section 4.2.3: The example adds a few things not discussed so far: "config true;" at the top: what's the default value? It must be true based on the other examples? You should state one way or the other (maybe in a // comment) that it's the default or not. Observed-speed could use a unit to be complete, but I actually think it should be left out because it hasn't been introduced yet. I'm merely mentioning it so you can decide ;-) Section 4.2.5: s/uint16/uint8/ Section 4.2.6 (I didn't get far enough into the document to check elsewhere): Can you use two "use" cases in a single statement. What about "use" followed by other objects? I suspect this is covered later. Section 4.2.7: If mandatory isn't needed there (I don't think so) it should probably be removed till it's introduced later. Choosing beer as the example data I think would be better since it provides an example of an empty clause, which isn't shown until now. Section 4.2.8: I found the first paragraph a bit oddly worded and hard to follow. I think the example could be a better one. In the real world, which that example sort of models, uid's exist for every type of user not just !wheel classes. Instead maybe a boolean "allow_login" instead? Section 4.2.9: s#acmefw-2.3#acmefw-2.3# I'm actually don't think the example is a great one in the first place since image installs are one of the more complex cases of "when does it happen" and it's the reply sort of indicates "it's happening beyond now". I'm fine with leaving it too, but a more concrete/less-fuzzy example would do better for the reader, IMHO. Section 4.2.10: Change notification from status=up to down to make more sense. Section 5.1: I found the whole modules/submodules thing confusing. Part of it is the wording, part is the lack of understanding of exactly why you couldn't just use modules everywhere and prohibit certain operations at the same time, etc. Don't get me wrong, I get it but I'm not sure the reader easily will. Maybe a diagram would help? |----------| import |-----------| | moduleA | - - - - ->| moduleB | |----------| |-----------| | ^ include| V include | V |---------| / |---------| | submod1 |- - - - -/ | submod2 | |---------| import |---------| | V include |---------| | submod2 | |---------| (badly done, but you might get the idea) 5.1.1: Use "p" as a prefix rather than "a" in the example for clarity against a:a. 5.3.1: I can't remember the version number decision if yang was "1" or "1.0" but ":1" looks odd after seeing ":1.0" in the netconf URNs. 5.4: It might be worth taking another editing hit on the second paragraph. 5.6.2: remove the "s" in '"features"' or put it after the " 5.6.4.3: I find the use of the second capability announcing the deviation a bit odd. Specifically, the fact that the URL doesn't seem to matter (ending in my-deviations) but the module name afterward (?module=my-devs) is what is supposed to be matched on. I'm sure readers will get it eventually but it took me a bit. Not only that, there might be confusion about how to advertise multiple deviation modules. 5.6.5: Need to decide on or remove the open question marking 6.1.3: It should be noted that many definitions of "whitespace" include newlines, including standard regular expressions. # perl -l -e 'print "hello" if ("\n" =~ /\s/);' hello But this section deviates from that and discusses whitespace heavily but the examples show that newlines are exempt from being called whitespace (and you really mean just spaces and tabs). (mostly in the paragraph "trailing whitespace is stripped..." which would remove the \n) 6.2.1: Again, the complexity associated with submodules and modules shows here. I get it, as I said, but I doubt most readers will (quickly at least). 6.3: "Forward references are allowed in YANG". MUST be supported? 7.1: "A module SHOULD have the following layout:" What if it doesn't? Does that mean a parser implementation doesn't have to accept it? (this is an example of text written toward the author when it's the parser implementation that will be the most affected but yet the text doesn't describe the requirements of the implementation). 7.1.2: Is yang-version technically a string, decimal64 or binary blob? 7.1.6: "It is an error ..." -> an example of a missing MUST NOT? 7.1.9: I'd add the word "published" or "distributed" in front of "editorial change" 7.2: It'd be less a strain on IANA to have submodules prefixed with "parentmodule:" so that there exists a naming hierarchy for submodules such that there is no chance for collision. 7.5.3: Please please please don't hard-code the startup/running/candidate components into the yang document. There is a definite possibility of future netconf extensions providing additional storage mechanisms and you don't want to rev yang because of it. Yang should stay out of specifying what datastores contain config, state or whatever. Somewhere: You might add an example that uses current() somewhere 7.5.4.3: That example works well to show why maybe inverse logic would be more useful for must statements ;-) 7.5.8: This seems to blur the lines into the netconf territory and makes me nervous about future expansion. Additionally, because it so netconf specific it doesn't allow parallel xml data of some other form. Somewhere: Does the document discuss long-term issues with leaves? IE, once a leaf name has been published it can never change in definition? 7.6.7: Before the colon add "placed into the previously defined "ssh" container: 7.7.5: What happens when a client requests data from a system ordered set of data, jumbles it (say makes it alphabetical according to how a user sorted it on the screen) and sends it back (eg, via a replace)? This isn't discussed... 1) can the server reject it? 2) does the server have to parse it? 3) is the server allowed to define internal semantics of it's own ordering? (see large routing table implementations) 7.8.3: The wording isn't perfectly clear and could use a bit of improvement I think (and I'm sorry for never offering some direct suggestions). If unique constraints can be ignored when some of the nodes are not present with data then it might be worth adding a note about using the mandatory clause to prevent this. It'd help the reader. Sorry I didn't get farther into the document... -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From randy_presuhn@mindspring.com Fri May 22 11:09: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 8597F3A698F for ; Fri, 22 May 2009 11:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-1.022, 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 MXwVzSNGdoo5 for ; Fri, 22 May 2009 11:09:54 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 59AC028C0FA for ; Fri, 22 May 2009 11:09:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TsruECPBMa4vZQIpE8rqoDT5Ee5R/l4hDkGBIIMcOc/TJ1aWaD7Zc3VGSzV6fP79; 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.146.224] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M7ZDP-0000uV-8R for netmod@ietf.org; Fri, 22 May 2009 14:11:31 -0400 Message-ID: <004001c9db09$331e9280$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <1242289874.6404.7.camel@missotis><20090520.224146.220136501.mbj@tail-f.com><1242899308.6931.95.camel@missotis><003501c9da32$12205aa0$6801a8c0@oemcomputer> <1242972802.6374.13.camel@missotis> Date: Fri, 22 May 2009 11:14:48 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696879fdf6e9c71db0aa7fb5abdc01ae8298350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.224 Subject: Re: [netmod] character encoding [Was:review ofdraft-ietf-netmod-yang-05] 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, 22 May 2009 18:09:55 -0000 Hi - > From: "Ladislav Lhotka" > To: > Sent: Thursday, May 21, 2009 11:13 PM > Subject: Re: [netmod] character encoding [Was:review ofdraft-ietf-netmod-yang-05] ... > From http://en.wikipedia.org/wiki/UTF-16: > > "UTF-16 is the native internal representation of text in the Microsoft > Windows 2000/XP/2003/Vista/CE; Qualcomm BREW operating systems; the Java > and .NET bytecode environments; Mac OS X's Cocoa and Core Foundation > frameworks; and the Qt cross-platform graphical widget toolkit." Our job in the IETF is to worry about what goes on the wire. When you advocate UTF-16, do you mean UTF-16BE or UTF-16LE? Both is it? Have you verified that surrogate pairs are actually handled correctly? What other IETF protocol actually USES some form of UTF-16 encoding? In another message: > The word "encoding" denotes (in the XML spec at least) the process of > mapping characters to byte sequences. > > I propose to add the following term to Sec. 3: > > o character: atomic unit of text as specified by [ISO/IEC10646]. > > And then use just "character". I'm afraid that definition would be misleading. Depending on the canonicalization rules in place, you might reduce, but can not eliminate, the possibility of combining marks and directionality marks, which, while atomic from the code point perspective, are not from a user perspective. Then, too, there are wondrous things like "COMBINING DOUBLE TILDE RIGHT HALF" and the ideographic variation selectors. The Unicode definition(s) of character won't help much either: | Character. (1) The smallest component of written language that has | semantic value; refers to the abstract meaning and/or shape, rather | than a specific shape (see also glyph), though in code tables some | form of visual representation is essential for the reader’s | understanding. (2) Synonym for abstract character. (3) The basic | unit of encoding for the Unicode character encoding. (4) The English | name for the ideographic written elements of Chinese origin. [See ideograph (2).] I *think* you intend definition #3. You could address the concern by referring to the specific definition, but I'm afraid it doesn't really help with the underlying problem. If you intend to be consistent with the IS 10646 and Unicode, then the solution is to use the term "code point," rather than "character". Randy From cfinss@dial.pipex.com Fri May 22 11:15: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 B41673A6E5F for ; Fri, 22 May 2009 11:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_NJABL_PROXY=1.643] 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 rKdVdNzxnp99 for ; Fri, 22 May 2009 11:15:12 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 82CF93A6D2C for ; Fri, 22 May 2009 11:15:12 -0700 (PDT) X-Trace: 161980020/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.131/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.131 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: AtkEAEiJFko+vBGD/2dsb2JhbABEgmQ6FIsCw2MIhAMF X-IronPort-AV: E=Sophos;i="4.41,234,1241391600"; d="scan'208";a="161980020" X-IP-Direction: IN Received: from 1cust131.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.131]) by smtp.pipex.tiscali.co.uk with SMTP; 22 May 2009 19:16:48 +0100 Message-ID: <000401c9db00$fb9070c0$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" , References: <1242289874.6404.7.camel@missotis><20090520.224146.220136501.mbj@tail-f.com><1242899308.6931.95.camel@missotis><003501c9da32$12205aa0$6801a8c0@oemcomputer> <1242972802.6374.13.camel@missotis> Date: Fri, 22 May 2009 17:11:43 +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] character encoding [Was:review ofdraft-ietf-netmod-yang-05] 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: Fri, 22 May 2009 18:15:13 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: Sent: Friday, May 22, 2009 8:13 AM > Randy Presuhn píše v Čt 21. 05. 2009 v 09:34 -0700: > > > > > > "All implementations MUST accept the UTF-8 and UTF-16 encodings of > > > ISO/IEC 10646 specified according to [XML], section 4.3.3." > > ... > > > > There is little or no value to having two mandatory encodings. > > Maybe, but then the XML in NETCONF PDUs would be more restricted than > general XML. From the XML 1.0 spec: > > "All XML processors must accept the UTF-8 and UTF-16 encodings of > 10646; ..." > > > Having two options increases the chances of error, and the code points > > requiring multiple words to encode in UTF-16 are sufficiently uncommon > > that it's likely that those code paths will not be properly tested. > > > > UTF-8 is the clear winner in the encoding wars. That should be the sole > > mandatory encoding, IMO. > > >From http://en.wikipedia.org/wiki/UTF-16: > > "UTF-16 is the native internal representation of text in the Microsoft > Windows 2000/XP/2003/Vista/CE; Don't I know it. Microsoft produced a version of Word which doubled the size of documents. They then produced another version which printed those documents one character (yes, character) to a line, consuming forests by the bucketload. Then I learnt about UTF-16 and put two and two together. So, Never! to UTF-16. Tom Petch > Qualcomm BREW operating systems; the Java > and .NET bytecode environments; Mac OS X's Cocoa and Core Foundation > frameworks; and the Qt cross-platform graphical widget toolkit." > > Lada > > > RAndy > > > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C From reid@snmp.com Fri May 22 12:16: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 E473528C13C for ; Fri, 22 May 2009 12:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 OHxxE6wuh4Up for ; Fri, 22 May 2009 12:16:21 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 630553A6DCC for ; Fri, 22 May 2009 12:16:06 -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 PAA10421; Fri, 22 May 2009 15:17:16 -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 PAA18824; Fri, 22 May 2009 15:17:16 -0400 (EDT) Message-Id: <200905221917.PAA18824@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Fri, 22 May 2009 15:09:29 +0200. <20090522.150929.01646103.mbj@tail-f.com> Date: Fri, 22 May 2009 15:17:15 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 22 May 2009 19:16:24 -0000 > > 5) What does it mean if path's nodeset consists of multiple nodes? > > What if they contain different values? > > This is fine; it is also necessary if a list has multiple keys, e.g.: > > list server { > key "ip port"; > ... > } > > leaf my-srv-ip { > type leafref { > path "../server/ip"; // this xpath may return mulitple nodes > } > } > ... I'm not sure I understand. How can I return multiple nodes under one leaf? -David Reid From andy@netconfcentral.com Fri May 22 12:28: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 F0CD628C116 for ; Fri, 22 May 2009 12:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 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 yyxHCT-9tbVb for ; Fri, 22 May 2009 12:28:15 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 126A83A7018 for ; Fri, 22 May 2009 12:28:15 -0700 (PDT) Received: (qmail 39777 invoked from network); 22 May 2009 19:29:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 22 May 2009 19:29:47 -0000 X-YMail-OSG: aQHznaUVM1kFU5DZWUofypCizf_hncUc1FA..QF9835jgfTDCmwcfgXL9Ks8.raePIag41ec1bE8aoWlcuzCCaI6NWEoOsX3Z2pbxPvta66YHNfrGofGtEQSp1aR7a2gjwl6td1DcqmJLAf9dhwJIYR2G6rMVY_58912XuagmeexP2ygAEcbC0bKoYC5.EDaYLJfY3t1i0RmQg77luIgGBD8nFZBjp45_XcZVRfGHP_T4nlUz7jK1RbB_QbGF8lLosVg9m9k.LXHC.Iw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A16FD29.2040002@netconfcentral.com> Date: Fri, 22 May 2009 12:29:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200905221917.PAA18824@adminfs.snmp.com> In-Reply-To: <200905221917.PAA18824@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 22 May 2009 19:28:16 -0000 David Reid wrote: >>> 5) What does it mean if path's nodeset consists of multiple nodes? >>> What if they contain different values? >> This is fine; it is also necessary if a list has multiple keys, e.g.: >> >> list server { >> key "ip port"; >> ... >> } >> >> leaf my-srv-ip { >> type leafref { >> path "../server/ip"; // this xpath may return mulitple nodes >> } >> } >> ... > > I'm not sure I understand. How can I return multiple nodes under one leaf? > 9.9. The leafref Built-in Type The leafref type is used to reference a particular leaf instance in the data tree. Its value is constrained to be the same as the value of an existing leaf. So, when require-instance=true (as it is by default in your example), the 'my-srv-ip' leaf is constrained to the set of actual values for "../server/ip" (i.e., must pick one of the 'ip' instances). If require-instance=false, then 'my-srv-ip' is constrained to the same data type as leaf 'ip'. The canonical output form for 'my-srv-ip' is the same as the referenced 'ip' leaf, regardless of the require-instance value. Easier to understand than implement correctly, especially when union, instance-identifier, leafref loops, and other interactions are added to the equation. > -David Reid Andy From jmh@joelhalpern.com Fri May 22 12:42: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 2D0B53A6F9D for ; Fri, 22 May 2009 12:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 H5-VKkcS50Iw for ; Fri, 22 May 2009 12:42:15 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 516E13A6DCC for ; Fri, 22 May 2009 12:42:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A72C24305B8 for ; Fri, 22 May 2009 12:42:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-141.clppva.btas.verizon.net [71.161.52.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 26C614305B2 for ; Fri, 22 May 2009 12:42:48 -0700 (PDT) Message-ID: <4A170035.9040701@joelhalpern.com> Date: Fri, 22 May 2009 15:42:45 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <200905221917.PAA18824@adminfs.snmp.com> <4A16FD29.2040002@netconfcentral.com> In-Reply-To: <4A16FD29.2040002@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] leaf-ref questions 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, 22 May 2009 19:42:16 -0000 As far as I can tell, there are several different confusions about what leafref means and how it is supposed to work. At the very least, significant clarifying text is needed. The meaning Andy suggests below, that the path defines a set of nodes which constrain the type and legal values of the leaf being defined, but does not actually define the value, is an interesting and self-consistent view. It would resolve many of the issues. If that is what the WG intended, significant additional text is needed. Personally, if I read that X (a leafref) is a reference to Y (a leaf), then I tend to expect that setting X sets Y. And that the distinction between which Y X points to and what the value Y has is clear. Yours, Joel Andy Bierman wrote: > David Reid wrote: >>>> 5) What does it mean if path's nodeset consists of multiple nodes? >>>> What if they contain different values? >>> This is fine; it is also necessary if a list has multiple keys, e.g.: >>> >>> list server { >>> key "ip port"; >>> ... >>> } >>> >>> leaf my-srv-ip { >>> type leafref { >>> path "../server/ip"; // this xpath may return mulitple nodes >>> } >>> } >>> ... >> >> I'm not sure I understand. How can I return multiple nodes under one >> leaf? >> > > > > 9.9. The leafref Built-in Type > > The leafref type is used to reference a particular leaf instance in > the data tree. Its value is constrained to be the same as the value > of an existing leaf. > > > So, when require-instance=true (as it is by default in your example), > the 'my-srv-ip' leaf is constrained to the set of actual values > for "../server/ip" (i.e., must pick one of the 'ip' instances). > > If require-instance=false, then 'my-srv-ip' is constrained to > the same data type as leaf 'ip'. > > The canonical output form for 'my-srv-ip' is the same as > the referenced 'ip' leaf, regardless of the require-instance > value. > > Easier to understand than implement correctly, especially > when union, instance-identifier, leafref loops, and other > interactions are added to the equation. > > >> -David Reid > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Fri May 22 13:24: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 BB5613A6812 for ; Fri, 22 May 2009 13:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=1.363, BAYES_00=-2.599, GB_I_LETTER=-2, 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 HY8kkSUMq2va for ; Fri, 22 May 2009 13:24:42 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9D29A3A6B19 for ; Fri, 22 May 2009 13:24:41 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DE4C1D800BD; Fri, 22 May 2009 22:26:16 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn In-Reply-To: <004001c9db09$331e9280$6801a8c0@oemcomputer> References: <1242289874.6404.7.camel@missotis> <20090520.224146.220136501.mbj@tail-f.com> <1242899308.6931.95.camel@missotis> <003501c9da32$12205aa0$6801a8c0@oemcomputer> <1242972802.6374.13.camel@missotis> <004001c9db09$331e9280$6801a8c0@oemcomputer> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 May 2009 22:26:14 +0200 Message-Id: <1243023974.18749.7.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] character encoding [Was:review ofdraft-ietf-netmod-yang-05] 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, 22 May 2009 20:24:42 -0000 Hi Randy, Randy Presuhn píše v Pá 22. 05. 2009 v 11:14 -0700: > Our job in the IETF is to worry about what goes on the wire. > When you advocate UTF-16, do you mean UTF-16BE or UTF-16LE? > Both is it? Oh, I don't advocate UTF-16, being a Linux user I would be quite happy with UTF-8 only. I just don't believe UTF-8 is that universal as you suggested. I happen to speak and write a language where these encodings are a real issue and every once in a while I get a text where the accented letters are broken. Lada > > Have you verified that surrogate pairs are actually handled > correctly? What other IETF protocol actually USES some form > of UTF-16 encoding? > > In another message: > > > The word "encoding" denotes (in the XML spec at least) the process of > > mapping characters to byte sequences. > > > > I propose to add the following term to Sec. 3: > > > > o character: atomic unit of text as specified by [ISO/IEC10646]. > > > > And then use just "character". > > I'm afraid that definition would be misleading. Depending on the > canonicalization rules in place, you might reduce, but can not > eliminate, the possibility of combining marks and directionality > marks, which, while atomic from the code point perspective, > are not from a user perspective. Then, too, there are wondrous things > like "COMBINING DOUBLE TILDE RIGHT HALF" and the ideographic variation > selectors. > > The Unicode definition(s) of character won't help much either: > > | Character. (1) The smallest component of written language that has > | semantic value; refers to the abstract meaning and/or shape, rather > | than a specific shape (see also glyph), though in code tables some > | form of visual representation is essential for the reader’s > | understanding. (2) Synonym for abstract character. (3) The basic > | unit of encoding for the Unicode character encoding. (4) The English > | name for the ideographic written elements of Chinese origin. [See ideograph (2).] > > I *think* you intend definition #3. You could address the concern > by referring to the specific definition, but I'm afraid it doesn't > really help with the underlying problem. > > If you intend to be consistent with the IS 10646 and Unicode, then > the solution is to use the term "code point," rather than "character". > > Randy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E 8C0C From andy@netconfcentral.com Fri May 22 13:43: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 9C3E23A6962 for ; Fri, 22 May 2009 13:43:00 -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.100, 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 J4xBervYJ3q1 for ; Fri, 22 May 2009 13:42:59 -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 86B573A6812 for ; Fri, 22 May 2009 13:42:59 -0700 (PDT) Received: (qmail 92351 invoked from network); 22 May 2009 20:44:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 22 May 2009 20:44:34 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A170EB2.6040509@netconfcentral.com> Date: Fri, 22 May 2009 13:44:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <1242289874.6404.7.camel@missotis><20090520.224146.220136501.mbj@tail-f.com><1242899308.6931.95.camel@missotis><003501c9da32$12205aa0$6801a8c0@oemcomputer> <1242972802.6374.13.camel@missotis> <000401c9db00$fb9070c0$0601a8c0@allison> In-Reply-To: <000401c9db00$fb9070c0$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] character encoding [Was:review ofdraft-ietf-netmod-yang-05] 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, 22 May 2009 20:43:00 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Ladislav Lhotka" > To: > Sent: Friday, May 22, 2009 8:13 AM >> Randy Presuhn píše v Čt 21. 05. 2009 v 09:34 -0700: >>>> "All implementations MUST accept the UTF-8 and UTF-16 encodings of >>>> ISO/IEC 10646 specified according to [XML], section 4.3.3." >>> ... >>> >>> There is little or no value to having two mandatory encodings. >> Maybe, but then the XML in NETCONF PDUs would be more restricted than >> general XML. From the XML 1.0 spec: >> >> "All XML processors must accept the UTF-8 and UTF-16 encodings of >> 10646; ..." >> >>> Having two options increases the chances of error, and the code points >>> requiring multiple words to encode in UTF-16 are sufficiently uncommon >>> that it's likely that those code paths will not be properly tested. >>> >>> UTF-8 is the clear winner in the encoding wars. That should be the sole >>> mandatory encoding, IMO. >> >From http://en.wikipedia.org/wiki/UTF-16: >> >> "UTF-16 is the native internal representation of text in the Microsoft >> Windows 2000/XP/2003/Vista/CE; > > Don't I know it. Microsoft produced a version of Word which doubled the size of > documents. They then produced another version which printed those documents one > character (yes, character) to a line, consuming forests by the bucketload. > > Then I learnt about UTF-16 and put two and two together. > > So, Never! to UTF-16. > +1 x 10^^42 UTF-8 is enough > Tom Petch Andy From andy@netconfcentral.com Fri May 22 13:59: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 CA81B3A6B0A for ; Fri, 22 May 2009 13:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 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 0K+OzWjPCA+N for ; Fri, 22 May 2009 13:59:24 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id EA2473A6A29 for ; Fri, 22 May 2009 13:59:23 -0700 (PDT) Received: (qmail 50924 invoked from network); 22 May 2009 21:01:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 22 May 2009 21:01:00 -0000 X-YMail-OSG: aaWej6QVM1myGQ3WrRdv2l_7vgQurgUcoUyRbFCqF9FX7nnBZ9LDlVAl1AkHZgZlC1FwEzQyItLWz0Uufzcjomri0lkBQ8CeOCaGmCrUIrXlLVWGAnoQl3f9kNG6wPqnxYI638IwCjCMQN7By3a_g0YXwYv5w228q8hzCDq3x8U.5chQ779MlvcSeZHyH5gPyeZJbpqAK97oNGBVc4Sv8oJ9vet1xVZ70dCUlBPbokhPFbmzuiLdYu8Kxkv06SuIxnQ41I.5QBPsq30NrmPBFhGAYJKxhtt8xTx2ctw7jLrLiPMDw5Qd X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A171274.8080607@netconfcentral.com> Date: Fri, 22 May 2009 14:00:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200905221917.PAA18824@adminfs.snmp.com> <4A16FD29.2040002@netconfcentral.com> <4A170035.9040701@joelhalpern.com> In-Reply-To: <4A170035.9040701@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 22 May 2009 20:59:24 -0000 Joel M. Halpern wrote: > As far as I can tell, there are several different confusions about what > leafref means and how it is supposed to work. At the very least, > significant clarifying text is needed. > > The meaning Andy suggests below, that the path defines a set of nodes > which constrain the type and legal values of the leaf being defined, but > does not actually define the value, is an interesting and > self-consistent view. It would resolve many of the issues. If that is > what the WG intended, significant additional text is needed. > I think leafref is implemented as I described, according to discussions with Martin about it. > Personally, if I read that X (a leafref) is a reference to Y (a leaf), > then I tend to expect that setting X sets Y. And that the distinction > between which Y X points to and what the value Y has is clear. > What kind of normative text is needed? More examples instead? Is it clear that the path statements can form a loop in 2 to N connected leafrefs? Is it clear that the XPath comparison problem shows up when the leafref path points to an instance-identifier? The manager-provided value needs to be compared to existing values of an instance-identifier leaf. Is the normalization of whitespace, token parsing, and prefix to expanded-name conversion required to properly compare 2 instance-identifiers clear? Is it clear that comparing any XPath expression or instance-identifier contained in an XML PDU to an agent-stored XPath expression or instance-identifier cannot be done with strcmp()? > Yours, > Joel > Andy From andy@netconfcentral.com Fri May 22 16:33: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 CF6C33A693F for ; Fri, 22 May 2009 16:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 T-hJE9NFftaQ for ; Fri, 22 May 2009 16:33:42 -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 288873A6F23 for ; Fri, 22 May 2009 16:33:42 -0700 (PDT) Received: (qmail 50073 invoked from network); 22 May 2009 23:35:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 22 May 2009 23:35:18 -0000 X-YMail-OSG: w.Kkl.YVM1lv0Kcyy3R.3d07JU0u1DLljQoA97Gh85yALB5nHN1BWCGu3CVpFESz594ypB4ZBRZzX6UWc2R84C9evhxSdyrK84zZ2tKwb4DbCGiuyDmkmvNibejCfdkxv1OQXj1kpD8_UKyAV7qFV.t982KvitX3up8Ar8IuE33.Mv.aXUJnQRlwjK4vER3t6JI8FVJpA8e4quWMyk3kRsv11K7A4Hxs4pN.b9I1_uBu7bxxbicP_muLp0yuDdhfXc7ZvHxsit8GS.zlhxxe61PVTA3Of4ZkjmSLDFlRxBvOkP8RVKRr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1736B5.3090701@netconfcentral.com> Date: Fri, 22 May 2009 16:35:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A15B752.8050602@netconfcentral.com> <20090521.222817.21625953.mbj@tail-f.com> <1242990107.6374.97.camel@missotis> <20090522.151854.168444343.mbj@tail-f.com> <1243001166.6374.117.camel@missotis> In-Reply-To: <1243001166.6374.117.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] revision mismatch 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, 22 May 2009 23:33:42 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Pá 22. 05. 2009 v 15:18 +0200: >>> Examples for two revisions of the same module, X0 is used by the >> server >>> and X1 by the client, where X0 < X1: >>> >>> * Revision X1 adds a new enum value and the client tries to set the >>> leaf to this value. For the server the value is invalid, so it >>> returns an error message. >>> >>> * Even worse: Leaf "mtu" has no default value defined in X0 (but is >> not >>> mandatory either), so the server uses a specific operational >> value, >>> say 296, perhaps hardwired. Revision X1 adds a default value of >> 1500 >>> for "mtu". When "mtu" is not in the configuration obtained from >> the >>> server, the client concludes MTU is set to 1500, which is not the >>> case. >>> >>> Are these not interoperability problems? >> I think these situations should be up to the client to handle >> properly. I don't think the solution is to say that such a client >> MUST close the session. Suppose the client simply does a >> for archival reasons - should it not be allowed to do >> this? > > In the first case, the edit-config operation fails, and the second is an > undetected mismatch in the client and server data. Both situations are > abnormal. > > Rather than closing the session, the client could learn about the > revision advertised by the server and switch to server's revision, and > abort the session only if it is not possible. This would induce a > modification in NETCONF hello negotiation, though. > The client already knows about the server's revision, because it is advertised in the . There is no modification needed, beyond the refinement already specified in the YANG draft. > Lada > Andy From andy@netconfcentral.com Sat May 23 07:26: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 1A8563A69B1 for ; Sat, 23 May 2009 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_50=0.001, 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 rWdtdS5wfc3m for ; Sat, 23 May 2009 07:26:35 -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 7A8C43A686D for ; Sat, 23 May 2009 07:26:35 -0700 (PDT) Received: (qmail 93311 invoked from network); 23 May 2009 14:28:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 23 May 2009 14:28:11 -0000 X-YMail-OSG: JFY4mGIVM1nkJe0MRn2H7WHhndm7RHOVpjabewgKmhzSQY6ERUYUowweI00GxJWiKuypj4qF4nvfuGGwu0NQCBP..lnOImvO7Z7PnRItCyozJ15I7480fmBkHVw4DB89rn2tTaYw8ouaD_jdtDIyt7HrwIN7UzRgQMWNsSsUbpf7nv2VRf0xqzKJE1fEHSTRUYjJGEaANy8W_6k6bzM9AeVLUnBTKiHXT.1uYTb1JQj1uLOr0OpqqJecTu2zJRyk86rI4SwsC9jsBiKN8Dm5PKSyfJmHzw8nbSZi8BQEYfwr.Hy4Js4D X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1807E6.6020202@netconfcentral.com> Date: Sat, 23 May 2009 07:27:50 -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] feature advertisement 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, 23 May 2009 14:26:36 -0000 Hi, Here is a corner-case for the feature capability that I am trying to code right now: module foo { feature A; feature B { if-feature A; } leaf X { if-feature B; mandatory true; type string; } } So what happens if the agent developer messes up and just enables feature 'B', not features 'A' and 'B'? Should the agent advertise feature 'B' for module 'foo'? The manager can figure out that 'A' is not enabled, and therefore leaf 'X' is not really mandatory. Or should the agent only advertise a capability if all of the nested if-features are also true? It seems like this is the intent, although either way works. Perhaps some text (in 5.6.4 and/or 7.18.1) about this issue is needed. Andy From andy@netconfcentral.com Sat May 23 16:41: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 E160C3A6C32 for ; Sat, 23 May 2009 16:41:15 -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 ZpLvgjxy-+fp for ; Sat, 23 May 2009 16:41:15 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 626AC3A6AD7 for ; Sat, 23 May 2009 16:40:57 -0700 (PDT) Received: (qmail 12846 invoked from network); 23 May 2009 23:42:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 23 May 2009 23:42:35 -0000 X-YMail-OSG: gG61yYAVM1mJwHgwmoVn.n8L0O1jej0a_2cvdKA.EYXm_pbUGlRzuPlBCFrFmjgn56BmB9k6PgXWPpi0FFEBLmWOzv9oHOKlo0WzLnvsqA7FmtKgBylJfkjCdgpS3YFEfwwpZf38m9thJ7ep7Wfi3BwMfuVKnDDXLASF8M6stv2MMT0y.B7vTyr4SSuqnDsvDjVYtuKy7JDdUCe_89qrKvU.4d5pPdcY589k_gcnDDQrM6cNcrADX2SLyU8HJ8j8XOmgVn2jwzLs8YC3 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1889EA.2080601@netconfcentral.com> Date: Sat, 23 May 2009 16:42:34 -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-05, 8.3, constraint enforcement 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, 23 May 2009 23:41:16 -0000 Hi, Section 8.3.1 completely ignores access-denied errors. None of the specified errors will be returned if the ACM test fails first. Then access-denied is the only error reported. Section 8.3.2 is mostly a redundant explanation of NETCONF processing rules. The last bullet mentions false 'when' statements but not false 'if-feature' statements/ This section on should specify if it is OK for a client to create a new node which has a false when statement attached to it. Clearly, a false 'if-feature' node is treated as an 'unknown-element' error. (Or is it?) The issue is of course the candidate config. An implementation must attempt to defer all errors that can possibly be fixed before the commit. (That's why it's called a scratch-pad database.) What if the when expression result(s) change before the ? What if they change many times before the ? Since it is a global scratch-pad, if another session issues a validate(), then is it OK for the agent to remove 'false conditional' nodes from the candidate? Can these nodes be silently removed like empty NP containers, or must an error be reported if they are set? What if the 'when' result(s) are true during , but false later, during another , or during a ? What if the set of enabled features changes before the ? Same sort of issues as for when-stmt. Andy From andy@netconfcentral.com Sat May 23 18:35: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 8C67F3A6B7D for ; Sat, 23 May 2009 18:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.493 X-Spam-Level: X-Spam-Status: No, score=-1.493 tagged_above=-999 required=5 tests=[AWL=-0.717, 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 L4bKvniubqcG for ; Sat, 23 May 2009 18:35:19 -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 E16433A6B18 for ; Sat, 23 May 2009 18:35:19 -0700 (PDT) Received: (qmail 63541 invoked from network); 24 May 2009 01:36:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 24 May 2009 01:36:56 -0000 X-YMail-OSG: WHo8auMVM1nsLxMRIMFH0HhfHGIbkof86E2ymTbGHJonsg2TJ477FoGoIptSzDCgzdH.ZDbYBVKT_32nlg0.e2V4zJaf2rO28IUBIHDQ3uo_iQ8BUgM60HbSo5rwv..iFWRfTeOOjGOLQCR3o_nEOvxP2vtAYP5C8HtZN.zXinzfDqH.8sY_C5jg9am8RFR7Xnd18Ik5IX.NnIy_fycCWAmdSSuqgPt.uugk_GyEqGDMxhWtvtIpT.SeoAD9.nwbDevGJRc1c.a1wx5R X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A18A4B7.4040705@netconfcentral.com> Date: Sat, 23 May 2009 18:36:55 -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: Sun, 24 May 2009 01:35:20 -0000 Martin Bjorklund wrote: ..... > 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". > Going back to Martin's original example for false-when deletion: What if the example above was config data instead of /rpc/input data? container ip-params { leaf ip-version { type inet:ip-version; } container ipv4-params { when "../ip-version = 'ipv4'"; ... } container ipv6-params { when "../ip-version = 'ipv6'"; ... } ... } Here is the existing config: ipv4 ... An operation is received: ... ... ipv6 Is it clear why the agent should not reject the request with an 'unknown-element' error (because ipv6-params does not exist when the PDU is received)? IMO, the correct behavior is to let false-when-nodes be created and then immediately delete them if the when expression does not change to true by the time all of the contents are applied. This will not produce an error like a false 'if-feature', but there is no standard way to enable/disable features, let alone to do it on-the-fly inside an . > > /martin > > > Andy From lhotka@cesnet.cz Sun May 24 02:23: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 506C83A6FCF for ; Sun, 24 May 2009 02:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[AWL=-0.949, 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 hLuCaQoRMnpW for ; Sun, 24 May 2009 02:22:59 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 865C83A6F54 for ; Sun, 24 May 2009 02:22: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 1A527D800C7; Sun, 24 May 2009 11:24:38 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A1736B5.3090701@netconfcentral.com> References: <4A15B752.8050602@netconfcentral.com> <20090521.222817.21625953.mbj@tail-f.com> <1242990107.6374.97.camel@missotis> <20090522.151854.168444343.mbj@tail-f.com> <1243001166.6374.117.camel@missotis> <4A1736B5.3090701@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sun, 24 May 2009 11:24:36 +0200 Message-Id: <1243157076.6709.3.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] revision mismatch 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, 24 May 2009 09:23:00 -0000 Andy Bierman píše v Pá 22. 05. 2009 v 16:35 -0700: > > Rather than closing the session, the client could learn about the > > revision advertised by the server and switch to server's revision, > and > > abort the session only if it is not possible. This would induce a > > modification in NETCONF hello negotiation, though. > > > > The client already knows about the server's revision, > because it is advertised in the . > There is no modification needed, beyond the refinement already > specified in the YANG draft. Oh yes, sorry, I assumed the supported modules are advertised by both the client and server, but after checking the draft I realized that the client doesn't send them in . So it should be OK provided that the server always sends the revision as a part of the capability string. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Sun May 24 07:01: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 25F663A6CCC for ; Sun, 24 May 2009 07:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_62=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 25NwiBrc08uX for ; Sun, 24 May 2009 07:01:17 -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 CDD4F3A68ED for ; Sun, 24 May 2009 07:01:01 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4848A616004; Sun, 24 May 2009 16:02:39 +0200 (CEST) Date: Sun, 24 May 2009 16:02:38 +0200 (CEST) Message-Id: <20090524.160238.199634663.mbj@tail-f.com> To: wjhns1@hardakers.net From: Martin Bjorklund In-Reply-To: References: 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 netmod-yang-05 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, 24 May 2009 14:01:18 -0000 Hi Wes, Wes Hardaker wrote: > General: > > - Many rules don't have MUSTs and SHOULDs and many do. The wording > seems to be fairly inconsistent with respect to this. There are many > points in the document where it's stated flatly that something is > allowed or disallowed, and other points where the use of the word MUST > is included. I'm confused as to why MUSTs are present sometimes and > not others. > > - Much of the document seems to be written with the mindset of the > (sub)module authors but don't discuss things in terms of > implementations. In fact many of the MUSTs/SHOULDs/MAYs seem to be > directed at module authors rather than parser authors. Maybe this is > intentional. Yes, in fact, I don't think any rules (except maybe the edit-config rules) are worded specifically for implementations. The rules try to specify what is legal and illegal in the YANG language. > - The substatement tables are *extremely* helpful. Thanks for doing those. > > > Section 4.2.3: > The example adds a few things not discussed so far: > "config true;" at the top: what's the default value? It must be true > based on the other examples? You should state one way or the other > (maybe in a // comment) that it's the default or not. The second sentence in 4.2.3 says: When a node is tagged with "config false", its subhierarchy is flagged as state data So it implies that if the node is not tagged with config false, and does not belong to such a subhierarchy, then it is is config data. Section 4 is an overview section, so I would rather not go into all the details here; the exact rules are covered later (in 7.19.1). > Observed-speed could use a unit to be complete, but I actually think > it should be left out because it hasn't been introduced yet. Ok, we'll leave it out :) > Section 4.2.5: > s/uint16/uint8/ Fixed. > Section 4.2.6 (I didn't get far enough into the document to check elsewhere): > > Can you use two "use" cases in a single statement. What about "use" > followed by other objects? I suspect this is covered later. Yes, this is all fine. > Section 4.2.7: > If mandatory isn't needed there (I don't think so) it should probably > be removed till it's introduced later. Done. > Choosing beer as the example data I think would be better since it > provides an example of an empty clause, which isn't shown until now. Done. NETCONF XML Example: > Section 4.2.8: > > I found the first paragraph a bit oddly worded and hard to follow. How about this rewording, and simplification: OLD: YANG allows a module to insert additional nodes into data models, including both the current module (and its submodules) or an external module. NEW: YANG allows a module to extend data models with additional nodes. > Section 4.2.9: > > s#acmefw-2.3#acmefw-2.3# Fixed. > Section 4.2.10: > > Change notification from status=up to down to make more sense. But it is the admin-status that is up. Since several people have been confused by this, I will add a leaf "if-oper-status" with the value 'down' as well: NETCONF XML Example: 2007-09-01T10:00:00Z so-1/2/3.0 up down > 5.1.1: > > Use "p" as a prefix rather than "a" in the example for clarity against > a:a. Fixed. > > 5.3.1: > > I can't remember the version number decision if yang was "1" or "1.0" > but ":1" looks odd after seeing ":1.0" in the netconf URNs. I don't think we ever had a discussion on this list about this, but IMO "1" is sufficient. > 5.4: > > It might be worth taking another editing hit on the second paragraph. > > 5.6.2: > > remove the "s" in '"features"' or put it after the " Removed the "s". > 5.6.4.3: > > I find the use of the second capability announcing the deviation a bit > odd. Specifically, the fact that the URL doesn't seem to matter > (ending in my-deviations) but the module name afterward > (?module=my-devs) is what is supposed to be matched on. I'm sure > readers will get it eventually but it took me a bit. Not only that, > there might be confusion about how to advertise multiple deviation > modules. > > 5.6.5: > > Need to decide on or remove the open question marking It was decided to move this text to the monitoring draft. > 6.1.3: > > It should be noted that many definitions of "whitespace" include > newlines, including standard regular expressions. > > # perl -l -e 'print "hello" if ("\n" =~ /\s/);' > hello > > But this section deviates from that and discusses whitespace heavily > but the examples show that newlines are exempt from being called > whitespace (and you really mean just spaces and tabs). (mostly in the > paragraph "trailing whitespace is stripped..." which would remove the \n) We can't simply s/whitespace/space or tab/. Do you think it would work if we write: If a string contains any whitespace characters (space or tab), or do we need more? > 6.3: > > "Forward references are allowed in YANG". > > MUST be supported? This would direct the rule to implementations, where the current text talks about what is legal. > 7.1: > > "A module SHOULD have the following layout:" > > What if it doesn't? Does that mean a parser implementation doesn't > have to accept it? (this is an example of text written toward the > author when it's the parser implementation that will be the most > affected but yet the text doesn't describe the requirements of the > implementation). The exact rules are specified in the grammar. This text is there to give the reader a quick overwiew of a what a module contains, instead of having to figure it out from the grammar. Would it be better to write A module has the following layout: or would that just make it worse? > 7.1.2: > > Is yang-version technically a string, decimal64 or binary blob? Or an uint8, uint64... Does it matter what it is? > 7.1.6: > > "It is an error ..." -> an example of a missing MUST NOT? NEW: Multiple revisions of the same module MUST NOT be imported. > 7.1.9: > > I'd add the word "published" or "distributed" in front of "editorial > change" Added "published". > 7.2: > > It'd be less a strain on IANA to have submodules prefixed with > "parentmodule:" so that there exists a naming hierarchy for submodules > such that there is no chance for collision. Does anyone else have an opinion on this? > 7.5.3: > > Please please please don't hard-code the startup/running/candidate > components into the yang document. There is a definite possibility of > future netconf extensions providing additional storage mechanisms and > you don't want to rev yang because of it. > > Yang should stay out of specifying what datastores contain config, > state or whatever. In some places (such as in 7.5.3) I think we can replace the text ", , or " with a more generic "NETCONF datastore", but in some other places, it gets tricky. Specifically in 8.3.3 which discusses when data is validated. In some earlier versions of the draft I just talked about "valid configuration", with the intention that 4741 specifies that is always valid, and is valid at commit time. The current text was added as clarification to this. > Somewhere: > > You might add an example that uses current() somewhere There are two examples in 9.9.6. > 7.5.8: > > This seems to blur the lines into the netconf territory and makes me > nervous about future expansion. Additionally, because it so netconf > specific it doesn't allow parallel xml data of some other form. 4741 leaves some questions open for the data modeling language to decide. I believe we must answer those questions in this docuement. This section (and other similar) is very specific by ints nature. > Somewhere: > > Does the document discuss long-term issues with leaves? IE, once a > leaf name has been published it can never change in definition? Yes, see section 10, Updating a Module. > 7.6.7: > > Before the colon add "placed into the previously defined "ssh" container: Done. > 7.7.5: > > What happens when a client requests data from a system ordered set of > data, jumbles it (say makes it alphabetical according to how a user > sorted it on the screen) and sends it back (eg, via a replace)? This > isn't discussed... > > 1) can the server reject it? > 2) does the server have to parse it? Why would the server reject it? Since there is no semantic order defined, the client can send the data in any order, but the server is free to re-order (but it doesn't have to). > 3) is the server allowed to define internal semantics of it's own > ordering? (see large routing table implementations) I don't understand what you mean with "define internal semantics"? > Sorry I didn't get farther into the document... Thanks for your comments! /martin From mbj@tail-f.com Sun May 24 07:36: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 20A1E28C0D0 for ; Sun, 24 May 2009 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_50=0.001, 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 vkauGPl6maSK for ; Sun, 24 May 2009 07:36: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 EF86D3A6AE2 for ; Sun, 24 May 2009 07:35:56 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BDA4E616004; Sun, 24 May 2009 16:37:34 +0200 (CEST) Date: Sun, 24 May 2009 16:37:34 +0200 (CEST) Message-Id: <20090524.163734.20328589.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1807E6.6020202@netconfcentral.com> References: <4A1807E6.6020202@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] feature advertisement 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, 24 May 2009 14:36:17 -0000 Andy Bierman wrote: > Hi, > > Here is a corner-case for the feature capability > that I am trying to code right now: > > module foo { > > feature A; > > feature B { > if-feature A; > } > > leaf X { > if-feature B; > mandatory true; > type string; > } > } > > > > So what happens if the agent developer messes up > and just enables feature 'B', not features 'A' and 'B'? > > Should the agent advertise feature 'B' for module 'foo'? > The manager can figure out that 'A' is not enabled, and > therefore leaf 'X' is not really mandatory. Since feature B is valid only if feature A is enabled, an agent that advertises only feature B has a bug. > Or should the agent only advertise a capability if all > of the nested if-features are also true? It seems like > this is the intent, although either way works. > > Perhaps some text (in 5.6.4 and/or 7.18.1) about this > issue is needed. Would this work (in 7.18.1): If a feature is dependent on another feature (i.e. the feature has a "if-feature" substatement), a device which implement the first feature MUST also implement the feature it depends on. /martin From mbj@tail-f.com Sun May 24 07:49: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 915823A6A01 for ; Sun, 24 May 2009 07:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.642 X-Spam-Level: X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_40=-0.185, 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 CNgwEoVTErHl for ; Sun, 24 May 2009 07:49:52 -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 C70E83A6879 for ; Sun, 24 May 2009 07:49:52 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5718C616004; Sun, 24 May 2009 16:51:30 +0200 (CEST) Date: Sun, 24 May 2009 16:51:29 +0200 (CEST) Message-Id: <20090524.165129.180686637.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1242892998.6931.49.camel@missotis> References: <1242821702.16094.37.camel@missotis> <20090520.225246.237098168.mbj@tail-f.com> <1242892998.6931.49.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] edit-config for lists 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, 24 May 2009 14:49:53 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAyMC4gMDUuIDIwMDkgdiAyMjo1MiArMDIwMDoNCj4gPiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gSGksDQo+ID4gPiANCj4g PiA+IGlmIEkgc2xpZ2h0bHkgZXh0ZW5kIHRoZSBleGFtcGxlIG5lYXIgdGhlIGVuZCBvZiBTZWMu IDcuNy44Og0KPiA+ID4gDQo+ID4gPiAuLi4NCj4gPiA+ICAgICA8c3NoPg0KPiA+ID4gICAgICAg ICA8Y2lwaGVyIG5jOm9wZXJhdGlvbj0iY3JlYXRlIg0KPiA+ID4gICAgICAgICAgICAgICAgIHlh bmc6aW5zZXJ0PSJhZnRlciINCj4gPiA+ICAgICAgICAgICAgICAgICB5YW5nOnZhbHVlPSIzZGVz LWNiYyI+Ymxvd2Zpc2gtY2JjPC9jaXBoZXI+DQo+ID4gPiAgICAgICAgIDxjaXBoZXIgbmM6b3Bl cmF0aW9uPSJjcmVhdGUiDQo+ID4gPiAgICAgICAgICAgICAgICAgeWFuZzppbnNlcnQ9ImFmdGVy Ig0KPiA+ID4gICAgICAgICAgICAgICAgIHlhbmc6dmFsdWU9IjNkZXMtY2JjIj5hZXMtY2JjPC9j aXBoZXI+DQo+ID4gPiAgICAgPC9zc2g+DQo+ID4gPiAuLi4NCj4gPiA+IA0KPiA+ID4gV2hhdCB3 aWxsIGJlIHRoZSByZXN1bHRpbmcgb3JkZXIgb2YgbGlzdCBlbnRyaWVzOiAiM2Rlcy1jYmMsIGJs b3dmaXNoLWNiYywNCj4gPiA+IGFlcy1jYmMiIG9yDQo+ID4gPiAiM2Rlcy1jYmMsIGFlcy1jYmMs IGJsb3dmaXNoLWNiYyI/DQo+ID4gDQo+ID4gU2luY2UgZWFjaCBvcGVyYXRpb24gaXMgYXBwbGll ZCBpbiBvcmRlciwgaXQgd2lsbCBiZSB0aGUgbGF0dGVyLg0KPiANCj4gV2hlcmUgaXMgdGhpcyBz cGVjaWZpZWQ/DQoNCkhtbSwgaXQncyBub3QgZXhwbGljaXRseSBzcGVjaWZpZWQgZm9yIHRoaXMg Y2FzZS4gIEl0IGlzIGV4cGxpY2l0bHkNCm1lbnRpb25lZCBmb3IgInJlcGxhY2UiLg0KDQpIb3cg YWJvdXQgYWRkaW5nIHRoaXMgdG8gNy44LjY6DQoNCiAgSWYgc2V2ZXJhbCBsaXN0IGVudHJpZXMg aW4gYW4gIm9yZGVyZWQtYnkgdXNlciIgbGlzdCBhcmUgbW9kaWZpZWQgaW4NCiAgdGhlIHNhbWUg PGVkaXQtY29uZmlnPiByZXF1ZXN0LCB0aGUgZW50aXJlcyBhcmUgbW9kaWZpZWQgb25lIGF0IHRo ZQ0KICB0aW1lLCBpbiB0aGUgb3JkZXIgb2YgdGhlIFhNTCBlbGVtZW50cyBpbiB0aGUgcmVxdWVz dC4NCg0KPiBJJ2QgYWN0dWFsbHkgcHJlZmVyIGlmIHRoZSBlbnRpcmUgZWRpdC1jb25maWcNCj4g d2FzIGF0b21pYy4NCg0KImF0b21pYyIgaXMgbWF5YmUgbm90IHRoZSByaWdodCB3b3JkLiAgRG8g eW91IG1lYW4gdGhhdCB0aGUgcmVzdWx0IG9mDQp0aGUgZXhhbXBsZSBzaG91bGQgYmUgdW5kZWZp bmVkPw0KDQoNCi9tYXJ0aW4NCg== From andy@netconfcentral.com Sun May 24 08:23: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 2F9F13A6A67 for ; Sun, 24 May 2009 08:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.843, 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 PK5-PwJf8cJT for ; Sun, 24 May 2009 08:23:43 -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 8643128C0D0 for ; Sun, 24 May 2009 08:23:43 -0700 (PDT) Received: (qmail 56026 invoked from network); 24 May 2009 15:25:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 24 May 2009 15:25:21 -0000 X-YMail-OSG: WwK8ljkVM1lQMTUec.i0smmC3qRzeIEZuOfwHFm_9vZcNG557H4wR7OG0y.nlkDAOZW4lx6.JEORUo0rQsStyqN49fpZrnse4yhnx11kBwUbNNR7Vf9luI3IrlXFieTeBcZe5Sxz7_NCfi23OpIco3qwwOvVjTL1UahBw7Kbd6X3kvKFxh6riaaYuvUp2tVwifA529w2zpLAGZqJeF3glUc8utQ2KBExzsDoZgNoCp1rWRmA6kOonZjS.iMnQAhzxpSqDDCzr_rSmQo9s827YO2KgcplRgDhCXKV6njpp5lWtHaGq.efRAXUh4..VoMT3C53HQ9vJn65q2HgG.HttVMO7Npe4VPPPL74yUeF48TfQtH_qQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1966CB.3060805@netconfcentral.com> Date: Sun, 24 May 2009 08:24:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1807E6.6020202@netconfcentral.com> <20090524.163734.20328589.mbj@tail-f.com> In-Reply-To: <20090524.163734.20328589.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] feature advertisement 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, 24 May 2009 15:23:50 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Here is a corner-case for the feature capability >> that I am trying to code right now: >> >> module foo { >> >> feature A; >> >> feature B { >> if-feature A; >> } >> >> leaf X { >> if-feature B; >> mandatory true; >> type string; >> } >> } >> >> >> >> So what happens if the agent developer messes up >> and just enables feature 'B', not features 'A' and 'B'? >> >> Should the agent advertise feature 'B' for module 'foo'? >> The manager can figure out that 'A' is not enabled, and >> therefore leaf 'X' is not really mandatory. > > Since feature B is valid only if feature A is enabled, an agent that > advertises only feature B has a bug. > OK -- let's make sure the text is clear about that >> Or should the agent only advertise a capability if all >> of the nested if-features are also true? It seems like >> this is the intent, although either way works. >> >> Perhaps some text (in 5.6.4 and/or 7.18.1) about this >> issue is needed. > > Would this work (in 7.18.1): > > If a feature is dependent on another feature (i.e. the feature > has a "if-feature" substatement), a device which implement the first > feature MUST also implement the feature it depends on. > How about: If a feature is dependent on any other features (i.e., the feature has one or more "if-feature" sub-statements), then all of features it depends on MUST also be implemented by the agent. > > > /martin > > Andy From mbj@tail-f.com Sun May 24 09:41: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 33C2B28C11B for ; Sun, 24 May 2009 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_40=-0.185, 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 EL+LELCpqw0T for ; Sun, 24 May 2009 09:41: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 6F0693A6F33 for ; Sun, 24 May 2009 09:41:20 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 68255616004; Sun, 24 May 2009 18:42:56 +0200 (CEST) Date: Sun, 24 May 2009 18:42:56 +0200 (CEST) Message-Id: <20090524.184256.63367475.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1966CB.3060805@netconfcentral.com> References: <4A1807E6.6020202@netconfcentral.com> <20090524.163734.20328589.mbj@tail-f.com> <4A1966CB.3060805@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] feature advertisement 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, 24 May 2009 16:41:25 -0000 Andy Bierman wrote: > How about: > > If a feature is dependent on any other features (i.e., the feature > has one or more "if-feature" sub-statements), then all of features > it depends on MUST also be implemented by the agent. Ok, with s/agent/device since we use "device" in the surrounding text. /martin From balazs.lengyel@ericsson.com Mon May 25 01:06: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 A28E43A6847 for ; Mon, 25 May 2009 01:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.143, 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 4vW6hJdIHAnU for ; Mon, 25 May 2009 01:06:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D892E3A6B38 for ; Mon, 25 May 2009 01:05:53 -0700 (PDT) X-AuditID: c1b4fb3c-b7b94ae000000eff-a8-4a1a51c49a20 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 08.C1.03839.4C15A1A4; Mon, 25 May 2009 10:07:32 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:07:31 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:07:30 +0200 Message-ID: <4A1A51C2.1040904@ericsson.com> Date: Mon, 25 May 2009 10:07:30 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1679C5.2080801@ericsson.com> <20090522.150929.01646103.mbj@tail-f.com> In-Reply-To: <20090522.150929.01646103.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2009 08:07:31.0017 (UTC) FILETIME=[DA1A3B90:01C9DD0F] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 25 May 2009 08:06:17 -0000 Martin Bjorklund wrote: > >> 2) Does a leafref has it's own value or is it just a second way of accessing >> the referenced leaf? > > It has it's own value. If not, 'require-instance false' would not > make much sense. > >> 3) Can I write to a leaf of type leafref? > > Of course. Is there anything in the text that suggest otherwise? > >> Will that modify the value of the >> referenced leaf? > > No. Is there anything in the text that suggest this? > list interface { key "name"; leaf name { type string; } leaf admin-status { type admin-status; } } ------------------------- leaf mgmt-interface-state { type leafref { path "../interface/name/admin-status"; } } ----------------------- A) If I change the value of mgmt-interface-state it will always be an error, because its value will become different from the value of the relevant admin-status? B) If I change the value of admin-status it will always be an error because, its value will become different from the value of the relevant mgmt-interface-state? True? (Forget for the moment manually setting both values at the same time, which is not nice.) Balazs From mbj@tail-f.com Mon May 25 01:15: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 0AF453A6E51 for ; Mon, 25 May 2009 01:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.223, 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 y1fhoCMSB7K4 for ; Mon, 25 May 2009 01:15:36 -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 25CE63A6E1A for ; Mon, 25 May 2009 01:15:35 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 5E5B661600D; Mon, 25 May 2009 10:17:15 +0200 (CEST) Date: Mon, 25 May 2009 10:17:18 +0200 (CEST) Message-Id: <20090525.101718.49696777.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A1A51C2.1040904@ericsson.com> References: <4A1679C5.2080801@ericsson.com> <20090522.150929.01646103.mbj@tail-f.com> <4A1A51C2.1040904@ericsson.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] leaf-ref questions 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, 25 May 2009 08:15:37 -0000 Balazs Lengyel wrote: > > > Martin Bjorklund wrote: > > > >> 2) Does a leafref has it's own value or is it just a second way of accessing > >> the referenced leaf? > > It has it's own value. If not, 'require-instance false' would not > > make much sense. > > > >> 3) Can I write to a leaf of type leafref? > > Of course. Is there anything in the text that suggest otherwise? > > > >> Will that modify the value of the > >> referenced leaf? > > No. Is there anything in the text that suggest this? > > > > list interface { > key "name"; > leaf name { > type string; > } > leaf admin-status { > type admin-status; > } > } > > ------------------------- > > leaf mgmt-interface-state { > type leafref { > path "../interface/name/admin-status"; > } > } > > ----------------------- > > A) If I change the value of mgmt-interface-state it will always be an error, > because its value will become different from the value of the relevant > admin-status? > > B) If I change the value of admin-status it will always be an error because, > its value will become different from the value of the relevant > mgmt-interface-state? > > True? Yes, unless it's the candidate which is allowed to be invalid. But note that this is a very odd use-case. At first we had just keyref, which didn't have this problem. Then we generalized it to leafref, mainly to handle the use case where you include such leafrefs in notifications. We did not add a CLR which made use cases like this one illegal. (And I prefer to keep it this way; who knows, maybe there's a great use case for this that we can't see right now). /martin From balazs.lengyel@ericsson.com Mon May 25 01:17: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 0323A28C171 for ; Mon, 25 May 2009 01:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.140, 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 g0UAQ+qFyRJt for ; Mon, 25 May 2009 01:17:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7F5E628C16A for ; Mon, 25 May 2009 01:16:17 -0700 (PDT) X-AuditID: c1b4fb3e-b7b8aae000007ae8-b4-4a1a543434ad Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 5A.46.31464.4345A1A4; Mon, 25 May 2009 10:17:56 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:17:56 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:17:56 +0200 Message-ID: <4A1A5433.4050809@ericsson.com> Date: Mon, 25 May 2009 10:17:55 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1679C5.2080801@ericsson.com> <20090522.150929.01646103.mbj@tail-f.com> In-Reply-To: <20090522.150929.01646103.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2009 08:17:56.0239 (UTC) FILETIME=[4EC389F0:01C9DD11] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 25 May 2009 08:17:14 -0000 Martin Bjorklund wrote: >> 1) Does path point to a leaf node in the datastore or just a potential leaf >> node? The draft says about path: >> "It takes as an argument a string which MUST refer to a leaf node." >> However I think if require-instance is false, path only points to a potential >> leaf. > > I think this is clear from the text on require-instance, which has > been clarified as suggested by Lada. > Quote: "The leafref type is used to reference a particular leaf instance in the data tree. Its value is constrained to be the same as the value of an existing leaf." To me the quoted sentences above say that the referred leaf must exists, contradicting the later explanation. How about: The leafref type is used to reference a particular leaf instance in the data tree which MAY or MAY NOT exist. If it exists, its value is constrained to be the same as the value of the referenced leaf." Balazs From balazs.lengyel@ericsson.com Mon May 25 01:17: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 D6CED3A6975 for ; Mon, 25 May 2009 01:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.137, 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 BBHsQJuiN3H5 for ; Mon, 25 May 2009 01:17:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 88A1B3A6880 for ; Mon, 25 May 2009 01:17:32 -0700 (PDT) X-AuditID: c1b4fb3e-b7b8aae000007ae8-fa-4a1a5480e227 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 5D.86.31464.0845A1A4; Mon, 25 May 2009 10:19:12 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:19:12 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:19:12 +0200 Message-ID: <4A1A547D.3050703@ericsson.com> Date: Mon, 25 May 2009 10:19:09 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1679C5.2080801@ericsson.com> <20090522.150929.01646103.mbj@tail-f.com> <4A1A51C2.1040904@ericsson.com> <20090525.101718.49696777.mbj@tail-f.com> In-Reply-To: <20090525.101718.49696777.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2009 08:19:12.0287 (UTC) FILETIME=[7C178AF0:01C9DD11] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 25 May 2009 08:17:34 -0000 My fear is that we introduced Many such odd cases. Balazs Martin Bjorklund wrote: > Balazs Lengyel wrote: >> >> Martin Bjorklund wrote: >>>> 2) Does a leafref has it's own value or is it just a second way of accessing >>>> the referenced leaf? >>> It has it's own value. If not, 'require-instance false' would not >>> make much sense. >>> >>>> 3) Can I write to a leaf of type leafref? >>> Of course. Is there anything in the text that suggest otherwise? >>> >>>> Will that modify the value of the >>>> referenced leaf? >>> No. Is there anything in the text that suggest this? >>> >> list interface { >> key "name"; >> leaf name { >> type string; >> } >> leaf admin-status { >> type admin-status; >> } >> } >> >> ------------------------- >> >> leaf mgmt-interface-state { >> type leafref { >> path "../interface/name/admin-status"; >> } >> } >> >> ----------------------- >> >> A) If I change the value of mgmt-interface-state it will always be an error, >> because its value will become different from the value of the relevant >> admin-status? >> >> B) If I change the value of admin-status it will always be an error because, >> its value will become different from the value of the relevant >> mgmt-interface-state? >> >> True? > > Yes, unless it's the candidate which is allowed to be invalid. > > But note that this is a very odd use-case. At first we had just > keyref, which didn't have this problem. Then we generalized it to > leafref, mainly to handle the use case where you include such leafrefs > in notifications. We did not add a CLR which made use cases like this > one illegal. (And I prefer to keep it this way; who knows, maybe > there's a great use case for this that we can't see right now). > > > /martin > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Mon May 25 01:22: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 51AB93A6930 for ; Mon, 25 May 2009 01:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.134, 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 tULHu9XlnZVA for ; Mon, 25 May 2009 01:22:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5F0FE3A6884 for ; Mon, 25 May 2009 01:22:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7b8aae000007ae8-2d-4a1a55bf6867 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 97.57.31464.FB55A1A4; Mon, 25 May 2009 10:24:31 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:24:31 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:24:31 +0200 Message-ID: <4A1A55BD.5000206@ericsson.com> Date: Mon, 25 May 2009 10:24:29 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1679C5.2080801@ericsson.com> <20090522.150929.01646103.mbj@tail-f.com> In-Reply-To: <20090522.150929.01646103.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2009 08:24:31.0100 (UTC) FILETIME=[3A1E8BC0:01C9DD12] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 25 May 2009 08:22:53 -0000 Martin Bjorklund wrote: >> 4) What does it mean if path's nodeset is empty? What happens if we read/write >> to this leafref? > > If it is a require-instance true, then it will not be valid (at > validate / commit time). > Yes but if require-instance is false what happens if I read or write to the leafref? a) What will I get in a operation for such a leafref? b) Can I write anything successfully to such a leafref? What does it really refer to? c) Why do we want to allow this in a valid configuration? What is the use-case? Balazs From mbj@tail-f.com Mon May 25 01:27: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 BFC043A68B0 for ; Mon, 25 May 2009 01:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.209, 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 6u2sg0s-tmw4 for ; Mon, 25 May 2009 01:27:26 -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 0AF7E3A6884 for ; Mon, 25 May 2009 01:27:25 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 76BED61600D; Mon, 25 May 2009 10:29:06 +0200 (CEST) Date: Mon, 25 May 2009 10:29:09 +0200 (CEST) Message-Id: <20090525.102909.263518864.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A1A5433.4050809@ericsson.com> References: <4A1679C5.2080801@ericsson.com> <20090522.150929.01646103.mbj@tail-f.com> <4A1A5433.4050809@ericsson.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] leaf-ref questions 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, 25 May 2009 08:27:26 -0000 Balazs Lengyel wrote: > > > Martin Bjorklund wrote: > >> 1) Does path point to a leaf node in the datastore or just a potential leaf > >> node? The draft says about path: > >> "It takes as an argument a string which MUST refer to a leaf node." > >> However I think if require-instance is false, path only points to a > >> potential > >> leaf. > > I think this is clear from the text on require-instance, which has > > been clarified as suggested by Lada. > > > Quote: > "The leafref type is used to reference a particular leaf instance in the data > tree. Its value is constrained to be the same as the value of an existing > leaf." > > To me the quoted sentences above say that the referred leaf must exists, > contradicting the later explanation. Agreed. It is clear that the text on leafrefs needs to be rewritten, and I will send a proposal to the list once its done. /martin From balazs.lengyel@ericsson.com Mon May 25 01:37: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 F012D3A6D87 for ; Mon, 25 May 2009 01:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.132, 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 DXusx04aloDm for ; Mon, 25 May 2009 01:37:33 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9B1B63A6841 for ; Mon, 25 May 2009 01:37:32 -0700 (PDT) X-AuditID: c1b4fb3c-b7b94ae000000eff-5e-4a1a592f3374 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A7.46.03839.F295A1A4; Mon, 25 May 2009 10:39:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:39:11 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 10:39:11 +0200 Message-ID: <4A1A592D.7070503@ericsson.com> Date: Mon, 25 May 2009 10:39:09 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1679C5.2080801@ericsson.com> <20090522.150929.01646103.mbj@tail-f.com> <4A1A51C2.1040904@ericsson.com> <20090525.101718.49696777.mbj@tail-f.com> In-Reply-To: <20090525.101718.49696777.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2009 08:39:11.0103 (UTC) FILETIME=[46A458F0:01C9DD14] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 25 May 2009 08:37:40 -0000 Martin Bjorklund wrote: > Balazs Lengyel wrote: >> >> Martin Bjorklund wrote: >>>> 2) Does a leafref has it's own value or is it just a second way of accessing >>>> the referenced leaf? >>> It has it's own value. If not, 'require-instance false' would not >>> make much sense. >>> >>>> 3) Can I write to a leaf of type leafref? >>> Of course. Is there anything in the text that suggest otherwise? >>> >>>> Will that modify the value of the >>>> referenced leaf? >>> No. Is there anything in the text that suggest this? >>> >> list interface { >> key "name"; >> leaf name { >> type string; >> } >> leaf admin-status { >> type admin-status; >> } >> } >> >> ------------------------- >> >> leaf mgmt-interface-state { >> type leafref { >> path "../interface/name/admin-status"; >> } >> } >> >> ----------------------- >> >> A) If I change the value of mgmt-interface-state it will always be an error, >> because its value will become different from the value of the relevant >> admin-status? >> >> B) If I change the value of admin-status it will always be an error because, >> its value will become different from the value of the relevant >> mgmt-interface-state? >> >> True? > > Yes, unless it's the candidate which is allowed to be invalid. > > But note that this is a very odd use-case. At first we had just > keyref, which didn't have this problem. Then we generalized it to > leafref, mainly to handle the use case where you include such leafrefs > in notifications. We did not add a CLR which made use cases like this > one illegal. (And I prefer to keep it this way; who knows, maybe > there's a great use case for this that we can't see right now). > > > /martin > IMO is there a real use case for allowing write operations for a leafref that points to a real leaf (not a key)? I would argue NO. How about Balazs' rule: If a leafref points to a non-key leaf it must be config false; Balazs From lhotka@cesnet.cz Mon May 25 02:42: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 0904A3A68AA for ; Mon, 25 May 2009 02:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[AWL=-0.570, 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 9PaagHDo0Tn5 for ; Mon, 25 May 2009 02:42:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4221F3A6880 for ; Mon, 25 May 2009 02:42:28 -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 18CCBD800CC for ; Mon, 25 May 2009 11:44:02 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090524.160238.199634663.mbj@tail-f.com> References: <20090524.160238.199634663.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 25 May 2009 11:44:01 +0200 Message-Id: <1243244641.9412.52.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] comments on netmod-yang-05 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, 25 May 2009 09:42:29 -0000 Martin Bjorklund píše v Ne 24. 05. 2009 v 16:02 +0200: > > > > It'd be less a strain on IANA to have submodules prefixed with > > "parentmodule:" so that there exists a naming hierarchy for submodules > > such that there is no chance for collision. > > Does anyone else have an opinion on this? Wes's concern is valid but the notation with the colon separator can be confused with QNames in YANG modules. How about forbidding '.' (dot) in module names and use it as the separator? ... > > > > Does the document discuss long-term issues with leaves? IE, once a > > leaf name has been published it can never change in definition? > > Yes, see section 10, Updating a Module. Not really, its definition can be changed in several ways: new values may be allowed via the leaf's datatype that were not possible in the original version, a default value may be defined, must statement removed etc. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue May 26 01:08: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 5BD633A691A for ; Tue, 26 May 2009 01:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=-0.380, 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 JxtzHffvzQWb for ; Tue, 26 May 2009 01:08:00 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 88E4A3A6A61 for ; Tue, 26 May 2009 01:08:00 -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 12541D800C7; Tue, 26 May 2009 10:09:27 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090524.165129.180686637.mbj@tail-f.com> References: <1242821702.16094.37.camel@missotis> <20090520.225246.237098168.mbj@tail-f.com> <1242892998.6931.49.camel@missotis> <20090524.165129.180686637.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 26 May 2009 10:09:26 +0200 Message-Id: <1243325366.6384.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] edit-config for lists 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, 26 May 2009 08:08:07 -0000 Martin Bjorklund píše v Ne 24. 05. 2009 v 16:51 +0200: > > > Since each operation is applied in order, it will be the latter. > > > > Where is this specified? > > Hmm, it's not explicitly specified for this case. It is explicitly > mentioned for "replace". > > How about adding this to 7.8.6: > > If several list entries in an "ordered-by user" list are modified in > the same request, the entires are modified one at the > time, in the order of the XML elements in the request. > > > I'd actually prefer if the entire edit-config > > was atomic. > > "atomic" is maybe not the right word. Do you mean that the result of > the example should be undefined? My remark about atomicity was related to your statement "each operation is applied in order". Does it mean that only a part of the edit-config may be applied? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Tue May 26 03:53: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 46CF128C1F5 for ; Tue, 26 May 2009 03:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_50=0.001, 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 vgOUMvK0hEgG for ; Tue, 26 May 2009 03:53:13 -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 47CE328C1F7 for ; Tue, 26 May 2009 03:53:13 -0700 (PDT) X-Trace: 106801634/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.179/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.179 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: AkIFANtnG0o+vGSz/2dsb2JhbACDKE6LC74mCIQDBQ X-IronPort-AV: E=Sophos;i="4.41,251,1241391600"; d="scan'208";a="106801634" X-IP-Direction: IN Received: from 1cust179.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.179]) by smtp.pipex.tiscali.co.uk with SMTP; 26 May 2009 11:54:50 +0100 Message-ID: <007a01c9dde7$e463cf20$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" , References: <20090520.224146.220136501.mbj@tail-f.com><1242899308.6931.95.camel@missotis><003501c9da32$12205aa0$6801a8c0@oemcomputer><20090521.222024.246864779.mbj@tail-f.com><001201c9dab5$6f681e40$0601a8c0@allison> <1242984953.6374.65.camel@missotis> Date: Tue, 26 May 2009 10:23:21 +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] character encoding 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, 26 May 2009 10:53:14 -0000 ---- Original Message ----- From: "Ladislav Lhotka" To: Sent: Friday, May 22, 2009 11:35 AM Subject: Re: [netmod] character encoding > tom.petch píše v Pá 22. 05. 2009 v 10:06 +0200: > > Um. Does > > > > 6. YANG syntax > > > > still say > > > > " YANG modules are written in the UTF-8 [RFC3629] character set." > > ? > > > > I have problems with this because UTF-8 is not a character set but a > > transformation format or character (en)coding syntax or ... (depending > > on your > > SDO:-( > > It specifies the encoding of YANG modules in text files. > > > > > And do we really mean that YANG modules can be written in a mixture of > > Han and > > Katakana and ... because that is what it seems to tell me? > > IMO, yes. > > Lada (Láďa, actually :-) Touché. But UTF-8 is still an encoding and not a character set so I think that that needs changing or, as Martin suggested, removing to 4741bis. Tom Petch > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Tue May 26 03:53: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 5740428C1F7 for ; Tue, 26 May 2009 03:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.749, 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 oBdC7FTRJzWi for ; Tue, 26 May 2009 03:53:15 -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 3B00228C1ED for ; Tue, 26 May 2009 03:53:15 -0700 (PDT) X-Trace: 106801679/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.179/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.179 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: AkIFANtnG0o+vGSz/2dsb2JhbACDKE6LC74mCIQDBQ X-IronPort-AV: E=Sophos;i="4.41,251,1241391600"; d="scan'208";a="106801679" X-IP-Direction: IN Received: from 1cust179.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.179]) by smtp.pipex.tiscali.co.uk with SMTP; 26 May 2009 11:54:55 +0100 Message-ID: <008301c9dde7$e75ebfa0$0601a8c0@allison> From: "tom.petch" To: , "Martin Bjorklund" References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> Date: Tue, 26 May 2009 11:32:25 +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] leaf-ref questions 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, 26 May 2009 10:53:16 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Monday, May 25, 2009 10:29 AM Subject: Re: [netmod] leaf-ref questions > Balazs Lengyel wrote: > > Martin Bjorklund wrote: > > >> 1) Does path point to a leaf node in the datastore or just a potential leaf > > >> node? The draft says about path: > > >> "It takes as an argument a string which MUST refer to a leaf node." > > >> However I think if require-instance is false, path only points to a > > >> potential > > >> leaf. > > > I think this is clear from the text on require-instance, which has > > > been clarified as suggested by Lada. > > > > > Quote: > > "The leafref type is used to reference a particular leaf instance in the data > > tree. Its value is constrained to be the same as the value of an existing > > leaf." > > > > To me the quoted sentences above say that the referred leaf must exists, > > contradicting the later explanation. > > Agreed. It is clear that the text on leafrefs needs to be rewritten, > and I will send a proposal to the list once its done. Disagree; what I think is lacking is a consensus on what the aim is and we would be better agreeing that before turning it into text. Andy asked for leaf-ref back in September, and said "But many times you want a pointer-to-a-leaf instead of cut-and-paste-of-a-leaf. The use-cases are very different." which I thought spot on, then and now. Balazs queried, then as now, whether the value was an XPath pointer or more like a linux soft-link. I did not see a resolution then and do not see one now and, perhaps as a result, we have something complex, self-contradictory even, in the I-D. I think that the use case is exactly what Andy said, a pointer to a leaf, so if the pointed-to changes, then so does the leaf-ref. Allowing the leaf-ref to be written to I think wrong. We are turning the schema tree into a schema mesh and having multiple-write, as opposed to multiple-read-write-once, is, for me, a step too far. I fundamentally disagree with the "(And I prefer to keep it this way; who knows, maybe there's a great use case for this that we can't see right now)." I see this approach as what has made this I-D so complex; as Andy said, you have to implement YANG in order to understand it (not what I would see as a positive feature). Rather, we have a use case, let's first agree - or not - on what it is and stick to it, not wander off. Tom Petch > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Tue May 26 05:06: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 D5BAE3A6843 for ; Tue, 26 May 2009 05:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.152, 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 gKTBHk7THkgg for ; Tue, 26 May 2009 05:06:25 -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 1229D3A6A22 for ; Tue, 26 May 2009 05:06:25 -0700 (PDT) Received: (qmail 10756 invoked from network); 26 May 2009 12:07:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 26 May 2009 12:07:43 -0000 X-YMail-OSG: 3ZKLrJIVM1kNiMhBXZAFFB.DFZBKL32UELsFnzOsdIQtudAwoUODsQm91zVvpGg8OVsteUwzKq2yU.J8tEzhRwuj22oFOkIt.jkVx.wgY9wtFiukKKSd6cA8YPhP9T2Fbw.r3LlWuIoeLZUCWAvkCDliIkBNY_m0kJ2MKrqBu8aGL6v1Vb68al7gvlg81RqZ6EIYHtJSyH5Jg.vU3088RNFGH1zQutTqetfIZ86Avagl.zkAH7l2.ruTA8lvfR2f_67s4xRZa1DmtLL_ILfuWsNkjXWeN45Ehh4pNTIMXULOpT_1c2ZtJ3w_xg7frE2mk3r9N7MtU_6mkuKEQHHluBoqdQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1BDB8E.3010403@netconfcentral.com> Date: Tue, 26 May 2009 05:07:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> <008301c9dde7$e75ebfa0$0601a8c0@allison> In-Reply-To: <008301c9dde7$e75ebfa0$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 26 May 2009 12:06:25 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, May 25, 2009 10:29 AM > Subject: Re: [netmod] leaf-ref questions > >> Balazs Lengyel wrote: >>> Martin Bjorklund wrote: >>>>> 1) Does path point to a leaf node in the datastore or just a potential > leaf >>>>> node? The draft says about path: >>>>> "It takes as an argument a string which MUST refer to a leaf node." >>>>> However I think if require-instance is false, path only points to a >>>>> potential >>>>> leaf. >>>> I think this is clear from the text on require-instance, which has >>>> been clarified as suggested by Lada. >>>> >>> Quote: >>> "The leafref type is used to reference a particular leaf instance in the > data >>> tree. Its value is constrained to be the same as the value of an existing >>> leaf." >>> >>> To me the quoted sentences above say that the referred leaf must exists, >>> contradicting the later explanation. >> Agreed. It is clear that the text on leafrefs needs to be rewritten, >> and I will send a proposal to the list once its done. > > Disagree; what I think is lacking is a consensus on what the aim is > and we would be better agreeing that before turning it into text. > > Andy asked for leaf-ref back in September, and said > "But many times you want a pointer-to-a-leaf instead of > cut-and-paste-of-a-leaf. The use-cases are very different." > which I thought spot on, then and now. Balazs queried, then as now, > whether the value was an XPath pointer or more like a linux soft-link. > > I did not see a resolution then and do not see one now and, perhaps > as a result, we have something complex, self-contradictory even, > in the I-D. > > I think that the use case is exactly what Andy said, a pointer to > a leaf, so if the pointed-to changes, then so does the leaf-ref. I don't think I said that. The leafref we have now is what I had in mind. By 'pointer' I just mean that the path indicates the referenced object instead of a description statement. > Allowing the leaf-ref to be written to I think wrong. We are > turning the schema tree into a schema mesh and having > multiple-write, as opposed to multiple-read-write-once, is, for > me, a step too far. > I do not understand this 'multiple write' problem. The client can lock the database and write whatever is needed, especially in the candidate. > I fundamentally disagree with the > "(And I prefer to keep it this way; who knows, maybe > there's a great use case for this that we can't see right now)." > I see this approach as what has made this I-D so complex; as Andy said, > you have to implement YANG in order to understand it (not what I would > see as a positive feature). > > Rather, we have a use case, let's first agree - or not - on what it is and > stick to it, not wander off. > The use-case is a machine-readable coupling instead of relying on description statements. > Tom Petch > >> /martin Andy From balazs.lengyel@ericsson.com Tue May 26 06:02: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 ACEF73A70C0 for ; Tue, 26 May 2009 06:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 73qe4fjawWS2 for ; Tue, 26 May 2009 06:02:35 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D6B6128C1DD for ; Tue, 26 May 2009 06:02:34 -0700 (PDT) X-AuditID: c1b4fb3c-b7b94ae000000eff-50-4a1be8b549cf Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 47.FC.03839.5B8EB1A4; Tue, 26 May 2009 15:03:49 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 15:03:49 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 15:03:49 +0200 Message-ID: <4A1BE8B4.3030600@ericsson.com> Date: Tue, 26 May 2009 15:03:48 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "tom.petch" References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> <008301c9dde7$e75ebfa0$0601a8c0@allison> In-Reply-To: <008301c9dde7$e75ebfa0$0601a8c0@allison> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2009 13:03:49.0240 (UTC) FILETIME=[69298780:01C9DE02] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 26 May 2009 13:02:40 -0000 Hello, I agree that it is hard to understand the concept of leafref. I see a danger of having one more complicated concept in YANG, the leafref. Martin's original keyref was much more simple. As an example, can someone explain the use case for writing to a leafref that is not a key, and what happens at writing? My problem is that I feel I have a number of such questions that are not answered today. Balazs tom.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, May 25, 2009 10:29 AM > Subject: Re: [netmod] leaf-ref questions > >> Balazs Lengyel wrote: >>> Martin Bjorklund wrote: >>>>> 1) Does path point to a leaf node in the datastore or just a potential > leaf >>>>> node? The draft says about path: >>>>> "It takes as an argument a string which MUST refer to a leaf node." >>>>> However I think if require-instance is false, path only points to a >>>>> potential >>>>> leaf. >>>> I think this is clear from the text on require-instance, which has >>>> been clarified as suggested by Lada. >>>> >>> Quote: >>> "The leafref type is used to reference a particular leaf instance in the > data >>> tree. Its value is constrained to be the same as the value of an existing >>> leaf." >>> >>> To me the quoted sentences above say that the referred leaf must exists, >>> contradicting the later explanation. >> Agreed. It is clear that the text on leafrefs needs to be rewritten, >> and I will send a proposal to the list once its done. > > Disagree; what I think is lacking is a consensus on what the aim is > and we would be better agreeing that before turning it into text. > > Andy asked for leaf-ref back in September, and said > "But many times you want a pointer-to-a-leaf instead of > cut-and-paste-of-a-leaf. The use-cases are very different." > which I thought spot on, then and now. Balazs queried, then as now, > whether the value was an XPath pointer or more like a linux soft-link. > > I did not see a resolution then and do not see one now and, perhaps > as a result, we have something complex, self-contradictory even, > in the I-D. > > I think that the use case is exactly what Andy said, a pointer to > a leaf, so if the pointed-to changes, then so does the leaf-ref. > Allowing the leaf-ref to be written to I think wrong. We are > turning the schema tree into a schema mesh and having > multiple-write, as opposed to multiple-read-write-once, is, for > me, a step too far. > > I fundamentally disagree with the > "(And I prefer to keep it this way; who knows, maybe > there's a great use case for this that we can't see right now)." > I see this approach as what has made this I-D so complex; as Andy said, > you have to implement YANG in order to understand it (not what I would > see as a positive feature). > > Rather, we have a use case, let's first agree - or not - on what it is and > stick to it, not wander off. > > Tom Petch > >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Tue May 26 06:29: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 4C93E28C21F for ; Tue, 26 May 2009 06:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, SARE_MILLIONSOF=0.315] 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-qGk5iB5thj for ; Tue, 26 May 2009 06:29:56 -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 7016828C20F for ; Tue, 26 May 2009 06:29:56 -0700 (PDT) Received: (qmail 72489 invoked from network); 26 May 2009 13:30:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 26 May 2009 13:30:30 -0000 X-YMail-OSG: kywr2R4VM1lDf8tJgW6g1g.LR9nyUi3s2K5H62YE_gu3FGa48VKOQ9lJ85L2TF6DjRgHD0caMdl91LGw41PtDVzcBhBmA5fO05kbIaexTniJ7_PV1fRSJxoaVaWohetr5hChu9W0h9wDrvNNyemiSSefd8jk._RMX29QoLvvjyrHwHvsFEEaynD0Ku5WMln7IS3A9EBTy6mu1cBWxenJ24cFOFBuWWMCE21b3q1WDI.zkf6btWBTtUMJXzX532dg.DA.pSEhDjEFT9z3ygsw4z7Qr.cKipJOoq7RNXXZdxEpc_xCkJWEUw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1BEEF6.1030703@netconfcentral.com> Date: Tue, 26 May 2009 06:30:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Balazs Lengyel References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> In-Reply-To: <4A1BE8B4.3030600@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 26 May 2009 13:29:57 -0000 Balazs Lengyel wrote: > Hello, > I agree that it is hard to understand the concept of leafref. > I see a danger of having one more complicated concept in YANG, the > leafref. Martin's original keyref was much more simple. > > As an example, can someone explain the use case for writing to a leafref > that is not a key, and what happens at writing? > > My problem is that I feel I have a number of such questions that are not > answered today. > The most simple example is a foreign key. YANG allows lists nested within other lists, but the data modeler is not forced to do that. Perhaps alignment with SMIv2 or SQL applications makes 2 sibling tables more appropriate than 1 nested table: list rmonHostControlEntry { key rmonHostControlIndex; leaf rmonHostControlIndex {...} // rest of control table columns } list rmonHostHistoryControlEntry { key "rmonHostControlIndex rmonHostHistoryControlIndex"; leaf rmonHostControlIndex { type leafref { path "/rmonHostControlEntry/rmonHostControlIndex"; } } leaf rmonHostHistoryControlIndex { type uint32; } // rest of aux control table // embedded host history data table } Perhaps the 2nd control table cannot be in the same module as the first. Perhaps it is not really a sparse augments because the condition for adding the augmenting control columns is not deterministic. The client decides when the 2nd control entry is needed, not the agent. Maybe the data modeler does not want the embedded host entry to be placed directly under the main control entry because an inadvertent of the top-level entry would include millions of bytes of statistics data. Perhaps these are weak use cases, and YANG should force the data modeler to use augment or nested lists, but the leafref seems OK to me the way it is defined now. > > Balazs Andy > > tom.petch wrote: >> ----- Original Message ----- >> From: "Martin Bjorklund" >> To: >> Cc: >> Sent: Monday, May 25, 2009 10:29 AM >> Subject: Re: [netmod] leaf-ref questions >> >>> Balazs Lengyel wrote: >>>> Martin Bjorklund wrote: >>>>>> 1) Does path point to a leaf node in the datastore or just a >>>>>> potential >> leaf >>>>>> node? The draft says about path: >>>>>> "It takes as an argument a string which MUST refer to a leaf node." >>>>>> However I think if require-instance is false, path only points to a >>>>>> potential >>>>>> leaf. >>>>> I think this is clear from the text on require-instance, which has >>>>> been clarified as suggested by Lada. >>>>> >>>> Quote: >>>> "The leafref type is used to reference a particular leaf instance in >>>> the >> data >>>> tree. Its value is constrained to be the same as the value of an >>>> existing >>>> leaf." >>>> >>>> To me the quoted sentences above say that the referred leaf must >>>> exists, >>>> contradicting the later explanation. >>> Agreed. It is clear that the text on leafrefs needs to be rewritten, >>> and I will send a proposal to the list once its done. >> >> Disagree; what I think is lacking is a consensus on what the aim is >> and we would be better agreeing that before turning it into text. >> >> Andy asked for leaf-ref back in September, and said >> "But many times you want a pointer-to-a-leaf instead of >> cut-and-paste-of-a-leaf. The use-cases are very different." >> which I thought spot on, then and now. Balazs queried, then as now, >> whether the value was an XPath pointer or more like a linux soft-link. >> >> I did not see a resolution then and do not see one now and, perhaps >> as a result, we have something complex, self-contradictory even, >> in the I-D. >> >> I think that the use case is exactly what Andy said, a pointer to >> a leaf, so if the pointed-to changes, then so does the leaf-ref. >> Allowing the leaf-ref to be written to I think wrong. We are turning >> the schema tree into a schema mesh and having multiple-write, as >> opposed to multiple-read-write-once, is, for >> me, a step too far. >> >> I fundamentally disagree with the >> "(And I prefer to keep it this way; who knows, maybe >> there's a great use case for this that we can't see right now)." >> I see this approach as what has made this I-D so complex; as Andy said, >> you have to implement YANG in order to understand it (not what I would >> see as a positive feature). >> >> Rather, we have a use case, let's first agree - or not - on what it is >> and >> stick to it, not wander off. >> >> Tom Petch >> >>> /martin >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> > From jmh@joelhalpern.com Tue May 26 06:40: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 92DAF3A7085 for ; Tue, 26 May 2009 06:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 3J4jO0u77lHm for ; Tue, 26 May 2009 06:40:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CE88C3A7084 for ; Tue, 26 May 2009 06:40:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 33FD84302A6; Tue, 26 May 2009 06:40:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.10] (pool-173-49-75-79.phlapa.fios.verizon.net [173.49.75.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AE92D4302D6; Tue, 26 May 2009 06:40:27 -0700 (PDT) Message-ID: <4A1BF14A.50706@joelhalpern.com> Date: Tue, 26 May 2009 09:40:26 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Balazs Lengyel References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> In-Reply-To: <4A1BE8B4.3030600@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 26 May 2009 13:40:07 -0000 (I have been talking with folks trying to understand leafref. I am getting close to being able to suggest text that reflects what I think the WG has agreed. Below is a paraphrase of my current understanding.) Declaring something as a leafref declares it to be the same type as the target identified by the path, and for non-config or require-instance also declares that the value of the leaf of type leafref must match the target of the path. Unfortunately, there are two different factors that affect the meaning and real-world constraints on the value. Some of these are consequences, not definitions. (Which makes writing a clear definition hard.) There is the spectrum of non-config, config with no require-instance, and config with require-isntances. These is also the spectrum of whether the path identifies a single leaf isntance or a set of instances (for example if there is a key field whose value is not specified in the path. Or, I think, a leaflist.) Let me remove one case. If the leaf of type leafref is config data, and is not require-instance, then all that declaring it as a leafref does is declare the type, and provide a semantic suggestion of the meaning to the human user. For non-config data, a leafref value will be the value of a node selected by the path. If the path selects one leaf, then the leafref leaf will have the same value as the selected leaf. If the path selects a set of leafs, then the leafref leaf will have a value from that set, determined by the system. The description clause and name will prsumably given the human user information as to which leaf will be swelected and what it means (as with all systems like this, semantics ends up being the human responsibility.) This leafs us with require-instance config leafrefs. That setup means that the value the leaf is set to must be the value of one of the leafs selected by the path. (In the corner case where the path selects exactly one leaf there was not much point in making this config data, as the value is fixed to match the selected leaf. In fact, in that case, setting either leaf requires setting both leaves; at least by the time validation is done.) I think it is reasonable that these pieces are all under one type. I am personally not sure that allowing require-instance to be false is particularly useful, but I believe the WG wanted it. This leafref is not an indirect pointer or alias. Rather, it is a value constraint. It uses a leaf or leaf set as the value constraint and type source, instead of a type and range, etc. This provides integrity constraints and better semantic clarity. Yours, Joel M. Halpern From andy@netconfcentral.com Tue May 26 07:08: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 6BDE028C24F for ; Tue, 26 May 2009 07:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 cMSnU92rGH7P for ; Tue, 26 May 2009 07:08:50 -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 76D263A68FF for ; Tue, 26 May 2009 07:08:49 -0700 (PDT) Received: from [68.142.200.224] by n20.bullet.mail.mud.yahoo.com with NNFMP; 26 May 2009 14:10:16 -0000 Received: from [68.142.201.241] by t5.bullet.mud.yahoo.com with NNFMP; 26 May 2009 14:10:16 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 26 May 2009 14:10:16 -0000 X-Yahoo-Newman-Id: 841801.49052.bm@omp402.mail.mud.yahoo.com Received: (qmail 45583 invoked from network); 26 May 2009 14:10:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 26 May 2009 14:10:15 -0000 X-YMail-OSG: aTwv8hsVM1n1VNt6RGfhzuOWunxxWT8121Gsmyga.X_82SsXHtjI3xgYAfbppKBGAsozc..GPvpQ7qBkRsLhSG_1o9UyLCnDwyVzlDkKs617nRQFBoQQZzpEolBQRhUPYtw48O1.AkLdDNO45HIh7urkmsFtu37RiBQeEZCb3qzfBsEL_IcmXkmk9y_YjNlbyAPsynPhoTK1a2RwKjThZZ3QOVunVDu1X0C3FpSB2.t8lxlYl5DtWxojU.UnKoUGkgHIpUSwOg0WotphJhKxS467kcl026v5Tw6oMaaw4t3bmNfGAuYM X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1BF847.90903@netconfcentral.com> Date: Tue, 26 May 2009 07:10:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> <4A1BF14A.50706@joelhalpern.com> In-Reply-To: <4A1BF14A.50706@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 26 May 2009 14:08:51 -0000 Joel M. Halpern wrote: > (I have been talking with folks trying to understand leafref. I am > getting close to being able to suggest text that reflects what I think > the WG has agreed. Below is a paraphrase of my current understanding.) > leafref use-cases are overloaded, which adds to the confusion. 1) a read-only leafref in a notification is like an alias 2) a leafref acting as a key, and pointing at another key, is like an SQL foreign key 3) a read-only leafref acting as a leaf, and pointing at a key, is almost like a RowPointer in SNMP 4) a read-write leafref acting as a leaf, and pointing at any leaf, is like a 'MyServer' kind of config copy. Some localized config is constrained to the global config values. 5) an RPC input parameter, pointing at any database leaf, is just another form of constraint semantics. The main confusion and concern is over (4), which is kind of an access control nightmare. There is confusion over the pointed-at semantics. The path only indicates constraint semantics for the leafref. The pointed-at leaf is never altered by changes to the leafref. One issue you raised (wrt/ #4) has not been answered at all: - If require-instance is true, and the pointed-at instance is deleted, what is the agent supposed to do with the leafref, and when is it supposed to be done? I do not view the require-instance as a special case. It just adds more constraints if true. > Declaring something as a leafref declares it to be the same type as the > target identified by the path, and for non-config or require-instance > also declares that the value of the leaf of type leafref must match the > target of the path. > > Unfortunately, there are two different factors that affect the meaning > and real-world constraints on the value. Some of these are > consequences, not definitions. (Which makes writing a clear definition > hard.) > There is the spectrum of non-config, config with no require-instance, > and config with require-isntances. > These is also the spectrum of whether the path identifies a single leaf > isntance or a set of instances (for example if there is a key field > whose value is not specified in the path. Or, I think, a leaflist.) > > Let me remove one case. If the leaf of type leafref is config data, and > is not require-instance, then all that declaring it as a leafref does is > declare the type, and provide a semantic suggestion of the meaning to > the human user. > > For non-config data, a leafref value will be the value of a node > selected by the path. If the path selects one leaf, then the leafref > leaf will have the same value as the selected leaf. If the path selects > a set of leafs, then the leafref leaf will have a value from that set, > determined by the system. The description clause and name will > prsumably given the human user information as to which leaf will be > swelected and what it means (as with all systems like this, semantics > ends up being the human responsibility.) > > This leafs us with require-instance config leafrefs. That setup means > that the value the leaf is set to must be the value of one of the leafs > selected by the path. (In the corner case where the path selects > exactly one leaf there was not much point in making this config data, as > the value is fixed to match the selected leaf. In fact, in that case, > setting either leaf requires setting both leaves; at least by the time > validation is done.) > > I think it is reasonable that these pieces are all under one type. > > I am personally not sure that allowing require-instance to be false is > particularly useful, but I believe the WG wanted it. > This is needed to support pre-provisioning. Without it, then secondary config tables would have to remain empty until the primary entry is instantiated. > This leafref is not an indirect pointer or alias. Rather, it is a value > constraint. It uses a leaf or leaf set as the value constraint and type > source, instead of a type and range, etc. This provides integrity > constraints and better semantic clarity. > > Yours, > Joel M. Halpern Andy From phil@juniper.net Tue May 26 07:12: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 40D8028C27E for ; Tue, 26 May 2009 07:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Zy6AH22ZE2QA for ; Tue, 26 May 2009 07:12:51 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 6F34F3A6B82 for ; Tue, 26 May 2009 07:12:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKShv5FuVMQTgmbsqcu6n2XNVksTh8uhA0@postini.com; Tue, 26 May 2009 07:14:06 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, 26 May 2009 07:07:45 -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, 26 May 2009 07:07:45 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 May 2009 07:07:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 07:07:44 -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 n4QE7hL89835; Tue, 26 May 2009 07:07:43 -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 n4QDvJr6075781; Tue, 26 May 2009 13:57:19 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905261357.n4QDvJr6075781@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A1966CB.3060805@netconfcentral.com> Date: Tue, 26 May 2009 09:57:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 May 2009 14:07:44.0129 (UTC) FILETIME=[56EF2710:01C9DE0B] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] feature advertisement 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, 26 May 2009 14:12:52 -0000 Andy Bierman writes: > If a feature is dependent on any other features (i.e., the feature > has one or more "if-feature" sub-statements), then all of features > it depends on MUST also be implemented by the agent. Will the Postel Principle render this moot, since if you tell me you support B and B requires A, I can reasonably assume that you support A? Sure, clean up the text, but any implementation should still be Postelistic (Postelized?). Thanks, Phil From andy@netconfcentral.com Tue May 26 07:24: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 CD9DF28C0DB for ; Tue, 26 May 2009 07:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, J_CHICKENPOX_64=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 41Na4SM93bat for ; Tue, 26 May 2009 07:24:02 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 020E93A6D05 for ; Tue, 26 May 2009 07:24:01 -0700 (PDT) Received: (qmail 89690 invoked from network); 26 May 2009 14:24:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 26 May 2009 14:24:33 -0000 X-YMail-OSG: tOKi3dEVM1n6R0pJ8bXhJ3ACFPMKzv1FRYEdxG00m01vXv5fNVtSh0UuuBpVVEp04_3QVigzWMHy_05p4dttvlahHCGFSiuXD6x9JKQmdp60JYBx2HMiiB23j9rhNNThme6tKZLobPeo6Mh6eElA8c3UWJ2_Qvx5hsvZ0hG7gy3y4LZQvfMQAhwPzzigdmqGcdVQOBCnmGig_d736X9qEFKeQeCnH_zYwz9_wnFIjLHfftxVDyeyegN5Qq8bDcRD8c0c7yVHNODTEafg X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1BFB8B.7040503@netconfcentral.com> Date: Tue, 26 May 2009 07:24:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Balazs Lengyel References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> In-Reply-To: <4A1BE8B4.3030600@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 26 May 2009 14:24:02 -0000 Balazs Lengyel wrote: > Hello, > I agree that it is hard to understand the concept of leafref. > I see a danger of having one more complicated concept in YANG, the > leafref. Martin's original keyref was much more simple. > > As an example, can someone explain the use case for writing to a leafref > that is not a key, and what happens at writing? > It would be OK with me if there was a CLR preventing database leafrefs with config=true. Implementation details vary greatly so we should not discuss them here, but I would rank robust implementation of this little part of YANG around 8.5 out of 10 in complexity. I seriously doubt there will be even one correct implementation for all corner cases. (I won't tell you which corner-cases I cheated on ;-) Leafref is easy enough -- it's the interactions with all the other YANG bits that makes it complicated. > My problem is that I feel I have a number of such questions that are not > answered today. > > > Balazs Andy From andy@netconfcentral.com Tue May 26 07:29: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 2F44128C25D for ; Tue, 26 May 2009 07:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 FmDT4UhFcnsn for ; Tue, 26 May 2009 07:29:51 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 68E7D28C2A5 for ; Tue, 26 May 2009 07:29:50 -0700 (PDT) Received: (qmail 86062 invoked from network); 26 May 2009 14:31:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 26 May 2009 14:31:22 -0000 X-YMail-OSG: aFWy35AVM1mfgj2ZrHKCnQHTw7XvllASthKTS6n.6Jsvyd_iFG7VMJ0JJW7SP3u5RI_DjGxg7JGX3RqorytDDHX467KOetYEdhmCL4p.EUPXx88XaDTQtSOBZj2CTf3ZL89NzQRIhFmEt1l89uHYi1.BCuZ9Dtznuazo9NcRX.yN4jBipWbETspGUi9hfdjYghQ9so3EHtl2tKeqnrs42qVCu6G7qFkwYJts5Q9l_6S6fBKIYvaIJ1AMr95kgpleuywPheox_.aXcjmCOB3sFogigsGOJRBG5K6zKp2jRsbCf7HyaM9F X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1BFD39.4010202@netconfcentral.com> Date: Tue, 26 May 2009 07:31:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905261357.n4QDvJr6075781@idle.juniper.net> In-Reply-To: <200905261357.n4QDvJr6075781@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] feature advertisement 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, 26 May 2009 14:29:52 -0000 Phil Shafer wrote: > Andy Bierman writes: >> If a feature is dependent on any other features (i.e., the feature >> has one or more "if-feature" sub-statements), then all of features >> it depends on MUST also be implemented by the agent. > > Will the Postel Principle render this moot, since if you tell me > you support B and B requires A, I can reasonably assume that you > support A? Sure, clean up the text, but any implementation should > still be Postelistic (Postelized?). > I think if the draft is clarified to force the agent to only advertise B if A==true, then you can assume that advertising B means that A is supported as well, but the agent MUST still send both A and B in the feature list. Is this text more clear: If a feature is dependent on any other features (i.e., the feature has one or more "if-feature" sub-statements), then all of features it depends on MUST also be implemented by the device, in order for the device to advertise the feature. > Thanks, > Phil > > Andy From mbj@tail-f.com Tue May 26 07:32: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 CE7B628C2C0 for ; Tue, 26 May 2009 07:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.211, 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 GPQaZ-OL0pTT for ; Tue, 26 May 2009 07:32: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 E555828C2E4 for ; Tue, 26 May 2009 07:31: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 8ED8F616018; Tue, 26 May 2009 16:32:49 +0200 (CEST) Date: Tue, 26 May 2009 16:32:48 +0200 (CEST) Message-Id: <20090526.163248.151812236.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A1BF14A.50706@joelhalpern.com> References: <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> <4A1BF14A.50706@joelhalpern.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] leaf-ref questions 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, 26 May 2009 14:32:35 -0000 Hi, Thank you Joel, I think this is a (mostly) correct description of the leafref idea. Some comments inline. "Joel M. Halpern" wrote: > (I have been talking with folks trying to understand leafref. I am getting > close to being able to suggest text that reflects what I think the WG has > agreed. Below is a paraphrase of my current understanding.) > > Declaring something as a leafref declares it to be the same type as the target > identified by the path, and for non-config or require-instance also declares > that the value of the leaf of type leafref must match the target of the path. > > Unfortunately, there are two different factors that affect the meaning and > real-world constraints on the value. Some of these are consequences, not > definitions. (Which makes writing a clear definition hard.) > There is the spectrum of non-config, config with no require-instance, and > config with require-isntances. > These is also the spectrum of whether the path identifies a single leaf > isntance or a set of instances In both cases, your description below applies: The path selects a set of leafs, and the leafref value is constrained to be from this set (for require-instance true leafrefs). > (for example if there is a key field whose value > is not specified in the path. Or, I think, a leaflist.) Currently a leafref cannot reference a leaf-list. > Let me remove one case. If the leaf of type leafref is config data, and is not > require-instance, then all that declaring it as a leafref does is declare the > type, and provide a semantic suggestion of the meaning to the human user. And to tools. As a simple example, a graphical interface may indicate a relation between the leafref value and the target leaf when the target leaf exist (e.g. by making the leafref value clickable). > For non-config data, a leafref value will be the value of a node selected by > the path. If the path selects one leaf, then the leafref leaf will have the > same value as the selected leaf. If the path selects a set of leafs, then the > leafref leaf will have a value from that set, determined by the system. The > description clause and name will prsumably given the human user information as > to which leaf will be swelected and what it means (as with all systems like > this, semantics ends up being the human responsibility.) > > This leafs us with require-instance config leafrefs. That setup means that the > value the leaf is set to must be the value of one of the leafs selected by the > path. (In the corner case where the path selects exactly one leaf there was > not much point in making this config data, as the value is fixed to match the > selected leaf. In fact, in that case, setting either leaf requires setting > both leaves; at least by the time validation is done.) > > I think it is reasonable that these pieces are all under one type. > > I am personally not sure that allowing require-instance to be false is > particularly useful, but I believe the WG wanted it. > > This leafref is not an indirect pointer or alias. Rather, it is a value > constraint. It uses a leaf or leaf set as the value constraint and type > source, instead of a type and range, etc. This provides integrity constraints > and better semantic clarity. /martin From cfinss@dial.pipex.com Tue May 26 08:06: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 300ED3A6E81 for ; Tue, 26 May 2009 08:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001, J_CHICKENPOX_62=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 r3kn-Kt3Dilx for ; Tue, 26 May 2009 08:06:57 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 29E1128C0DB for ; Tue, 26 May 2009 08:06:57 -0700 (PDT) X-Trace: 162950076/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.189/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.189 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: AkIFAOuiG0o+vGS9/2dsb2JhbACDKDoUiwvAOwiEAwU X-IronPort-AV: E=Sophos;i="4.41,252,1241391600"; d="scan'208";a="162950076" X-IP-Direction: IN Received: from 1cust189.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.189]) by smtp.pipex.tiscali.co.uk with SMTP; 26 May 2009 16:08:24 +0100 Message-ID: <000801c9de0b$50a88e00$0601a8c0@allison> From: "tom.petch" To: , "Martin Bjorklund" References: <20090524.160238.199634663.mbj@tail-f.com> Date: Tue, 26 May 2009 14:59:47 +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] comments on netmod-yang-05 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, 26 May 2009 15:06:59 -0000 Sounds like a good idea to me. (The question is in the middle:-) but to save having to search, it is > Does anyone else have an opinion on this? which arises from > > It'd be less a strain on IANA to have submodules prefixed with > > "parentmodule:" so that there exists a naming hierarchy for submodules > > such that there is no chance for collision. In fact, a very good one. Tom Petch ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Sunday, May 24, 2009 4:02 PM Subject: Re: [netmod] comments on netmod-yang-05 > Hi Wes, > > Wes Hardaker wrote: > > General: > > > > - Many rules don't have MUSTs and SHOULDs and many do. The wording > > seems to be fairly inconsistent with respect to this. There are many > > points in the document where it's stated flatly that something is > > allowed or disallowed, and other points where the use of the word MUST > > is included. I'm confused as to why MUSTs are present sometimes and > > not others. > > > > - Much of the document seems to be written with the mindset of the > > (sub)module authors but don't discuss things in terms of > > implementations. In fact many of the MUSTs/SHOULDs/MAYs seem to be > > directed at module authors rather than parser authors. Maybe this is > > intentional. > > Yes, in fact, I don't think any rules (except maybe the edit-config > rules) are worded specifically for implementations. The rules try to > specify what is legal and illegal in the YANG language. > > > - The substatement tables are *extremely* helpful. Thanks for doing those. > > > > > > Section 4.2.3: > > The example adds a few things not discussed so far: > > "config true;" at the top: what's the default value? It must be true > > based on the other examples? You should state one way or the other > > (maybe in a // comment) that it's the default or not. > > The second sentence in 4.2.3 says: > > When a node is tagged with "config false", > its subhierarchy is flagged as state data > > So it implies that if the node is not tagged with config false, and > does not belong to such a subhierarchy, then it is is config data. > > Section 4 is an overview section, so I would rather not go into all > the details here; the exact rules are covered later (in 7.19.1). > > > Observed-speed could use a unit to be complete, but I actually think > > it should be left out because it hasn't been introduced yet. > > Ok, we'll leave it out :) > > > Section 4.2.5: > > s/uint16/uint8/ > > Fixed. > > > Section 4.2.6 (I didn't get far enough into the document to check elsewhere): > > > > Can you use two "use" cases in a single statement. What about "use" > > followed by other objects? I suspect this is covered later. > > Yes, this is all fine. > > > Section 4.2.7: > > If mandatory isn't needed there (I don't think so) it should probably > > be removed till it's introduced later. > > Done. > > > Choosing beer as the example data I think would be better since it > > provides an example of an empty clause, which isn't shown until now. > > Done. > > NETCONF XML Example: > > > > > > > > Section 4.2.8: > > > > I found the first paragraph a bit oddly worded and hard to follow. > > How about this rewording, and simplification: > > OLD: > > YANG allows a module to insert additional nodes into data models, > including both the current module (and its submodules) or an > external module. > > NEW: > > YANG allows a module to extend data models with additional nodes. > > > Section 4.2.9: > > > > s#acmefw-2.3#acmefw-2.3# > > Fixed. > > > Section 4.2.10: > > > > Change notification from status=up to down to make more sense. > > But it is the admin-status that is up. > > Since several people have been confused by this, I will add a leaf > "if-oper-status" with the value 'down' as well: > > NETCONF XML Example: > > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > 2007-09-01T10:00:00Z > > so-1/2/3.0 > up > down > > > > > > 5.1.1: > > > > Use "p" as a prefix rather than "a" in the example for clarity against > > a:a. > > Fixed. > > > > > 5.3.1: > > > > I can't remember the version number decision if yang was "1" or "1.0" > > but ":1" looks odd after seeing ":1.0" in the netconf URNs. > > I don't think we ever had a discussion on this list about this, but > IMO "1" is sufficient. > > > 5.4: > > > > It might be worth taking another editing hit on the second paragraph. > > > > 5.6.2: > > > > remove the "s" in '"features"' or put it after the " > > Removed the "s". > > > 5.6.4.3: > > > > I find the use of the second capability announcing the deviation a bit > > odd. Specifically, the fact that the URL doesn't seem to matter > > (ending in my-deviations) but the module name afterward > > (?module=my-devs) is what is supposed to be matched on. I'm sure > > readers will get it eventually but it took me a bit. Not only that, > > there might be confusion about how to advertise multiple deviation > > modules. > > > > 5.6.5: > > > > Need to decide on or remove the open question marking > > It was decided to move this text to the monitoring draft. > > > 6.1.3: > > > > It should be noted that many definitions of "whitespace" include > > newlines, including standard regular expressions. > > > > # perl -l -e 'print "hello" if ("\n" =~ /\s/);' > > hello > > > > But this section deviates from that and discusses whitespace heavily > > but the examples show that newlines are exempt from being called > > whitespace (and you really mean just spaces and tabs). (mostly in the > > paragraph "trailing whitespace is stripped..." which would remove the \n) > > We can't simply s/whitespace/space or tab/. > > Do you think it would work if we write: > > If a string contains any whitespace characters (space or tab), > > or do we need more? > > > 6.3: > > > > "Forward references are allowed in YANG". > > > > MUST be supported? > > This would direct the rule to implementations, where the current text > talks about what is legal. > > > 7.1: > > > > "A module SHOULD have the following layout:" > > > > What if it doesn't? Does that mean a parser implementation doesn't > > have to accept it? (this is an example of text written toward the > > author when it's the parser implementation that will be the most > > affected but yet the text doesn't describe the requirements of the > > implementation). > > The exact rules are specified in the grammar. This text is there to > give the reader a quick overwiew of a what a module contains, instead > of having to figure it out from the grammar. Would it be better to > write > > A module has the following layout: > > or would that just make it worse? > > > 7.1.2: > > > > Is yang-version technically a string, decimal64 or binary blob? > > Or an uint8, uint64... Does it matter what it is? > > > 7.1.6: > > > > "It is an error ..." -> an example of a missing MUST NOT? > > NEW: > > Multiple revisions of the same module MUST NOT be imported. > > > 7.1.9: > > > > I'd add the word "published" or "distributed" in front of "editorial > > change" > > Added "published". > > > 7.2: > > > > It'd be less a strain on IANA to have submodules prefixed with > > "parentmodule:" so that there exists a naming hierarchy for submodules > > such that there is no chance for collision. > > Does anyone else have an opinion on this? > > > 7.5.3: > > > > Please please please don't hard-code the startup/running/candidate > > components into the yang document. There is a definite possibility of > > future netconf extensions providing additional storage mechanisms and > > you don't want to rev yang because of it. > > > > Yang should stay out of specifying what datastores contain config, > > state or whatever. > > In some places (such as in 7.5.3) I think we can replace the text > ", , or " with a more generic "NETCONF > datastore", but in some other places, it gets tricky. Specifically in > 8.3.3 which discusses when data is validated. > > In some earlier versions of the draft I just talked about "valid > configuration", with the intention that 4741 specifies that > is always valid, and is valid at commit time. The current > text was added as clarification to this. > > > Somewhere: > > > > You might add an example that uses current() somewhere > > There are two examples in 9.9.6. > > > 7.5.8: > > > > This seems to blur the lines into the netconf territory and makes me > > nervous about future expansion. Additionally, because it so netconf > > specific it doesn't allow parallel xml data of some other form. > > 4741 leaves some questions open for the data modeling language to > decide. I believe we must answer those questions in this docuement. > This section (and other similar) is very specific by ints nature. > > > Somewhere: > > > > Does the document discuss long-term issues with leaves? IE, once a > > leaf name has been published it can never change in definition? > > Yes, see section 10, Updating a Module. > > > 7.6.7: > > > > Before the colon add "placed into the previously defined "ssh" container: > > Done. > > > 7.7.5: > > > > What happens when a client requests data from a system ordered set of > > data, jumbles it (say makes it alphabetical according to how a user > > sorted it on the screen) and sends it back (eg, via a replace)? This > > isn't discussed... > > > > 1) can the server reject it? > > 2) does the server have to parse it? > > Why would the server reject it? Since there is no semantic order > defined, the client can send the data in any order, but the server is > free to re-order (but it doesn't have to). > > > 3) is the server allowed to define internal semantics of it's own > > ordering? (see large routing table implementations) > > I don't understand what you mean with "define internal semantics"? > > > Sorry I didn't get farther into the document... > > Thanks for your comments! > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From bertietf@bwijnen.net Tue May 26 09:13: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 CAD8328C2BF for ; Tue, 26 May 2009 09:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=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 FJGGxQRbPNhI for ; Tue, 26 May 2009 09:13:35 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 4125928C2DD for ; Tue, 26 May 2009 09:11:29 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1M8zGi-0007DM-5e for netmod@ietf.org; Tue, 26 May 2009 18:12:48 +0200 Message-ID: <54D8DEEBE1394FF29322FDF317122229@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <20090519094501.5BA253A6B7C@core3.amsl.com> In-Reply-To: <20090519094501.5BA253A6B7C@core3.amsl.com> Date: Tue, 26 May 2009 18:12:29 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-usage-00.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: Tue, 26 May 2009 16:13:35 -0000 My comments after a first (quick) read: - figure 1. Maybe add TLS ? - section 3 http://www.isi.edu/in-notes/rfc-editor/instructions2authors.txt I believe the RFC editor prefers: http://www.rfc-editor.org/rfc-editor/instructions2authors.txt - section 3.5.1 If an Internet-Draft defines a new name space that is to be administered by the IANA, then the document MUST include an IANA Considerations section, specifies how the name space is to be administered. s/section, specifies/section, that specifies/ Bert From greg.rabil@jagornet.com Tue May 26 09:56: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 D0DA93A6FE9; Tue, 26 May 2009 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 ZrkpwRpr2sXr; Tue, 26 May 2009 09:56:17 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 7B1003A6C36; Tue, 26 May 2009 09:55:56 -0700 (PDT) Received: by ewy24 with SMTP id 24so3884036ewy.37 for ; Tue, 26 May 2009 09:56:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.8.83 with SMTP id 61mr3233949weq.156.1243357008027; Tue, 26 May 2009 09:56:48 -0700 (PDT) Date: Tue, 26 May 2009 12:56:48 -0400 Message-ID: From: "A. Gregory Rabil" To: netconf@ietf.org, netmod@ietf.org Content-Type: multipart/alternative; boundary=0016364d2369cae30b046ad39cbd Subject: Re: [netmod] draft-rabil-dhc-dhcpv6-xmlconfig-00.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: Tue, 26 May 2009 16:56:17 -0000 --0016364d2369cae30b046ad39cbd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello NETCONF/NETMOD gurus, I have made an individual submission of an Internet-Draft which describes an XML schema for configuration of DHCPv6 servers. http://www.ietf.org/internet-drafts/draft-rabil-dhc-dhcpv6-xmlconfig-00.txt However, you will note that the definition is in XML Schema syntax. I have read the YANG draft, as well as a related draft which describes converting from YANG *to* XML schema. In general, I have to admit that I'm having trouble understanding the need for *another* language for specifying the contents of XML. XML Schema was supposed to be the defacto standard, now RelaxNG is competing for that, and further we have YANG. I would like to receive any comments or feedback from the folks in this working group as to what mechanisms may exist for converting *from* XML Schema *to* YANG or suggestions for defining the schema just once without the need to maintain several "authoritative" sources of the schema definition. BTW, an open-source implementation of a stateless DHCPv6 server which uses the XML configuration schema defined in the above draft as its native configuration format, is available at: http://code.google.com/p/jagornet-dhcpv6 Best regards, Greg Rabil --0016364d2369cae30b046ad39cbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello NETCONF/NETMOD gurus,

I have made an individual submission of = an Internet-Draft which describes an XML schema for configuration of DHCPv6 servers.

http://www.ietf.org/internet-drafts/draf= t-rabil-dhc-dhcpv6-xmlconfig-00.txt

However, you will note that = the definition is in XML Schema syntax.=A0 I have read the YANG draft, as w= ell as a related draft which describes converting from YANG to XML schema.=A0 In general, I have to admit that I'm having trouble un= derstanding the need for another language for specifying the = contents of XML.=A0 XML Schema was supposed to be the defacto standard, now= RelaxNG is competing for that, and further we have YANG.=A0 I would like t= o receive any comments or feedback from the folks in this working group as = to what mechanisms may exist for converting from XML Schema <= i>to YANG or suggestions for defining the schema just once witho= ut the need to maintain several "authoritative" sources of the sc= hema definition.


BTW, an open-source implementation of a stateless DHCPv6 server which uses the XML configuration schema defined in the above draft as its native = configuration format, is available at:

= http://code.google.com/p/jagornet-dhcpv6

Best regards,
Greg R= abil
--0016364d2369cae30b046ad39cbd-- From cfinss@dial.pipex.com Tue May 26 11:37: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 0F31F3A693C for ; Tue, 26 May 2009 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, J_CHICKENPOX_64=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 fVeBR8X3hPsf for ; Tue, 26 May 2009 11:37:22 -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 23EF63A6A2B for ; Tue, 26 May 2009 11:37:21 -0700 (PDT) X-Trace: 217148079/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.150/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.150 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: AkIFAKvTG0o+vBOW/2dsb2JhbACDKDoUiwu/LAiEAwU X-IronPort-AV: E=Sophos;i="4.41,253,1241391600"; d="scan'208";a="217148079" X-IP-Direction: IN Received: from 1cust150.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.150]) by smtp.pipex.tiscali.co.uk with SMTP; 26 May 2009 19:38:28 +0100 Message-ID: <000501c9de28$a8c1c8a0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Balazs Lengyel" References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> <4A1BFB8B.7040503@netconfcentral.com> Date: Tue, 26 May 2009 18:02:14 +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] leaf-ref questions 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, 26 May 2009 18:37:23 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Balazs Lengyel" Cc: "tom.petch" ; Sent: Tuesday, May 26, 2009 4:24 PM Subject: Re: [netmod] leaf-ref questions > Balazs Lengyel wrote: > > Hello, > > I agree that it is hard to understand the concept of leafref. > > I see a danger of having one more complicated concept in YANG, the > > leafref. Martin's original keyref was much more simple. > > > > As an example, can someone explain the use case for writing to a leafref > > that is not a key, and what happens at writing? > > It would be OK with me if there was a CLR > preventing database leafrefs with config=true. It would be ok with me as well. > Implementation details vary greatly so we should > not discuss them here, but I would rank robust > implementation of this little part of YANG around > 8.5 out of 10 in complexity. I seriously doubt there will be > even one correct implementation for all corner cases. > (I won't tell you which corner-cases I cheated on ;-) > > Leafref is easy enough -- it's the interactions > with all the other YANG bits that makes it complicated. Yes, a comment I would generalise to other parts of YANG. I cannot even separate it out into discrete sets or axes to master independently - which sounds like the same thing; sigh:-( Tom Petch. > > My problem is that I feel I have a number of such questions that are not > > answered today. > > > > Balazs > > Andy > From mbj@tail-f.com Tue May 26 12:37: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 AB2BF3A716A; Tue, 26 May 2009 12:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.209, 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 sgWLetpPalML; Tue, 26 May 2009 12:37:46 -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 ADB973A7166; Tue, 26 May 2009 12:37: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 EE03D616005; Tue, 26 May 2009 21:39:04 +0200 (CEST) Date: Tue, 26 May 2009 21:39:04 +0200 (CEST) Message-Id: <20090526.213904.79416403.mbj@tail-f.com> To: greg.rabil@jagornet.com From: Martin Bjorklund In-Reply-To: References: 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: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] draft-rabil-dhc-dhcpv6-xmlconfig-00.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: Tue, 26 May 2009 19:37:47 -0000 Hi Greg, "A. Gregory Rabil" wrote: > In general, I have to admit that I'm having > trouble understanding the need for *another* language for specifying the > contents of XML. YANG is not a generic XML Schema language. It is not used to specify the syntax of generic XML instance documents. YANG is used to describe configuration data models that can co-exist with other data models, evolve over time, be extended by other data models, and that can be manipulated with the NETCONF protocol. YANG is also used to decribe state data, rpcs and notifications, all handled by NETCONF. Some info is available at http://www.yang-central.org/twiki/bin/view/Main/WhyYang and from other links at yang-central. > XML Schema was supposed to be the defacto standard, now > RelaxNG is competing for that, and further we have YANG. I would like to > receive any comments or feedback from the folks in this working group as to > what mechanisms may exist for converting *from* XML Schema *to* YANG This is not possible in the general case, since YANG cannot model e.g. XML attributes. > or > suggestions for defining the schema just once without the need to maintain > several "authoritative" sources of the schema definition. If you have a YANG model, you can generate XSD and RNG from that model. This is implemented in tools like pyang and yangdump. /martin From greg.rabil@jagornet.com Tue May 26 13:57: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 10D383A6DA5; Tue, 26 May 2009 13:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 ORvmcTahGPr3; Tue, 26 May 2009 13:57:24 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 72F883A6988; Tue, 26 May 2009 13:57:23 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so970455eyd.31 for ; Tue, 26 May 2009 13:58:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.54.72 with SMTP id h50mr3345482wec.28.1243371537216; Tue, 26 May 2009 13:58:57 -0700 (PDT) In-Reply-To: <20090526.213904.79416403.mbj@tail-f.com> References: <20090526.213904.79416403.mbj@tail-f.com> Date: Tue, 26 May 2009 16:58:57 -0400 Message-ID: From: "A. Gregory Rabil" To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001485f1d912ccb67f046ad6feef Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] draft-rabil-dhc-dhcpv6-xmlconfig-00.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: Tue, 26 May 2009 20:57:25 -0000 --001485f1d912ccb67f046ad6feef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Martin, Thank you for your response. The "WhyYang" page really clears some things up for me. I would consider converting my draft to one that uses YANG, if you believe that there would be interest from the NETCONF/NETMOD community for me to do so. Regards, Greg On Tue, May 26, 2009 at 3:39 PM, Martin Bjorklund wrote: > Hi Greg, > > "A. Gregory Rabil" wrote: > > In general, I have to admit that I'm having > > trouble understanding the need for *another* language for specifying the > > contents of XML. > > YANG is not a generic XML Schema language. It is not used to specify > the syntax of generic XML instance documents. > > YANG is used to describe configuration data models that can co-exist > with other data models, evolve over time, be extended by other data > models, and that can be manipulated with the NETCONF protocol. > > YANG is also used to decribe state data, rpcs and notifications, all > handled by NETCONF. > > Some info is available at > http://www.yang-central.org/twiki/bin/view/Main/WhyYang and from other > links at yang-central. > > > XML Schema was supposed to be the defacto standard, now > > RelaxNG is competing for that, and further we have YANG. I would like to > > receive any comments or feedback from the folks in this working group as > to > > what mechanisms may exist for converting *from* XML Schema *to* YANG > > This is not possible in the general case, since YANG cannot model > e.g. XML attributes. > > > or > > suggestions for defining the schema just once without the need to > maintain > > several "authoritative" sources of the schema definition. > > If you have a YANG model, you can generate XSD and RNG from that > model. This is implemented in tools like pyang and yangdump. > > > /martin > --001485f1d912ccb67f046ad6feef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Martin,

Thank you for your response.=A0 The "WhyYang" p= age really clears some things up for me.=A0 I would consider converting my = draft to one that uses YANG, if you believe that there would be interest fr= om the NETCONF/NETMOD community for me to do so.

Regards,
Greg

On Tue, May 26, 2009= at 3:39 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi Greg,

"A. Gregory Rabil" <greg.rabil@jagornet.com> wrote:
> In general, I have to admit that I'm having
> trouble understanding the need for *another* language for specifying t= he
> contents of XML.

YANG is not a generic XML Schema language. =A0It is not used to speci= fy
the syntax of generic XML instance documents.

YANG is used to describe configuration data models that can co-exist
with other data models, evolve over time, be extended by other data
models, and that can be manipulated with the NETCONF protocol.

YANG is also used to decribe state data, rpcs and notifications, all
handled by NETCONF.

Some info is available at
http://www.yang-central.org/twiki/bin/view/Main/WhyYang and= from other
links at yang-central.

> XML Schema was supposed to be the defacto standard, now
> RelaxNG is competing for that, and further we have YANG. =A0I would li= ke to
> receive any comments or feedback from the folks in this working group = as to
> what mechanisms may exist for converting *from* XML Schema *to* YANG
This is not possible in the general case, since YANG cannot model
e.g. XML attributes.

> or
> suggestions for defining the schema just once without the need to main= tain
> several "authoritative" sources of the schema definition.
If you have a YANG model, you can generate XSD and RNG from that
model. =A0This is implemented in tools like pyang and yangdump.


/martin

--001485f1d912ccb67f046ad6feef-- From jmh@joelhalpern.com Tue May 26 19:07: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 E0F923A6B09 for ; Tue, 26 May 2009 19:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 cAat9AEuwyXw for ; Tue, 26 May 2009 19:07:17 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2D41D3A6ABC for ; Tue, 26 May 2009 19:07:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 52B33430988; Tue, 26 May 2009 19:08:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 90D5043098C; Tue, 26 May 2009 19:08:58 -0700 (PDT) Message-ID: <4A1CA0B8.2060105@joelhalpern.com> Date: Tue, 26 May 2009 22:08:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman References: <4A1679C5.2080801@ericsson.com><20090522.150929.01646103.mbj@tail-f.com><4A1A5433.4050809@ericsson.com> <20090525.102909.263518864.mbj@tail-f.com> <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> <4A1BF14A.50706@joelhalpern.com> <4A1BF847.90903@netconfcentral.com> In-Reply-To: <4A1BF847.90903@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 27 May 2009 02:07:18 -0000 The more I think about it, the more convinced I am that for me, the problem is "require-instance = false;". If that did not exist (and hence, there were no "require-instance" statement, then the definition of leafref would simply be: This is a type declaration which matches a type of an existing leaf declaration of a target leaf (defined via the path statement.) The values of this leaf are range restricted to match the values of estinsting leafs pointed to by the defined path. Andy Bierman wrote: > Joel M. Halpern wrote: >> I am personally not sure that allowing require-instance to be false is >> particularly useful, but I believe the WG wanted it. >> > > > This is needed to support pre-provisioning. > Without it, then secondary config tables would > have to remain empty until the primary entry > is instantiated. Given that the enforcement rules (which still would need to be referenced) are such that there are several ways to define leaf/leafref sets where both need to be updated, even if we always "require-isntance=true", it seems to me that allowing false merely introduces more ways to achieve the same goal, while adding confusion. If we don't need the statement, then life seems simpler without it. From Washam.Fan@huaweisymantec.com Tue May 26 19:19: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 2D2A23A6B09 for ; Tue, 26 May 2009 19:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 g1QhPKo0jpva for ; Tue, 26 May 2009 19:19:50 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 63FE33A6A18 for ; Tue, 26 May 2009 19:19:50 -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 <0KKA0086J6JKHU60@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 27 May 2009 10:21:20 +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 <0KKA00EBA6JK1100@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 27 May 2009 10:21:20 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 27 May 2009 10:21:20 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Wed, 27 May 2009 10:21:20 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090526.163248.151812236.mbj@tail-f.com> References: <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> <4A1BF14A.50706@joelhalpern.com> <20090526.163248.151812236.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 27 May 2009 02:19:51 -0000 > In both cases, your description below applies: > > The path selects a set of leafs, and the leafref value is constrained > to be from this set (for require-instance true leafrefs). > The path might not always select the same set of leafs, i.e., the leafref value is constrained to be from a floating set rather a fixed set. How to deal with a leafref whose value is valid before but invalid now? washam From jmh@joelhalpern.com Tue May 26 19: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 A8F9C3A6E47 for ; Tue, 26 May 2009 19:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 pQmxmKawk59f for ; Tue, 26 May 2009 19:32:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2C2413A6EAC for ; Tue, 26 May 2009 19:32:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C6A0743098E; Tue, 26 May 2009 19:33:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 1AB40430990; Tue, 26 May 2009 19:33:16 -0700 (PDT) Message-ID: <4A1CA66B.10207@joelhalpern.com> Date: Tue, 26 May 2009 22:33:15 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: <008301c9dde7$e75ebfa0$0601a8c0@allison> <4A1BE8B4.3030600@ericsson.com> <4A1BF14A.50706@joelhalpern.com> <20090526.163248.151812236.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 27 May 2009 02:32:44 -0000 When the leaf, which is a target of a leafref path, is changed, and the change is validated ...(section 8 of the YANG document explains exactly when that is. It is unfortunately more complex than one would really like.) then validation will fail, and an error will be returned. The user will need to fix things. Yes, leafref inconsistency is an obscure error. But that is what it means to use a set of leaves as a validity constraint. Yours, Joel WashamFan wrote: >> In both cases, your description below applies: >> >> The path selects a set of leafs, and the leafref value is constrained >> to be from this set (for require-instance true leafrefs). >> > > The path might not always select the same set of leafs, i.e., > the leafref value is constrained to be from a floating set rather > a fixed set. How to deal with a leafref whose value is valid > before but invalid now? > > washam > From david.partain@ericsson.com Tue May 26 23:45: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 887163A6AB4 for ; Tue, 26 May 2009 23:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.381, 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 1FLJXJTaz5nH for ; Tue, 26 May 2009 23:45:38 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 952843A67EE for ; Tue, 26 May 2009 23:45:38 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-98-4a1ce1f6482d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id EA.75.30868.6F1EC1A4; Wed, 27 May 2009 08:47:19 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 08:47:18 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 08:47:17 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 27 May 2009 08:47:17 +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: <200905270847.17695.david.partain@ericsson.com> X-OriginalArrivalTime: 27 May 2009 06:47:18.0003 (UTC) FILETIME=[FA261430:01C9DE96] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: draft-ietf-netmod-yang-types-03.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, 27 May 2009 06:45:39 -0000 Dear all, This is the working group last call on the current working group document: - Common YANG Data Types: http://tools.ietf.org/html/draft-ietf-netmod-yang-types-03.txt The editor and the chairs think that this document is mature enough for WGLC. This WGLC will last until June 10, 2009. Please review and send comments to this list. Thanks. David^2 From mbj@tail-f.com Wed May 27 00:11: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 64D793A6B2E for ; Wed, 27 May 2009 00:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.197, 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 51KlxeMxEkyj for ; Wed, 27 May 2009 00:11:26 -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 967F63A6ABD for ; Wed, 27 May 2009 00:11:26 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 1BCD8616001; Wed, 27 May 2009 09:12:34 +0200 (CEST) Date: Wed, 27 May 2009 09:12:35 +0200 (CEST) Message-Id: <20090527.091235.60398524.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A1CA0B8.2060105@joelhalpern.com> References: <4A1BF14A.50706@joelhalpern.com> <4A1BF847.90903@netconfcentral.com> <4A1CA0B8.2060105@joelhalpern.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] leaf-ref questions 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, 27 May 2009 07:11:27 -0000 "Joel M. Halpern" wrote: > The more I think about it, the more convinced I am that for me, the problem is > "require-instance = false;". The reason we added this was to allow config data that refers to non-config data, e.g. a pointer to a physical slot. Without require-instance false, if we allow config to refer to non-config (state), the state data might change dynamically, making the configuration invalid. Another use case is pre-provisioning, as Andy described. /martin > Andy Bierman wrote: > > Joel M. Halpern wrote: > >> I am personally not sure that allowing require-instance to be false is > >> particularly useful, but I believe the WG wanted it. > >> > > This is needed to support pre-provisioning. > > Without it, then secondary config tables would > > have to remain empty until the primary entry > > is instantiated. > > Given that the enforcement rules (which still would need to be referenced) are > such that there are several ways to define leaf/leafref sets where both need to > be updated, even if we always "require-isntance=true", it seems to me that > allowing false merely introduces more ways to achieve the same goal, while > adding confusion. If it was just another way of doing the same thing, then I agree with you. But how could you do this pre-provisioning with just require-instance true? /martin From cfinss@dial.pipex.com Wed May 27 04: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 65CB83A6B93 for ; Wed, 27 May 2009 04:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.567, 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 k+CmUsH-K3Gj for ; Wed, 27 May 2009 04:16:45 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 80DD828C126 for ; Wed, 27 May 2009 04:16:31 -0700 (PDT) X-Trace: 163226277/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.211/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.211 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: ApwEAIO+HEo+vGTT/2dsb2JhbACDKItkvw8IhAMF X-IronPort-AV: E=Sophos;i="4.41,258,1241391600"; d="scan'208";a="163226277" X-IP-Direction: IN Received: from 1cust211.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.211]) by smtp.pipex.tiscali.co.uk with SMTP; 27 May 2009 12:17:54 +0100 Message-ID: <003c01c9deb4$469020a0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A1BF14A.50706@joelhalpern.com><4A1BF847.90903@netconfcentral.com><4A1CA0B8.2060105@joelhalpern.com> <20090527.091235.60398524.mbj@tail-f.com> Date: Wed, 27 May 2009 11:39: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] leaf-ref questions 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: Wed, 27 May 2009 11:16:46 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Wednesday, May 27, 2009 9:12 AM Subject: Re: [netmod] leaf-ref questions > "Joel M. Halpern" wrote: > > The more I think about it, the more convinced I am that for me, the problem is > > "require-instance = false;". > > The reason we added this was to allow config data that refers to > non-config data, e.g. a pointer to a physical slot. Without > require-instance false, if we allow config to refer to non-config > (state), the state data might change dynamically, making the > configuration invalid. > > Another use case is pre-provisioning, as Andy described. I am getting into a terminological confusion here. Config is writable and non-config is not so this allows me to write to read-only data. Does this mean that a second writable instance of the node is created? It's not the require-instance false that bothers me but the life-cycle of this leaf-ref'd node, when it exists, what causes it to be updated etc. And where does this fit in Andy's excellent list of five use cases? Tom Petch > /martin > > > Andy Bierman wrote: > > > Joel M. Halpern wrote: > > >> I am personally not sure that allowing require-instance to be false is > > >> particularly useful, but I believe the WG wanted it. > > >> > > > This is needed to support pre-provisioning. > > > Without it, then secondary config tables would > > > have to remain empty until the primary entry > > > is instantiated. > > > > Given that the enforcement rules (which still would need to be referenced) are > > such that there are several ways to define leaf/leafref sets where both need to > > be updated, even if we always "require-isntance=true", it seems to me that > > allowing false merely introduces more ways to achieve the same goal, while > > adding confusion. > > If it was just another way of doing the same thing, then I agree with > you. But how could you do this pre-provisioning with just > require-instance true? > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Wed May 27 05:20: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 97A3C3A6E32 for ; Wed, 27 May 2009 05:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.208, 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 AS+3zRv5ZkAk for ; Wed, 27 May 2009 05:20:22 -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 5150D3A70BA for ; Wed, 27 May 2009 05:20: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 D80EF616001; Wed, 27 May 2009 14:21:40 +0200 (CEST) Date: Wed, 27 May 2009 14:21:40 +0200 (CEST) Message-Id: <20090527.142140.201274546.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <003c01c9deb4$469020a0$0601a8c0@allison> References: <4A1CA0B8.2060105@joelhalpern.com> <20090527.091235.60398524.mbj@tail-f.com> <003c01c9deb4$469020a0$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=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 27 May 2009 12:20:23 -0000 "tom.petch" wrote: > > "Joel M. Halpern" wrote: > > > The more I think about it, the more convinced I am that for me, the problem > is > > > "require-instance = false;". > > > > The reason we added this was to allow config data that refers to > > non-config data, e.g. a pointer to a physical slot. Without > > require-instance false, if we allow config to refer to non-config > > (state), the state data might change dynamically, making the > > configuration invalid. > > > > Another use case is pre-provisioning, as Andy described. > > I am getting into a terminological confusion here. Config is writable and > non-config is not so this allows me to write to read-only data. No, since the leafref is not like a symbolic link. Consider this: list slot { config "false"; key "index"; leaf index { type int32; } } leafref vip-slot { config "true"; type leafref { path "/slot/index"; require-instance "true"; } } The 'vip-slot' leaf is its very own, writable, leaf. A leaf has a value which matches its type. When you write to the leaf, the leaf's value is changed. Compare with this: struct slot slots[MAX_SLOTS]; int vip_slot; /* index into the slots array */ When you set the variable vip_slot, nothing in the slots array gets modified. A leafref works the same way (but the comment in the code is formalized in the path statement in a leafref). > Does this mean that a second writable instance of the node is created? > It's not the require-instance false that bothers me but the life-cycle of > this leaf-ref'd node, when it exists, what causes it to be updated etc. > > And where does this fit in Andy's excellent list of five use cases? I don't think it is covered in his list. /martin From phil@juniper.net Wed May 27 05:21: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 A9CC328C12C for ; Wed, 27 May 2009 05:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 PAi96pKwZtXo for ; Wed, 27 May 2009 05:21:30 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id A5EE43A6A3F for ; Wed, 27 May 2009 05:21:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSh0wfrhNUvxupbgRw3bVsagXyyUQPTD4@postini.com; Wed, 27 May 2009 05:22: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; Wed, 27 May 2009 05:15: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); Wed, 27 May 2009 05:15:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 05:15:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 05:15: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 n4RCFYL65417; Wed, 27 May 2009 05:15: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 n4RC59hi091565; Wed, 27 May 2009 12:05:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905271205.n4RC59hi091565@idle.juniper.net> To: WashamFan In-Reply-To: Date: Wed, 27 May 2009 08:05:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 May 2009 12:15:34.0920 (UTC) FILETIME=[D66D1880:01C9DEC4] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 27 May 2009 12:21:30 -0000 WashamFan writes: >> In both cases, your description below applies: >> The path selects a set of leafs, and the leafref value is constrained >> to be from this set (for require-instance true leafrefs). Nice simple language. >The path might not always select the same set of leafs, i.e., >the leafref value is constrained to be from a floating set rather >a fixed set. How to deal with a leafref whose value is valid >before but invalid now? If you are modeling something where the value is either a member of a fixed set or is allowed to be something else, then you really have a union of two types, one that is constrained and one that is not. In JUNOS, a common scenario is when a value is constrained to either a user-defined value or a small set of JUNOS-defined (builtin) values. In YANG, this would be a union of a enumeration and a leafref. I see joining a set of user-defined values and non-defined values as a similar scenario. +1 for removing 'require-instance'. Thanks, Phil From andy@netconfcentral.com Wed May 27 07:37: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 295003A6B93 for ; Wed, 27 May 2009 07:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.124, 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 u0K2cS9Lb4lm for ; Wed, 27 May 2009 07:37:58 -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 842EC3A68DE for ; Wed, 27 May 2009 07:37:57 -0700 (PDT) Received: (qmail 81688 invoked from network); 27 May 2009 14:38:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 27 May 2009 14:38:59 -0000 X-YMail-OSG: lUzt4qYVM1n6lmCFifLbjxG4xYLvyWVe3bjU0atoxuydMBW.zc3C4G3yS5b.g3IiAA5pYnrtq3YQti3as9Wn5WGrBT_QwztH07zFvQ8alycH8y6R09Da1qCX07u0f8kXcdL.PREeb85SjjxvSEGUfsXAud.rg3d0b9ms_lEnWcEGcmbH6m43MCYdfGrbtnC0OBAp01tSSrZmTiQ6TMNGYuwXYbEYT41NTf7Rv3HIZRT5P5zviM4BYzvMJSG8U9HmNozX3xm1oGUMd3QgLVnG_PZTCXxqoXpTRO_OZ5rVni2lqzILCF4f X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1D506C.3000606@netconfcentral.com> Date: Wed, 27 May 2009 07:38:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905271205.n4RC59hi091565@idle.juniper.net> In-Reply-To: <200905271205.n4RC59hi091565@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 27 May 2009 14:37:59 -0000 Phil Shafer wrote: > WashamFan writes: >>> In both cases, your description below applies: >>> The path selects a set of leafs, and the leafref value is constrained >>> to be from this set (for require-instance true leafrefs). > > Nice simple language. > >> The path might not always select the same set of leafs, i.e., >> the leafref value is constrained to be from a floating set rather >> a fixed set. How to deal with a leafref whose value is valid >> before but invalid now? > > If you are modeling something where the value is either a member > of a fixed set or is allowed to be something else, then you really > have a union of two types, one that is constrained and one that is > not. The most common use of require-instance=false is to pre-provision for known instances that are not currently available. However, config pre-provisioning is not actually supported in NETCONF/YANG. NETCONF does not have any concept of RowStatus='notInService'. An application cannot distinguish live config from pending config in a standard way. > > In JUNOS, a common scenario is when a value is constrained to either > a user-defined value or a small set of JUNOS-defined (builtin) > values. In YANG, this would be a union of a enumeration and a leafref. > I see joining a set of user-defined values and non-defined values > as a similar scenario. > So the user variables do not conform to the original typedef semantics? This seems rather strange to me: typedef foo { type union { type leafref { path "/some/uint32/leaf"; require-instance false; } type string; } } Allowing the user to enter a string when the pointed-at leaf takes a uint32 seems odd. The intent of leafref is to constrain the new leaf to the same set of values that are allowed in the pointed-at leaf. > +1 for removing 'require-instance'. > then how will any pre-provisioning be supported? > Thanks, > Phil Andy From jmh@joelhalpern.com Wed May 27 07:59: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 5BEB828C0E7 for ; Wed, 27 May 2009 07:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=-0.531, 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 oyhAfRMmV6tC for ; Wed, 27 May 2009 07:59:57 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id AB9133A6859 for ; Wed, 27 May 2009 07:59:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id 4438FA3A16 for ; Wed, 27 May 2009 08:01:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 32EBC4303D0 for ; Wed, 27 May 2009 07:56:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AB7864303B6 for ; Wed, 27 May 2009 07:56:11 -0700 (PDT) Message-ID: <4A1D548A.5050209@joelhalpern.com> Date: Wed, 27 May 2009 10:56:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <4A1BF14A.50706@joelhalpern.com> <4A1BF847.90903@netconfcentral.com> <4A1CA0B8.2060105@joelhalpern.com> <20090527.091235.60398524.mbj@tail-f.com> In-Reply-To: <20090527.091235.60398524.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] leaf-ref questions 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, 27 May 2009 14:59:58 -0000 (Responding to both Andy and Martin.) Both of these cases (pre-provisioning, and referencing to dynamic operational data that may change) seem to not be leafrefs. That is the definition of the leaf in these cases seems to be "has a value which should be thought of as naming a foo (path-target) even if there is no foo with that name." The "system" value seems to be that if the foo with the given name exists, then the system can understand the relationship. It can not enforce it. Adding an entire statement, and complicating a definition, so that that some gui might sometime be able to show a relationship? The system, as described, does not have enough information to know when something must shift from being pre-provisioning to provision (and hence enforced.) There are other ways to represent this. Remember that the actual system being configured is generally going to need programmed logic to understand the semantics of a field. Yes, a leafref (even one with require-instance set to false) can slightly simplify that logic. But in fact, if pre-provisioning is different from deferring commit on candidate, it would introduce additional complications for the system, and raise a number of interesting error cases for configuration. All in all, I still think it is a bad idea. Joel Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> The more I think about it, the more convinced I am that for me, the problem is >> "require-instance = false;". > > The reason we added this was to allow config data that refers to > non-config data, e.g. a pointer to a physical slot. Without > require-instance false, if we allow config to refer to non-config > (state), the state data might change dynamically, making the > configuration invalid. > > Another use case is pre-provisioning, as Andy described. > > > /martin From phil@juniper.net Wed May 27 08:04: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 A473F3A67FD for ; Wed, 27 May 2009 08:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 LpQJjV09+U62 for ; Wed, 27 May 2009 08:04:44 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id C1CA928C0E7 for ; Wed, 27 May 2009 08:04:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSh1W2ck4Jqq3gxMMPAxBcH+q6AZ7zJHd@postini.com; Wed, 27 May 2009 08:06:26 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; Wed, 27 May 2009 07:59:38 -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); Wed, 27 May 2009 07:59:37 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 07:59:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 07:59: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 n4RExaL39157; Wed, 27 May 2009 07:59:36 -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 n4REnBtv092681; Wed, 27 May 2009 14:49:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905271449.n4REnBtv092681@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A1D506C.3000606@netconfcentral.com> Date: Wed, 27 May 2009 10:49:11 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 May 2009 14:59:36.0943 (UTC) FILETIME=[C0BA9FF0:01C9DEDB] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 27 May 2009 15:04:44 -0000 Andy Bierman writes: >So the user variables do not conform to the original typedef semantics? Sure, just use the original typedef for the non-leafref part of the union. Don't say "string" if you mean "uint32". >then how will any pre-provisioning be supported? This feels like a red herring. You said: The most common use of require-instance=false is to pre-provision for known instances that are not currently available. But if you are intentionally making dangling references, then what's the value of the leafref? If the user can put anything in the leaf, what is the value of the constraint that the leafref represents? You are asking for a constraint that isn't enforced. Thanks, Phil From andy@netconfcentral.com Wed May 27 08:06: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 99E823A6C8C for ; Wed, 27 May 2009 08:06:43 -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.117, 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 pZTfr2v+9KSI for ; Wed, 27 May 2009 08:06:42 -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 62C7528C13F for ; Wed, 27 May 2009 08:06:33 -0700 (PDT) Received: (qmail 63672 invoked from network); 27 May 2009 15:07:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 27 May 2009 15:07:47 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1D5742.3000201@netconfcentral.com> Date: Wed, 27 May 2009 08:07:46 -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] leafref issues 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, 27 May 2009 15:06:43 -0000 Hi, I am trying to keep up with all the leafref issues, but it is difficult. Maybe we can summarize them, eliminate duplicate issues, etc. ------------------------------------------------------------------ use-case chart: 1) a read-only leafref in a notification is like an alias 2) a leafref acting as a key, and pointing at another key, is like an SQL foreign key 3) a read-only leafref acting as a leaf, and pointing at a key, is almost like a RowPointer in SNMP 4) a read-write leafref acting as a leaf, and pointing at any leaf, is like a 'MyServer' kind of config copy. Some localized config is constrained to the global config values. 5) an RPC input parameter, pointing at any database leaf, is just another form of constraint semantics. 6) vip-slot example (not sure what to call this mode.) It is not a shadow, but a secondary knob which is constrained to the values of an external non-key leaf. (RMON users might think of the 'dataSource', which is a just a column in the main table, but an INDEX in other tables.) ----------------------------------------------------------------- Issues: 1) require-instance, needed or not? 2) use-case 4, needed or not? 3) use-case 6, needed or not? 4) behavior when pointed-at leaf is deleted (or value in leafref no longer in use)? 5) nested lists not supported (**) ------------------------------------------------------------------ ** One issue not mentioned is that leafref is severely limited in utility because all key value pairs except the innermost layer need to be hardwired into the path expression. For example, use-case (1) is not actually supported by leafref for any nested lists, for this reason. For notifications, the only thing that will really work is a varbind list: list varbind { config false; leaf name { description "Identifies the leaf in the running database associated with this variable binding."; type instance-identifier; mandatory true; } leaf value { description "Contains the value of the leaf instance identified by the associated name field. This field will not be present if the variable binding has no value, e.g., built-in type is 'empty'."; // could be union of all built-in types or just // the string representation of the canonical encoding type string; } } Andy From jmh@joelhalpern.com Wed May 27 08:19: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 09FBB3A6CBB for ; Wed, 27 May 2009 08:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 mm9NqcEpsBfZ for ; Wed, 27 May 2009 08:19:24 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4B61D3A6C9A for ; Wed, 27 May 2009 08:19:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1E6ED4303CF for ; Wed, 27 May 2009 08:19:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 99CB54303B6 for ; Wed, 27 May 2009 08:19:46 -0700 (PDT) Message-ID: <4A1D5A10.203@joelhalpern.com> Date: Wed, 27 May 2009 11:19:44 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group References: <4A1D5742.3000201@netconfcentral.com> In-Reply-To: <4A1D5742.3000201@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] leafref issues 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, 27 May 2009 15:19:25 -0000 Pulling out one piece from Andy's list... Andy Bierman wrote: > Hi, > > I am trying to keep up with all the leafref issues, but it > is difficult. Maybe we can summarize them, eliminate > duplicate issues, etc. > ** One issue not mentioned is that leafref is severely limited > in utility because all key value pairs except the innermost layer > need to be hardwired into the path expression. > For example, use-case (1) is not actually supported > by leafref for any nested lists, for this reason. In an off-list conversation, I apparently got confused between "it doesn't mean that" and "it shouldn't mean that." it seems to me that the current restriction in the path statement that only the last key value be unbound does not actually do what we want. It allows one to know what leaf is being "referenced." But a leafref is not actually a reference. It is a value constraint. As such, it would work just fine with multiple unspecified keys. There would be no way from just the leafref to determine which leaf has the value that the leafref is using. But that is not the purpose of the leafref. (You can still have a leafref that points to a key, and where only the terminal key is unspecified. But one would not be restricted to that. Also, other xpath expressions would allow netconf applications to find the leaf with the given value. YANG does not need to "find" the leaf itself.) If we remove that key-specifying condition in the path statement, we pcik up significant value, and reduce the constraints on the structures with which leafref can be used as a value constraint (which seems to be what it is intended for.) Joel From root@core3.amsl.com Wed May 27 08:30: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 CA1153A6859; Wed, 27 May 2009 08:30: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: <20090527153001.CA1153A6859@core3.amsl.com> Date: Wed, 27 May 2009 08:30:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-arch-01.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, 27 May 2009 15:30:02 -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 : An NETCONF- and NETMOD-based Architecture for Network Management Author(s) : P. Shafer Filename : draft-ietf-netmod-arch-01.txt Pages : 20 Date : 2009-05-27 NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-01.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-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-27082934.I-D@ietf.org> --NextPart-- From phil@juniper.net Wed May 27 08:55: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 DEE083A6CBB; Wed, 27 May 2009 08:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Lmd6n+1pvU9q; Wed, 27 May 2009 08:55:12 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id C59043A69AF; Wed, 27 May 2009 08:55:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSh1iJQpmPGtMwLEKGnVsU1PYsPwpBxDf@postini.com; Wed, 27 May 2009 08:56:54 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; Wed, 27 May 2009 08:50:01 -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); Wed, 27 May 2009 08:50:00 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 08:50:00 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 08:49:59 -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 n4RFnwL62393; Wed, 27 May 2009 08:49:58 -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 n4RFdXRq093177; Wed, 27 May 2009 15:39:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905271539.n4RFdXRq093177@idle.juniper.net> To: Internet-Drafts@ietf.org In-Reply-To: <20090527153001.CA1153A6859@core3.amsl.com> Date: Wed, 27 May 2009 11:39:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 May 2009 15:49:59.0213 (UTC) FILETIME=[CA246DD0:01C9DEE2] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org, i-d-announce@ietf.org Subject: Re: [netmod] I-D Action:draft-ietf-netmod-arch-01.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, 27 May 2009 15:55:19 -0000 Internet-Drafts@ietf.org writes: > Title : An NETCONF- and NETMOD-based Architecture for Network Managemen >t > Author(s) : P. Shafer > Filename : draft-ietf-netmod-arch-01.txt This is bungled. A new one is enroute. Thanks, Phil From andy@netconfcentral.com Wed May 27 08:55: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 4E79B3A698B for ; Wed, 27 May 2009 08:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 FFSjGVtXS40B for ; Wed, 27 May 2009 08:55:37 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 6D38E3A69AF for ; Wed, 27 May 2009 08:55:37 -0700 (PDT) Received: (qmail 40999 invoked from network); 27 May 2009 15:56:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 27 May 2009 15:56:08 -0000 X-YMail-OSG: IK2EDk4VM1k7oUMJ6pzNaKHt3yADr6ZqRVawIusL0GhYz39V4rGE_XlI6A68oUpeq9fTQaAWffUyjC6liBQwWYgkVGrVpN3TXHlOAdfq9tWP6Sg_.E_bPwkQqqpXJCQpPUGW2hMMGykwjLQPBqAtPmIhuGHNJRzjTMzPHLJiW4F8UDBDkwQxCWfVawktPzqkYLBpx1GGJ7L66YRCSzji2FARAEUr27yNm99WbfUVwhRUjAKias0zlR4Eg_Mwxcvz8BM70EqYIFtzhxhe3mTzuCTNatlYdfGHj5Gx15KqzpHI4Lsu652W X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1D6296.9020708@netconfcentral.com> Date: Wed, 27 May 2009 08:56:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A1D5742.3000201@netconfcentral.com> <4A1D5A10.203@joelhalpern.com> In-Reply-To: <4A1D5A10.203@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] leafref issues 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, 27 May 2009 15:55:38 -0000 Joel M. Halpern wrote: > Pulling out one piece from Andy's list... > Add one more: access control issues related to #4 and #6 > Andy Bierman wrote: >> Hi, >> >> I am trying to keep up with all the leafref issues, but it >> is difficult. Maybe we can summarize them, eliminate >> duplicate issues, etc. > >> ** One issue not mentioned is that leafref is severely limited >> in utility because all key value pairs except the innermost layer >> need to be hardwired into the path expression. >> For example, use-case (1) is not actually supported >> by leafref for any nested lists, for this reason. > > In an off-list conversation, I apparently got confused between "it > doesn't mean that" and "it shouldn't mean that." > > it seems to me that the current restriction in the path statement that > only the last key value be unbound does not actually do what we want. > It allows one to know what leaf is being "referenced." > But a leafref is not actually a reference. It is a value constraint. No -- the agent/tool really does need to find the target leaf in order to use the correct type statement for validation and canonical output. > As such, it would work just fine with multiple unspecified keys. There > would be no way from just the leafref to determine which leaf has the > value that the leafref is using. But that is not the purpose of the > leafref. (You can still have a leafref that points to a key, and where > only the terminal key is unspecified. But one would not be restricted > to that. Also, other xpath expressions would allow netconf applications > to find the leaf with the given value. YANG does not need to "find" the > leaf itself.) > What does the last sentence mean? > If we remove that key-specifying condition in the path statement, we > pcik up significant value, and reduce the constraints on the structures > with which leafref can be used as a value constraint (which seems to be > what it is intended for.) > IMO, the leafref is so complicated, that making even more variants of it seems like the wrong direction. In fact, at least 2 ACM implementations use an instance-identifier as you described (optional key predicates), to specify the data associated with an ACL. But not a leafref -- an XPath string that (almost) conforms to the instance-identifier data type. > Joel Andy From root@core3.amsl.com Wed May 27 09:00: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 920403A6F5A; Wed, 27 May 2009 09:00: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: <20090527160001.920403A6F5A@core3.amsl.com> Date: Wed, 27 May 2009 09:00:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-arch-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, 27 May 2009 16:00: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 : An NETCONF- and NETMOD-based Architecture for Network Management Author(s) : P. Shafer Filename : draft-ietf-netmod-arch-02.txt Pages : 20 Date : 2009-05-27 NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-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-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-27084549.I-D@ietf.org> --NextPart-- From jmh@joelhalpern.com Wed May 27 09:04:33 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 02C5A3A6879 for ; Wed, 27 May 2009 09:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 mDXWUMvmWuma for ; Wed, 27 May 2009 09:04:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 422423A70F8 for ; Wed, 27 May 2009 09:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B29464303D2; Wed, 27 May 2009 09:05:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A72524303D9; Wed, 27 May 2009 09:05:29 -0700 (PDT) Message-ID: <4A1D64C7.2020805@joelhalpern.com> Date: Wed, 27 May 2009 12:05:27 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman References: <4A1D5742.3000201@netconfcentral.com> <4A1D5A10.203@joelhalpern.com> <4A1D6296.9020708@netconfcentral.com> In-Reply-To: <4A1D6296.9020708@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] leafref issues 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, 27 May 2009 16:04:33 -0000 Why does the agent need to find a specific leaf in order to find the type? It seems that any leaf with the given path, but with different keys at different places, will have the same type. (Different cases in a choice should result in different node names, not just different key values.) Joel Andy Bierman wrote: > Joel M. Halpern wrote: >> Pulling out one piece from Andy's list... >> > > Add one more: access control issues related to #4 and #6 > > >> Andy Bierman wrote: >>> Hi, >>> >>> I am trying to keep up with all the leafref issues, but it >>> is difficult. Maybe we can summarize them, eliminate >>> duplicate issues, etc. >> >>> ** One issue not mentioned is that leafref is severely limited >>> in utility because all key value pairs except the innermost layer >>> need to be hardwired into the path expression. >>> For example, use-case (1) is not actually supported >>> by leafref for any nested lists, for this reason. >> >> In an off-list conversation, I apparently got confused between "it >> doesn't mean that" and "it shouldn't mean that." >> >> it seems to me that the current restriction in the path statement that >> only the last key value be unbound does not actually do what we want. >> It allows one to know what leaf is being "referenced." >> But a leafref is not actually a reference. It is a value constraint. > > No -- the agent/tool really does need to find the target leaf > in order to use the correct type statement for validation > and canonical output. > > >> As such, it would work just fine with multiple unspecified keys. >> There would be no way from just the leafref to determine which leaf >> has the value that the leafref is using. But that is not the purpose >> of the leafref. (You can still have a leafref that points to a key, >> and where only the terminal key is unspecified. But one would not be >> restricted to that. Also, other xpath expressions would allow netconf >> applications to find the leaf with the given value. YANG does not >> need to "find" the leaf itself.) >> > > What does the last sentence mean? > > >> If we remove that key-specifying condition in the path statement, we >> pcik up significant value, and reduce the constraints on the >> structures with which leafref can be used as a value constraint (which >> seems to be what it is intended for.) >> > > IMO, the leafref is so complicated, that making even more variants > of it seems like the wrong direction. > > In fact, at least 2 ACM implementations use an instance-identifier > as you described (optional key predicates), to specify the > data associated with an ACL. But not a leafref -- an XPath string > that (almost) conforms to the instance-identifier data type. > > >> Joel > > Andy > > From mbj@tail-f.com Wed May 27 09:25: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 46FDA28C0D8 for ; Wed, 27 May 2009 09:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.206, 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+qDH-7wVCz9 for ; Wed, 27 May 2009 09:25:03 -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 D25C13A6C3D for ; Wed, 27 May 2009 09:25:02 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1BB0661602A; Wed, 27 May 2009 18:26:16 +0200 (CEST) Date: Wed, 27 May 2009 18:26:15 +0200 (CEST) Message-Id: <20090527.182615.118040817.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1D5742.3000201@netconfcentral.com> References: <4A1D5742.3000201@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] leafref issues 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, 27 May 2009 16:25:04 -0000 Andy Bierman wrote: > Hi, > > I am trying to keep up with all the leafref issues, but it > is difficult. Maybe we can summarize them, eliminate > duplicate issues, etc. > > ------------------------------------------------------------------ > use-case chart: > > 1) a read-only leafref in a notification is like an alias > > 2) a leafref acting as a key, and pointing at another key, > is like an SQL foreign key > > 3) a read-only leafref acting as a leaf, and pointing at a key, > is almost like a RowPointer in SNMP Why is the leaf read-only in this use-case? IMO, the most important use-case is read-write leafref acting as key or leaf, pointing to another key. (this was all the original keyref type did). > 4) a read-write leafref acting as a leaf, and pointing at any > leaf, is like a 'MyServer' kind of config copy. Some localized > config is constrained to the global config values. > > 5) an RPC input parameter, pointing at any database leaf, > is just another form of constraint semantics. > > 6) vip-slot example (not sure what to call this mode.) > It is not a shadow, but a secondary knob which > is constrained to the values of an external non-key leaf. > (RMON users might think of the 'dataSource', which is a > just a column in the main table, but an INDEX in other > tables.) > > ----------------------------------------------------------------- > > Issues: > 1) require-instance, needed or not? > 2) use-case 4, needed or not? > 3) use-case 6, needed or not? People have reported that require-instance makes leafrefs more complicated. Personally, I don't see that, but we need to make progress and solve this. I prefer not to, but I can live with removing require-instance and also add a CLR to prevent use-case 4. > 4) behavior when pointed-at leaf is deleted > (or value in leafref no longer in use)? Is this an issue? It works just like a false must constraint - the config becomes invalid. > 5) nested lists not supported (**) > > ------------------------------------------------------------------ > > ** One issue not mentioned is that leafref is severely limited > in utility because all key value pairs except the innermost layer > need to be hardwired into the path expression. > For example, use-case (1) is not actually supported > by leafref for any nested lists, for this reason. No, any depth and number of keys are supported. But in order to identify a leaf, you need values for all keys on all levels. One leaf can only hold one value, so it means you need as many leafrefs as there are keys. An example from the draft: container default-address { leaf ifname { type leafref { path "../../interface/name"; } } leaf address { type leafref { path "../../interface[name = current()/../ifname]" + "/address/ip"; } } } This syntax becomes clumsy when there are more than 2-3 keys, but it is possible. /martin From andy@netconfcentral.com Wed May 27 10:14: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 071D13A6B27 for ; Wed, 27 May 2009 10:14:48 -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 w7USZXKbqdFI for ; Wed, 27 May 2009 10:14:47 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id DD01E3A694C for ; Wed, 27 May 2009 10:14:46 -0700 (PDT) Received: (qmail 63879 invoked from network); 27 May 2009 17:08:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 27 May 2009 17:08:22 -0000 X-YMail-OSG: h6bAMjIVM1mjDToMwQvwCScPt4QNvKSOVet719IZdq8J_IeuTLnQPmJO61eQDz46XwK1Y1J7rmkRXHAiKZoXC7AYhJPz6UgH87JiyM778gBSGGX9QvgFF5jwT3yBPnT4KlxE_2XCrdHLk_9cr5FBHo0YMdDWcq9I6otE1yjSHxlYZXIcRcheTFSFJsQA0Z6LV8RsmVhjk3bq3LBBLUS0XNWnyTKfRnDc.g0FzFcq7e9LxQNlK8q0HIoNmslwUz2QevzcVcK.Le69eWtCxkEv20tpq5UFqRStUyzkZCQbAml8A6wvzSeOCJ9FY_Mn6WKx2CuDo5dEaOZEaw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1D7384.6030700@netconfcentral.com> Date: Wed, 27 May 2009 10:08:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> In-Reply-To: <20090527.182615.118040817.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] leafref issues 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, 27 May 2009 17:14:48 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I am trying to keep up with all the leafref issues, but it >> is difficult. Maybe we can summarize them, eliminate >> duplicate issues, etc. >> >> ------------------------------------------------------------------ >> use-case chart: >> >> 1) a read-only leafref in a notification is like an alias >> >> 2) a leafref acting as a key, and pointing at another key, >> is like an SQL foreign key >> >> 3) a read-only leafref acting as a leaf, and pointing at a key, >> is almost like a RowPointer in SNMP > > Why is the leaf read-only in this use-case? > > IMO, the most important use-case is read-write leafref acting as key > or leaf, pointing to another key. (this was all the original keyref > type did). this is use-case #2 > >> 4) a read-write leafref acting as a leaf, and pointing at any >> leaf, is like a 'MyServer' kind of config copy. Some localized >> config is constrained to the global config values. >> >> 5) an RPC input parameter, pointing at any database leaf, >> is just another form of constraint semantics. >> >> 6) vip-slot example (not sure what to call this mode.) >> It is not a shadow, but a secondary knob which >> is constrained to the values of an external non-key leaf. >> (RMON users might think of the 'dataSource', which is a >> just a column in the main table, but an INDEX in other >> tables.) >> module A { list base { key x; leaf x { type uint32; } leaf pointed-at { type instance-identifier; } } leaf a { type leafref { // is it OK to leave out the '[x=n]' key predicate? path "../base/pointed-at"; } leaf b { type leafref { path "../a"; } } Given this config: 17 /A:a 42 /A:b It is clear that leaf 'a' is allowed to contain the values /A:a or /A:b, and leaf 'b' is only allowed to contain the current value of leaf 'a'. So if the operator wants to configure an ACM rule to restrict read access to '/base/pointed-at', does that mean the operator needs to track down every single leafref in the system that directly or indirectly references '/base/pointed-at' and configure an ACM rule for that leaf as well? >> ----------------------------------------------------------------- >> >> Issues: >> 1) require-instance, needed or not? This sub-statement is also used in instance-identifier-specification. Will require-instance go away completely? >> 2) use-case 4, needed or not? >> 3) use-case 6, needed or not? > > People have reported that require-instance makes leafrefs more > complicated. Personally, I don't see that, but we need to make > progress and solve this. I prefer not to, but I can live with > removing require-instance and also add a CLR to prevent use-case 4. > How do we distinguish #4 from #6? >> 4) behavior when pointed-at leaf is deleted >> (or value in leafref no longer in use)? > > Is this an issue? It works just like a false must constraint - the > config becomes invalid. so that means the constraint is enforced at commit-time on candidate and edit-config-time on running. > >> 5) nested lists not supported (**) >> >> ------------------------------------------------------------------ >> >> ** One issue not mentioned is that leafref is severely limited >> in utility because all key value pairs except the innermost layer >> need to be hardwired into the path expression. >> For example, use-case (1) is not actually supported >> by leafref for any nested lists, for this reason. > > No, any depth and number of keys are supported. But in order to > identify a leaf, you need values for all keys on all levels. This is the problem for use-case #1. It is too clumsy in YANG to specify what SMIv2 does so easily: - specify the database object to be included in the payload - the payload includes the instance-identifier of the selected instance of the specified object, and its current value One > leaf can only hold one value, so it means you need as many leafrefs as > there are keys. An example from the draft: > > container default-address { > leaf ifname { > type leafref { > path "../../interface/name"; > } > } > leaf address { > type leafref { > path "../../interface[name = current()/../ifname]" > + "/address/ip"; > } > } > } > > This syntax becomes clumsy when there are more than 2-3 keys, but it > is possible. > > > > /martin > > Andy From mbj@tail-f.com Wed May 27 12:11: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 40F5A3A7199 for ; Wed, 27 May 2009 12:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.205, 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 UuyD68Srexz4 for ; Wed, 27 May 2009 12:11:34 -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 9FC903A6D76 for ; Wed, 27 May 2009 12:11:13 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 670F3616013; Wed, 27 May 2009 21:12:19 +0200 (CEST) Date: Wed, 27 May 2009 21:12:19 +0200 (CEST) Message-Id: <20090527.211219.236583686.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1D7384.6030700@netconfcentral.com> References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <4A1D7384.6030700@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] leafref issues 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, 27 May 2009 19:11:35 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> I am trying to keep up with all the leafref issues, but it > >> is difficult. Maybe we can summarize them, eliminate > >> duplicate issues, etc. > >> > >> ------------------------------------------------------------------ > >> use-case chart: > >> > >> 1) a read-only leafref in a notification is like an alias > >> > >> 2) a leafref acting as a key, and pointing at another key, > >> is like an SQL foreign key > >> > >> 3) a read-only leafref acting as a leaf, and pointing at a key, > >> is almost like a RowPointer in SNMP > > Why is the leaf read-only in this use-case? > > IMO, the most important use-case is read-write leafref acting as key > > or leaf, pointing to another key. (this was all the original keyref > > type did). > > this is use-case #2 Ok, so use-case #2 should be "acting as a key or leaf". > >> 4) a read-write leafref acting as a leaf, and pointing at any > >> leaf, is like a 'MyServer' kind of config copy. Some localized > >> config is constrained to the global config values. > >> > >> 5) an RPC input parameter, pointing at any database leaf, > >> is just another form of constraint semantics. > >> > >> 6) vip-slot example (not sure what to call this mode.) > >> It is not a shadow, but a secondary knob which > >> is constrained to the values of an external non-key leaf. > >> (RMON users might think of the 'dataSource', which is a > >> just a column in the main table, but an INDEX in other > >> tables.) > >> > > module A { > list base { > key x; > leaf x { type uint32; } > leaf pointed-at { > type instance-identifier; > } > } > > leaf a { > type leafref { > // is it OK to leave out the '[x=n]' key predicate? > path "../base/pointed-at"; > } > > leaf b { > type leafref { > path "../a"; > } > } > > > Given this config: > > > 17 > /A:a > > > 42 > /A:b > > > It is clear that leaf 'a' is allowed to contain > the values /A:a or /A:b, and leaf 'b' is only allowed > to contain the current value of leaf 'a'. > > So if the operator wants to configure an ACM rule > to restrict read access to '/base/pointed-at', > does that mean the operator needs to track down every single > leafref in the system that directly or indirectly > references '/base/pointed-at' and configure an ACM rule > for that leaf as well? Well, there is no such thing as an ACM (yet). But if this is a leafref, rather than just type reuse and some description text, then the ACM could actually handle this, so that a user that is not allowed to read X is also not allowed to read a pointer to X (unless explicitly allowed maybe). Compare with SNMP - suppose you want to restrict read access to ifIndex, then you will have to track down all places an interface is referenced and configure VACM accordingly. > >> ----------------------------------------------------------------- > >> > >> Issues: > >> 1) require-instance, needed or not? > > > This sub-statement is also used in instance-identifier-specification. > > Will require-instance go away completely? If we remove it for leafref, I think it should be removed for instance-identifier as well. We should remove it if we see no value in having references to not-yet configured data; this applies to both types of "pointers" we have. > >> 2) use-case 4, needed or not? > >> 3) use-case 6, needed or not? > > People have reported that require-instance makes leafrefs more > > complicated. Personally, I don't see that, but we need to make > > progress and solve this. I prefer not to, but I can live with > > removing require-instance and also add a CLR to prevent use-case 4. > > > > How do we distinguish #4 from #6? #4 is a config leafref that points to a non-key leaf. #6 is a config leafref that points to a non-config leaf > >> 4) behavior when pointed-at leaf is deleted > >> (or value in leafref no longer in use)? > > Is this an issue? It works just like a false must constraint - the > > config becomes invalid. > > so that means the constraint is enforced at commit-time > on candidate and edit-config-time on running. Yes. > >> 5) nested lists not supported (**) > >> > >> ------------------------------------------------------------------ > >> > >> ** One issue not mentioned is that leafref is severely limited > >> in utility because all key value pairs except the innermost layer > >> need to be hardwired into the path expression. > >> For example, use-case (1) is not actually supported > >> by leafref for any nested lists, for this reason. > > No, any depth and number of keys are supported. But in order to > > identify a leaf, you need values for all keys on all levels. > > > This is the problem for use-case #1. So do you still think that "nested lists are not supported"? > It is too clumsy in YANG to specify what SMIv2 does so easily: > > - specify the database object to be included in the payload > - the payload includes the instance-identifier of the selected > instance of the specified object, and its current value I agree. There are two reasons for this, I think. One is XML vs. the varbinds in SNMP, where the key in each key/value pair contains the complete instance identifier. The other reason is that all object names are unique per module in SMIv2, which makes it easier to reference an object. It would be great to solve this problem in NETCONF/YANG. /martin From mbj@tail-f.com Wed May 27 12:14: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 B9C743A69D1; Wed, 27 May 2009 12:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.204, 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 pOQ+6NpC7IF1; Wed, 27 May 2009 12:14:05 -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 EDE5B3A696E; Wed, 27 May 2009 12:14:04 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EBEE6616013; Wed, 27 May 2009 21:14:39 +0200 (CEST) Date: Wed, 27 May 2009 21:14:39 +0200 (CEST) Message-Id: <20090527.211439.108634833.mbj@tail-f.com> To: greg.rabil@jagornet.com From: Martin Bjorklund In-Reply-To: References: <20090526.213904.79416403.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: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] draft-rabil-dhc-dhcpv6-xmlconfig-00.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, 27 May 2009 19:14:05 -0000 Hi, "A. Gregory Rabil" wrote: > Hi Martin, > > Thank you for your response. The "WhyYang" page really clears some things > up for me. I would consider converting my draft to one that uses YANG, if > you believe that there would be interest from the NETCONF/NETMOD community > for me to do so. Yes I believe this would be very interesting so I would encourage you to try write your data model in YANG. We would be very interested in your feedback! /martin From andy@netconfcentral.com Wed May 27 13:17: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 84F483A70FE for ; Wed, 27 May 2009 13:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_64=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 UsfZKrwCJF9k for ; Wed, 27 May 2009 13:17:06 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 5A1F43A715B for ; Wed, 27 May 2009 13:17:06 -0700 (PDT) Received: (qmail 66579 invoked from network); 27 May 2009 20:18:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 27 May 2009 20:18:36 -0000 X-YMail-OSG: wPjD898VM1kGluh0fpJUAjzZrNvyNBHATNQh.88ZUzFliKN5uqa1fTMzBhjVLuhEccMsaecVvXH78z5Wo9IJ8HzLeegSHQtGalOkjZr3FSbU6ixCeC6rSJ9v1cUPWOgqXPmA.RkBQ1uNjrfQ_0KYR_z2QJToAe3O2Ng9F51v5Hi1ZIfXoiQ9YLcxZEjO0mJfIZupTlkG1OzSKW8FxvfpK5cV1bHwW0Rn4Q2RgcHng93XwJ9RktjfhnADCMU4DtR.2RaD97DoYPMLLPaN09UXT80o77hYBA12mDL.hYa3_87s.D_cjW6Sr3IPgKW2G5590oxDf2xYQ9en2w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1DA01A.2090809@netconfcentral.com> Date: Wed, 27 May 2009 13:18:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <4A1D7384.6030700@netconfcentral.com> <20090527.211219.236583686.mbj@tail-f.com> In-Reply-To: <20090527.211219.236583686.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] leafref issues 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, 27 May 2009 20:17:07 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> I am trying to keep up with all the leafref issues, but it >>>> is difficult. Maybe we can summarize them, eliminate >>>> duplicate issues, etc. >>>> >>>> ------------------------------------------------------------------ >>>> use-case chart: >>>> >>>> 1) a read-only leafref in a notification is like an alias >>>> >>>> 2) a leafref acting as a key, and pointing at another key, >>>> is like an SQL foreign key >>>> >>>> 3) a read-only leafref acting as a leaf, and pointing at a key, >>>> is almost like a RowPointer in SNMP >>> Why is the leaf read-only in this use-case? >>> IMO, the most important use-case is read-write leafref acting as key >>> or leaf, pointing to another key. (this was all the original keyref >>> type did). >> this is use-case #2 > > Ok, so use-case #2 should be "acting as a key or leaf". > >>>> 4) a read-write leafref acting as a leaf, and pointing at any >>>> leaf, is like a 'MyServer' kind of config copy. Some localized >>>> config is constrained to the global config values. >>>> >>>> 5) an RPC input parameter, pointing at any database leaf, >>>> is just another form of constraint semantics. >>>> >>>> 6) vip-slot example (not sure what to call this mode.) >>>> It is not a shadow, but a secondary knob which >>>> is constrained to the values of an external non-key leaf. >>>> (RMON users might think of the 'dataSource', which is a >>>> just a column in the main table, but an INDEX in other >>>> tables.) >>>> >> module A { >> list base { >> key x; >> leaf x { type uint32; } >> leaf pointed-at { >> type instance-identifier; >> } >> } >> >> leaf a { >> type leafref { >> // is it OK to leave out the '[x=n]' key predicate? >> path "../base/pointed-at"; >> } >> >> leaf b { >> type leafref { >> path "../a"; >> } >> } >> >> >> Given this config: >> >> >> 17 >> /A:a >> >> >> 42 >> /A:b >> >> >> It is clear that leaf 'a' is allowed to contain >> the values /A:a or /A:b, and leaf 'b' is only allowed >> to contain the current value of leaf 'a'. >> >> So if the operator wants to configure an ACM rule >> to restrict read access to '/base/pointed-at', >> does that mean the operator needs to track down every single >> leafref in the system that directly or indirectly >> references '/base/pointed-at' and configure an ACM rule >> for that leaf as well? > > Well, there is no such thing as an ACM (yet). But if this is a > leafref, rather than just type reuse and some description text, then > the ACM could actually handle this, so that a user that is not allowed > to read X is also not allowed to read a pointer to X (unless > explicitly allowed maybe). > > Compare with SNMP - suppose you want to restrict read access to > ifIndex, then you will have to track down all places an interface is > referenced and configure VACM accordingly. > >>>> ----------------------------------------------------------------- >>>> >>>> Issues: >>>> 1) require-instance, needed or not? >> >> This sub-statement is also used in instance-identifier-specification. >> >> Will require-instance go away completely? > > If we remove it for leafref, I think it should be removed for > instance-identifier as well. We should remove it if we see no value > in having references to not-yet configured data; this applies to both > types of "pointers" we have. > >>>> 2) use-case 4, needed or not? >>>> 3) use-case 6, needed or not? >>> People have reported that require-instance makes leafrefs more >>> complicated. Personally, I don't see that, but we need to make >>> progress and solve this. I prefer not to, but I can live with >>> removing require-instance and also add a CLR to prevent use-case 4. >>> >> How do we distinguish #4 from #6? > > #4 is a config leafref that points to a non-key leaf. > > #6 is a config leafref that points to a non-config leaf > I am strongly opposed to #6 because it requires the agent to splice non-config parts of the running config into the candidate database, to determine if the config leafref is being set to a proper instance of the the non-config leaf. IMO, the candidate database MUST only contain config=true nodes. I am in favor of disallowing both #4 and #6, and only allowing use-case #2 for config=true leafref database nodes. Removing require-instance (hardwire to true) is fine too. The example I gave had a chicken-and-egg instance-identifier/leafref problem. The pointed-at leaf is not actually allowed to contain the value /A:a or /A:b until either of those nodes exists, but neither of those leafs is allowed to exist until pointed-at exists first. Setting require-instance to false on the pointed-at leaf is the easiest way to solve this problem. Or just remove use cases #4 and #6 -- that also solves the problem. >>>> 4) behavior when pointed-at leaf is deleted >>>> (or value in leafref no longer in use)? >>> Is this an issue? It works just like a false must constraint - the >>> config becomes invalid. >> so that means the constraint is enforced at commit-time >> on candidate and edit-config-time on running. > > Yes. > >>>> 5) nested lists not supported (**) >>>> >>>> ------------------------------------------------------------------ >>>> >>>> ** One issue not mentioned is that leafref is severely limited >>>> in utility because all key value pairs except the innermost layer >>>> need to be hardwired into the path expression. >>>> For example, use-case (1) is not actually supported >>>> by leafref for any nested lists, for this reason. >>> No, any depth and number of keys are supported. But in order to >>> identify a leaf, you need values for all keys on all levels. >> >> This is the problem for use-case #1. > > So do you still think that "nested lists are not supported"? > not easily supported, but this is a rare event, so it probably doesn't matter >> It is too clumsy in YANG to specify what SMIv2 does so easily: >> >> - specify the database object to be included in the payload >> - the payload includes the instance-identifier of the selected >> instance of the specified object, and its current value > > I agree. There are two reasons for this, I think. One is XML vs. the > varbinds in SNMP, where the key in each key/value pair contains the > complete instance identifier. The other reason is that all object > names are unique per module in SMIv2, which makes it easier to > reference an object. > Yes -- in YANG, the schema-identifier would need to be used instead: (Think I posted this 2 or 3 times already. notification foo { varbind a { // 5 clauses, path mandatory, showing the defaults path "/interfaces/interface/ifMtu"; status current; description "this is like an SMIv2 OBJECTS entry"; reference "..."; mandatory false; } varbind b { path "/interfaces/interface/ifInOctets"; mandatory true; } leaf local-var { description "this is likse an SMIv2 a notify-only data definition."; type string; } } ... /if:interfaces/if:interface[if:name='eth0']/if:ifMtu 1500 /if:interfaces/if:interface[if:name='eth0']/if:ifInOctets 38765552 interface eth0 status string inserted here > It would be great to solve this problem in NETCONF/YANG. > yes > > /martin > > Andy From jmh@joelhalpern.com Wed May 27 13:34: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 07F473A68D7 for ; Wed, 27 May 2009 13:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 cXaiScshPX6O for ; Wed, 27 May 2009 13:34:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2A00E3A6DAD for ; Wed, 27 May 2009 13:34:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1614F4303D5; Wed, 27 May 2009 13:35:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 176AD4303E9; Wed, 27 May 2009 13:35:48 -0700 (PDT) Message-ID: <4A1DA422.7090006@joelhalpern.com> Date: Wed, 27 May 2009 16:35:46 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <4A1D7384.6030700@netconfcentral.com> <20090527.211219.236583686.mbj@tail-f.com> <4A1DA01A.2090809@netconfcentral.com> In-Reply-To: <4A1DA01A.2090809@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 27 May 2009 20:34:08 -0000 Comments after Andy's text, with partial agreement. Andy Bierman wrote: > Martin Bjorklund wrote: >> #4 is a config leafref that points to a non-key leaf. >> >> #6 is a config leafref that points to a non-config leaf >> > > I am strongly opposed to #6 because it requires > the agent to splice non-config parts of the running config > into the candidate database, to determine if the > config leafref is being set to a proper instance > of the the non-config leaf. > > IMO, the candidate database MUST only contain config=true nodes. > > I am in favor of disallowing both #4 and #6, and only > allowing use-case #2 for config=true leafref database nodes. > > Removing require-instance (hardwire to true) is fine too. > The example I gave had a chicken-and-egg instance-identifier/leafref > problem. The pointed-at leaf is not actually allowed to > contain the value /A:a or /A:b until either of those nodes exists, > but neither of those leafs is allowed to exist until pointed-at > exists first. > > Setting require-instance to false on the pointed-at leaf > is the easiest way to solve this problem. Or just remove > use cases #4 and #6 -- that also solves the problem. Removing case 6 (config leaf with a leafref to non-config data) does seem like a good idea. Otherwise, very strange inconsistencies would seem possible. However, I do not see what the problem with case 4 is, and it seems to have value. However, this is based on an assumption. That assumption is that it is reasonable to multiple unbound keys in the path statement of a leafref. The leafref is merely constrained to have a value pointed at by some key sequence. In that model, a config leafref pointing to a non-key config leaf still has multiple values, so it can be set (i.e. is meaningful config information.) If a leafref pointing to a non-key leaf can not have any unbound keys in the path, then there is no point in such, since although it claims to be config data, it can not meaningfully be set (its value is constrained to a single value at any given time.) Yours, Joel From mbj@tail-f.com Wed May 27 14:35: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 A91863A6A78 for ; Wed, 27 May 2009 14:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=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 t3muemyDdRKq for ; Wed, 27 May 2009 14:35:04 -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 4851A3A6D5B for ; Wed, 27 May 2009 14:35:04 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 95D51616013; Wed, 27 May 2009 23:36:43 +0200 (CEST) Date: Wed, 27 May 2009 23:36:43 +0200 (CEST) Message-Id: <20090527.233643.179592162.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1DA01A.2090809@netconfcentral.com> References: <4A1D7384.6030700@netconfcentral.com> <20090527.211219.236583686.mbj@tail-f.com> <4A1DA01A.2090809@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] leafref issues 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, 27 May 2009 21:35:05 -0000 Andy Bierman wrote: > >> How do we distinguish #4 from #6? > > #4 is a config leafref that points to a non-key leaf. > > #6 is a config leafref that points to a non-config leaf > > > > I am strongly opposed to #6 because it requires > the agent to splice non-config parts of the running config > into the candidate database, to determine if the > config leafref is being set to a proper instance > of the the non-config leaf. No, because in when a config point to a non-config, require instance must be false. > IMO, the candidate database MUST only contain config=true nodes. Absolutely. /martin From andy@netconfcentral.com Wed May 27 14:59: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 509813A6A7E for ; Wed, 27 May 2009 14:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=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 hwCvJe3kT0eU for ; Wed, 27 May 2009 14:59:15 -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 A719A3A67EB for ; Wed, 27 May 2009 14:59:15 -0700 (PDT) Received: (qmail 50485 invoked from network); 27 May 2009 22:00:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 27 May 2009 22:00:53 -0000 X-YMail-OSG: BQ5zQY0VM1l0gHkHSz1z4LW.YWGBZVcw0mrHeVRNn6kighJdY3cCKF_6u_DkwVcBqkq50LE401mHwhHcTOg1FRixOwcLw2XxOzDuCIV8dS4o0S1Jmulg9.YFZtHm67pvfH4F46ZbFbNq13fo8fqCOH5ftvUXQ5Y4FwHa0qXLmVFKO7.qXt2dzdMqToljvY9XZv391H5_6Wql9lMEM_VA7Gelm4Dchom_VfPIGPtHdq8GlAJxX7usAD5FQQ85QfO5R4PG1YUwi9dzEmXvuFO_r3eDB1uA4AnDJ6UBf7DHq7NxuXIMmy6xAbIGAL5E_t2I9quYCqpLRvPV1w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1DB814.30100@netconfcentral.com> Date: Wed, 27 May 2009 15:00:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1D7384.6030700@netconfcentral.com> <20090527.211219.236583686.mbj@tail-f.com> <4A1DA01A.2090809@netconfcentral.com> <20090527.233643.179592162.mbj@tail-f.com> In-Reply-To: <20090527.233643.179592162.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] leafref issues 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, 27 May 2009 21:59:16 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>>> How do we distinguish #4 from #6? >>> #4 is a config leafref that points to a non-key leaf. >>> #6 is a config leafref that points to a non-config leaf >>> >> I am strongly opposed to #6 because it requires >> the agent to splice non-config parts of the running config >> into the candidate database, to determine if the >> config leafref is being set to a proper instance >> of the the non-config leaf. > > No, because in when a config point to a non-config, require instance > must be false. > but what if require-instance goes away, and is hard-wired to true? Will it be hard-wired to false for any leafref pointing at a non-config leaf? This is all a bit confusing. It is not clear what is allowed, or what sub-statements are being kept, or going away, or changing again. I still do not like this because the XPath target is associated with a specific database, e.g., the parameter in the operation. An XPath expression that is evaluated against the candidate database should be limited to nodes actually in the candidate database. Although 'unknown-element' is a just a no-match condition, it is extremely confusing to treat references to non-config nodes in some special way, within an XPath expression. >> IMO, the candidate database MUST only contain config=true nodes. > > Absolutely. > > > /martin > > Andy From cfinss@dial.pipex.com Thu May 28 01: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 213863A6D1A for ; Thu, 28 May 2009 01:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=-0.740, 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 7QPDcDYFh8FC for ; Thu, 28 May 2009 01:57:55 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 047C53A68D8 for ; Thu, 28 May 2009 01:57:54 -0700 (PDT) X-Trace: 163568528/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.227/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.227 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: Aq0EADLvHUo+vGnj/2dsb2JhbACDKItpvyEIhAUF X-IronPort-AV: E=Sophos;i="4.41,264,1241391600"; d="scan'208";a="163568528" X-IP-Direction: IN Received: from 1cust227.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.227]) by smtp.pipex.tiscali.co.uk with SMTP; 28 May 2009 09:59:20 +0100 Message-ID: <006901c9df6a$149e0ec0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Martin Bjorklund" References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> Date: Thu, 28 May 2009 09:43:03 +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: [netmod] XPath issues 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: Thu, 28 May 2009 08:57:56 -0000 Something simple for a change:-) I like the coverage of XPath in -05 but think it needs a little tweaking. XPath appears in 'must' (7.5.3), 'augment' (7.15), 'when' (7.19.5), 'path' (9.9.2), 'instance-identifier' (9.13) and 6.4 but is not treated consistently. XPath needs a context - node, position, size, variable bindings, function library and namespace declarations - and, since this is not a document, a specification of the XPath root node. 6.4 says something about context node and namespaces 'must' and 'when' cover context node, function library, namespace declarations, XPath root node. 'augment', 'path', 'instance identifier' cover none of this. Why the difference? Can some of this be in 6.4, eg on function library, if it is common to all use cases of XPath? Possibly likewise with namespaces (I struggle to decide which namespaces are current for XPath within the assemblage of module/submodule/grouping/import/include/uses/augments) And 'augment', 'path', 'instance-identifier' prohibit axes, which leaves me stumped. 'self', 'parent', 'child', 'descendant' are all axes and without them, I struggle to create a meaningful XPath expression. I also struggle with 'sibling'; this is not an axis but 'following-sibling' and 'preceding-sibling' are, but we do not have a document order so presumably can never use either form of sibling axis; if so, this would fit with 6.4. Tom Petch From cfinss@dial.pipex.com Thu May 28 01: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 C27113A6D1A for ; Thu, 28 May 2009 01:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.361, 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 XBiJcfvc3WfV for ; Thu, 28 May 2009 01:57:55 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFB23A6CDA for ; Thu, 28 May 2009 01:57:55 -0700 (PDT) X-Trace: 163568544/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.227/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.227 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: Aq0EADLvHUo+vGnj/2dsb2JhbACDKItpvyEIhAUF X-IronPort-AV: E=Sophos;i="4.41,264,1241391600"; d="scan'208";a="163568544" X-IP-Direction: IN Received: from 1cust227.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.227]) by smtp.pipex.tiscali.co.uk with SMTP; 28 May 2009 09:59:21 +0100 Message-ID: <006a01c9df6a$1556b060$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A1CA0B8.2060105@joelhalpern.com><20090527.091235.60398524.mbj@tail-f.com><003c01c9deb4$469020a0$0601a8c0@allison> <20090527.142140.201274546.mbj@tail-f.com> Date: Thu, 28 May 2009 09:47:19 +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] leaf-ref questions 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: Thu, 28 May 2009 08:57:56 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Wednesday, May 27, 2009 2:21 PM Subject: Re: [netmod] leaf-ref questions > "tom.petch" wrote: > > > "Joel M. Halpern" wrote: > > > > The more I think about it, the more convinced I am that for me, the problem > > is > > > > "require-instance = false;". > > > > > > The reason we added this was to allow config data that refers to > > > non-config data, e.g. a pointer to a physical slot. Without > > > require-instance false, if we allow config to refer to non-config > > > (state), the state data might change dynamically, making the > > > configuration invalid. > > > > > > Another use case is pre-provisioning, as Andy described. > > > > I am getting into a terminological confusion here. Config is writable and > > non-config is not so this allows me to write to read-only data. > > No, since the leafref is not like a symbolic link. Consider this: > > list slot { > config "false"; > key "index"; > leaf index { > type int32; > } > } > > leafref vip-slot { > config "true"; > type leafref { > path "/slot/index"; > require-instance "true"; > } > } > > > The 'vip-slot' leaf is its very own, writable, leaf. A leaf has a > value which matches its type. When you write to the leaf, the leaf's > value is changed. > > Compare with this: > > struct slot slots[MAX_SLOTS]; > > int vip_slot; /* index into the slots array */ > > When you set the variable vip_slot, nothing in the slots array gets > modified. A leafref works the same way (but the comment in the code > is formalized in the path statement in a leafref). > > > Does this mean that a second writable instance of the node is created? > > It's not the require-instance false that bothers me but the life-cycle of > > this leaf-ref'd node, when it exists, what causes it to be updated etc. > > > > And where does this fit in Andy's excellent list of five use cases? > > I don't think it is covered in his list. > Martin, Thank you, I now understand this use case ( although it leaves me unclear about Andy's case four which I would have thought covered it). I assume that as vip-slot is config and so writable, then it can be changed as long as the new value is within the slot/index set of values. To me, this is more like an 'External enumeration', to coin a phrase; would it be better handled by putting the constraint on the slot list, that the vip-slot leafref must appear in the slot list, as opposed to putting the constraint on the vip-slot leafref? Conceptually, we do seem to be mixing - a single object instance with different paths to get to it in the data mesh (which is how I see Andy's case 1 although I could be wrong:-( - multiple object instances with different life cycles which have a mutual constraint between the values or sets therof. Which may confuse more than me. Tom Petch > > /martin From mbj@tail-f.com Thu May 28 02:04: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 5BDD228C0E7 for ; Thu, 28 May 2009 02:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.186, 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 t+CgyJDuotoo for ; Thu, 28 May 2009 02:04:13 -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 A6EDE3A685F for ; Thu, 28 May 2009 02:04:12 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 69CCC61600C; Thu, 28 May 2009 11:05:54 +0200 (CEST) Date: Thu, 28 May 2009 11:05:55 +0200 (CEST) Message-Id: <20090528.110555.136788297.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1DB814.30100@netconfcentral.com> References: <4A1DA01A.2090809@netconfcentral.com> <20090527.233643.179592162.mbj@tail-f.com> <4A1DB814.30100@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] leafref issues 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, 28 May 2009 09:04:18 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >>>> How do we distinguish #4 from #6? > >>> #4 is a config leafref that points to a non-key leaf. > >>> #6 is a config leafref that points to a non-config leaf > >>> > >> I am strongly opposed to #6 because it requires > >> the agent to splice non-config parts of the running config > >> into the candidate database, to determine if the > >> config leafref is being set to a proper instance > >> of the the non-config leaf. > > No, because in when a config point to a non-config, require instance > > must be false. > > > > but what if require-instance goes away, > and is hard-wired to true? > > Will it be hard-wired to false for any leafref > pointing at a non-config leaf? One reason we added require-instance was to be able to handle #6. So if we remove require-instance, I think a config leafref MUST refer to a config leaf, and a non-config leafref can refer to anything. > This is all a bit confusing. > It is not clear what is allowed, or what sub-statements > are being kept, or going away, or changing again. Nothing has been decided yet, we're still trying to understand the consequences of making various changes. If we remove require-instance, I believe we get these combinations: a) config leafref can refer to config leaf or key use-case: #2 and #4 b) non-config leafref can refer to any config or non-config leaf or key use-case: #1, #3, and #5 It seems we have a couple of people that want to remove require-instance (and thus use-case #6), and a couple that can accept this decision. Any objections to removing require-instance for leafrefs? If we remove require-instance for leafrefs, the question is if we should also remove it for instance-identifiers. I earlier said yes, but I have changed my mind. One example is if you have an access control model based on instance-identifiers. Then it would be very difficult to specify rules only for existing instances. The other issue is if we should add a CLR to prevent usecase #4. I am not sure if anyone is actually proposing this, although a couple of people have said they can accept it. Joel explcitily said he wants to keep it. /martin From mbj@tail-f.com Thu May 28 02:14: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 AEA3D3A6D70 for ; Thu, 28 May 2009 02:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.176, 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 wndiNMw9OuNr for ; Thu, 28 May 2009 02:14:09 -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 DF7443A6D47 for ; Thu, 28 May 2009 02:14:08 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 1062C61600C; Thu, 28 May 2009 11:15:51 +0200 (CEST) Date: Thu, 28 May 2009 11:15:51 +0200 (CEST) Message-Id: <20090528.111551.241341287.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <006a01c9df6a$1556b060$0601a8c0@allison> References: <003c01c9deb4$469020a0$0601a8c0@allison> <20090527.142140.201274546.mbj@tail-f.com> <006a01c9df6a$1556b060$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=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-ref questions 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, 28 May 2009 09:14:09 -0000 Hi, "tom.petch" wrote: > Thank you, I now understand this use case ( although it leaves me unclear about > Andy's case four which I would have thought covered it). Maybe it did - I read it as a config leafref pointing to config leaf. > I assume that as vip-slot is config and so writable, then it can be changed as > long as the new value is within the slot/index set of values. > > To me, this is more like an 'External enumeration', to coin a phrase; would it > be better handled by putting the constraint on the slot list, that the vip-slot > leafref must appear in the slot list, as opposed to putting the constraint on > the vip-slot leafref? The the slot list might be published in one module, and the vip-slot in some other module later on. If we remove require instance, this kind of reference will have to described in the description clause. > Conceptually, we do seem to be mixing > - a single object instance with different paths to get to it in the data mesh > (which is how I see Andy's case 1 although I could be wrong:-( When the leafref is included in a notification, as in Andy's use-case 1, it is more like a copy of the data. You can't really access the same instance this way. So IMO, we never have multiple paths to a single instance. > - multiple object instances with different life cycles which have a mutual > constraint between the values or sets therof. This description matches my view of this. /martin From mbj@tail-f.com Thu May 28 02:56: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 973F33A6BCB for ; Thu, 28 May 2009 02:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.167, 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 hbArcF7ihcGf for ; Thu, 28 May 2009 02:56: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 263BE3A6A31 for ; Thu, 28 May 2009 02:56:21 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id B3AD661600C; Thu, 28 May 2009 11:56:54 +0200 (CEST) Date: Thu, 28 May 2009 11:56:55 +0200 (CEST) Message-Id: <20090528.115655.03590098.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <006901c9df6a$149e0ec0$0601a8c0@allison> References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <006901c9df6a$149e0ec0$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=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath issues 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, 28 May 2009 09:56:46 -0000 Hi Tom, "tom.petch" wrote: > Something simple for a change:-) > > I like the coverage of XPath in -05 but think it needs a little tweaking. > > XPath appears in 'must' (7.5.3), 'augment' (7.15), 'when' (7.19.5), 'path' > (9.9.2), 'instance-identifier' (9.13) and 6.4 but is not treated consistently. > > XPath needs a context - node, position, size, variable bindings, function > library and namespace declarations - and, since this is not a document, a > specification of the XPath root node. > > 6.4 says something about context node and namespaces > > 'must' and 'when' cover context node, function library, namespace declarations, > XPath root node. > > 'augment', 'path', 'instance identifier' cover none of this. > > Why the difference? Ladislav pointed this out as well. Specifically, he wanted this spec for 'path'. > Can some of this be in 6.4, eg on function library, if it > is common to all use cases of XPath? The function library is common to all use cases which allow functions (must and when). Note that augment, path and instance-identifier all have a very restricted form of XPath where functions and variables cannot appear. > Possibly likewise with namespaces (I > struggle to decide which namespaces are current for XPath within the assemblage > of module/submodule/grouping/import/include/uses/augments) > > And 'augment', 'path', 'instance-identifier' prohibit axes, which leaves me > stumped. 'self', 'parent', 'child', 'descendant' are all axes and without > them, I struggle to create a meaningful XPath expression. The intention is to allow the abbreviated syntax which has the 'child' axis as default, but prohibit explicit axis specification. E.g. /foo/bar is legal, but /foo/child::bar is not. Do we need to clarify this in the text? As an alternative, these expressions could be defined w/o mentioning XPath at all, e.g. augment is a '/' separated string of node identifiers. But I'm not sure this would be better / simpler. > I also struggle with 'sibling'; this is not an axis but 'following-sibling' and > 'preceding-sibling' are, but we do not have a document order so presumably can > never use either form of sibling axis; if so, this would fit with 6.4. Andy wrote about this in the guidelines docuement. Do you think we need to include anything from his text in this document, or can be leave it there? /martin From andy@netconfcentral.com Thu May 28 09:05: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 A6B553A6DD7 for ; Thu, 28 May 2009 09:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 8tTJSw5Dw62X for ; Thu, 28 May 2009 09:05: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 D85823A69B3 for ; Thu, 28 May 2009 09:05:19 -0700 (PDT) Received: from [209.191.108.96] by n20.bullet.mail.mud.yahoo.com with NNFMP; 28 May 2009 16:07:01 -0000 Received: from [68.142.201.73] by t3.bullet.mud.yahoo.com with NNFMP; 28 May 2009 16:07:01 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 28 May 2009 16:07:01 -0000 X-Yahoo-Newman-Id: 485234.18247.bm@omp425.mail.mud.yahoo.com Received: (qmail 70709 invoked from network); 28 May 2009 16:07:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 28 May 2009 16:07:00 -0000 X-YMail-OSG: 9b60vm0VM1mLfyhA9PSI3upBm6Sdm8ZapoCEtnUDH8jn7bO2DR._0JGxQ_8nr3npAc6739vSbqaZ5QUfu8Hc5JuNPUQcQw6yVf_oSoehg9o6a8ybrKT1237LQBk7Yl2R_B5G4juKqOIgReX91LPF3uFS3G7LiQJATD6f6QfkZdFglxnmBQorW.NoSQIR8TtRnUX52k6eOUdjDw4PRfOndUd2AXS523WtMeofWqHs1ZfJ_9m7kmcuY2_EdK21RHDPiAlH1aeFa0ztFKcp_icfjSEUK80jHsb1iVTYFlqcgSvGoabWy.Zp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1EB6A1.2080302@netconfcentral.com> Date: Thu, 28 May 2009 09:06: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] XPath root node for /rpc 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, 28 May 2009 16:05:20 -0000 Hi, [This applies to must-stmt, not just when-stmt.] The text in 7.19.5 (when-stmt) says the root of the accessible data tree for /rpc/any-function/input and /rpc/any-function/output is . The issue of referencing the wrong subtree (e.g., reference /any-function/output/x in an input parameter when-stmt) has already been discussed. Although not intuitive, it is consistent with . Any errors of this type in the XPath will be treated as 'no-match' conditions and not reported as errors. GI = GO. The other issue not really mentioned so far is that the contents of the database cannot be used at all in conditional object expressions inside RPC methods or notifications. The must/when expressions must use nodes from same subtree (input, output, or the notification payload). I don't know if it is worth fixing this limitation, but perhaps an example would help, showing an RPC input and/or output with when-stmts. Andy From cfinss@dial.pipex.com Thu May 28 11:33:33 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 BCE5A3A6FAC for ; Thu, 28 May 2009 11:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.573, 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 ZH3aL3idl6DJ for ; Thu, 28 May 2009 11:33:32 -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 4295A3A6D21 for ; Thu, 28 May 2009 11:32:10 -0700 (PDT) X-Trace: 217937043/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.244/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.244 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: Aq0EAH91Hko+vGT0/2dsb2JhbACDKItpwBsIhAUF X-IronPort-AV: E=Sophos;i="4.41,266,1241391600"; d="scan'208";a="217937043" X-IP-Direction: IN Received: from 1cust244.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.244]) by smtp.pipex.tiscali.co.uk with SMTP; 28 May 2009 19:33:48 +0100 Message-ID: <002d01c9dfba$55470a80$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A1D5742.3000201@netconfcentral.com><20090527.182615.118040817.mbj@tail-f.com><006901c9df6a$149e0ec0$0601a8c0@allison> <20090528.115655.03590098.mbj@tail-f.com> Date: Thu, 28 May 2009 18:42:25 +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] XPath issues 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: Thu, 28 May 2009 18:33:33 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; Sent: Thursday, May 28, 2009 11:56 AM > > "tom.petch" wrote: > > > > XPath appears in 'must' (7.5.3), 'augment' (7.15), 'when' (7.19.5), 'path' > > (9.9.2), 'instance-identifier' (9.13) and 6.4 but is not treated consistently. > > > > XPath needs a context - node, position, size, variable bindings, function > > library and namespace declarations - and, since this is not a document, a > > specification of the XPath root node. > > > > 6.4 says something about context node and namespaces > > > > 'must' and 'when' cover context node, function library, namespace declarations, > > XPath root node. > > > > 'augment', 'path', 'instance identifier' cover none of this. > > > > Why the difference? > > Ladislav pointed this out as well. Specifically, he wanted this spec > for 'path'. Ah, I missed that; I would like it for all three, or else a note as to why this is not an issue. I think that namespaces is the aspect I cannot readily work out (import/include/uses/augments ...etc) > > Can some of this be in 6.4, eg on function library, if it > > is common to all use cases of XPath? > > The function library is common to all use cases which allow > functions (must and when). Note that augment, path and > instance-identifier all have a very restricted form of XPath where > functions and variables cannot appear. > Well, to be picky, path allows the current() function. > > Possibly likewise with namespaces (I > > struggle to decide which namespaces are current for XPath within the assemblage > > of module/submodule/grouping/import/include/uses/augments) > > > > And 'augment', 'path', 'instance-identifier' prohibit axes, which leaves me > > stumped. 'self', 'parent', 'child', 'descendant' are all axes and without > > them, I struggle to create a meaningful XPath expression. > > The intention is to allow the abbreviated syntax which has the 'child' > axis as default, but prohibit explicit axis specification. > E.g. /foo/bar is legal, but /foo/child::bar is not. Do we need to > clarify this in the text? I think so; I would stay with XPath as a base since it is used elsewhere but I think that the text on axes should be explicit - self, parent, child, descendant? - rather than implicit by saying that any axis that can be specified by abbreviated syntax is valid (except attribute because there are none) or what we have now which for me is a contradiction; axes specified via the abbreviated syntax are still axes to me. > As an alternative, these expressions could be defined w/o mentioning > XPath at all, e.g. augment is a '/' separated string of node > identifiers. But I'm not sure this would be better / simpler. > > > I also struggle with 'sibling'; this is not an axis but 'following-sibling' and > > 'preceding-sibling' are, but we do not have a document order so presumably can > > never use either form of sibling axis; if so, this would fit with 6.4. > > Andy wrote about this in the guidelines docuement. Do you think we > need to include anything from his text in this document, or can be > leave it there? I would include it in this document Tom Petch > > /martin From cfinss@dial.pipex.com Thu May 28 11:33:33 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 CF3393A6D21 for ; Thu, 28 May 2009 11:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 NfytgzY9zP9B for ; Thu, 28 May 2009 11:33:32 -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 D7D6F3A6E21 for ; Thu, 28 May 2009 11:32:10 -0700 (PDT) X-Trace: 217937056/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.244/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.244 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: Aq0EAH91Hko+vGT0/2dsb2JhbACDKItpwBsIgjWBUAU X-IronPort-AV: E=Sophos;i="4.41,266,1241391600"; d="scan'208";a="217937056" X-IP-Direction: IN Received: from 1cust244.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.244]) by smtp.pipex.tiscali.co.uk with SMTP; 28 May 2009 19:33:50 +0100 Message-ID: <002e01c9dfba$5639a7e0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Martin Bjorklund" References: <4A1D5742.3000201@netconfcentral.com><20090527.182615.118040817.mbj@tail-f.com> <4A1D7384.6030700@netconfcentral.com> Date: Thu, 28 May 2009 18:51:03 +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] leafref issues 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: Thu, 28 May 2009 18:33:33 -0000 Andy I like the taxonomy but struggle with two potential attributes of each case: - whether there is a second instance created, which has an independent life cycle as opposed to creating a second path to a single instance. In 1), I had assumed one instance multiple paths but Martin says not. - and whether the leafref has write access; in 2), I assume that the foreign key is read only ie as a data modeller, if I have designed and specified a key and its use, I don't want someone else coming along and changing it. I don't doubt that you can implement multiple write but would not like to see it on offer. I would like to be clearer on this before saying how many of the use cases I would like to bin:-) Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: Sent: Wednesday, May 27, 2009 7:08 PM Subject: Re: [netmod] leafref issues > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> I am trying to keep up with all the leafref issues, but it > >> is difficult. Maybe we can summarize them, eliminate > >> duplicate issues, etc. > >> > >> ------------------------------------------------------------------ > >> use-case chart: > >> > >> 1) a read-only leafref in a notification is like an alias > >> > >> 2) a leafref acting as a key, and pointing at another key, > >> is like an SQL foreign key > >> > >> 3) a read-only leafref acting as a leaf, and pointing at a key, > >> is almost like a RowPointer in SNMP > > > > Why is the leaf read-only in this use-case? > > > > IMO, the most important use-case is read-write leafref acting as key > > or leaf, pointing to another key. (this was all the original keyref > > type did). > > this is use-case #2 > > > > >> 4) a read-write leafref acting as a leaf, and pointing at any > >> leaf, is like a 'MyServer' kind of config copy. Some localized > >> config is constrained to the global config values. > >> > >> 5) an RPC input parameter, pointing at any database leaf, > >> is just another form of constraint semantics. > >> > >> 6) vip-slot example (not sure what to call this mode.) > >> It is not a shadow, but a secondary knob which > >> is constrained to the values of an external non-key leaf. > >> (RMON users might think of the 'dataSource', which is a > >> just a column in the main table, but an INDEX in other > >> tables.) > >> > > module A { > list base { > key x; > leaf x { type uint32; } > leaf pointed-at { > type instance-identifier; > } > } > > leaf a { > type leafref { > // is it OK to leave out the '[x=n]' key predicate? > path "../base/pointed-at"; > } > > leaf b { > type leafref { > path "../a"; > } > } > > > Given this config: > > > 17 > /A:a > > > 42 > /A:b > > > It is clear that leaf 'a' is allowed to contain > the values /A:a or /A:b, and leaf 'b' is only allowed > to contain the current value of leaf 'a'. > > So if the operator wants to configure an ACM rule > to restrict read access to '/base/pointed-at', > does that mean the operator needs to track down every single > leafref in the system that directly or indirectly > references '/base/pointed-at' and configure an ACM rule > for that leaf as well? > > > >> ----------------------------------------------------------------- > >> > >> Issues: > >> 1) require-instance, needed or not? > > > This sub-statement is also used in instance-identifier-specification. > > Will require-instance go away completely? > > > >> 2) use-case 4, needed or not? > >> 3) use-case 6, needed or not? > > > > People have reported that require-instance makes leafrefs more > > complicated. Personally, I don't see that, but we need to make > > progress and solve this. I prefer not to, but I can live with > > removing require-instance and also add a CLR to prevent use-case 4. > > > > How do we distinguish #4 from #6? > > >> 4) behavior when pointed-at leaf is deleted > >> (or value in leafref no longer in use)? > > > > Is this an issue? It works just like a false must constraint - the > > config becomes invalid. > > so that means the constraint is enforced at commit-time > on candidate and edit-config-time on running. > > >> 5) nested lists not supported (**) > >> > >> ------------------------------------------------------------------ > >> > >> ** One issue not mentioned is that leafref is severely limited > >> in utility because all key value pairs except the innermost layer > >> need to be hardwired into the path expression. > >> For example, use-case (1) is not actually supported > >> by leafref for any nested lists, for this reason. > > > > No, any depth and number of keys are supported. But in order to > > identify a leaf, you need values for all keys on all levels. > > This is the problem for use-case #1. > It is too clumsy in YANG to specify what SMIv2 does so easily: > > - specify the database object to be included in the payload > - the payload includes the instance-identifier of the selected > instance of the specified object, and its current value > > > One > > leaf can only hold one value, so it means you need as many leafrefs as > > there are keys. An example from the draft: > > > > container default-address { > > leaf ifname { > > type leafref { > > path "../../interface/name"; > > } > > } > > leaf address { > > type leafref { > > path "../../interface[name = current()/../ifname]" > > + "/address/ip"; > > } > > } > > } > > > > This syntax becomes clumsy when there are more than 2-3 keys, but it > > is possible. > > > > /martin > > > Andy From mbj@tail-f.com Thu May 28 11:53: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 50C8D3A6976 for ; Thu, 28 May 2009 11:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.203, 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 15KSeQdaK1p7 for ; Thu, 28 May 2009 11:53: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 8337A3A6A7A for ; Thu, 28 May 2009 11:53:44 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8646961600C; Thu, 28 May 2009 20:55:24 +0200 (CEST) Date: Thu, 28 May 2009 20:55:24 +0200 (CEST) Message-Id: <20090528.205524.156254374.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1EB6A1.2080302@netconfcentral.com> References: <4A1EB6A1.2080302@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] XPath root node for /rpc 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, 28 May 2009 18:53:51 -0000 Andy Bierman wrote: > Hi, > > [This applies to must-stmt, not just when-stmt.] > > The text in 7.19.5 (when-stmt) says the root of > the accessible data tree for /rpc/any-function/input > and /rpc/any-function/output is . Yes, and it says: - 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. So in: ... ... The node 'any-function' is the root, and its children are 'param1'... > The issue of referencing the wrong subtree > (e.g., reference /any-function/output/x > in an input parameter when-stmt) has already been > discussed. Although not intuitive, it is > consistent with . If you look at it from an instance-document pow, it is easier to understand. > Any errors of this > type in the XPath will be treated as 'no-match' > conditions and not reported as errors. GI = GO. Yes, this is how XPath works. > The other issue not really mentioned so far is that > the contents of the database cannot be used > at all in conditional object expressions inside > RPC methods or notifications. The must/when > expressions must use nodes from same subtree > (input, output, or the notification payload). > > I don't know if it is worth fixing this limitation, > but perhaps an example would help, showing > an RPC input and/or output with when-stmts. Maybe... but it is a corner case, and when this happens in real data models, I suspect most of the time relative paths will be used. Maybe we should start a collection of examples of different use cases online somewhere. /martin From jmh@joelhalpern.com Thu May 28 12:52:33 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 AFFF83A6A75 for ; Thu, 28 May 2009 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 rf2t0faBcVr5 for ; Thu, 28 May 2009 12:52:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 34C903A6993 for ; Thu, 28 May 2009 12:52:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CBD00434003; Thu, 28 May 2009 12:54:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7B182434017; Thu, 28 May 2009 12:54:14 -0700 (PDT) Message-ID: <4A1EEBE3.8080803@joelhalpern.com> Date: Thu, 28 May 2009 15:54:11 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <4A1D5742.3000201@netconfcentral.com><20090527.182615.118040817.mbj@tail-f.com> <4A1D7384.6030700@netconfcentral.com> <002e01c9dfba$5639a7e0$0601a8c0@allison> In-Reply-To: <002e01c9dfba$5639a7e0$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 28 May 2009 19:52:33 -0000 I believe the intent and agreement is that there are two separate instances. The leaf of type leafref has a value. The leaf (or leaves) pointed to by the paths have their own value(s). The path selected leaf(s) define the value type of the leaf which has a type of leafref. The values of the targeted leaf(s) define the permissible values, just as a range restriction does for other types. This is not two paths pointing to the same place. It is two separate things, with a constraint relationship. For non-config data, particularly for non-config data where the path points to a single leaf, this will look like it is two paths to the same operational data. But it is still really two separate leaves. Joel tom.petch wrote: > Andy > > I like the taxonomy but struggle with two potential attributes of each case: > - whether there is a second instance created, which has an independent life > cycle as opposed to creating a second path to a single instance. > > In 1), I had assumed one instance multiple paths but Martin says not. > > - and whether the leafref has write access; in 2), I assume that the foreign > key is read only ie as a data modeller, if I have designed and specified a > key and its use, I don't want someone else coming along and changing it. > I don't doubt that you can implement multiple write but would not like to see it > on offer. > > I would like to be clearer on this before saying how many of the use cases I > would like to bin:-) > > Tom Petch > > > ----- Original Message ----- > From: "Andy Bierman" > To: "Martin Bjorklund" > Cc: > Sent: Wednesday, May 27, 2009 7:08 PM > Subject: Re: [netmod] leafref issues > > >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> I am trying to keep up with all the leafref issues, but it >>>> is difficult. Maybe we can summarize them, eliminate >>>> duplicate issues, etc. >>>> >>>> ------------------------------------------------------------------ >>>> use-case chart: >>>> >>>> 1) a read-only leafref in a notification is like an alias >>>> >>>> 2) a leafref acting as a key, and pointing at another key, >>>> is like an SQL foreign key >>>> >>>> 3) a read-only leafref acting as a leaf, and pointing at a key, >>>> is almost like a RowPointer in SNMP >>> Why is the leaf read-only in this use-case? >>> >>> IMO, the most important use-case is read-write leafref acting as key >>> or leaf, pointing to another key. (this was all the original keyref >>> type did). >> this is use-case #2 >> >>>> 4) a read-write leafref acting as a leaf, and pointing at any >>>> leaf, is like a 'MyServer' kind of config copy. Some localized >>>> config is constrained to the global config values. >>>> >>>> 5) an RPC input parameter, pointing at any database leaf, >>>> is just another form of constraint semantics. >>>> >>>> 6) vip-slot example (not sure what to call this mode.) >>>> It is not a shadow, but a secondary knob which >>>> is constrained to the values of an external non-key leaf. >>>> (RMON users might think of the 'dataSource', which is a >>>> just a column in the main table, but an INDEX in other >>>> tables.) >>>> >> module A { >> list base { >> key x; >> leaf x { type uint32; } >> leaf pointed-at { >> type instance-identifier; >> } >> } >> >> leaf a { >> type leafref { >> // is it OK to leave out the '[x=n]' key predicate? >> path "../base/pointed-at"; >> } >> >> leaf b { >> type leafref { >> path "../a"; >> } >> } >> >> >> Given this config: >> >> >> 17 >> /A:a >> >> >> 42 >> /A:b >> >> >> It is clear that leaf 'a' is allowed to contain >> the values /A:a or /A:b, and leaf 'b' is only allowed >> to contain the current value of leaf 'a'. >> >> So if the operator wants to configure an ACM rule >> to restrict read access to '/base/pointed-at', >> does that mean the operator needs to track down every single >> leafref in the system that directly or indirectly >> references '/base/pointed-at' and configure an ACM rule >> for that leaf as well? >> >> >>>> ----------------------------------------------------------------- >>>> >>>> Issues: >>>> 1) require-instance, needed or not? >> >> This sub-statement is also used in instance-identifier-specification. >> >> Will require-instance go away completely? >> >> >>>> 2) use-case 4, needed or not? >>>> 3) use-case 6, needed or not? >>> People have reported that require-instance makes leafrefs more >>> complicated. Personally, I don't see that, but we need to make >>> progress and solve this. I prefer not to, but I can live with >>> removing require-instance and also add a CLR to prevent use-case 4. >>> >> How do we distinguish #4 from #6? >> >>>> 4) behavior when pointed-at leaf is deleted >>>> (or value in leafref no longer in use)? >>> Is this an issue? It works just like a false must constraint - the >>> config becomes invalid. >> so that means the constraint is enforced at commit-time >> on candidate and edit-config-time on running. >> >>>> 5) nested lists not supported (**) >>>> >>>> ------------------------------------------------------------------ >>>> >>>> ** One issue not mentioned is that leafref is severely limited >>>> in utility because all key value pairs except the innermost layer >>>> need to be hardwired into the path expression. >>>> For example, use-case (1) is not actually supported >>>> by leafref for any nested lists, for this reason. >>> No, any depth and number of keys are supported. But in order to >>> identify a leaf, you need values for all keys on all levels. >> This is the problem for use-case #1. >> It is too clumsy in YANG to specify what SMIv2 does so easily: >> >> - specify the database object to be included in the payload >> - the payload includes the instance-identifier of the selected >> instance of the specified object, and its current value >> >> >> One >>> leaf can only hold one value, so it means you need as many leafrefs as >>> there are keys. An example from the draft: >>> >>> container default-address { >>> leaf ifname { >>> type leafref { >>> path "../../interface/name"; >>> } >>> } >>> leaf address { >>> type leafref { >>> path "../../interface[name = current()/../ifname]" >>> + "/address/ip"; >>> } >>> } >>> } >>> >>> This syntax becomes clumsy when there are more than 2-3 keys, but it >>> is possible. >>> >>> /martin >>> > >> Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From reid@snmp.com Thu May 28 13:51: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 A25463A6F36 for ; Thu, 28 May 2009 13:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 AYqPdjOM90kj for ; Thu, 28 May 2009 13:51:48 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id E77643A6927 for ; Thu, 28 May 2009 13:51:18 -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 QAA18682 for ; Thu, 28 May 2009 16:53: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 QAA20202 for ; Thu, 28 May 2009 16:53:01 -0400 (EDT) Message-Id: <200905282053.QAA20202@adminfs.snmp.com> To: netmod@ietf.org Date: Thu, 28 May 2009 16:53:01 -0400 From: David Reid Subject: [netmod] filter with selection nodes 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, 28 May 2009 20:51:54 -0000 Can I use a netconf subtree filter with selection nodes to select one leaf in a list? For example, is the following legal if ifIndex is the key: I would expect that to return all instances of ifDescr, but the yang spec says the keys have to be encoded first in a list and I didn't include the key. -David Reid From andy@netconfcentral.com Thu May 28 14:54: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 3649728C13D for ; Thu, 28 May 2009 14:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.086, 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 wAQRFZbp6UHd for ; Thu, 28 May 2009 14:54:04 -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 1E4F928B56A for ; Thu, 28 May 2009 14:54:01 -0700 (PDT) Received: (qmail 69369 invoked from network); 28 May 2009 21:55:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 28 May 2009 21:55:41 -0000 X-YMail-OSG: LcKEv5EVM1nIhdwLaAGC.My0_sV3AwMNTIfgh3KFi.2mnyBlRXHRRWkcM6UG96DnfwF3WZg5cRS3uqGeLr3n0CpU_z96hZoS1JaUtg1TFKA3vKFcFi.erMoYsc3KwhJIxUzOgOYKCbqaBJoHLXonZgIH9tDFJZl9GUjVOYPtCLUZv69PbIisB6gZWQTaKNOnAnY303E4gl6pqN3qtPaTz29h0OQOZGDfCuJAlqksF_ANguTDc7kAeeQmC445aT5ZwjYlVLijCCLkileFCRf2oZXC6kc_egWUNF2Ij9dHj9IISkTk7XtNx8MgRRBE7XqEwLVCMGPh5jWrULp2Bu1o X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1F085A.6070403@netconfcentral.com> Date: Thu, 28 May 2009 14:55:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200905282053.QAA20202@adminfs.snmp.com> In-Reply-To: <200905282053.QAA20202@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] filter with selection nodes 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, 28 May 2009 21:54:10 -0000 David Reid wrote: > Can I use a netconf subtree filter with selection nodes to select one leaf > in a list? For example, is the following legal if ifIndex is the key: > > > > > > > > > > > > > > > > I would expect that to return all instances of ifDescr, but the yang spec > says the keys have to be encoded first in a list and I didn't include the > key. > This is an area that is a bit unclear in 4741. I think it is good to always return the keys in subtree and XPath filter results, otherwise the manager does not know which ifEntries it is getting. XPath is much worse because the spec refers to a nodeset result, and NETCONF does not have any concept of nodes -- just XML subtrees starting from root. > -David Reid Andy From andy@netconfcentral.com Thu May 28 15:06: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 37F373A6FCC for ; Thu, 28 May 2009 15:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.083, 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 bSPIG2XGUe0z for ; Thu, 28 May 2009 15:06:48 -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 B785728C178 for ; Thu, 28 May 2009 15:06:38 -0700 (PDT) Received: (qmail 23943 invoked from network); 28 May 2009 22:08:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 28 May 2009 22:08:21 -0000 X-YMail-OSG: 7jjDeXgVM1ktxy2vyiZX9cShE9ao0CG4kd_tEMz696avceji7k4DJIdsR1rGWc8jP1cuFG3EFApOZrGZv4TvYHnCP0Ym7uFvvnRFgJaOCyoXHuHMYpPPaNS4vPG4TNcAus.oLHj00HjZkUv97kfgSflQQ9rbaX48hUD5uc7DG4y9JdO6pXUKQkMCNLyi3sb5Ftuj6YEVuv8HB4_tUWtsSRIL0Iwxhw3ZDa6QMbQzFSRmjZlg53BHdhqruT7NoCoUISJyUXR6MI1RKqxjiLkLCaRuuzTc5hBFurcEx80kc3PwUfcn4kTSm3ILgAU3sq63iMSKPYA0O2PRAQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1F0B3E.1020008@netconfcentral.com> Date: Thu, 28 May 2009 15:07:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1DA01A.2090809@netconfcentral.com> <20090527.233643.179592162.mbj@tail-f.com> <4A1DB814.30100@netconfcentral.com> <20090528.110555.136788297.mbj@tail-f.com> In-Reply-To: <20090528.110555.136788297.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] leafref issues 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, 28 May 2009 22:06:49 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>>>> How do we distinguish #4 from #6? >>>>> #4 is a config leafref that points to a non-key leaf. >>>>> #6 is a config leafref that points to a non-config leaf >>>>> >>>> I am strongly opposed to #6 because it requires >>>> the agent to splice non-config parts of the running config >>>> into the candidate database, to determine if the >>>> config leafref is being set to a proper instance >>>> of the the non-config leaf. >>> No, because in when a config point to a non-config, require instance >>> must be false. >>> >> but what if require-instance goes away, >> and is hard-wired to true? >> >> Will it be hard-wired to false for any leafref >> pointing at a non-config leaf? > > One reason we added require-instance was to be able to handle #6. So > if we remove require-instance, I think a config leafref MUST > refer to a config leaf, and a non-config leafref can refer to > anything. > >> This is all a bit confusing. >> It is not clear what is allowed, or what sub-statements >> are being kept, or going away, or changing again. > > Nothing has been decided yet, we're still trying to understand the > consequences of making various changes. > > If we remove require-instance, I believe we get these combinations: > > a) config leafref can refer to config leaf or key > use-case: #2 and #4 > > b) non-config leafref can refer to any config or non-config leaf or > key > use-case: #1, #3, and #5 > > > It seems we have a couple of people that want to remove > require-instance (and thus use-case #6), and a couple that can accept > this decision. Any objections to removing require-instance for > leafrefs? I'm still unclear on all the implications of removing require-instance. We should think this through carefully and remember why it was added in the first place. I finally understand use-case #6, wrt/ use-cases for pointing at state data with config data. A good example is the "favorite channels" feature built into most set-top CATV boxes. You don't get to pick the set of valid channels. That is done by the service provider. So the set of pointed-at values is read-only to you. The set of 10 favorite channels is read-write to you, but each member of the set must be one of your enabled channels. It only makes sense if require-instance=true though. BTW, there is no reason a leaf-list could not work here: leaf-list channel { type uint32 { range 1..9999; } config false; } leaf-list favorite-channel { type leafref { path /channel; } max-elements 10; } So why is leaf-list disallowed again? All instances are required to be unique. It's like pointing at a key leaf, but the rest of the list is missing ;-) > > If we remove require-instance for leafrefs, the question is if we > should also remove it for instance-identifiers. I earlier said yes, > but I have changed my mind. One example is if you have an access > control model based on instance-identifiers. Then it would be very > difficult to specify rules only for existing instances. > > The other issue is if we should add a CLR to prevent usecase #4. I am > not sure if anyone is actually proposing this, although a couple of > people have said they can accept it. Joel explcitily said he wants to > keep it. > > > /martin > > Andy From jmh@joelhalpern.com Thu May 28 15: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 911D73A6FB5 for ; Thu, 28 May 2009 15:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 REeWmPlr90cY for ; Thu, 28 May 2009 15:19:50 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 47C283A6FCF for ; Thu, 28 May 2009 15:19:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DB500434019 for ; Thu, 28 May 2009 15:21:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 61667434003 for ; Thu, 28 May 2009 15:21:33 -0700 (PDT) Message-ID: <4A1F0E6A.4050000@joelhalpern.com> Date: Thu, 28 May 2009 18:21:30 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <4A1DA01A.2090809@netconfcentral.com> <20090527.233643.179592162.mbj@tail-f.com> <4A1DB814.30100@netconfcentral.com> <20090528.110555.136788297.mbj@tail-f.com> <4A1F0B3E.1020008@netconfcentral.com> In-Reply-To: <4A1F0B3E.1020008@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] leafref issues 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, 28 May 2009 22:19:55 -0000 a) I have no problem with allowing leafrefs to point to leaf-lists. I actually thought it was allowed since it made so much sense to me. b) With regard to the example of config data pointing at state data, (in this case, favorite channel), the quesiton is what should happen if the favorite channel is no longer available. b1) If that favorite will get deleted, then a leafref may well make sense, but the operational handling requirement is hard to describe. b2) If the entry will remain, even though the channel no longer "exists", then it is not a leafref. It is a number, which corresponds to a channel iff there is one. While we could try to capture that level of semantic in the type system, it seems quite sensible to just say no. Just my personal reaction to a clear example. Joel Andy Bierman wrote: > I'm still unclear on all the implications of removing > require-instance. We should think this through carefully > and remember why it was added in the first place. > > > I finally understand use-case #6, wrt/ use-cases > for pointing at state data with config data. > > A good example is the "favorite channels" feature > built into most set-top CATV boxes. > > You don't get to pick the set of valid channels. > That is done by the service provider. So the > set of pointed-at values is read-only to you. > The set of 10 favorite channels is read-write to you, > but each member of the set must be one of your > enabled channels. > > It only makes sense if require-instance=true though. > > BTW, there is no reason a leaf-list could not work here: > > leaf-list channel { > type uint32 { range 1..9999; } > config false; > } > > leaf-list favorite-channel { > type leafref { path /channel; } > max-elements 10; > } > > > So why is leaf-list disallowed again? > All instances are required to be unique. > It's like pointing at a key leaf, but the > rest of the list is missing ;-) > ... > > Andy From andy@netconfcentral.com Thu May 28 15:53: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 9CA433A6A9D for ; Thu, 28 May 2009 15:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 pL1YDMmkxX2G for ; Thu, 28 May 2009 15:53:12 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id B8AED3A67A6 for ; Thu, 28 May 2009 15:53:12 -0700 (PDT) Received: (qmail 56326 invoked from network); 28 May 2009 22:54:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 28 May 2009 22:54:51 -0000 X-YMail-OSG: Ku54knEVM1n2RaDTQPYgVpd9LcoE8WyvMfY0znUxGtKvQP4gX6tOr7xV.A.beuEyylVlkYvA.TrWRKRtyOVxy7mbepJ6Hx5UjsgnSN_uohrtlcl45QWSB5JPBepk2TR_VuDxtMKeW6xNtBTIxX3Zc4ERph6lZ8Knk.b1GqTx2qqtt.26SFQp3g.3D.dKaVmlWrWSTkxR1vqYBqjBfLPhDsEGVEHPxIDP6T0khY9StuHlj0mwI0xFz.nf_2J5UnM3CGf.8Egyrj0EoJexpMR1Iyyh7DIrGMJ.2i7ir43Y8Hvmxba2rnqh X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1F1637.3010707@netconfcentral.com> Date: Thu, 28 May 2009 15:54:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A1DA01A.2090809@netconfcentral.com> <20090527.233643.179592162.mbj@tail-f.com> <4A1DB814.30100@netconfcentral.com> <20090528.110555.136788297.mbj@tail-f.com> <4A1F0B3E.1020008@netconfcentral.com> <4A1F0E6A.4050000@joelhalpern.com> In-Reply-To: <4A1F0E6A.4050000@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 28 May 2009 22:53:13 -0000 Joel M. Halpern wrote: > a) I have no problem with allowing leafrefs to point to leaf-lists. I > actually thought it was allowed since it made so much sense to me. > > b) With regard to the example of config data pointing at state data, (in > this case, favorite channel), the quesiton is what should happen if the > favorite channel is no longer available. > b1) If that favorite will get deleted, then a leafref may well make > sense, but the operational handling requirement is hard to describe. > b2) If the entry will remain, even though the channel no longer > "exists", then it is not a leafref. It is a number, which corresponds > to a channel iff there is one. While we could try to capture that level > of semantic in the type system, it seems quite sensible to just say no. > this is a great summary. I agree that this issue is very important to clarify in the draft. Saying that the config becomes invalid doesn't really work because it's the running config where this matters, and an invalid running config is not allowed. So in the candidate config, the constraint is not being enforced. If the operation is eventually given, then it will fail. I think solution (b1) makes the most sense, when dealing with running config. So, when is leafref:require-instance=true enforced in the running config? From an implementation POV, it is undesirable to check if any possible leafrefs changed from valid to invalid, every time some non-config node is modified or deleted. But that is what solution b1 for use-case #6 requires. That is one reason I prefer to avoid #6 completely. Requiring that all usage like #6 (config --> non-config) has to set require-instance=false seems less that useful, especially if solution b2 is used instead of b1. Might as well just declare a common typedef (ChannelNumber) and use it in both objects. There is no instance coupling, just a common type. I am in favor of removing require-instance for leafref but leaving it in place for instance-identifier. That means that use-case #6 is illegal because require-instance is going to be hard-wired to true. > Just my personal reaction to a clear example. > Joel > Andy From reid@snmp.com Thu May 28 20:37: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 AF3D23A69C3 for ; Thu, 28 May 2009 20:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 EXs5Kp-8ieJG for ; Thu, 28 May 2009 20:37:35 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 8D6553A6983 for ; Thu, 28 May 2009 20:37:35 -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 XAA09576; Thu, 28 May 2009 23:39:14 -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 XAA25373; Thu, 28 May 2009 23:39:13 -0400 (EDT) Message-Id: <200905290339.XAA25373@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Thu, 28 May 2009 14:55:38 -0700. <4A1F085A.6070403@netconfcentral.com> Date: Thu, 28 May 2009 23:39:11 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] filter with selection nodes 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, 29 May 2009 03:37:36 -0000 > David Reid wrote: > > Can I use a netconf subtree filter with selection nodes to select one leaf > > in a list? For example, is the following legal if ifIndex is the key: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would expect that to return all instances of ifDescr, but the yang spec > > says the keys have to be encoded first in a list and I didn't include the > > key. > > > > This is an area that is a bit unclear in 4741. > I think it is good to always return the keys > in subtree and XPath filter results, otherwise > the manager does not know which ifEntries it > is getting. My question is about the filter. Is the filter legal since it does not include the key in the list but the yang spec says a list must always include the keys as the first items in the list. -David Reid From per@tail-f.com Thu May 28 22:16: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 A8DFE3A6938 for ; Thu, 28 May 2009 22:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=0.455, 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 9GqIgIZdCkaz for ; Thu, 28 May 2009 22:16:19 -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 C56623A6BDB for ; Thu, 28 May 2009 22:16:03 -0700 (PDT) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mail.tail-f.com (Postfix) with ESMTPSA id AC7CE61600C; Fri, 29 May 2009 07:10:50 +0200 (CEST) Message-ID: <4A1F6E56.7050507@tail-f.com> Date: Fri, 29 May 2009 07:10:46 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Andy Bierman References: <4A1DA01A.2090809@netconfcentral.com> <20090527.233643.179592162.mbj@tail-f.com> <4A1DB814.30100@netconfcentral.com> <20090528.110555.136788297.mbj@tail-f.com> <4A1F0B3E.1020008@netconfcentral.com> In-Reply-To: <4A1F0B3E.1020008@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 29 May 2009 05:16:20 -0000 On 2009-05-29 00:07, Andy Bierman wrote: > > I finally understand use-case #6, wrt/ use-cases > for pointing at state data with config data. > > A good example is the "favorite channels" feature > built into most set-top CATV boxes. > > You don't get to pick the set of valid channels. > That is done by the service provider. So the > set of pointed-at values is read-only to you. > The set of 10 favorite channels is read-write to you, > but each member of the set must be one of your > enabled channels. > > It only makes sense if require-instance=true though. And if the service provider changes the number for one of your favorite channels, you can't watch TV at all until you update the favorite list, because the box refuses to run with an invalid configuration.:-) I agree that it's a good example, but I think it makes sense with require-instance=false - think of it as a SHOULD rather than a MUST, perhaps. --Per Hedeland From mbj@tail-f.com Thu May 28 23:33: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 917BF3A6951 for ; Thu, 28 May 2009 23:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.159, 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 HCtOU1-GaKVB for ; Thu, 28 May 2009 23:33: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 6FF313A683A for ; Thu, 28 May 2009 23:33:35 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 5BA88616017; Fri, 29 May 2009 08:35:16 +0200 (CEST) Date: Fri, 29 May 2009 08:32:30 +0200 (CEST) Message-Id: <20090529.083230.244306342.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1F085A.6070403@netconfcentral.com> References: <200905282053.QAA20202@adminfs.snmp.com> <4A1F085A.6070403@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] filter with selection nodes 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, 29 May 2009 06:33:36 -0000 Andy Bierman wrote: > David Reid wrote: > > Can I use a netconf subtree filter with selection nodes to select one leaf > > in a list? For example, is the following legal if ifIndex is the key: > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would expect that to return all instances of ifDescr, but the yang spec > > says the keys have to be encoded first in a list and I didn't include the > > key. > > > > This is an area that is a bit unclear in 4741. > I think it is good to always return the keys > in subtree and XPath filter results, otherwise > the manager does not know which ifEntries it > is getting. Absolutelty agree that this is the way is ought to work. However, the subtree filtering algorithm in 4741 is pretty clear that siblings nodes to a selection node is not included in the result. In the motivation so subtree filter it says: "The agent does not need to utilize any data-model- specific semantics during processing" Maybe 4741bis should say that additional nodes MAY be included in the result, but a generic client can never rely on this, so it better ask for the keys in the filter (which isn't that difficult anyway - if the client is prepared to read the keys from the reply, it is trivial to include them in the request.) /martin From mbj@tail-f.com Thu May 28 23:35: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 7647D3A6951 for ; Thu, 28 May 2009 23:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.152, 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 37e-HUvaMeTn for ; Thu, 28 May 2009 23:35: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 A781C3A683A for ; Thu, 28 May 2009 23:35:41 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 041D3616016; Fri, 29 May 2009 08:37:24 +0200 (CEST) Date: Fri, 29 May 2009 08:37:27 +0200 (CEST) Message-Id: <20090529.083727.183950184.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200905290339.XAA25373@adminfs.snmp.com> References: <4A1F085A.6070403@netconfcentral.com> <200905290339.XAA25373@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] filter with selection nodes 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, 29 May 2009 06:35:42 -0000 David Reid wrote: > > David Reid wrote: > > > Can I use a netconf subtree filter with selection nodes to select one leaf > > > in a list? For example, is the following legal if ifIndex is the key: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would expect that to return all instances of ifDescr, but the yang spec > > > says the keys have to be encoded first in a list and I didn't include the > > > key. > > > > > > > This is an area that is a bit unclear in 4741. > > I think it is good to always return the keys > > in subtree and XPath filter results, otherwise > > the manager does not know which ifEntries it > > is getting. > > My question is about the filter. Is the filter legal since it does not include > the key in the list but the yang spec says a list must always include the keys > as the first items in the list. Yes, the filter and result is legal. The spec says that keys are encoded first, and then all the nodes of the list. This doesn't mean that all keys and all nodes always MUST be present; nodes can be missing if you didn't select them in the filter or if you don't have access to them. /martin From mbj@tail-f.com Thu May 28 23:54: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 4AEE628C120 for ; Thu, 28 May 2009 23:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.145, 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 R3CCVjHpYiQj for ; Thu, 28 May 2009 23:54:08 -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 3C51628C116 for ; Thu, 28 May 2009 23:54:08 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 37E78616016; Fri, 29 May 2009 08:55:51 +0200 (CEST) Date: Fri, 29 May 2009 08:55:47 +0200 (CEST) Message-Id: <20090529.085547.141023419.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1F1637.3010707@netconfcentral.com> References: <4A1F0B3E.1020008@netconfcentral.com> <4A1F0E6A.4050000@joelhalpern.com> <4A1F1637.3010707@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] leafref issues 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, 29 May 2009 06:54:09 -0000 Andy Bierman wrote: > Joel M. Halpern wrote: > > a) I have no problem with allowing leafrefs to point to leaf-lists. I > > actually thought it was allowed since it made so much sense to me. I agree. At first we just had keyref, but when we generalized into leafref, we should have thought about this. Ok, we just need to make sure this is captured in the text (withouth making the text even more complex...) > > b) With regard to the example of config data pointing at state data, (in this > > case, favorite channel), the quesiton is what should happen if the favorite > > channel is no longer available. > > b1) If that favorite will get deleted, then a leafref may well make sense, > > but the operational handling requirement is hard to describe. > > b2) If the entry will remain, even though the channel no longer "exists", > > then it is not a leafref. It is a number, which corresponds to a channel iff > > there is one. While we could try to capture that level of semantic in the > > type system, it seems quite sensible to just say no. > > > > this is a great summary. > I agree that this issue is very important to clarify > in the draft. Saying that the config becomes invalid > doesn't really work because it's the running config > where this matters, and an invalid running config is > not allowed. But this is the very reason for specifying this with require-instance=false! If you do that, your system continues to work when your service provider deletes a channel to which you pointed. When looking at the datamodel, it is very clear that the favorite list is a pointing into the channels list. So having require-instance=false makes this a much clearer datamodel, IMO. The alternative woould be: leaf-list channel { type uint32 { range 1..9999; } config false; } leaf-list favorite-channel { type uint32 { range 1..9999; } max-elements 10; description "A number in this leaf-lists refers to an entry in the '/channel' list, if it exists. If it doesn't exist in the channel list, then the favorite channel is unvailable."; } So, w/o require-instance=false, people will have to catch this semantics in the description clause. /martin From andy@netconfcentral.com Fri May 29 00:45: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 3583628C15C for ; Fri, 29 May 2009 00:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 d+4t1GKDbVQh for ; Fri, 29 May 2009 00:45:28 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 2C16928C15B for ; Fri, 29 May 2009 00:45:28 -0700 (PDT) Received: (qmail 45827 invoked from network); 29 May 2009 07:47:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 29 May 2009 07:47:09 -0000 X-YMail-OSG: Am0u_UYVM1mQEBX9emm.yi9DX.0gUMg54GGj7xSRN5VRnIso3GBh.1VUdMAeItCzr6VqpQNxbAyHc7YEJONP.nQT0uy3oy9bYNC6a7JHSm51XGj2KiFOa__hJFIpmUSPqVuYI.LC_vLSw5B1ANDQo7iFHeoyMkA02N_6g8Xf54NoCtno.2M2Cl.DoOFpXPheG7yQ5AmVXyTQN2iVE9yILHaMVYWUBScZJhx3AYc1JbYsj9IKn_XnwEVCsZLCJuMxEjXrs2MLpxMMgc1BM_qBrML8qz1T0l1BoJ4gI3XlVkpa4yC1Jotz6fMBp_T0AA8TYtc1pZpjt39E5Chs2lbd X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1F92FA.40401@netconfcentral.com> Date: Fri, 29 May 2009 00:47:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200905290339.XAA25373@adminfs.snmp.com> In-Reply-To: <200905290339.XAA25373@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] filter with selection nodes 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, 29 May 2009 07:45:29 -0000 David Reid wrote: >> David Reid wrote: >>> Can I use a netconf subtree filter with selection nodes to select one leaf >>> in a list? For example, is the following legal if ifIndex is the key: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I would expect that to return all instances of ifDescr, but the yang spec >>> says the keys have to be encoded first in a list and I didn't include the >>> key. >>> >> This is an area that is a bit unclear in 4741. >> I think it is good to always return the keys >> in subtree and XPath filter results, otherwise >> the manager does not know which ifEntries it >> is getting. > > My question is about the filter. Is the filter legal since it does not include > the key in the list but the yang spec says a list must always include the keys > as the first items in the list. > The filter element is 'anyxml', so none of the encoding rules for lists actually apply to it. > -David Reid > > Andy From andy@netconfcentral.com Fri May 29 00:48: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 5F6DE28C116 for ; Fri, 29 May 2009 00:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.063, 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 xpUlK2DOT9Z0 for ; Fri, 29 May 2009 00:48:30 -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 C1E2D3A6E63 for ; Fri, 29 May 2009 00:48:30 -0700 (PDT) Received: (qmail 63076 invoked from network); 29 May 2009 07:50:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 29 May 2009 07:50:11 -0000 X-YMail-OSG: CgJPg_UVM1mup5NtEcM_JLLsiwrlExIuyYJ4MSkNxLnyJZhgADRfJbbQ6jvfVwFewjq20PoxfUIKhYRzh9fIebGFMYqjj76.cIwVKjYQhFj576CXCmu..CeZCsQhbAYL951uEZ8hkr2qaTFcEsFT_e89jwmXbgNAnmlXg.2KN_jQ4yHDKOmPh.FwvFCJV5FGxd54PO_IDAaz3KDJBWv_OkngbHXbUAXkKOOuRb10wazTMh9kTkjFRTNkLTAfP5mGTZSzrjKbuWeqOrajAxPul9fun.YbeNH2VTPyGRoaBmaRPUULWCOo X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1F93B1.1040909@netconfcentral.com> Date: Fri, 29 May 2009 00:50:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Per Hedeland References: <4A1DA01A.2090809@netconfcentral.com> <20090527.233643.179592162.mbj@tail-f.com> <4A1DB814.30100@netconfcentral.com> <20090528.110555.136788297.mbj@tail-f.com> <4A1F0B3E.1020008@netconfcentral.com> <4A1F6E56.7050507@tail-f.com> In-Reply-To: <4A1F6E56.7050507@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 29 May 2009 07:48:31 -0000 Per Hedeland wrote: > On 2009-05-29 00:07, Andy Bierman wrote: >> I finally understand use-case #6, wrt/ use-cases >> for pointing at state data with config data. >> >> A good example is the "favorite channels" feature >> built into most set-top CATV boxes. >> >> You don't get to pick the set of valid channels. >> That is done by the service provider. So the >> set of pointed-at values is read-only to you. >> The set of 10 favorite channels is read-write to you, >> but each member of the set must be one of your >> enabled channels. >> >> It only makes sense if require-instance=true though. > > And if the service provider changes the number for one of your favorite > channels, you can't watch TV at all until you update the favorite list, > because the box refuses to run with an invalid configuration.:-) I agree > that it's a good example, but I think it makes sense with > require-instance=false - think of it as a SHOULD rather than a MUST, > perhaps. > No -- If the agent uses the delete-dead-leafref behavior, then the invalid config is deleted immediately, IMO, the leafref datatype should be used for situations that require a real coupling of instances, not merely using the same data type. > --Per Hedeland > > Andy From mbj@tail-f.com Fri May 29 01:28: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 B01AB3A6E68 for ; Fri, 29 May 2009 01:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.139, 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 Y9q2vs+8wvja for ; Fri, 29 May 2009 01:28:26 -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 33BA43A6A97 for ; Fri, 29 May 2009 01:28:25 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 68F72616016; Fri, 29 May 2009 10:30:02 +0200 (CEST) Date: Fri, 29 May 2009 10:30:04 +0200 (CEST) Message-Id: <20090529.103004.12049218.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1F93B1.1040909@netconfcentral.com> References: <4A1F0B3E.1020008@netconfcentral.com> <4A1F6E56.7050507@tail-f.com> <4A1F93B1.1040909@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] leafref issues 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, 29 May 2009 08:28:30 -0000 Andy Bierman wrote: > IMO, the leafref datatype should be used for situations > that require a real coupling of instances, not merely using > the same data type. So, should it be removed also from notifications? In your channels example, these *is* a coupling. The channels and favorite lists do not just by accident use the same datatype. /martin From per@tail-f.com Fri May 29 01:48: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 D8F2A3A6A9B for ; Fri, 29 May 2009 01:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-0.230, 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 XTk6--pafOkM for ; Fri, 29 May 2009 01:48: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 ED3F63A6A19 for ; Fri, 29 May 2009 01:48:15 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1615A616016; Fri, 29 May 2009 10:49:59 +0200 (CEST) Message-ID: <4A1FA1B6.2090309@tail-f.com> Date: Fri, 29 May 2009 10:49:58 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Andy Bierman References: <4A1DA01A.2090809@netconfcentral.com> <20090527.233643.179592162.mbj@tail-f.com> <4A1DB814.30100@netconfcentral.com> <20090528.110555.136788297.mbj@tail-f.com> <4A1F0B3E.1020008@netconfcentral.com> <4A1F6E56.7050507@tail-f.com> <4A1F93B1.1040909@netconfcentral.com> In-Reply-To: <4A1F93B1.1040909@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 29 May 2009 08:48:16 -0000 On 05/29/09 09:50, Andy Bierman wrote: > Per Hedeland wrote: >> On 2009-05-29 00:07, Andy Bierman wrote: >>> I finally understand use-case #6, wrt/ use-cases >>> for pointing at state data with config data. >>> >>> A good example is the "favorite channels" feature >>> built into most set-top CATV boxes. >>> >>> You don't get to pick the set of valid channels. >>> That is done by the service provider. So the >>> set of pointed-at values is read-only to you. >>> The set of 10 favorite channels is read-write to you, >>> but each member of the set must be one of your >>> enabled channels. >>> >>> It only makes sense if require-instance=true though. >> >> And if the service provider changes the number for one of your favorite >> channels, you can't watch TV at all until you update the favorite list, >> because the box refuses to run with an invalid configuration.:-) I agree >> that it's a good example, but I think it makes sense with >> require-instance=false - think of it as a SHOULD rather than a MUST, >> perhaps. >> > > No -- If the agent uses the delete-dead-leafref behavior, > then the invalid config is deleted immediately, Is such a behavior even being considered? To me it seems like a bizarre idea that the type of a leaf could imply automatic deletion from the configuration. If a config leafref's require-instance=true is not satisfied, it means that the configuration is invalid, just as if the value of an integer is out of range - you wouldn't automatically modify such an integer value to fall within the closest range... --Per From lhotka@cesnet.cz Fri May 29 05:20: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 6D6BE3A6E22 for ; Fri, 29 May 2009 05:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=-0.377, 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 mHIObFyr32a1 for ; Fri, 29 May 2009 05:20:21 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 998E23A6CA1 for ; Fri, 29 May 2009 05:20:21 -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 66675D800E8; Fri, 29 May 2009 14:21:34 +0200 (CEST) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <002d01c9dfba$55470a80$0601a8c0@allison> References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <006901c9df6a$149e0ec0$0601a8c0@allison> <20090528.115655.03590098.mbj@tail-f.com> <002d01c9dfba$55470a80$0601a8c0@allison> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 29 May 2009 14:21:34 +0200 Message-Id: <1243599694.7849.26.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath issues 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, 29 May 2009 12:20:22 -0000 tom.petch píše v Čt 28. 05. 2009 v 18:42 +0200: > > > > > > 'augment', 'path', 'instance identifier' cover none of this. > > > > > > Why the difference? > > > > Ladislav pointed this out as well. Specifically, he wanted this spec > > for 'path'. > > Ah, I missed that; I would like it for all three, or else a note as > to why this is not an issue. I think that namespaces is the aspect I cannot > readily work out (import/include/uses/augments ...etc) The context is quite clear for "augment", but the document is the corresponding schema tree, unlike the other uses of XPath. I was thinking about 'path' under 'leafref' and IMO the accessible tree should be the main data tree. Are there any use cases for, say, a leafref in RPC output referring to a leaf inside the same RPC output tree? I am not sure about instance identifier, for me it's quite an exotic data type. > > > > Can some of this be in 6.4, eg on function library, if it > > > is common to all use cases of XPath? > > > > The function library is common to all use cases which allow > > functions (must and when). Note that augment, path and > > instance-identifier all have a very restricted form of XPath where > > functions and variables cannot appear. > > > > Well, to be picky, path allows the current() function. I don't think current() is allowed in those three cases. On the other hand, I am wondering about other XPath constructs that seem to be legal e.g. in the 'path' argument, for instance "foo//bar". I think this should be banned, too, such a 'leafref' would be really mindboggling. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Fri May 29 06: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 DD30D3A6DAA for ; Fri, 29 May 2009 06:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 6xf54+NxOlGT for ; Fri, 29 May 2009 06:29:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 017FB3A6CBC for ; Fri, 29 May 2009 06:29:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8653F43024A for ; Fri, 29 May 2009 06:30:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 1003F43014A for ; Fri, 29 May 2009 06:30:36 -0700 (PDT) Message-ID: <4A1FE379.6010609@joelhalpern.com> Date: Fri, 29 May 2009 09:30:33 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org References: <4A1F0B3E.1020008@netconfcentral.com> <4A1F6E56.7050507@tail-f.com> <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> In-Reply-To: <20090529.103004.12049218.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] leafref issues 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, 29 May 2009 13:29:55 -0000 It does not look like a leafref to the available channels to me. If you want to view it as a leafref, it is a leafref to the list of all offered channels from the operator, including all currently unpaid for premiums, etc. And if someone has a "favorite" on that list, you might as well delete it, because it is gone. I think we get a much simpler conceptual model, that covers the cases correctly, if we just use leafref for the cases when the values are coupled (which includes notifications.) Leafref with require-instance=false is just a type alias. It is not a value restriction. Displaying the leaf as "pointing-to" some range of other leafs is actually misleading, since its value space is not limited. It is as if we included a "typical" option in a range statement to say that the range restriction was not mandatory, only advisory (maybe the GUI should highlight it if it is outside the "typical" range".) Yours, Joel Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO, the leafref datatype should be used for situations >> that require a real coupling of instances, not merely using >> the same data type. > > So, should it be removed also from notifications? > > > In your channels example, these *is* a coupling. The channels and > favorite lists do not just by accident use the same datatype. > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Fri May 29 07:03: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 6B69A3A6C5E for ; Fri, 29 May 2009 07:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 Br8COLIzrFoF for ; Fri, 29 May 2009 07:03:49 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 76A7D3A692C for ; Fri, 29 May 2009 07:03:49 -0700 (PDT) Received: (qmail 12085 invoked from network); 29 May 2009 14:04:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 29 May 2009 14:04:58 -0000 X-YMail-OSG: 8CkbDj0VM1kkWzQtATNC5k7k89LBzlydBChkKcHesHKt80UyGc_FhraCCbmP3VrnRwmqjKz0fkEFYMIoDYXPcL9QLM35ZkBW3YgnSb5AwrfqaszXFFYFo0pgPfWkJKSne4xikFlBelXY8M2nPK1jxzFpigynKwP_7KDfXQ7f2wB7dSjJhiPjmyczYI18mRMgJ5NfzNC5gEqLl49Xqp_EBHA0DeHllLGts3maWwINEyq43fVCuVmwxWvdu5dzKQTTO4uL_o22K_1dq5Vm X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1FEB87.8000304@netconfcentral.com> Date: Fri, 29 May 2009 07:04:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A1F0B3E.1020008@netconfcentral.com> <4A1F6E56.7050507@tail-f.com> <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FE379.6010609@joelhalpern.com> In-Reply-To: <4A1FE379.6010609@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 29 May 2009 14:03:50 -0000 Joel M. Halpern wrote: > It does not look like a leafref to the available channels to me. > If you want to view it as a leafref, it is a leafref to the list of all > offered channels from the operator, including all currently unpaid for > premiums, etc. And if someone has a "favorite" on that list, you might > as well delete it, because it is gone. > > I think we get a much simpler conceptual model, that covers the cases > correctly, if we just use leafref for the cases when the values are > coupled (which includes notifications.) > Seems like require-instance should always be true for notifications. You are reporting on a database node (or about-to-be-deleted node), so it makes sense to report only real instances. > Leafref with require-instance=false is just a type alias. It is not a > value restriction. Displaying the leaf as "pointing-to" some range of > other leafs is actually misleading, since its value space is not > limited. It is as if we included a "typical" option in a range > statement to say that the range restriction was not mandatory, only > advisory (maybe the GUI should highlight it if it is outside the > "typical" range".) > I agree with this concern about require-instance=false. At the interim, I also raised the concern about forcing the YANG reader (our highest priority) to read XPath expressions and track down the correct version of the module containing the pointed-at leaf, just to see its data type. > Yours, > Joel Andy From andy@netconfcentral.com Fri May 29 07:27: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 949C83A6F73 for ; Fri, 29 May 2009 07:27:45 -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 gc1OyFrcIthU for ; Fri, 29 May 2009 07:27:44 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id B0D3B3A6B60 for ; Fri, 29 May 2009 07:27:44 -0700 (PDT) Received: (qmail 88417 invoked from network); 29 May 2009 14:28:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 29 May 2009 14:28:54 -0000 X-YMail-OSG: iNgZNiwVM1neVqy9rjzaYsSFx4.gWJNP_dG5UJnx.6LVOZloO7ykP2DC3_VFKaAnPyLydTJ4uv6PvdZv_2d2Lx1ZJhcMgs7VTHkHiH7JdqiH1d75smjD0c7vtIwADJ_.4Ss00XDMEUZ.nvu78lQUakOBeICUWX9QUoZsEZdNH7QV6M1hbLqEPpP7ntD.cAnzoNLmPb1zIFj11cbg9toAAujWJ.EuZcsBuuWuoDDt9DSwyv.ZFBNefV6rC1lxAxRi3LxKlaSodzJ9dE6yQvwbbHzjzWx2fgB.GDhlJV9YEhRJMkn3dPE9wrDYV_g5919AarAG5LvByuKpWQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1FF122.8000304@netconfcentral.com> Date: Fri, 29 May 2009 07:28:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1F0B3E.1020008@netconfcentral.com> <4A1F6E56.7050507@tail-f.com> <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> In-Reply-To: <20090529.103004.12049218.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] leafref issues 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, 29 May 2009 14:27:45 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO, the leafref datatype should be used for situations >> that require a real coupling of instances, not merely using >> the same data type. > > So, should it be removed also from notifications? > > Notifications in NETCONF/YANG are rather limited and unless the WG(s) do something to fix them, it isn't really worth worrying about. A 'useful' notification will need to include all the keys from the relevant entries, as well as some data selected from these entries. Since leafref just returns the value of the pointed-at node with no indication of the actual instance selected, it is not very useful for notifications. > In your channels example, these *is* a coupling. The channels and > favorite lists do not just by accident use the same datatype. > But you could say this about any 2 leafs that happen to use the same derived data type. > > > /martin > > > Andy From simon.leinen@switch.ch Fri May 29 08:32: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 3CA193A6A5D; Fri, 29 May 2009 08:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, 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 uzCyOxqqM5DC; Fri, 29 May 2009 08:32:42 -0700 (PDT) Received: from diotima.switch.ch (diotima.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d751]) by core3.amsl.com (Postfix) with ESMTP id E78083A6906; Fri, 29 May 2009 08:32:40 -0700 (PDT) Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.3+Sun/8.14.3) with ESMTP id n4TFYIcv000962; Fri, 29 May 2009 17:34:18 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.14.3+Sun/8.14.3/Submit) id n4TFYIwf000961; Fri, 29 May 2009 17:34:18 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: "A. Gregory Rabil" In-Reply-To: (A. Gregory Rabil's message of "Tue, 26 May 2009 16:58:57 -0400") References: <20090526.213904.79416403.mbj@tail-f.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (usg-unix-v) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Fri, 29 May 2009 17:34:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] draft-rabil-dhc-dhcpv6-xmlconfig-00.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: Fri, 29 May 2009 15:32:43 -0000 > I would consider converting my draft to one that uses YANG, if you > believe that there would be interest from the NETCONF/NETMOD community > for me to do so. I would also be interested in this, for two reasons: As an operator who is likely to configure DHCPv6 servers in the future (we configure DHCPv4 servers, but currently use SAAC without DHCP for IPv6), and on the other hand because I'd like to hear about your experiences as a "domain expert" with YANG, e.g., learning curve & how happy you'll be with the resulting YANG formulation of your configuration model. -- Simon. From balazs.lengyel@ericsson.com Fri May 29 09:53: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 975C23A686D for ; Fri, 29 May 2009 09:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.127, 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 Mtvt+10p9wdn for ; Fri, 29 May 2009 09:53:34 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 369C13A67FF for ; Fri, 29 May 2009 09:53:34 -0700 (PDT) X-AuditID: c1b4fb3c-b7b28ae000005484-a8-4a20079b91db Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 21.3F.21636.B97002A4; Fri, 29 May 2009 18:04:43 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 18:04:41 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 18:04:41 +0200 Message-ID: <4A200799.7070501@ericsson.com> Date: Fri, 29 May 2009 18:04:41 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group References: <4A1D5742.3000201@netconfcentral.com> In-Reply-To: <4A1D5742.3000201@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2009 16:04:41.0570 (UTC) FILETIME=[2CE4EC20:01C9E077] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] leafref issues 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, 29 May 2009 16:53:35 -0000 Hello, One reason why leafref is so complex is that it is overloaded. 6 different use-cases are IMHO too many for a single construct. I would strongly vote for keeping require-instance on instance-identifier. I see the use of it and it is an easily understandable concept. I much liked Andy's idea about varbinds, because its a clean and simple solution for use-case 1. I am strongly against automatically deleting leafrefs. What if it is a mandatory leaf or part of a leaf-list with min-elements > 0 or part of a mandatory choice, or if a must checks it's existence, or if a when references it? I also liked Martin's proposal: require-instance hardwired to true if leafref referres to a config leaf, otherwise hardwired to false. About documentation: I was very much missing the following from the text: - The leafref and the referred to leaf/leaf-list have separate values. - The aim of the leafref is to document the semantic connection between the leafref and the referred to leaf AND to constrain the allowed values of the leafref to a set defined by the referred to leafs/leaf-lists. Balazs Andy Bierman wrote: > Hi, > > I am trying to keep up with all the leafref issues, but it > is difficult. Maybe we can summarize them, eliminate > duplicate issues, etc. > > ------------------------------------------------------------------ > use-case chart: > > 1) a read-only leafref in a notification is like an alias > > 2) a leafref acting as a key, and pointing at another key, > is like an SQL foreign key > > 3) a read-only leafref acting as a leaf, and pointing at a key, > is almost like a RowPointer in SNMP > > 4) a read-write leafref acting as a leaf, and pointing at any > leaf, is like a 'MyServer' kind of config copy. Some localized > config is constrained to the global config values. > > 5) an RPC input parameter, pointing at any database leaf, > is just another form of constraint semantics. > > 6) vip-slot example (not sure what to call this mode.) > It is not a shadow, but a secondary knob which > is constrained to the values of an external non-key leaf. > (RMON users might think of the 'dataSource', which is a > just a column in the main table, but an INDEX in other > tables.) > > ----------------------------------------------------------------- > > Issues: > 1) require-instance, needed or not? > 2) use-case 4, needed or not? > 3) use-case 6, needed or not? > 4) behavior when pointed-at leaf is deleted > (or value in leafref no longer in use)? > 5) nested lists not supported (**) > > ------------------------------------------------------------------ > > ** One issue not mentioned is that leafref is severely limited > in utility because all key value pairs except the innermost layer > need to be hardwired into the path expression. > For example, use-case (1) is not actually supported > by leafref for any nested lists, for this reason. > > > For notifications, the only thing that will really work > is a varbind list: > > list varbind { > config false; > > leaf name { > description > "Identifies the leaf in the running database > associated with this variable binding."; > type instance-identifier; > mandatory true; > } > > leaf value { > description > "Contains the value of the leaf instance identified > by the associated name field. This field will > not be present if the variable binding has no value, > e.g., built-in type is 'empty'."; > > // could be union of all built-in types or just > // the string representation of the canonical encoding > type string; > } > } > > > > > Andy > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Fri May 29 10:40: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 1865B3A6E05 for ; Fri, 29 May 2009 10:40:16 -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.253, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=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 s-kh8fKBsknJ for ; Fri, 29 May 2009 10:40:15 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 337223A6A20 for ; Fri, 29 May 2009 10:40:15 -0700 (PDT) Received: (qmail 46436 invoked from network); 29 May 2009 17:41:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 29 May 2009 17:41:10 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A201E34.2090103@netconfcentral.com> Date: Fri, 29 May 2009 10:41:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <4A1D5742.3000201@netconfcentral.com><20090527.182615.118040817.mbj@tail-f.com><006901c9df6a$149e0ec0$0601a8c0@allison> <20090528.115655.03590098.mbj@tail-f.com> <002d01c9dfba$55470a80$0601a8c0@allison> In-Reply-To: <002d01c9dfba$55470a80$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath issues 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, 29 May 2009 17:40:16 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: ; ; > Sent: Thursday, May 28, 2009 11:56 AM >> "tom.petch" wrote: >>> XPath appears in 'must' (7.5.3), 'augment' (7.15), 'when' (7.19.5), 'path' >>> (9.9.2), 'instance-identifier' (9.13) and 6.4 but is not treated > consistently. >>> XPath needs a context - node, position, size, variable bindings, function >>> library and namespace declarations - and, since this is not a document, a >>> specification of the XPath root node. >>> >>> 6.4 says something about context node and namespaces >>> >>> 'must' and 'when' cover context node, function library, namespace > declarations, >>> XPath root node. >>> >>> 'augment', 'path', 'instance identifier' cover none of this. >>> >>> Why the difference? >> Ladislav pointed this out as well. Specifically, he wanted this spec >> for 'path'. > > Ah, I missed that; I would like it for all three, or else a note as > to why this is not an issue. I think that namespaces is the aspect I cannot > readily work out (import/include/uses/augments ...etc) Remember that the target strings used in augment, refine, and deviation statements are all schema-nodeid strings and they must include choice and case nodes in the string. The identify a node in the object tree. The path-stmt in a leafref identifies one or more conceptual nodes in the value tree, so there are no choice or case nodes and there can be predicates for list keys. The value of an instance-identifier is an absolute path expression representing one conceptual node in the value tree. The prefixes are relative, so comparing instance-identifiers is an implementation detail, i.e., not strcmp(). I find it much easier to conceptualize YANG by thinking of how it would be implemented. Imagine a tree of all available objects (rpc, notification, data-def-stmt). Then imagine another 'mirror' tree, with zero or more instances of each object node. It isn't really necessary to copy all the YANG defaults into the value tree, so some implementations don't. (That's why we need with-defaults.) The value tree doesn't have any config=false nodes in it, but the object tree has them, so implementing require-instance=false only requires some special code -- just a major XPath implementation requirement to process the internal object tree, not some XML instance document. It would be really inefficient to process XPath by creating an XML document, so it is more likely the value tree will be processed directly anyway. Then there is the issue of deleting invalid config leafrefs when the non-config pointed-at leaf changes value. This is a problem for implementors. I was thinking it was OK to leave the invalid config leafref in , but what about ? Either direct via or indirect via mirroring, the invalid leafref will end up in the config, causing a problem later. Removing the leafref may cause more problems than leaving it there, due to must, when, mandatory, min-elements statements. IMO, config leafrefs are not very important to have, except as foreign keys. But the problem doesn't go away for foreign keys, so might as well support #4. SMIv2 can have simple INDEX clause because all the leaf names must be unique. YANG would need to specify the schema path as follows: container interfaces { list interface { key name; leaf name { ... } leaf ifIndex { // what to do about read-only ifIndex? // should that be supported? IMO, no } ... } } list oldIfEntry { key "/interfaces/interface/ifIndex"; // no leaf-stmt for ifIndex leaf foo {} } list extOldIfEntry { key "/interfaces/interface/ifIndex localIndex"; // no leaf-stmt for ifIndex leaf localIndex {} leaf foo {} } Note how a local key is also a valid path expression, consistent with the foreign keys? IMO, this would eliminate the need for config leafrefs, and it is more direct. The SMIv2 'copy-fooIndex" approach is too cut-and-paste. If you want a foreign key, then it should be specified in the key-stmt. Mixing foreign and local keys from the same namespace would require some name collision checking, but the YANG compiler does that already. >... > Tom Petch >> /martin > > > Andy From mbj@tail-f.com Fri May 29 10:47: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 1AC6D3A6C27 for ; Fri, 29 May 2009 10:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 6naWxqaOcCR6 for ; Fri, 29 May 2009 10:47:09 -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 469CC3A6A20 for ; Fri, 29 May 2009 10:47:09 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 693EE61600B; Fri, 29 May 2009 19:48:16 +0200 (CEST) Date: Fri, 29 May 2009 19:48:15 +0200 (CEST) Message-Id: <20090529.194815.74630685.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A1FF122.8000304@netconfcentral.com> References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@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] leafref issues 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, 29 May 2009 17:47:10 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> IMO, the leafref datatype should be used for situations > >> that require a real coupling of instances, not merely using > >> the same data type. > > So, should it be removed also from notifications? > > > > Notifications in NETCONF/YANG are rather limited and > unless the WG(s) do something to fix them, > it isn't really worth worrying about. > > A 'useful' notification will need to include > all the keys from the relevant entries, as > well as some data selected from these entries. > > Since leafref just returns the value of the pointed-at node > with no indication of the actual instance selected, > it is not very useful for notifications. We changed keyref to leafref mainly for supporting leafref in notifications. If you think we don't need to worry about notifications, can we change leafref back to keyref? > > In your channels example, these *is* a coupling. The channels and > > favorite lists do not just by accident use the same datatype. > > > > But you could say this about any 2 leafs that happen > to use the same derived data type. ? Are you suggesting that two leafs in this example are just as coupled as favorite and channel in your example? If so, I am confused. typedef AdminString { type string { ... } } leaf sys-name { type AdminString; } leaf entity-name { type AdminString; } /martin From andy@netconfcentral.com Fri May 29 10:51: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 107E53A6C75 for ; Fri, 29 May 2009 10:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 2o6W+MvhT5qS for ; Fri, 29 May 2009 10:51:30 -0700 (PDT) Received: from n15b.bullet.mail.mud.yahoo.com (n15b.bullet.mail.mud.yahoo.com [68.142.207.236]) by core3.amsl.com (Postfix) with SMTP id 548893A6C81 for ; Fri, 29 May 2009 10:51:07 -0700 (PDT) Received: from [68.142.200.225] by n15.bullet.mail.mud.yahoo.com with NNFMP; 29 May 2009 17:51:48 -0000 Received: from [68.142.201.70] by t6.bullet.mud.yahoo.com with NNFMP; 29 May 2009 17:51:48 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 29 May 2009 17:51:48 -0000 X-Yahoo-Newman-Id: 280691.70598.bm@omp422.mail.mud.yahoo.com Received: (qmail 8782 invoked from network); 29 May 2009 17:51:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 29 May 2009 17:51:47 -0000 X-YMail-OSG: .4b8wQMVM1mTMEMDpbt7UQY7oQlqjpWdvuPeuL.7A7z4VArLA6djH_js2m8g4rfhBDVmPM4iOJlIKMTwzb.RW3Kf41CurgpjjuwmVoeW6_Z2qQRKyP4ffPWmYv4SgxTTvBrfO7Nc.lfp7bVEH7JMdqU429GZnHNS.tewAX5DKYgMgE_fUcjY33cJFs7B4RUPg3VdvtezwPaEaHBxbcMG9ERPkEY0ulgpul_nAB3xbnaZWaPmh5Vek3vZiemkzG4Aeq_kJIKYye6ZyZ0vQmI2VMlHSEbEFqiLLgauKYm9GhQRslb_U0QM X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A20209C.60204@netconfcentral.com> Date: Fri, 29 May 2009 10:51:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <4A1D5742.3000201@netconfcentral.com><20090527.182615.118040817.mbj@tail-f.com><006901c9df6a$149e0ec0$0601a8c0@allison> <20090528.115655.03590098.mbj@tail-f.com> <002d01c9dfba$55470a80$0601a8c0@allison> <4A201E34.2090103@netconfcentral.com> In-Reply-To: <4A201E34.2090103@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath issues 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, 29 May 2009 17:51:31 -0000 Andy Bierman wrote: > tom.petch wrote: ..... > SMIv2 can have simple INDEX clause because all the leaf names > must be unique. YANG would need to specify the schema path > as follows: > > container interfaces { > list interface { oops -- forgot that ifIndex needs a unique-stmt: unique ifIndex; > key name; > leaf name { ... } > leaf ifIndex { > // what to do about read-only ifIndex? > // should that be supported? IMO, no > } > ... > } > } > > list oldIfEntry { > key "/interfaces/interface/ifIndex"; > // no leaf-stmt for ifIndex > leaf foo {} > } > > list extOldIfEntry { > key "/interfaces/interface/ifIndex localIndex"; > // no leaf-stmt for ifIndex > leaf localIndex {} > leaf foo {} > } > Andy From jmh@joelhalpern.com Fri May 29 10:55: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 45B843A6D1F for ; Fri, 29 May 2009 10:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 okKL-t79vdz0 for ; Fri, 29 May 2009 10:55:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 705973A6C9F for ; Fri, 29 May 2009 10:55:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 348B9430424; Fri, 29 May 2009 10:55:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 413BA4303F1; Fri, 29 May 2009 10:55:58 -0700 (PDT) Message-ID: <4A2021A9.1050103@joelhalpern.com> Date: Fri, 29 May 2009 13:55:53 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> In-Reply-To: <20090529.194815.74630685.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] leafref issues 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, 29 May 2009 17:55:22 -0000 While there is some semantic information in a config leaf whose type is a leafref with require-instance=false, it is a very small amount of information. It will allow a few uses, but usually won't allow what an NMW would like (for example, it will not allow the nms to provide a list of valid values to the user.) It seems a complication with little actual use. Real semantics is always in the description clause anyway. Joel Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> IMO, the leafref datatype should be used for situations >>>> that require a real coupling of instances, not merely using >>>> the same data type. >>> So, should it be removed also from notifications? >>> >> Notifications in NETCONF/YANG are rather limited and >> unless the WG(s) do something to fix them, >> it isn't really worth worrying about. >> >> A 'useful' notification will need to include >> all the keys from the relevant entries, as >> well as some data selected from these entries. >> >> Since leafref just returns the value of the pointed-at node >> with no indication of the actual instance selected, >> it is not very useful for notifications. > > We changed keyref to leafref mainly for supporting leafref in > notifications. If you think we don't need to worry about > notifications, can we change leafref back to keyref? > >>> In your channels example, these *is* a coupling. The channels and >>> favorite lists do not just by accident use the same datatype. >>> >> But you could say this about any 2 leafs that happen >> to use the same derived data type. > > ? > > Are you suggesting that two leafs in this example are just as > coupled as favorite and channel in your example? If so, I am > confused. > > typedef AdminString { > type string { ... } > } > > leaf sys-name { > type AdminString; > } > leaf entity-name { > type AdminString; > } > > > > /martin > > > > > > > > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Fri May 29 11:04: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 91F2B3A6E34 for ; Fri, 29 May 2009 11:04:00 -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 JXBrNcE-72rJ for ; Fri, 29 May 2009 11:03:59 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id A44A13A6A6B for ; Fri, 29 May 2009 11:03:59 -0700 (PDT) Received: (qmail 90266 invoked from network); 29 May 2009 18:05:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 29 May 2009 18:05:06 -0000 X-YMail-OSG: 0UHZQ5kVM1k2PXTA_WQizleBTaUXbbZA4zdDeBPZGxg_FxpV8qBuqH4dsVSGzbGyEClmNA3xN6Twb5Z9d7mC1bBAnkq3htcCBlyJJ4aOU40nq0keisXVF9M1M1M7hAkP6SgHLJ.GeT6DCKYLNiGmbZTPclCgDX247Mh_txmawF4bsL2UmIAxpJHRQRnI1CTaIZnlEmRZ5kNdfQj3QmfOkwEE6Yrb8Sau5o6JxKkaDfsBQNq5tvUdxv8_Jv8KJm1ltVcQCaqjt.O9KeSPbUXoyuaTK7sjceunt2IimChUL2ot_xR3Fps.Hfp41braASTJvcsY_RJKyRdlcA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A2023CF.30105@netconfcentral.com> Date: Fri, 29 May 2009 11:05:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> In-Reply-To: <20090529.194815.74630685.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] leafref issues 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, 29 May 2009 18:04:00 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> IMO, the leafref datatype should be used for situations >>>> that require a real coupling of instances, not merely using >>>> the same data type. >>> So, should it be removed also from notifications? >>> >> Notifications in NETCONF/YANG are rather limited and >> unless the WG(s) do something to fix them, >> it isn't really worth worrying about. >> >> A 'useful' notification will need to include >> all the keys from the relevant entries, as >> well as some data selected from these entries. >> >> Since leafref just returns the value of the pointed-at node >> with no indication of the actual instance selected, >> it is not very useful for notifications. > > We changed keyref to leafref mainly for supporting leafref in > notifications. If you think we don't need to worry about > notifications, can we change leafref back to keyref? > I really don't like the cut-and-paste problems that show up because of leafref/keyref: list A { key x; leaf x { type string; } ... } list B { key x; leaf x { type leafref { path /A/x; }} ... } list C { key x; leaf x { type leafref { path /B/x; }} ... } This copy-of-x approach allows copy-of-copy-of-x as well. This is either a bug or a feature, depending on your POV. I prefer to put the path-stmt directly into the key-stmt, eliminating the need for any duplication of the foreign leaf used as a key. list A { key x; leaf x { type string; } ... } list B { // valid key "/A/x"; ... } list C { // invalid because /B/x is a foreign key key "/B/x"; ... } We don't really need 2 or 3 different ways to declare a foreign leaf as a list key. >>> In your channels example, these *is* a coupling. The channels and >>> favorite lists do not just by accident use the same datatype. >>> >> But you could say this about any 2 leafs that happen >> to use the same derived data type. > > ? > > Are you suggesting that two leafs in this example are just as > coupled as favorite and channel in your example? If so, I am > confused. > > typedef AdminString { > type string { ... } > } > > leaf sys-name { > type AdminString; > } > leaf entity-name { > type AdminString; > } > They are sort of the same because the set of channel numbers is static and valid. The actual stations enabled to produce content instead of a blank screen is a dynamic read-only list. > > > /martin Andy From andy@netconfcentral.com Fri May 29 11:17: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 0D08B3A6C1E for ; Fri, 29 May 2009 11:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 6b6LdETZxUdW for ; Fri, 29 May 2009 11:17:56 -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 3CE483A6944 for ; Fri, 29 May 2009 11:17:56 -0700 (PDT) Received: from [68.142.200.225] by n25.bullet.mail.mud.yahoo.com with NNFMP; 29 May 2009 18:10:25 -0000 Received: from [68.142.201.241] by t6.bullet.mud.yahoo.com with NNFMP; 29 May 2009 18:10:25 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 29 May 2009 18:10:25 -0000 X-Yahoo-Newman-Id: 103888.74083.bm@omp402.mail.mud.yahoo.com Received: (qmail 66573 invoked from network); 29 May 2009 18:10:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 29 May 2009 18:10:23 -0000 X-YMail-OSG: i3XYIRQVM1n4S1NtTC_Wyp.L3TfyIB5RlYtXv32CZb_tpGaU9pbzg7lUR7SnZlVbB03nh5_FWgcR1hzM0_oxpoLN2Hb_rjbLcaf6.2RnQIHbVGsr5nxNJKyUUwp5G3DwefiSwzz5Ft85J6UGwGijDwUkMWylPSHvMg_WT1uEQSV5Q2emv3fSRtAiAuXC.4zlRMiDhkayWbYWPTAss9ezfcDLpUWUgZxTJM68KOpns5ke19_HS5gLfB_PINmchLSqUewJF2CHxDLHsASw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A20250E.1050204@netconfcentral.com> Date: Fri, 29 May 2009 11:10:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> <4A2023CF.30105@netconfcentral.com> In-Reply-To: <4A2023CF.30105@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 29 May 2009 18:17:57 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: ..... >> Are you suggesting that two leafs in this example are just as >> coupled as favorite and channel in your example? If so, I am >> confused. >> >> typedef AdminString { >> type string { ... } >> } >> >> leaf sys-name { >> type AdminString; >> } >> leaf entity-name { >> type AdminString; >> } >> > > > They are sort of the same because the set of > channel numbers is static and valid. > The actual stations enabled to produce > content instead of a blank screen is > a dynamic read-only list. > I got this use-case wrong. This is not read-only (config-false) data. The enabled-station list is simply config data that access control is allowing the user to read, but preventing the user from changing. IMO, there is no use-case for config leafrefs pointing at non-config leafs. > >> >> >> /martin > > > Andy Andy From mbj@tail-f.com Fri May 29 13:32: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 A6B733A691D for ; Fri, 29 May 2009 13:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 4dt-M-f1-YB1 for ; Fri, 29 May 2009 13:32: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 D4C1A3A693C for ; Fri, 29 May 2009 13:31:59 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E410616004; Fri, 29 May 2009 22:33:38 +0200 (CEST) Date: Fri, 29 May 2009 22:33:37 +0200 (CEST) Message-Id: <20090529.223337.116612168.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A2023CF.30105@netconfcentral.com> References: <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> <4A2023CF.30105@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] leafref issues 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, 29 May 2009 20:32:00 -0000 Andy Bierman wrote: > I really don't like the cut-and-paste problems that > show up because of leafref/keyref: > > > list A { > key x; > leaf x { type string; } > ... > } > > list B { > key x; > leaf x { type leafref { path /A/x; }} > ... > } > > list C { > key x; > leaf x { type leafref { path /B/x; }} > ... > } > > This copy-of-x approach allows copy-of-copy-of-x > as well. This is either a bug or a feature, > depending on your POV. This is only a problem with leafref, it was not in the original keyref. > I prefer to put the path-stmt directly into > the key-stmt, eliminating the need for any > duplication of the foreign leaf used as a key. But this would solve only the foreign key problem. It does not solve the leaf-to-key reference problem. (Compare with channelIfIndex from RMON-MIB, which is a reference to ifIndex, but this info is only available in the description clause) > We don't really need 2 or 3 different ways to declare > a foreign leaf as a list key. I think we have one way to declare a foreign leaf as a key - a leaf of type leafref. /martin From andy@netconfcentral.com Fri May 29 13:43: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 BD9503A6E4B for ; Fri, 29 May 2009 13:43:24 -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 ESWaX4Luo1kh for ; Fri, 29 May 2009 13:43:24 -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 2142D3A6FB1 for ; Fri, 29 May 2009 13:43:24 -0700 (PDT) Received: (qmail 81713 invoked from network); 29 May 2009 20:45:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 29 May 2009 20:45:04 -0000 X-YMail-OSG: 3VlSZ94VM1kzn.8PVPbVgro_olyYcmw9jw3jSW6Lack5um5QOWuHLoCbI5_VS.8y2pVpjl_T3oIVEeq2HfC44G3Ujg_5.Di.pbxGD_1aWHaosbLFUCKduLDznnSI2SKNr62e4BsBSBLT7sW9YWonVQRZtSQTFkySIHEeZ33XvEy6qG0v3I__YQajGfYer89W1YpbkodxNOR4QGfIywubvMf_uWxIswm09.t.0LZYx0j1aMR83JFK2jn9SNFjSf4K0uW6kPwT0pwBhvF32uNdVaucqCTuWgSalhBbbspnGy4eTbbBQnYt X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A20494E.9020601@netconfcentral.com> Date: Fri, 29 May 2009 13:45:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> <4A2021A9.1050103@joelhalpern.com> In-Reply-To: <4A2021A9.1050103@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues 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, 29 May 2009 20:43:24 -0000 Joel M. Halpern wrote: > While there is some semantic information in a config leaf whose type is > a leafref with require-instance=false, it is a very small amount of > information. It will allow a few uses, but usually won't allow what an > NMW would like (for example, it will not allow the nms to provide a list > of valid values to the user.) > It seems a complication with little actual use. Real semantics is > always in the description clause anyway. > You are being fooled by the name 'leafref', when all that is being supported is really 'typeref'. The leaf or leaf-list node containing the leafref type statement can override any of the sub-statements (e.g., units, default, description, if-feature). I would think 'leafref' meant that there was a coupling between the pointer and pointed-at (as 'ref' suggests). I would also think the thing being referenced was the entire leaf, not just the type-stmt from that leaf. I would also not guess that there were at least 6 different use-cases allegedly supported, given the existing text. Some of them are clearly under-specified, if in fact they remain in the draft. > Joel Andy From andy@netconfcentral.com Sat May 30 11:08: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 2E0CA3A67B5 for ; Sat, 30 May 2009 11:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 jcbFmuP9Y0B0 for ; Sat, 30 May 2009 11:08:09 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 9E40F3A67EC for ; Sat, 30 May 2009 11:08:09 -0700 (PDT) Received: (qmail 9888 invoked from network); 30 May 2009 18:09:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 30 May 2009 18:09:50 -0000 X-YMail-OSG: 0nzqArUVM1m7vrgxXl4EAfIqd5sjVtEFPEJ9eRMEaVJ6CS_M.czDUZLkNQzdMgoHhZIf5IYcG8ZdHG9zKW9.iheqpCgQ.c_Xepp5hpsz4jqSBTBUGf0l96XoC6rK7FiT4oJsZ9JaLIF5DKaTUyzM.4dfvE6NPBTZdidKuWthzfVAjfdj92KZA67TfCrtcxUGwh0OGxtO9dkTeukLLKdOy77lVvw7FQLYi6cNLJkcoEOcr2EiaRWRn6wLaAfY0uDZFVm7AQ0RbVTnsYOlU6iJp3RMPBAZmZp_PYWirCW9wCPLZys0n3gfsfY3 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A21766C.5000108@netconfcentral.com> Date: Sat, 30 May 2009 11:09:48 -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-05; ABNF bug 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, 30 May 2009 18:08:16 -0000 Hi, The stmtend tokens in the min-elements-stmt and max-elements-stmt end in ';' (stmtend;). This is a bug. Andy From andy@netconfcentral.com Sat May 30 11:15: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 0990D3A7014 for ; Sat, 30 May 2009 11:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-0.892, 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 H+S6JjBKX2JZ for ; Sat, 30 May 2009 11:15:00 -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 5CBDC3A67B5 for ; Sat, 30 May 2009 11:15:00 -0700 (PDT) Received: (qmail 8013 invoked from network); 30 May 2009 18:16:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 30 May 2009 18:16:41 -0000 X-YMail-OSG: CG58uwMVM1mOAf3MpQCuPUdfKuqT3Jyqiy3JSJ7pcYFVebG58U.6Ba6AQaftcEL17z8uFXABtddehCi7ASvdaUGLsCFIZJI5XfhKkl7X1wXmbI_ZrZHmccpSpzSHB3odVIGiP0NHoX5ggm1lQH0iN0GJq.RJnvbBtWd3byd5sFlcahwVzsGapUnkisco04Xi2H5dHiaICrOma_vYu4l8fT.HbB0LmCWQUXhR1mpl66p_W9N9D0MJ.EkpMJ5di8pVoXUJCjW6wbJuN_E3WDuBA628Ykty3n73LZRk2VXACi05VDT8vte. X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A217808.9060104@netconfcentral.com> Date: Sat, 30 May 2009 11:16:40 -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] must-stmt usage example 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, 30 May 2009 18:15:01 -0000 Hi, [Warning: enhancement request up ahead!] If one were to write a YANG file to model the create-subscription operation in RFC 5277, one might add the following must-stmt to the stopTime leaf: leaf stopTime { must ". < ../startTime"; type xsd:dateTime; description "An optional parameter used with the optional replay feature to indicate the newest notifications of interest. If stop time is not present, the notifications will continue until the subscription is terminated. Must be used with startTime."; } The problem is that the error-tag specified for this exact error condition (in RFC 5277) is 'bad-element'. However, the YANG draft specifies that the error-tag used is hard-wired to 'operation-failed'. IMO, an optional error-tag-stmt added to the must-stmt subclauses will make this construct more useful. If the clause is missing, then the default is 'operation-failed'. The string has to match one of the standard error-tag values in RFC 4741. leaf stopTime { must ". < ../startTime" { error-tag "bad-element"; } type xsd:dateTime; description "An optional parameter used with the optional replay feature to indicate the newest notifications of interest. If stop time is not present, the notifications will continue until the subscription is terminated. Must be used with startTime."; } error-tag-stmt = error-tag-keyword sep error-tag-arg-str stmtend error-tag-arg-str = < a string which matches the rule error-tag-arg > error-tag-arg = ** error-tag values enumerated ** This would affect the length, pattern, range, and must statements. All of them allow the error-app-tag and error-message fields now, so they should allow an error-tag field as well. Comments? Andy From andy@netconfcentral.com Sat May 30 11:19: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 27E283A7014 for ; Sat, 30 May 2009 11:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=-0.869, 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 6oHkvrRtvhZr for ; Sat, 30 May 2009 11:19:57 -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 7E0C23A69D5 for ; Sat, 30 May 2009 11:19:57 -0700 (PDT) Received: (qmail 7334 invoked from network); 30 May 2009 18:21:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 30 May 2009 18:21:42 -0000 X-YMail-OSG: uqEs93IVM1lH_.MdzuT8jFzOcv.or5TK2J_9LE8mIPEV_JW3p9w7VLDioQvBhlYllxaCTPLGSRtUtP0Y0NxyZtmAxu.BKG0YIG2pMc4MOpIm7xT6vMqI8h5TLD5_6UIyMeIGn8GlQV9uUcWM7na8ZkvRz6fOJeDWE8RrEE4QBh7OerUu92WjFM0iOR5m10JnDCTxOWlM4qBuMCwGVM25qtr2LHJWY7_cd1ysbD1kKMSoBJ_WHwlObdaM2d9LVhYU0g62U3Iw2Zz2s61h X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A217934.4000806@netconfcentral.com> Date: Sat, 30 May 2009 11:21:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group References: <4A217808.9060104@netconfcentral.com> In-Reply-To: <4A217808.9060104@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] must-stmt usage example 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, 30 May 2009 18:19:58 -0000 Andy Bierman wrote: > Hi, > > [Warning: enhancement request up ahead!] > > > If one were to write a YANG file to model > the create-subscription operation in RFC 5277, > one might add the following must-stmt to > the stopTime leaf: > > > leaf stopTime { > must ". < ../startTime"; oops -- got it backwards: must ". >= ../startTime"; Andy From andy@netconfcentral.com Sat May 30 11:33: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 C50C93A6B25 for ; Sat, 30 May 2009 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.082, 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 9T8q20S2vgPT for ; Sat, 30 May 2009 11:33:32 -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 1FAEB3A7075 for ; Sat, 30 May 2009 11:33:32 -0700 (PDT) Received: (qmail 5406 invoked from network); 30 May 2009 18:35:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 30 May 2009 18:35:16 -0000 X-YMail-OSG: 6llJz_sVM1lvBLFie6vw1OnbSdoyke0ND1gbRW0itU68Uo1QGU752kFNuZIVy5nQ6bTUDs0BtUHdxnZTqnIfo25S1q3y6ceo7wPB8BBuwoPgc1VXKIMMfICeF4vawgvqpPTXVfVjMVIDjjB28Qsi1oUhKWeLjhFzHQq9NuHyz0tPWpFKXG4Vk109zlbReHgapYxWFkxaMH1gM3JGxk_v73TOtMxro1k.jD3PJNREY0yYu2_Lze0TUw39sSkoMXkPGpUWyYllQkKd5JcUvNtH9HcPrbHOAGpMBk844hNMaRweArFm9V4v X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A217C4D.3000503@netconfcentral.com> Date: Sat, 30 May 2009 11:34:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group References: <4A217808.9060104@netconfcentral.com> In-Reply-To: <4A217808.9060104@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] must-stmt usage example 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, 30 May 2009 18:33:32 -0000 Andy Bierman wrote: > Hi, > > [Warning: enhancement request up ahead!] I just remembered that the create-subscription operation defines some useless added to it (bad-element). Modeling all the error-info is more than I had in mind, and the error-tag alone is not enough to automate the error response correctly. Perhaps YANG2 should model every error detail, but not now. BTW, in the future, we should not misuse the error-info. The already points to the bad input parameter, so this data is redundant. Andy From cfinss@dial.pipex.com Sat May 30 13:33: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 F31DF3A7084 for ; Sat, 30 May 2009 13:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001, 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 ZALgsc1MWU71 for ; Sat, 30 May 2009 13:33:44 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 03AAD3A7093 for ; Sat, 30 May 2009 13:33:42 -0700 (PDT) X-Trace: 164484297/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.216/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.216 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: AroEABc1IUo+vGnY/2dsb2JhbACDKYtyvyoIhAQF X-IronPort-AV: E=Sophos;i="4.41,276,1241391600"; d="scan'208";a="164484297" X-IP-Direction: IN Received: from 1cust216.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.216]) by smtp.pipex.tiscali.co.uk with SMTP; 30 May 2009 21:35:23 +0100 Message-ID: <006101c9e15d$a4289160$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <006901c9df6a$149e0ec0$0601a8c0@allison> <20090528.115655.03590098.mbj@tail-f.com> <002d01c9dfba$55470a80$0601a8c0@allison> <1243599694.7849.26.camel@missotis> Date: Sat, 30 May 2009 21:23:35 +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 Cc: netmod@ietf.org Subject: Re: [netmod] XPath issues 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: Sat, 30 May 2009 20:33:45 -0000 ---- Original Message ----- From: "Ladislav Lhotka" To: "tom.petch" Cc: "Martin Bjorklund" ; ; Sent: Friday, May 29, 2009 2:21 PM > tom.petch píše v Čt 28. 05. 2009 v 18:42 +0200: > > > > > > > > 'augment', 'path', 'instance identifier' cover none of this. > > > > > > > > Why the difference? > > > > > > Ladislav pointed this out as well. Specifically, he wanted this spec > > > for 'path'. > > > > Ah, I missed that; I would like it for all three, or else a note as > > to why this is not an issue. I think that namespaces is the aspect I cannot > > readily work out (import/include/uses/augments ...etc) > > The context is quite clear for "augment", but the document is the > corresponding schema tree, unlike the other uses of XPath. > > I was thinking about 'path' under 'leafref' and IMO the accessible tree > should be the main data tree. Are there any use cases for, say, a > leafref in RPC output referring to a leaf inside the same RPC output > tree? > > I am not sure about instance identifier, for me it's quite an exotic > data type. > > > > > Can some of this be in 6.4, eg on function library, if it > > > > is common to all use cases of XPath? > > > > > > The function library is common to all use cases which allow > > > functions (must and when). Note that augment, path and > > > instance-identifier all have a very restricted form of XPath where > > > functions and variables cannot appear. > > > > Well, to be picky, path allows the current() function. > > I don't think current() is allowed in those three cases. On the other > hand, I am wondering about other XPath constructs that seem to be legal > e.g. in the 'path' argument, for instance "foo//bar". I think this > should be banned, too, such a 'leafref' would be really mindboggling. Well, reading the ABNF, current() is explicitly mentioned for path:-) But functions is the least concern for me. Biggest is namespaces. We (have rough consensus to) deviate from XPath 1.0 by making names without prefixes part of the current module and that is called out for 'must and 'when'. Hence I think it needs calling out for the others; omitting this must surely confuse. Perhaps a candidate for 6.4. Second biggest is root. Again, this was discussed (January) and we do (have rough consensus to) not deviate from XPath 1.0, that is the XPath (virtual) root node sits above the root element nodes of the 'document' and 'must' and 'when' clearly call out what that means. Again, I think that this needs calling out for the others, particularly for 'augment'; else we may not get interoperability for absolute paths. And yes, I can see a leafref in output or notification referring to a leaf node therein, but I cannot think of a case where the same thing could not be achieved by a second reference to the data tree, so a short cut for the data modeller rather than a must have. 'instance-identifier' yes, I have not got my mind around it yet. Tom Petch > Lada > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C From mbj@tail-f.com Sat May 30 14: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 ECDAB3A6F97 for ; Sat, 30 May 2009 14:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 rqqP+YPrRwBq for ; Sat, 30 May 2009 14: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 31A313A6E76 for ; Sat, 30 May 2009 14:10:23 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E8C0616011; Sat, 30 May 2009 23:12:04 +0200 (CEST) Date: Sat, 30 May 2009 23:12:04 +0200 (CEST) Message-Id: <20090530.231204.114241280.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A21766C.5000108@netconfcentral.com> References: <4A21766C.5000108@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-05; ABNF bug 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, 30 May 2009 21:10:24 -0000 Andy Bierman wrote: > Hi, > > The stmtend tokens in the min-elements-stmt > and max-elements-stmt end in ';' (stmtend;). > This is a bug. Well, it's legal ABNF (which is why abnfgen doesn't complain), since ';' marks the beginning of a comment, but I have removed them of course; they were mistakes. /martin