From root@core3.amsl.com Tue Dec 1 01: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 2FA7428C1CC; Tue, 1 Dec 2009 01:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091201093002.2FA7428C1CC@core3.amsl.com> Date: Tue, 1 Dec 2009 01:30:02 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-09.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, 01 Dec 2009 09: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 : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-09.txt Pages : 179 Date : 2009-12-01 YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-01012438.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Dec 1 02:15:01 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 55A973A68CC; Tue, 1 Dec 2009 02:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091201101501.55A973A68CC@core3.amsl.com> Date: Tue, 1 Dec 2009 02:15:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-types-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: Tue, 01 Dec 2009 10:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Common YANG Data Types Author(s) : J. Schoenwaelder Filename : draft-ietf-netmod-yang-types-05.txt Pages : 32 Date : 2009-12-01 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-types-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-01020041.I-D@ietf.org> --NextPart-- From balazs.lengyel@ericsson.com Tue Dec 1 08:27: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 911B73A672E; Tue, 1 Dec 2009 08:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.791 X-Spam-Level: X-Spam-Status: No, score=-4.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 AtWrv6kdhPfw; Tue, 1 Dec 2009 08:27:55 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2FA833A67A1; Tue, 1 Dec 2009 08:27:11 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-cd-4b1543b4c5f2 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 93.B7.02357.4B3451B4; Tue, 1 Dec 2009 17:26:28 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:26:18 +0100 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 17:26:17 +0100 Message-ID: <4B1543A9.2000407@ericsson.com> Date: Tue, 01 Dec 2009 17:26:17 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 16:26:17.0947 (UTC) FILETIME=[026DDAB0:01CA72A3] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org, NETMOD Working Group Subject: Re: [netmod] [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Dec 2009 16:27:56 -0000 +1 for SHOULD
Balazs

On 11/20/09 19:32, Ersue, Mehmet (NSN - DE/Munich) wrote:
Consensus call: With-Defaults as SHOULD in 4741bis

Hi All,

in the NETCONF/NETMOD conference call we discussed the
handling of with-defaults in 4741bis document and the
YANG specification.

We had a rough consensus on having 'with-defaults' as
SHOULD to implement (see point 3 in the attached mail
from October 02, 2009), which is going to be added to
the 4741bis document if we have consensus.

We do not want to go through a re-run of all arguments
for and against. Since this conclusion has an impact
on both NETCONF 4741bis and the YANG specifications
the co-chairs of NETCONF and NETMOD WGs are keen of
having a final consensus call on that.

All on NETCONF and NETMOD WG maillists, please read
the attached mail of David Partain and respond to this
mail by December 1, 2009 EOB PT.
<<[netmod] Information from chair phone call on 24 September>>

If you agree with the conclusion having 'with-defaults'
as SHOULD to implement in 4741bis please state so.
If you disagree with this consensus, state your opinion too.

Thank you.

Bert & Mehmet 


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

-- 
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 Washam.Fan@huaweisymantec.com Tue Dec 1 22:48: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 9E2653A6882; Tue, 1 Dec 2009 22:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=0.382, 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 qD7J+nFoJjc2; Tue, 1 Dec 2009 22:48:18 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id DE17F3A67EE; Tue, 1 Dec 2009 22:48:17 -0800 (PST) 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-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KU000F4RIVZ4490@hstga02-in.huaweisymantec.com>; Wed, 02 Dec 2009 14:48:00 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KU000DMZIVZFB10@hstml01-in.huaweisymantec.com>; Wed, 02 Dec 2009 14:47:59 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 02 Dec 2009 14:47:59 +0800 From: WashamFan To: netconf@ietf.org, NETMOD Working Group Message-id: Date: Wed, 02 Dec 2009 14:47:59 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B41B5E4198@zcarhxm2.corp.nortel.com> References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> <200911301500.53656.david.partain@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41B5E4198@zcarhxm2.corp.nortel.com> Subject: Re: [netmod] [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 06:48:18 -0000 +1 for SHOULD. washam > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of David Partain > Sent: Monday, November 30, 2009 9:01 AM > To: netconf@ietf.org; NETMOD Working Group > Subject: Re: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis > > Greetings, > > > If you agree with the conclusion having 'with-defaults' > > as SHOULD to implement in 4741bis please state so. > > +1 > > or... > > Yes, I agree with this conclusion. > > Cheers, > > David From lhotka@cesnet.cz Tue Dec 1 23:05:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E109C3A6844 for ; Tue, 1 Dec 2009 23:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=-0.404, 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 tkBME7kHNTAr for ; Tue, 1 Dec 2009 23:05:21 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 194F43A67F7 for ; Tue, 1 Dec 2009 23:05:21 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E25C5D80096 for ; Wed, 2 Dec 2009 08:05:12 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 08:05:11 +0100 Message-ID: <1259737511.22111.49.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [netmod] when 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, 02 Dec 2009 07:05:22 -0000 Hi, the issues raised in the other thread about 'when' IMO need to be addressed. They are illustrated in this YANG fragment: leaf foo { type uint8; default 42; when "not(../bar=1)"; } leaf bar { type uint8; default 1; when "not(../foo=42)"; } Dealing with the schema constraints at the same time as with the 'when' and 'default' statements leads to a deadlock. I think it is necessary to make the schema immune to "run-time" modifications, so that 'when' should not be allowed under 'augment' and 'uses'. Only features might modify the schema. In addition, it is necessary to prioritize the validation procedure by dividing it into three steps similar to those outlined in DSDL mapping draft, sec. 7: 1. The schema-based constraints are checked first, independently of the remaining two steps. 2. Default values and ancestor containers are (conceptually) added where necessary - this forms the "conceptual data tree". 3. Rule-based constraint ('must' and 'when') are checked. In the above example, if the configuration contains neither "foo" nor "bar", then - step 1 succeeds because both leafs are optional, - step 2 adds the leafs 421 (and ancestor container(s), if necessary), - in step 3, both 'when' rules are found to be violated, which leads to a validation error. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Dec 1 23:10: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 6FAEC3A67F7; Tue, 1 Dec 2009 23:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.422 X-Spam-Level: X-Spam-Status: No, score=0.422 tagged_above=-999 required=5 tests=[AWL=-0.928, 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 vcHb3CP0YUmg; Tue, 1 Dec 2009 23:10:29 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4821B3A6A11; Tue, 1 Dec 2009 23:10:29 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B9B39D80095; Wed, 2 Dec 2009 08:10:21 +0100 (CET) From: Ladislav Lhotka To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 08:10:20 +0100 Message-ID: <1259737820.22111.50.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org, NETMOD Working Group Subject: Re: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 07:10:30 -0000 Ersue, Mehmet (NSN - DE/Munich) píše v Pá 20. 11. 2009 v 19:32 +0100: > If you agree with the conclusion having 'with-defaults' > as SHOULD to implement in 4741bis please state so. +1 to SHOULD. Lada > If you disagree with this consensus, state your opinion too. > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Dec 1 23:31: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 1B6C73A6A4B for ; Tue, 1 Dec 2009 23:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, 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 OVUehsdprKbG for ; Tue, 1 Dec 2009 23:31:13 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 517033A6A49 for ; Tue, 1 Dec 2009 23:31:12 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BC92B76C6DB; Wed, 2 Dec 2009 08:31:03 +0100 (CET) Date: Wed, 02 Dec 2009 08:31:03 +0100 (CET) Message-Id: <20091202.083103.38229948.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1259737511.22111.49.camel@missotis> References: <1259737511.22111.49.camel@missotis> X-Mailer: Mew version 6.2.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] when 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, 02 Dec 2009 07:31:14 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > the issues raised in the other thread about 'when' IMO need to be > addressed. They are illustrated in this YANG fragment: > > leaf foo { > type uint8; > default 42; > when "not(../bar=1)"; > } > leaf bar { > type uint8; > default 1; > when "not(../foo=42)"; > } > > Dealing with the schema constraints at the same time as with the 'when' > and 'default' statements leads to a deadlock. I think the problem comes from the recursive definition here. I'd rather make recurisive when expressions illegal. > I think it is necessary to make the schema immune to "run-time" > modifications, so that 'when' should not be allowed under 'augment' and > 'uses'. I don't understand this. Can you provide an example? Originally, we had "when" only for augment, allowing you to formally specify the conditions for a sparse augmentation. > In addition, it is necessary to prioritize the validation procedure Why is this necessary? It seems to be an implementation detail in which order things are checked. An implementation needs to detect invalid configs, but how it does this does not matter. > by > dividing it into three steps similar to those outlined in DSDL mapping > draft, sec. 7: > > 1. The schema-based constraints are checked first, independently of the > remaining two steps. leaf-list x { type int32; min-entries 1; when "../y > 1"; } leaf y { type int32; } Does your rule 1 mean that first I should check min-entries, regardless of the 'when' statement? So this instance doc will fail: 2 /martin From j.schoenwaelder@jacobs-university.de Wed Dec 2 00:08: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 114893A683D for ; Wed, 2 Dec 2009 00:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.307, 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 hFRsBuGwPQV6 for ; Wed, 2 Dec 2009 00:08:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 01FCD3A68F9 for ; Wed, 2 Dec 2009 00:08:54 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27CB6C0035; Wed, 2 Dec 2009 09:08:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BB7spOKEFeSd; Wed, 2 Dec 2009 09:08:45 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7B3BC0034; Wed, 2 Dec 2009 09:08:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 445BBE40533; Wed, 2 Dec 2009 09:08:44 +0100 (CET) Date: Wed, 2 Dec 2009 09:08:44 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091202080844.GA6557@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1259737511.22111.49.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1259737511.22111.49.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] when issues 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, 02 Dec 2009 08:08:55 -0000 On Wed, Dec 02, 2009 at 08:05:11AM +0100, Ladislav Lhotka wrote: > Hi, > > the issues raised in the other thread about 'when' IMO need to be > addressed. They are illustrated in this YANG fragment: > > leaf foo { > type uint8; > default 42; > when "not(../bar=1)"; > } > leaf bar { > type uint8; > default 1; > when "not(../foo=42)"; > } > > Dealing with the schema constraints at the same time as with the 'when' > and 'default' statements leads to a deadlock. > > I think it is necessary to make the schema immune to "run-time" > modifications, so that 'when' should not be allowed under 'augment' and > 'uses'. Only features might modify the schema. There is no 'run-time' modification. You can always screw up data models; even in SMIv2 land you can easily write new object definitions where the description clause contradicts some other object definitions. The only difference here is that YANG provides some very sharp tools likely encouraging people to write down more contraints than they would do in natural language and thus the likelihood to regret certain constraints later on increases as well. > In addition, it is necessary to prioritize the validation procedure by > dividing it into three steps similar to those outlined in DSDL mapping > draft, sec. 7: > > 1. The schema-based constraints are checked first, independently of the > remaining two steps. > > 2. Default values and ancestor containers are (conceptually) added > where necessary - this forms the "conceptual data tree". > > 3. Rule-based constraint ('must' and 'when') are checked. > > In the above example, if the configuration contains neither "foo" nor > "bar", then > - step 1 succeeds because both leafs are optional, > - step 2 adds the leafs 421 (and ancestor > container(s), if necessary), > - in step 3, both 'when' rules are found to be violated, which leads to > a validation error. So why are these steps useful for interoperability? The situation you have above should ideally be caught before implementation begins, e.g. by having a tool that understands YANG and is able to generate valid pseudo configurations, much like abnfgen. If it is impossible to generate valid instances, then this ideally should be caught before 'runtime'. /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 Wed Dec 2 00:21: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 0A72D3A6A5A for ; Wed, 2 Dec 2009 00:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=0.438, 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 u5QqB8YOGCHK for ; Wed, 2 Dec 2009 00:21:44 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E07AB3A6A64 for ; Wed, 2 Dec 2009 00:21:43 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C0285D80095; Wed, 2 Dec 2009 09:21:35 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091202.083103.38229948.mbj@tail-f.com> References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 09:21:34 +0100 Message-ID: <1259742094.22111.98.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 08:21:45 -0000 Martin Bjorklund píše v St 02. 12. 2009 v 08:31 +0100: > Hi, > > Ladislav Lhotka wrote: > > Hi, > > > > the issues raised in the other thread about 'when' IMO need to be > > addressed. They are illustrated in this YANG fragment: > > > > leaf foo { > > type uint8; > > default 42; > > when "not(../bar=1)"; > > } > > leaf bar { > > type uint8; > > default 1; > > when "not(../foo=42)"; > > } > > > > Dealing with the schema constraints at the same time as with the 'when' > > and 'default' statements leads to a deadlock. > > I think the problem comes from the recursive definition here. I'd > rather make recurisive when expressions illegal. Such interferences can happen across any number of steps and can be hidden in the complexity of XPath expressions, so there is no practical way for detecting this in a general case. > > > I think it is necessary to make the schema immune to "run-time" > > modifications, so that 'when' should not be allowed under 'augment' and > > 'uses'. > > I don't understand this. Can you provide an example? Originally, we > had "when" only for augment, allowing you to formally specify the > conditions for a sparse augmentation. I think it is fundamentally wrong if an instance document is allowed to modify the schema which is supposed to define the document's grammar. No schema language I am aware of permits this. The schema derived from all advertised modules and features should be fixed. > > > In addition, it is necessary to prioritize the validation procedure > > Why is this necessary? It seems to be an implementation detail in > which order things are checked. An implementation needs to detect > invalid configs, but how it does this does not matter. It does resolve the above deadlock. > > > by > > dividing it into three steps similar to those outlined in DSDL mapping > > draft, sec. 7: > > > > 1. The schema-based constraints are checked first, independently of the > > remaining two steps. > > leaf-list x { > type int32; > min-entries 1; > when "../y > 1"; > } > leaf y { > type int32; > } > > Does your rule 1 mean that first I should check min-entries, > regardless of the 'when' statement? So this instance doc will fail: > > 2 Yes. The 'when' statement is then essentially equivalent to the following 'must' constraint specified in the parent container: must "y>1 or not(x)"; But you could achieve the right thing by using must "not(y>1) or count(x)>=1"; leaf-list x { type int32; min-entries 0; } leaf y { type int32; } Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Dec 2 00:31: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 559033A6A5A for ; Wed, 2 Dec 2009 00:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.290, 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 fIwdNSp67Wzh for ; Wed, 2 Dec 2009 00:31:55 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 57F963A67E5 for ; Wed, 2 Dec 2009 00:31:55 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C945C0034; Wed, 2 Dec 2009 09:31:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HwEQghLu+SfV; Wed, 2 Dec 2009 09:31:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB061C0004; Wed, 2 Dec 2009 09:31:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1337DE409CF; Wed, 2 Dec 2009 09:31:46 +0100 (CET) Date: Wed, 2 Dec 2009 09:31:46 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091202083145.GA6708@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <1259742094.22111.98.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1259742094.22111.98.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] when issues 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, 02 Dec 2009 08:31:56 -0000 On Wed, Dec 02, 2009 at 09:21:34AM +0100, Ladislav Lhotka wrote: > > > I think it is necessary to make the schema immune to "run-time" > > > modifications, so that 'when' should not be allowed under 'augment' and > > > 'uses'. > > > > I don't understand this. Can you provide an example? Originally, we > > had "when" only for augment, allowing you to formally specify the > > conditions for a sparse augmentation. > > I think it is fundamentally wrong if an instance document is allowed to > modify the schema which is supposed to define the document's grammar. No > schema language I am aware of permits this. > > The schema derived from all advertised modules and features should be > fixed. I do not get why you believe an instance document modifies the schema. /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 Wed Dec 2 00:38: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 CB64B3A6855 for ; Wed, 2 Dec 2009 00:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[AWL=-0.798, 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 X9Fo7oY3mIjF for ; Wed, 2 Dec 2009 00:38:10 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0C8713A68B6 for ; Wed, 2 Dec 2009 00:38:10 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 346A0D80096; Wed, 2 Dec 2009 09:38:02 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091202083145.GA6708@elstar.local> References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <1259742094.22111.98.camel@missotis> <20091202083145.GA6708@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 09:38:00 +0100 Message-ID: <1259743080.22111.110.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] when 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, 02 Dec 2009 08:38:10 -0000 Juergen Schoenwaelder píše v St 02. 12. 2009 v 09:31 +0100: > On Wed, Dec 02, 2009 at 09:21:34AM +0100, Ladislav Lhotka wrote: > > > > > I think it is necessary to make the schema immune to "run-time" > > > > modifications, so that 'when' should not be allowed under 'augment' and > > > > 'uses'. > > > > > > I don't understand this. Can you provide an example? Originally, we > > > had "when" only for augment, allowing you to formally specify the > > > conditions for a sparse augmentation. > > > > I think it is fundamentally wrong if an instance document is allowed to > > modify the schema which is supposed to define the document's grammar. No > > schema language I am aware of permits this. > > > > The schema derived from all advertised modules and features should be > > fixed. > > I do not get why you believe an instance document modifies the schema. Look at the example at the end of Martin's last message. Can you tell what the schema is without looking into any instance document? Probably I should rather have said that the schema depends on the instance document. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Dec 2 00:52: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 7729E3A6A4B for ; Wed, 2 Dec 2009 00:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, 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 NH3NB16s6w5O for ; Wed, 2 Dec 2009 00:52:55 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B533A3A6A17 for ; Wed, 2 Dec 2009 00:52:55 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C48A76C6DB; Wed, 2 Dec 2009 09:52:46 +0100 (CET) Date: Wed, 02 Dec 2009 09:52:46 +0100 (CET) Message-Id: <20091202.095246.240237381.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1259742094.22111.98.camel@missotis> References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <1259742094.22111.98.camel@missotis> X-Mailer: Mew version 6.2.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] when 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, 02 Dec 2009 08:52:56 -0000 Ladislav Lhotka wrote: > I think it is fundamentally wrong if an instance document is allowed to > modify the schema which is supposed to define the document's grammar. No > schema language I am aware of permits this. The instance document does not modify the schema tree. > The schema derived from all advertised modules and features should be > fixed. Yes. > > > In addition, it is necessary to prioritize the validation procedure > > > > Why is this necessary? It seems to be an implementation detail in > > which order things are checked. An implementation needs to detect > > invalid configs, but how it does this does not matter. > > It does resolve the above deadlock. > > > > > > by > > > dividing it into three steps similar to those outlined in DSDL mapping > > > draft, sec. 7: > > > > > > 1. The schema-based constraints are checked first, independently of the > > > remaining two steps. > > > > leaf-list x { > > type int32; > > min-entries 1; > > when "../y > 1"; > > } > > leaf y { > > type int32; > > } > > > > Does your rule 1 mean that first I should check min-entries, > > regardless of the 'when' statement? So this instance doc will fail: > > > > 2 > > Yes. But it is valid! When y > 1, no x should exist. When y <= 1, at least 1 x must exist. /martin From lhotka@cesnet.cz Wed Dec 2 01:18: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 4AE8828C169 for ; Wed, 2 Dec 2009 01:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[AWL=0.459, 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 0X8p94dwGsHu for ; Wed, 2 Dec 2009 01:18:50 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3720928C15D for ; Wed, 2 Dec 2009 01:18:50 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 18D93D80095; Wed, 2 Dec 2009 10:18:42 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091202.095246.240237381.mbj@tail-f.com> References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <1259742094.22111.98.camel@missotis> <20091202.095246.240237381.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 10:18:40 +0100 Message-ID: <1259745520.22111.138.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 09:18:51 -0000 Martin Bjorklund píše v St 02. 12. 2009 v 09:52 +0100: > Ladislav Lhotka wrote: > > I think it is fundamentally wrong if an instance document is allowed to > > modify the schema which is supposed to define the document's grammar. No > > schema language I am aware of permits this. > > The instance document does not modify the schema tree. OK, the schema *depends on* the instance document, and such dependencies are not localized and may even come from other modules via groupings and augments. > > > The schema derived from all advertised modules and features should be > > fixed. > > Yes. In your example, what is then the ordinality constraint on leaf-list x? > > > > > In addition, it is necessary to prioritize the validation procedure > > > > > > Why is this necessary? It seems to be an implementation detail in > > > which order things are checked. An implementation needs to detect > > > invalid configs, but how it does this does not matter. > > > > It does resolve the above deadlock. > > > > > > > > > by > > > > dividing it into three steps similar to those outlined in DSDL mapping > > > > draft, sec. 7: > > > > > > > > 1. The schema-based constraints are checked first, independently of the > > > > remaining two steps. > > > > > > leaf-list x { > > > type int32; > > > min-entries 1; > > > when "../y > 1"; > > > } > > > leaf y { > > > type int32; > > > } > > > > > > Does your rule 1 mean that first I should check min-entries, > > > regardless of the 'when' statement? So this instance doc will fail: > > > > > > 2 > > > > Yes. > > But it is valid! When y > 1, no x should exist. When y <= 1, at > least 1 x must exist. I showed you how this condition can be expressed using just 'must' and 'must' is absolutely safe because it operates by design only on the instance document - or rather the conceptual data tree created from the document. Are there any cases where 'when' cannot be emulated this way? Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Dec 2 01:31: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 850B528C173 for ; Wed, 2 Dec 2009 01:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3svynfxir44 for ; Wed, 2 Dec 2009 01:31:01 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8704228C0DD for ; Wed, 2 Dec 2009 01:31:01 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 95A8C76C6DB; Wed, 2 Dec 2009 10:30:53 +0100 (CET) Date: Wed, 02 Dec 2009 10:30:53 +0100 (CET) Message-Id: <20091202.103053.188403128.mbj@tail-f.com> To: bertietf@bwijnen.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <4B163004.8020304@bwijnen.net> References: <1259742094.22111.98.camel@missotis> <20091202.095246.240237381.mbj@tail-f.com> <4B163004.8020304@bwijnen.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] when 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, 02 Dec 2009 09:31:02 -0000 "Bert (IETF) Wijnen" wrote: > > >>>> 1. The schema-based constraints are checked first, independently of the > >>>> remaining two steps. > >>>> > >>> leaf-list x { > >>> type int32; > >>> min-entries 1; > >>> when "../y > 1"; > >>> } > >>> leaf y { > >>> type int32; > >>> } > >>> > >>> Does your rule 1 mean that first I should check min-entries, > >>> regardless of the 'when' statement? So this instance doc will fail: > >>> > >>> 2 > >>> > >> Yes. > >> > > > > But it is valid! When y > 1, no x should exist. When y <= 1, at > > least 1 x must exist. > > > > Martin, I am not up to speed in YANG as you guys are, > > but did you not mean > > When y <= 1, no x should exist. When y > 1, at > least 1 x must exist. Yes! Thanks for catching this. Negation is tricky... So my original example and question should be: With this data model: leaf-list x { type int32; min-entries 1; when "../y <= 1"; } leaf y { type int32; } Does your rule 1 mean that first I should check min-entries, regardless of the 'when' statement? So this instance doc will fail: 2 It should not fail, since when y > 1, no x should exist. When y <= 1, at least 1 x must exist. /martin From lhotka@cesnet.cz Wed Dec 2 02:09: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 98BB328C183 for ; Wed, 2 Dec 2009 02:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=0.432, 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 H5mIkUIhn2CG for ; Wed, 2 Dec 2009 02:09:41 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 78AC628C187 for ; Wed, 2 Dec 2009 02:09:41 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 76AAED800CC; Wed, 2 Dec 2009 11:09:33 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091202.103053.188403128.mbj@tail-f.com> References: <1259742094.22111.98.camel@missotis> <20091202.095246.240237381.mbj@tail-f.com> <4B163004.8020304@bwijnen.net> <20091202.103053.188403128.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 11:09:31 +0100 Message-ID: <1259748571.22111.171.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 10:09:42 -0000 Martin Bjorklund píše v St 02. 12. 2009 v 10:30 +0100: > "Bert (IETF) Wijnen" wrote: > > > > >>>> 1. The schema-based constraints are checked first, independently of the > > >>>> remaining two steps. > > >>>> > > >>> leaf-list x { > > >>> type int32; > > >>> min-entries 1; > > >>> when "../y > 1"; > > >>> } > > >>> leaf y { > > >>> type int32; > > >>> } > > >>> > > >>> Does your rule 1 mean that first I should check min-entries, > > >>> regardless of the 'when' statement? So this instance doc will fail: > > >>> > > >>> 2 > > >>> > > >> Yes. > > >> > > > > > > But it is valid! When y > 1, no x should exist. When y <= 1, at > > > least 1 x must exist. > > > > > > > Martin, I am not up to speed in YANG as you guys are, > > > > but did you not mean > > > > When y <= 1, no x should exist. When y > 1, at > > least 1 x must exist. > > Yes! Thanks for catching this. Negation is tricky... Right, I missed this too, but we know what the problem is. BTW, min-entries should be min-elements. :-) > > So my original example and question should be: > > With this data model: > > leaf-list x { > type int32; > min-entries 1; > when "../y <= 1"; > } > leaf y { > type int32; > } > > Does your rule 1 mean that first I should check min-entries, > regardless of the 'when' statement? So this instance doc will fail: > > 2 > > It should not fail, since when y > 1, no x should exist. When y <= 1, > at least 1 x must exist. It comes as no surprise if you know the rules of the game, namely that "min-elements 1" is a constraint on the schema and 'when' is checked on the conceptual data tree. You can safely implement the desired logic this way: must "not(y<=1) or count(x)>=1"; leaf-list x { type int32; min-elements 0; } leaf y { type int32; } Then 2 will be valid but 1 won't, although both documents are valid according to the schema (step 1). It's the same as with other languages: lexical, syntactic and semantic analyses are independent steps, because otherwise you can't reliably cope with the complexity. Lada > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Dec 2 02:37: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 EAB3C3A67BE for ; Wed, 2 Dec 2009 02:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 P8d5yy6rqwpf for ; Wed, 2 Dec 2009 02:37:43 -0800 (PST) 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 32D843A67A4 for ; Wed, 2 Dec 2009 02:37:43 -0800 (PST) Received: (qmail 92721 invoked from network); 2 Dec 2009 10:37:33 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 02 Dec 2009 02:37:33 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Vl16z.gVM1mqUMtCEji0MBfZsGqoZlM4O6gg6NOTba6YZPPRrg_Cilpm1N1fNX7Sj6ad71bl5TwZTiqDzjADA7gR5eG5T9SS2ttPVC6WjHxkOUrHgU.0VCJumQEraxVpaa_YjwMm5soctRKjMS37U7Baiug5I6ZudqTwZA2G8ixb4fXdajdaryD79yrud2IK2Tq4ddJgF0sj_ZhOT1gVuNQwzMi8YvPYS7838hgpbXPFFeJC22LnInhvEFvTNyJbD69JTUzmJarfMofLP03aKwyw0oFlJpPkFDW0UmQDEvOD8yxyKCky X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16438A.6080406@netconfcentral.com> Date: Wed, 02 Dec 2009 02:38:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> In-Reply-To: <20091202.083103.38229948.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 10:37:44 -0000 Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: >> Hi, >> >> the issues raised in the other thread about 'when' IMO need to be >> addressed. They are illustrated in this YANG fragment: >> >> leaf foo { >> type uint8; >> default 42; >> when "not(../bar=1)"; >> } >> leaf bar { >> type uint8; >> default 1; >> when "not(../foo=42)"; >> } >> >> Dealing with the schema constraints at the same time as with the 'when' >> and 'default' statements leads to a deadlock. > > I think the problem comes from the recursive definition here. I'd > rather make recurisive when expressions illegal. > You can't do this. It is too difficult to check for these perfectly legal XPath expressions that happen to do 'the wrong thing' from a data modeling perspective. >> I think it is necessary to make the schema immune to "run-time" >> modifications, so that 'when' should not be allowed under 'augment' and >> 'uses'. > > I don't understand this. Can you provide an example? Originally, we > had "when" only for augment, allowing you to formally specify the > conditions for a sparse augmentation. > The 'when' and 'if-feature' statements combine to form an intensely complex implementation requirement. So what? Nobody said implementing YANG would be easy. There is no way (or need) to limit the combination of 'upstream' constraints (via uses, augment) with the 'downstream' constraints (leaf, container, etc.). >> In addition, it is necessary to prioritize the validation procedure > > Why is this necessary? It seems to be an implementation detail in > which order things are checked. An implementation needs to detect > invalid configs, but how it does this does not matter. > >> by >> dividing it into three steps similar to those outlined in DSDL mapping >> draft, sec. 7: >> >> 1. The schema-based constraints are checked first, independently of the >> remaining two steps. > > leaf-list x { > type int32; > min-entries 1; > when "../y > 1"; > } > leaf y { > type int32; > } > > Does your rule 1 mean that first I should check min-entries, > regardless of the 'when' statement? So this instance doc will fail: > > 2 > If 'when' and/or 'if-feature' is false, then the node doesn't exist -- it doesn't count towards the existence tests of its siblings or ancestors. > > > /martin Andy From lhotka@cesnet.cz Wed Dec 2 04: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 7D69F3A6A88 for ; Wed, 2 Dec 2009 04:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=0.408, 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 ZSYwJn7vslVU for ; Wed, 2 Dec 2009 04:19:46 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A6A6828C177 for ; Wed, 2 Dec 2009 04:19:45 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 72A05D800E8; Wed, 2 Dec 2009 13:19:33 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B16438A.6080406@netconfcentral.com> References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 13:19:32 +0100 Message-ID: <1259756372.24695.23.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 12:19:47 -0000 Andy Bierman píše v St 02. 12. 2009 v 02:38 -0800: > The 'when' and 'if-feature' statements combine > to form an intensely complex implementation > requirement. So what? Nobody said implementing > YANG would be easy. But it should at least be based on sound principles, or we will find ourselves writing a new "Lessons learned ..." draft after few more years. YANG is said to be simple but the fact is that it is now so complex that its "grammars" cannot be even classified within the Chomsky hierarchy - and we don't care? XSD was carefully designed to produce context-free grammars. It turned out it couldn't handle arbitrary order of children. RELAX NG can handle this very well because it is based on the theory of hedge automata. In both cases, it has been mathematically proven that there is an algorithm for checking instance membership (validity). We can't hope to do this for YANG, so I am extremely cautious about all "powerful" and "flexible" features that move too far away from the established models. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Dec 2 04:24: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 A6F1A28C0EA for ; Wed, 2 Dec 2009 04:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.275, 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 5N42BPCgWSpN for ; Wed, 2 Dec 2009 04:24:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 75C353A6900 for ; Wed, 2 Dec 2009 04:24:48 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34283C000E; Wed, 2 Dec 2009 13:24:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aQFKpNJxeMxg; Wed, 2 Dec 2009 13:24:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A0D9C000D; Wed, 2 Dec 2009 13:24:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7EBCEE410FD; Wed, 2 Dec 2009 13:24:38 +0100 (CET) Date: Wed, 2 Dec 2009 13:24:38 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091202122438.GB7160@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> <1259756372.24695.23.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1259756372.24695.23.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] when issues 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, 02 Dec 2009 12:24:49 -0000 On Wed, Dec 02, 2009 at 01:19:32PM +0100, Ladislav Lhotka wrote: > Andy Bierman p????e v St 02. 12. 2009 v 02:38 -0800: > > The 'when' and 'if-feature' statements combine > > to form an intensely complex implementation > > requirement. So what? Nobody said implementing > > YANG would be easy. > > But it should at least be based on sound principles, or we will find > ourselves writing a new "Lessons learned ..." draft after few more > years. YANG is said to be simple but the fact is that it is now so > complex that its "grammars" cannot be even classified within the Chomsky > hierarchy - and we don't care? Please provide evidence. > XSD was carefully designed to produce context-free grammars. It turned > out it couldn't handle arbitrary order of children. RELAX NG can handle > this very well because it is based on the theory of hedge automata. > > In both cases, it has been mathematically proven that there is an > algorithm for checking instance membership (validity). We can't hope to > do this for YANG, so I am extremely cautious about all "powerful" and > "flexible" features that move too far away from the established models. It will help me a lot if you can write up a clear email providing evidence (e.g. by presenting a valid example) that it is not decidable whether an instance document is valid or not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Wed Dec 2 04:46: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 BE7F328C1C3 for ; Wed, 2 Dec 2009 04:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.864 X-Spam-Level: X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[AWL=0.386, 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 6DAAfNuuAtoV for ; Wed, 2 Dec 2009 04:46:20 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9F24728C1C2 for ; Wed, 2 Dec 2009 04:46:19 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C5606D800F5; Wed, 2 Dec 2009 13:46:11 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091202122438.GB7160@elstar.local> References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> <1259756372.24695.23.camel@missotis> <20091202122438.GB7160@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 13:46:10 +0100 Message-ID: <1259757970.24695.42.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] when 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, 02 Dec 2009 12:46:20 -0000 Juergen Schoenwaelder píše v St 02. 12. 2009 v 13:24 +0100: > On Wed, Dec 02, 2009 at 01:19:32PM +0100, Ladislav Lhotka wrote: > > Andy Bierman p????e v St 02. 12. 2009 v 02:38 -0800: > > > The 'when' and 'if-feature' statements combine > > > to form an intensely complex implementation > > > requirement. So what? Nobody said implementing > > > YANG would be easy. > > > > But it should at least be based on sound principles, or we will find > > ourselves writing a new "Lessons learned ..." draft after few more > > years. YANG is said to be simple but the fact is that it is now so > > complex that its "grammars" cannot be even classified within the Chomsky > > hierarchy - and we don't care? > > Please provide evidence. Even the most general - type 0 - grammar only knows about terminals, non-terminals and production rules, there are no conditionals. You can implement very limited context sensitivity like this: ::= 1 | 2 and the same can be done in XSD and RELAX NG. What 'when' in YANG attempts to do is ::= if "y<=1" then else > > > XSD was carefully designed to produce context-free grammars. It turned > > out it couldn't handle arbitrary order of children. RELAX NG can handle > > this very well because it is based on the theory of hedge automata. > > > > In both cases, it has been mathematically proven that there is an > > algorithm for checking instance membership (validity). We can't hope to > > do this for YANG, so I am extremely cautious about all "powerful" and > > "flexible" features that move too far away from the established models. > > It will help me a lot if you can write up a clear email providing > evidence (e.g. by presenting a valid example) that it is not decidable > whether an instance document is valid or not. I started this thread by providing such an example. Is the document containing neither nor valid or not? Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Wed Dec 2 04:50: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 E57D128C190 for ; Wed, 2 Dec 2009 04:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=-2.370, 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 9qYesp48G1rm for ; Wed, 2 Dec 2009 04:50:10 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 8522E28C0EA for ; Wed, 2 Dec 2009 04:50:10 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NFoeb-0003vT-5z; Wed, 02 Dec 2009 13:49:57 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id 29F472F593; Wed, 2 Dec 2009 13:49:57 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NFoeb-0003av-0m; Wed, 02 Dec 2009 13:49:57 +0100 Message-ID: <4B166274.9040308@bwijnen.net> Date: Wed, 02 Dec 2009 13:49:56 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andy Bierman References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> In-Reply-To: <4B16438A.6080406@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd49abd8b62a201c35390c5ce3810f123d6 Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 12:50:12 -0000 Andy Bierman wrote: > The 'when' and 'if-feature' statements combine > to form an intensely complex implementation > requirement. So what? Nobody said implementing > YANG would be easy. > > Statements like the above make me worried!!!! That was not what we set out to do was it? Bert From mbj@tail-f.com Wed Dec 2 05:10: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 C2BEB28C1C9 for ; Wed, 2 Dec 2009 05:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, 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 GiOXjD52-obK for ; Wed, 2 Dec 2009 05:10:39 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 542DF3A684A for ; Wed, 2 Dec 2009 05:10:38 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9930D76C6DB; Wed, 2 Dec 2009 14:10:29 +0100 (CET) Date: Wed, 02 Dec 2009 14:10:29 +0100 (CET) Message-Id: <20091202.141029.185100377.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1259757970.24695.42.camel@missotis> References: <1259756372.24695.23.camel@missotis> <20091202122438.GB7160@elstar.local> <1259757970.24695.42.camel@missotis> X-Mailer: Mew version 6.2.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] when 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, 02 Dec 2009 13:10:40 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyIHDDrcWhZSB2IFN0IDAyLiAxMi4gMjAwOSB2IDEzOjI0ICswMTAwOg0KPiA+IE9u IFdlZCwgRGVjIDAyLCAyMDA5IGF0IDAxOjE5OjMyUE0gKzAxMDAsIExhZGlzbGF2IExob3RrYSB3 cm90ZToNCj4gPiA+IEFuZHkgQmllcm1hbiBwPz8/P2UgdiBTdCAwMi4gMTIuIDIwMDkgdiAwMjoz OCAtMDgwMDoNCj4gPiA+ID4gVGhlICd3aGVuJyBhbmQgJ2lmLWZlYXR1cmUnIHN0YXRlbWVudHMg Y29tYmluZQ0KPiA+ID4gPiB0byBmb3JtIGFuIGludGVuc2VseSBjb21wbGV4IGltcGxlbWVudGF0 aW9uDQo+ID4gPiA+IHJlcXVpcmVtZW50LiAgU28gd2hhdD8gIE5vYm9keSBzYWlkIGltcGxlbWVu dGluZw0KPiA+ID4gPiBZQU5HIHdvdWxkIGJlIGVhc3kuDQo+ID4gPiANCj4gPiA+IEJ1dCBpdCBz aG91bGQgYXQgbGVhc3QgYmUgYmFzZWQgb24gc291bmQgcHJpbmNpcGxlcywgb3Igd2Ugd2lsbCBm aW5kDQo+ID4gPiBvdXJzZWx2ZXMgd3JpdGluZyBhIG5ldyAiTGVzc29ucyBsZWFybmVkIC4uLiIg ZHJhZnQgYWZ0ZXIgZmV3IG1vcmUNCj4gPiA+IHllYXJzLiBZQU5HIGlzIHNhaWQgdG8gYmUgc2lt cGxlIGJ1dCB0aGUgZmFjdCBpcyB0aGF0IGl0IGlzIG5vdyBzbw0KPiA+ID4gY29tcGxleCB0aGF0 IGl0cyAiZ3JhbW1hcnMiIGNhbm5vdCBiZSBldmVuIGNsYXNzaWZpZWQgd2l0aGluIHRoZSBDaG9t c2t5DQo+ID4gPiBoaWVyYXJjaHkgLSBhbmQgd2UgZG9uJ3QgY2FyZT8NCj4gPiANCj4gPiBQbGVh c2UgcHJvdmlkZSBldmlkZW5jZS4NCj4gDQo+IEV2ZW4gdGhlIG1vc3QgZ2VuZXJhbCAtIHR5cGUg MCAtIGdyYW1tYXIgb25seSBrbm93cyBhYm91dCB0ZXJtaW5hbHMsDQo+IG5vbi10ZXJtaW5hbHMg YW5kIHByb2R1Y3Rpb24gcnVsZXMsIHRoZXJlIGFyZSBubyBjb25kaXRpb25hbHMuIFlvdSBjYW4N Cj4gaW1wbGVtZW50IHZlcnkgbGltaXRlZCBjb250ZXh0IHNlbnNpdGl2aXR5IGxpa2UgdGhpczoN Cj4gDQo+IDxmb28+IDo6PSAxPHg+IHwgMg0KPiANCj4gYW5kIHRoZSBzYW1lIGNhbiBiZSBkb25l IGluIFhTRCBhbmQgUkVMQVggTkcuIFdoYXQgJ3doZW4nIGluIFlBTkcNCj4gYXR0ZW1wdHMgdG8g ZG8gaXMNCj4gDQo+IDxmb28+IDo6PSBpZiAieTw9MSIgdGhlbiA8eT48eD4gZWxzZSA8eT4gDQoN CkJ1dCB5b3UgcHJvdmlkZWQgYW4gZXF1aXZhbGVudCBtdXN0IGV4cHJlc3Npb24gd2hpY2ggeW91 IHdlcmUgaGFwcHkNCndpdGguDQoNCkluIG15IHZpZXcsIHRoZSBzY2hlbWEgaXMgZml4ZWQsIGFu ZCB0aGUgd2hlbiAoYW5kIG11c3QpIGV4cHJlc3Npb25zDQpzcGVjaWZ5IGNvbnN0cmFpbnRzIG9u IGNvbnRlbnQgKGluc3RhbmNlIGRvY3VtZW50cykuDQoNClRoZSBkaWZmZXJlbmNlIGJldHdlZW4g d2hlbiBhbmQgbXVzdCBpcyB3aGVuL2hvdyB0aGV5IGFyZSBlbmZvcmNlZC4NCg0KPiA+ID4gWFNE IHdhcyBjYXJlZnVsbHkgZGVzaWduZWQgdG8gcHJvZHVjZSBjb250ZXh0LWZyZWUgZ3JhbW1hcnMu IEl0IHR1cm5lZA0KPiA+ID4gb3V0IGl0IGNvdWxkbid0IGhhbmRsZSBhcmJpdHJhcnkgb3JkZXIg b2YgY2hpbGRyZW4uIFJFTEFYIE5HIGNhbiBoYW5kbGUNCj4gPiA+IHRoaXMgdmVyeSB3ZWxsIGJl Y2F1c2UgaXQgaXMgYmFzZWQgb24gdGhlIHRoZW9yeSBvZiBoZWRnZSBhdXRvbWF0YS4NCj4gPiA+ IA0KPiA+ID4gSW4gYm90aCBjYXNlcywgaXQgaGFzIGJlZW4gbWF0aGVtYXRpY2FsbHkgcHJvdmVu IHRoYXQgdGhlcmUgaXMgYW4NCj4gPiA+IGFsZ29yaXRobSBmb3IgY2hlY2tpbmcgaW5zdGFuY2Ug bWVtYmVyc2hpcCAodmFsaWRpdHkpLiBXZSBjYW4ndCBob3BlIHRvDQo+ID4gPiBkbyB0aGlzIGZv ciBZQU5HLCBzbyBJIGFtIGV4dHJlbWVseSBjYXV0aW91cyBhYm91dCBhbGwgInBvd2VyZnVsIiBh bmQNCj4gPiA+ICJmbGV4aWJsZSIgZmVhdHVyZXMgdGhhdCBtb3ZlIHRvbyBmYXIgYXdheSBmcm9t IHRoZSBlc3RhYmxpc2hlZCBtb2RlbHMuDQo+ID4gDQo+ID4gSXQgd2lsbCBoZWxwIG1lIGEgbG90 IGlmIHlvdSBjYW4gd3JpdGUgdXAgYSBjbGVhciBlbWFpbCBwcm92aWRpbmcNCj4gPiBldmlkZW5j ZSAoZS5nLiBieSBwcmVzZW50aW5nIGEgdmFsaWQgZXhhbXBsZSkgdGhhdCBpdCBpcyBub3QgZGVj aWRhYmxlDQo+ID4gd2hldGhlciBhbiBpbnN0YW5jZSBkb2N1bWVudCBpcyB2YWxpZCBvciBub3Qu DQo+IA0KPiBJIHN0YXJ0ZWQgdGhpcyB0aHJlYWQgYnkgcHJvdmlkaW5nIHN1Y2ggYW4gZXhhbXBs ZS4gSXMgdGhlIGRvY3VtZW50DQo+IGNvbnRhaW5pbmcgbmVpdGhlciA8Zm9vPiBub3IgPGJhcj4g dmFsaWQgb3Igbm90Pw0KDQpZZXMgaXQgaXMgdmFsaWQuICB3aGVuIGV4cHJlc3Npb25zIGFyZSBu b3QgZXZhbHVhdGVkIGZvciBub2RlcyB0aGF0IGRvDQpub3QgZXhpc3QuDQoNClRoZSBwcm9ibGVt IHdpdGggeW91ciBleGFtcGxlIGlzIHRoYXQgaXMgaGFkIGJvdGggJ3doZW4nIGFuZA0KJ2RlZmF1 bHQnLCBhbmQgaW4geW91ciBzdGVwIDIgeW91IGFkZGVkIHRoZSBkZWZhdWx0IHZhbHVlcyB0byB0 aGUgdHJlZQ0KYW5kIHRoZW4gZXZhbHVhdGVkIHRoZSB3aGVuIGV4cHJlc3Npb24gZm9yIHRoZXNl IGxlYWZzIC0gYnV0IHRoZXkgd2VyZQ0Kbm90IHRoZXJlIGZyb20gdGhlIHN0YXJ0LCBzbyB5b3Ug c2hvdWxkIG5vdCBldmFsdWF0ZSB0aGVpciB3aGVuDQpleHByZXNzaW9ucy4NCg0KTWF5YmUgd2Ug c2hvdWxkIG5vdCBhbGxvdyBkZWZhdWx0IGFuZCB3aGVuIGF0IHRoZSBzYW1lIHRpbWUuDQpPdGhl cndpc2Ugd2UnZCBoYXZlIHRvIGludGVycHJldCB0aGlzIGFzIGEgY29uZGl0aW9uYWwgZGVmYXVs dCwgYW5kIEkNCnRoaW5rIHRoYXQgd291bGQgYmUgdG9vIGNvbXBsaWNhdGVkLiAgKGkuZS4gaWYg dGhlIG5vZGUgaXMgbm90IHRoZXJlDQphbmQgaXRzIHdoZW4gZXhwcmVzc2lvbiBpcyB0cnVlLCB0 aGVuIHRoZSBkZWZhdWx0IHZhbHVlIGFwcGxpZXM7IGJ1dA0KaWYgaXQgaXMgbm90IHRoZXJlIGFu ZCBpdHMgd2hlbiBleHByZXNzaW9uIGlzIGZhbHNlLCB0aGVuIHRoZSBkZWZhdWx0DQpkb2Vzbid0 IGFwcGx5IGVpdGhlcikuDQoNCg0KDQovbWFydGluDQo= From lhotka@cesnet.cz Wed Dec 2 06:00: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 0ACED3A6AC2 for ; Wed, 2 Dec 2009 06:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.883 X-Spam-Level: X-Spam-Status: No, score=-0.883 tagged_above=-999 required=5 tests=[AWL=0.367, 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 eTJmW6dt2pxQ for ; Wed, 2 Dec 2009 06:00:44 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C51783A6A5C for ; Wed, 2 Dec 2009 06:00:43 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8D6CCD800E8; Wed, 2 Dec 2009 15:00:35 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091202.141029.185100377.mbj@tail-f.com> References: <1259756372.24695.23.camel@missotis> <20091202122438.GB7160@elstar.local> <1259757970.24695.42.camel@missotis> <20091202.141029.185100377.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 15:00:33 +0100 Message-ID: <1259762433.24695.94.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 14:00:45 -0000 Martin Bjorklund píše v St 02. 12. 2009 v 14:10 +0100: > Ladislav Lhotka wrote: > > Juergen Schoenwaelder píše v St 02. 12. 2009 v 13:24 +0100: > > > On Wed, Dec 02, 2009 at 01:19:32PM +0100, Ladislav Lhotka wrote: > > > > Andy Bierman p????e v St 02. 12. 2009 v 02:38 -0800: > > > > > The 'when' and 'if-feature' statements combine > > > > > to form an intensely complex implementation > > > > > requirement. So what? Nobody said implementing > > > > > YANG would be easy. > > > > > > > > But it should at least be based on sound principles, or we will find > > > > ourselves writing a new "Lessons learned ..." draft after few more > > > > years. YANG is said to be simple but the fact is that it is now so > > > > complex that its "grammars" cannot be even classified within the Chomsky > > > > hierarchy - and we don't care? > > > > > > Please provide evidence. > > > > Even the most general - type 0 - grammar only knows about terminals, > > non-terminals and production rules, there are no conditionals. You can > > implement very limited context sensitivity like this: > > > > ::= 1 | 2 > > > > and the same can be done in XSD and RELAX NG. What 'when' in YANG > > attempts to do is > > > > ::= if "y<=1" then else > > But you provided an equivalent must expression which you were happy > with. No, the 'must' expression has nothing to do with the grammar, it is only a semantic rule that the conceptual data tree is checked against. > > In my view, the schema is fixed, and the when (and must) expressions > specify constraints on content (instance documents). But there are grammatic (syntactic) constraints and semantic constraints. 'when' mixes them together. > > The difference between when and must is when/how they are enforced. > > > > > XSD was carefully designed to produce context-free grammars. It turned > > > > out it couldn't handle arbitrary order of children. RELAX NG can handle > > > > this very well because it is based on the theory of hedge automata. > > > > > > > > In both cases, it has been mathematically proven that there is an > > > > algorithm for checking instance membership (validity). We can't hope to > > > > do this for YANG, so I am extremely cautious about all "powerful" and > > > > "flexible" features that move too far away from the established models. > > > > > > It will help me a lot if you can write up a clear email providing > > > evidence (e.g. by presenting a valid example) that it is not decidable > > > whether an instance document is valid or not. > > > > I started this thread by providing such an example. Is the document > > containing neither nor valid or not? > > Yes it is valid. when expressions are not evaluated for nodes that do > not exist. So what is in the reply to if with-defaults is set to "report-all"? If nothing, both 'when' expressions in the data model evaluate as true, so both nodes are valid and their defaults should apply, which however makes the 'when' expressions false. > > The problem with your example is that is had both 'when' and > 'default', and in your step 2 you added the default values to the tree > and then evaluated the when expression for these leafs - but they were > not there from the start, so you should not evaluate their when > expressions. > > Maybe we should not allow default and when at the same time. > Otherwise we'd have to interpret this as a conditional default, and I > think that would be too complicated. (i.e. if the node is not there > and its when expression is true, then the default value applies; but > if it is not there and its when expression is false, then the default > doesn't apply either). The same problem is with 'mandatory': leaf foo { mandatory true; when "not(bar)"; ... } leaf bar { mandatory true; when "not(foo)"; ... } Again, this looks trivial, but the same logic can be buried deeply in XPath expressions and more nodes may be involved. And forbidding 'when' as a sibling of 'default' also doesn't help: container superfoo { when "not(../superbar/bar = 1)"; leaf foo { type uint8; default 42; } } container superbar { when "not(../superfoo/foo = 42)"; leaf bar { type uint8; default 1; } } If there is neither nor , we have the same problem as before. Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Dec 2 06:08: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 ECC0D3A6AD1 for ; Wed, 2 Dec 2009 06:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, 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 U5IB2jyIJk5o for ; Wed, 2 Dec 2009 06:08:54 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 254CA3A6ACA for ; Wed, 2 Dec 2009 06:08:53 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DEEB476C6DB; Wed, 2 Dec 2009 15:08:45 +0100 (CET) Date: Wed, 02 Dec 2009 15:08:45 +0100 (CET) Message-Id: <20091202.150845.247944292.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1259762433.24695.94.camel@missotis> References: <1259757970.24695.42.camel@missotis> <20091202.141029.185100377.mbj@tail-f.com> <1259762433.24695.94.camel@missotis> X-Mailer: Mew version 6.2.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] when 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, 02 Dec 2009 14:08:55 -0000 Ladislav Lhotka wrote: > > In my view, the schema is fixed, and the when (and must) expressions > > specify constraints on content (instance documents). > > But there are grammatic (syntactic) constraints and semantic > constraints. 'when' mixes them together. Why do you think it does? Why can't you view when as providing semantic constraints like must? > > Maybe we should not allow default and when at the same time. > > Otherwise we'd have to interpret this as a conditional default, and I > > think that would be too complicated. (i.e. if the node is not there > > and its when expression is true, then the default value applies; but > > if it is not there and its when expression is false, then the default > > doesn't apply either). > > The same problem is with 'mandatory': > > leaf foo { > mandatory true; > when "not(bar)"; > ... > } > leaf bar { > mandatory true; > when "not(foo)"; > ... > } And you get the same problem with s/when/must/g above. /martin From j.schoenwaelder@jacobs-university.de Wed Dec 2 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 CE2053A6ACA for ; Wed, 2 Dec 2009 06:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.261, 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 2si90olfY6Kr for ; Wed, 2 Dec 2009 06:16:59 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C6DC93A6ABF for ; Wed, 2 Dec 2009 06:16:58 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF481C000E; Wed, 2 Dec 2009 15:16:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ufV-nnfzmVpR; Wed, 2 Dec 2009 15:16:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A6D7C000D; Wed, 2 Dec 2009 15:16:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 57B8CE41508; Wed, 2 Dec 2009 15:16:49 +0100 (CET) Date: Wed, 2 Dec 2009 15:16:49 +0100 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20091202141649.GA7346@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , Andy Bierman , "netmod@ietf.org" References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> <4B166274.9040308@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B166274.9040308@bwijnen.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] when issues 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, 02 Dec 2009 14:16:59 -0000 On Wed, Dec 02, 2009 at 01:49:56PM +0100, Bert (IETF) Wijnen wrote: > Andy Bierman wrote: > > The 'when' and 'if-feature' statements combine > > to form an intensely complex implementation > > requirement. So what? Nobody said implementing > > YANG would be easy. > > > > > Statements like the above make me worried!!!! > That was not what we set out to do was it? I suggest to ignore the statement. Every data modeling language allows to write down data models that can't be implemented. This is not a new feature invented by YANG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Dec 2 06:31: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 0E0873A685B for ; Wed, 2 Dec 2009 06:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.249, 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 Np7vwmjskoTD for ; Wed, 2 Dec 2009 06:31:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C95F128C1EC for ; Wed, 2 Dec 2009 06:31:00 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D133DC000E; Wed, 2 Dec 2009 15:30:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 38qRtfa3nomo; Wed, 2 Dec 2009 15:30:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7980C000D; Wed, 2 Dec 2009 15:30:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1D098E415D4; Wed, 2 Dec 2009 15:30:51 +0100 (CET) Date: Wed, 2 Dec 2009 15:30:51 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091202143051.GB7346@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> <1259756372.24695.23.camel@missotis> <20091202122438.GB7160@elstar.local> <1259757970.24695.42.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1259757970.24695.42.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] when issues 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, 02 Dec 2009 14:31:02 -0000 On Wed, Dec 02, 2009 at 01:46:10PM +0100, Ladislav Lhotka wrote: > Even the most general - type 0 - grammar only knows about terminals, > non-terminals and production rules, there are no conditionals. You can > implement very limited context sensitivity like this: > > ::= 1 | 2 > > and the same can be done in XSD and RELAX NG. What 'when' in YANG > attempts to do is > > ::= if "y<=1" then else I know what a type 0 grammar is, still I can't follow. > I started this thread by providing such an example. Is the document > containing neither nor valid or not? So I guess you mean this one: leaf foo { type uint8; default 42; when "not(../bar=1)"; } leaf bar { type uint8; default 1; when "not(../foo=42)"; } The _grammar_ for the XML instance document is pretty clear I would say. Neither the semantics in the when clauses nor the instance document change the _grammar_. Your other question is whether both and can exist. Yes, I think this is possible and this would be a valid instance: 0 0 Your question was about what happens if there are no explicit values and the default statements kick in. In that case, you run into a _semantic_ contradiction but _not_ into a grammar contradiction. Hence, I fail to see the link to Chomsky language hierarchies. And for what its worth, this example can be written without a when statement: leaf foo { type uint8; default 42; description "this leaf exists only when bar != 1"; } leaf bar { type uint8; default 1; description "this leaf exists only when foo != 42"; } I see no change in the Chomsky hierarchy between these two versions of the example. Both examples simply show the same modeling error. /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 Wed Dec 2 06:34: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 A1A873A6ACC for ; Wed, 2 Dec 2009 06:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=0.350, 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 y00C8kIZYuSQ for ; Wed, 2 Dec 2009 06:34:28 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CD53E3A6AD6 for ; Wed, 2 Dec 2009 06:34:27 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id ABFE7D800CE for ; Wed, 2 Dec 2009 15:34:19 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20091202.150845.247944292.mbj@tail-f.com> References: <1259757970.24695.42.camel@missotis> <20091202.141029.185100377.mbj@tail-f.com> <1259762433.24695.94.camel@missotis> <20091202.150845.247944292.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 15:34:18 +0100 Message-ID: <1259764458.24695.115.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] when 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, 02 Dec 2009 14:34:31 -0000 Martin Bjorklund píše v St 02. 12. 2009 v 15:08 +0100: > Ladislav Lhotka wrote: > > > In my view, the schema is fixed, and the when (and must) expressions > > > specify constraints on content (instance documents). > > > > But there are grammatic (syntactic) constraints and semantic > > constraints. 'when' mixes them together. > > Why do you think it does? Why can't you view when as providing > semantic constraints like must? This is what I tried to suggest by checking them after doing (independently) the grammar validation and applying the defaults. Your example with list ordinality indicates that the purpose of 'when' is to take effect at the same time as the grammar. > > > > > Maybe we should not allow default and when at the same time. > > > Otherwise we'd have to interpret this as a conditional default, and I > > > think that would be too complicated. (i.e. if the node is not there > > > and its when expression is true, then the default value applies; but > > > if it is not there and its when expression is false, then the default > > > doesn't apply either). > > > > The same problem is with 'mandatory': > > > > leaf foo { > > mandatory true; > > when "not(bar)"; > > ... > > } > > leaf bar { > > mandatory true; > > when "not(foo)"; > > ... > > } > > And you get the same problem with s/when/must/g above. No, I don't, because I can never end up in a deadlock. A document without and/or is gramatically invalid and document with both of them is semantically invalid. So the module is broken but it will not make my device cycle forever. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Dec 2 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 26A1228C1F1 for ; Wed, 2 Dec 2009 07:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[AWL=0.334, 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 IER9eshPSBZj for ; Wed, 2 Dec 2009 07:29:51 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1935228C1EC for ; Wed, 2 Dec 2009 07:29:51 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C9E1AD800C0; Wed, 2 Dec 2009 16:29:42 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091202143051.GB7346@elstar.local> References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> <1259756372.24695.23.camel@missotis> <20091202122438.GB7160@elstar.local> <1259757970.24695.42.camel@missotis> <20091202143051.GB7346@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 16:29:41 +0100 Message-ID: <1259767781.24695.168.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] when 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, 02 Dec 2009 15:29:52 -0000 Juergen Schoenwaelder píše v St 02. 12. 2009 v 15:30 +0100: > On Wed, Dec 02, 2009 at 01:46:10PM +0100, Ladislav Lhotka wrote: > > > Even the most general - type 0 - grammar only knows about terminals, > > non-terminals and production rules, there are no conditionals. You can > > implement very limited context sensitivity like this: > > > > ::= 1 | 2 > > > > and the same can be done in XSD and RELAX NG. What 'when' in YANG > > attempts to do is > > > > ::= if "y<=1" then else > > I know what a type 0 grammar is, still I can't follow. The rule like the last one is not type 0 production rule. Consider this: leaf y { type unit32; } leaf x { mandatory true; type int32; when "../y<=1"; } A true grammar rule can only say that x is mandatory. So 2 will be grammatically invalid, no matter what the semantic rule says. > > > I started this thread by providing such an example. Is the document > > containing neither nor valid or not? > > So I guess you mean this one: > > leaf foo { > type uint8; > default 42; > when "not(../bar=1)"; > } > leaf bar { > type uint8; > default 1; > when "not(../foo=42)"; > } > > The _grammar_ for the XML instance document is pretty clear I would > say. Neither the semantics in the when clauses nor the instance > document change the _grammar_. If I understand what 'when' is supposed to do in YANG, the grammar - ordinality of nodes - is not fully determined without knowing the uint8 values in a particular instance. In particular, if 'when' is a substatement of 'uses', then clearly the grouping may or may not contribute new nodes, depending on the result of an XPath expression. But if we agree that it is not the case - that the grammar simply says that both nodes are optional in this example - then it is exactly what I suggested: the grammar is determined first, the instance document validated against it, defaults are applied and only then the semantic 'when' rules are checked. Lada > > Your other question is whether both and can exist. Yes, > I think this is possible and this would be a valid instance: > > 0 > 0 > > Your question was about what happens if there are no explicit values > and the default statements kick in. In that case, you run into a > _semantic_ contradiction but _not_ into a grammar contradiction. > Hence, I fail to see the link to Chomsky language hierarchies. And for > what its worth, this example can be written without a when statement: > > leaf foo { > type uint8; > default 42; > description "this leaf exists only when bar != 1"; > } > leaf bar { > type uint8; > default 1; > description "this leaf exists only when foo != 42"; > } > > I see no change in the Chomsky hierarchy between these two versions of > the example. Both examples simply show the same modeling error. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Dec 2 08:20: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 2E90028C204 for ; Wed, 2 Dec 2009 08:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.238, 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 WojxswwmoaH8 for ; Wed, 2 Dec 2009 08:20:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A039928C1FC for ; Wed, 2 Dec 2009 08:20:11 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9922DC000D; Wed, 2 Dec 2009 17:20:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dtQQ5e3eaq0P; Wed, 2 Dec 2009 17:20:02 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14046C0037; Wed, 2 Dec 2009 17:20:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6CF8FE41C85; Wed, 2 Dec 2009 17:20:01 +0100 (CET) Date: Wed, 2 Dec 2009 17:20:01 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091202162001.GA7889@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> <1259756372.24695.23.camel@missotis> <20091202122438.GB7160@elstar.local> <1259757970.24695.42.camel@missotis> <20091202143051.GB7346@elstar.local> <1259767781.24695.168.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1259767781.24695.168.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] when issues 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, 02 Dec 2009 16:20:13 -0000 On Wed, Dec 02, 2009 at 04:29:41PM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v St 02. 12. 2009 v 15:30 +0100: > > On Wed, Dec 02, 2009 at 01:46:10PM +0100, Ladislav Lhotka wrote: > > > > > Even the most general - type 0 - grammar only knows about terminals, > > > non-terminals and production rules, there are no conditionals. You can > > > implement very limited context sensitivity like this: > > > > > > ::= 1 | 2 > > > > > > and the same can be done in XSD and RELAX NG. What 'when' in YANG > > > attempts to do is > > > > > > ::= if "y<=1" then else > > > > I know what a type 0 grammar is, still I can't follow. > > The rule like the last one is not type 0 production rule. > Consider this: > > leaf y { > type unit32; > } > leaf x { > mandatory true; > type int32; > when "../y<=1"; > } > > A true grammar rule can only say that x is mandatory. So 2 will > be grammatically invalid, no matter what the semantic rule says. You seem to be trying to translate semantic contraints down into grammar, which generally does not work. Even in languages like C, I can write int i = 1 / 0; and this does not violate the grammar. Semantically, this is broken and some compilers catch this (gcc by default emits a warning, not a parse error). > > > I started this thread by providing such an example. Is the document > > > containing neither nor valid or not? > > > > So I guess you mean this one: > > > > leaf foo { > > type uint8; > > default 42; > > when "not(../bar=1)"; > > } > > leaf bar { > > type uint8; > > default 1; > > when "not(../foo=42)"; > > } > > > > The _grammar_ for the XML instance document is pretty clear I would > > say. Neither the semantics in the when clauses nor the instance > > document change the _grammar_. > > If I understand what 'when' is supposed to do in YANG, the grammar - > ordinality of nodes - is not fully determined without knowing the uint8 > values in a particular instance. In particular, if 'when' is a > substatement of 'uses', then clearly the grouping may or may not > contribute new nodes, depending on the result of an XPath expression. > > But if we agree that it is not the case - that the grammar simply says > that both nodes are optional in this example - then it is exactly what I > suggested: the grammar is determined first, the instance document > validated against it, defaults are applied and only then the semantic > 'when' rules are checked. Can we agree on this: The 'when' and 'must' statements do not affect the grammar - they are semantic constraints. A valid document needs to satisfy the grammar constraints and the semantic constraints. For me, having agreement on this would also be sufficient - I do not think we need to spell out how and which conflicts or inconsistencies have to be detected at compile time and which ones at run time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Dec 2 08:22: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 6E17E28C219 for ; Wed, 2 Dec 2009 08:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 K1gOAVGCwyWe for ; Wed, 2 Dec 2009 08:22:46 -0800 (PST) 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 C694728C1FC for ; Wed, 2 Dec 2009 08:22:46 -0800 (PST) Received: (qmail 36923 invoked from network); 2 Dec 2009 16:22:36 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 02 Dec 2009 08:22:36 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: EEWb7TwVM1meXcHWN3TjVxzERR9yiKPD.RwidJZR9Fn0T.DBMHX3BR9TKHE2fifC1_1JABiWUr6N6BDesmNsi..yPPc00r8J_A2H6XMgSyNZd1Vk.w49xqUBmD9XpkEI1OLm.WtMeuvOO9ecIUYqnPyWLNFalFI0FE99xGjX0NsDfHkor4hlBNE5lXwDHoxhR_YUJ_Ch4R883PgAKYIknAGh3vH3wys4Gc2Os_MmBccrQkagFw4X2ngbildW5dQF X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16946C.6010102@netconfcentral.com> Date: Wed, 02 Dec 2009 08:23:08 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Bert \(IETF\) Wijnen" References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> <4B166274.9040308@bwijnen.net> In-Reply-To: <4B166274.9040308@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 16:22:47 -0000 Bert (IETF) Wijnen wrote: > Andy Bierman wrote: >> The 'when' and 'if-feature' statements combine >> to form an intensely complex implementation >> requirement. So what? Nobody said implementing >> YANG would be easy. >> >> > Statements like the above make me worried!!!! > That was not what we set out to do was it? > There are lots of loops to detect, but they are the responsibility of the compiler. Since 'when' expression evaluation depends on the database values at run-time, the server has to detect these loops. Of course, none of YANG has to be implemented in an automated fashion in the central stack. The draft has some text explaining how a server doesn't really need XPath. (It just needs to implement the behavior of specific data nodes in YANG modules.) In this case the complexity is obvious isn't it? In order to find out if /x is allowed, the values in the XPath expression need to be retrieved. In order to retrieve the value, the server first has to make sure the 'when' condition is met, so those values have to retrieved first. It could be challenging for an implementation to ever decide either /x or /y is allowed to exist. Using must-stmt like loop detection, the expression will always be false (because breaking the loop looks the same as if the node does not exist). > Bert > > Andy From lhotka@cesnet.cz Wed Dec 2 08:56: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 0CF543A6870 for ; Wed, 2 Dec 2009 08:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=0.319, 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 HO3jQFIJrV3k for ; Wed, 2 Dec 2009 08:56:39 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2F57A3A6AD6 for ; Wed, 2 Dec 2009 08:56:39 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2C6D5D800F3; Wed, 2 Dec 2009 17:56:31 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091202162001.GA7889@elstar.local> References: <1259737511.22111.49.camel@missotis> <20091202.083103.38229948.mbj@tail-f.com> <4B16438A.6080406@netconfcentral.com> <1259756372.24695.23.camel@missotis> <20091202122438.GB7160@elstar.local> <1259757970.24695.42.camel@missotis> <20091202143051.GB7346@elstar.local> <1259767781.24695.168.camel@missotis> <20091202162001.GA7889@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Dec 2009 17:56:29 +0100 Message-ID: <1259772989.24695.199.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] when 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, 02 Dec 2009 16:56:40 -0000 Juergen Schoenwaelder píše v St 02. 12. 2009 v 17:20 +0100: > > > > leaf y { > > type unit32; > > } > > leaf x { > > mandatory true; > > type int32; > > when "../y<=1"; > > } > > > > A true grammar rule can only say that x is mandatory. So 2 will > > be grammatically invalid, no matter what the semantic rule says. > > You seem to be trying to translate semantic contraints down into How did you come to this conclusion? I think exactly the opposite is true. As you say below: 'when' statement does not affect the grammar, so node "x" is mandatory and the document 2 is not grammatically correct because is missing. But this is what Martin protested against. It would be useful to clarify our positions on this example. Martin? > Can we agree on this: The 'when' and 'must' statements do not affect > the grammar - they are semantic constraints. A valid document needs to > satisfy the grammar constraints and the semantic constraints. Yes, we are in a perfect agreement here. :-) In any case, this is how the DSDL mapping works - grammar translates to RELAX NG, 'must' and 'when' to Schematron. Lada > > For me, having agreement on this would also be sufficient - I do not > think we need to spell out how and which conflicts or inconsistencies > have to be detected at compile time and which ones at run time. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Dec 2 09:42: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 40E3F3A686C for ; Wed, 2 Dec 2009 09:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Mla6r3RKWZ15 for ; Wed, 2 Dec 2009 09:42:17 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 312033A687C for ; Wed, 2 Dec 2009 09:42:15 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7A52E616001; Wed, 2 Dec 2009 18:42:06 +0100 (CET) Date: Wed, 02 Dec 2009 18:42:06 +0100 (CET) Message-Id: <20091202.184206.202657795.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1259772989.24695.199.camel@missotis> References: <1259767781.24695.168.camel@missotis> <20091202162001.GA7889@elstar.local> <1259772989.24695.199.camel@missotis> X-Mailer: Mew version 6.2.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] when 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, 02 Dec 2009 17:42:18 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyIHDDrcWhZSB2IFN0IDAyLiAxMi4gMjAwOSB2IDE3OjIwICswMTAwOg0KPiA+ID4g DQo+ID4gPiBsZWFmIHkgew0KPiA+ID4gICAgIHR5cGUgdW5pdDMyOw0KPiA+ID4gfQ0KPiA+ID4g bGVhZiB4IHsNCj4gPiA+ICAgICBtYW5kYXRvcnkgdHJ1ZTsNCj4gPiA+ICAgICB0eXBlIGludDMy Ow0KPiA+ID4gICAgIHdoZW4gIi4uL3k8PTEiOw0KPiA+ID4gfQ0KPiA+ID4gDQo+ID4gPiBBIHRy dWUgZ3JhbW1hciBydWxlIGNhbiBvbmx5IHNheSB0aGF0IHggaXMgbWFuZGF0b3J5LiBTbyA8eT4y PC95PiB3aWxsDQo+ID4gPiBiZSBncmFtbWF0aWNhbGx5IGludmFsaWQsIG5vIG1hdHRlciB3aGF0 IHRoZSBzZW1hbnRpYyBydWxlIHNheXMuDQo+ID4gDQo+ID4gWW91IHNlZW0gdG8gYmUgdHJ5aW5n IHRvIHRyYW5zbGF0ZSBzZW1hbnRpYyBjb250cmFpbnRzIGRvd24gaW50bw0KPiANCj4gSG93IGRp ZCB5b3UgY29tZSB0byB0aGlzIGNvbmNsdXNpb24/DQoNClRoYXQncyBhbHNvIGhvdyBJIHJlYWQg eW91ciBhcmd1bWVudHMsIGFuZCB3aGF0IEkgKHRob3VnaHQgSSkgcHJvdGVzdGVkDQphZ2FpbnN0 LiANCg0KPiBJIHRoaW5rIGV4YWN0bHkgdGhlIG9wcG9zaXRlIGlzDQo+IHRydWUuIEFzIHlvdSBz YXkgYmVsb3c6ICd3aGVuJyBzdGF0ZW1lbnQgZG9lcyBub3QgYWZmZWN0IHRoZSBncmFtbWFyLCBz bw0KPiBub2RlICJ4IiBpcyBtYW5kYXRvcnkgYW5kIHRoZSBkb2N1bWVudCA8eT4yPC95PiBpcyBu b3QgZ3JhbW1hdGljYWxseQ0KPiBjb3JyZWN0IGJlY2F1c2UgPHg+IGlzIG1pc3NpbmcuIEJ1dCB0 aGlzIGlzIHdoYXQgTWFydGluIHByb3Rlc3RlZA0KPiBhZ2FpbnN0LiBJdCB3b3VsZCBiZSB1c2Vm dWwgdG8gY2xhcmlmeSBvdXIgcG9zaXRpb25zIG9uIHRoaXMgZXhhbXBsZS4NCj4gTWFydGluPw0K PiAgDQo+ID4gQ2FuIHdlIGFncmVlIG9uIHRoaXM6IFRoZSAnd2hlbicgYW5kICdtdXN0JyBzdGF0 ZW1lbnRzIGRvIG5vdCBhZmZlY3QNCj4gPiB0aGUgZ3JhbW1hciAtIHRoZXkgYXJlIHNlbWFudGlj IGNvbnN0cmFpbnRzLiBBIHZhbGlkIGRvY3VtZW50IG5lZWRzIHRvDQo+ID4gc2F0aXNmeSB0aGUg Z3JhbW1hciBjb25zdHJhaW50cyBhbmQgdGhlIHNlbWFudGljIGNvbnN0cmFpbnRzLg0KPiANCj4g WWVzLCB3ZSBhcmUgaW4gYSBwZXJmZWN0IGFncmVlbWVudCBoZXJlLiA6LSkgSW4gYW55IGNhc2Us IHRoaXMgaXMgaG93DQo+IHRoZSBEU0RMIG1hcHBpbmcgd29ya3MgLSBncmFtbWFyIHRyYW5zbGF0 ZXMgdG8gUkVMQVggTkcsICdtdXN0JyBhbmQNCj4gJ3doZW4nIHRvIFNjaGVtYXRyb24uDQoNCkkg YWxzbyBhZ3JlZS4gIEkgZG8gbm90IHdhbnQgdGhlIHdoZW4gc3RhdGVtZW50IHRvIGFmZmVjdCB0 aGUgZ3JhbW1hci4NCg0KDQovbWFydGluDQo= From andy@netconfcentral.com Wed Dec 2 10:39: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 163F63A6A6C for ; Wed, 2 Dec 2009 10:39:54 -0800 (PST) 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.064, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 0UyORO9YCuqu for ; Wed, 2 Dec 2009 10:39:53 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id 5BF2F3A6A31 for ; Wed, 2 Dec 2009 10:39:53 -0800 (PST) Received: (qmail 52399 invoked from network); 2 Dec 2009 18:39:43 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 02 Dec 2009 10:39:43 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: tr6Y3tQVM1npi.TI1PIwxh51UqsqkshWf8II5F1bRL_V2FUig.llBhh1DWs.hNAR3RHZAZ3.O9X0xK0lmqCot9S9uejnL4lnVdwLXNLtj5P18.elGGpgSiwPKogoOqDDVN_a.2dfM82eOXj5SKXT6TkeeMt3Ct9SqhMwbnnP59pw2Yqse1DbDIiMiCqk2EnSWipJyia1qh5uQ3c2dsKcOOvzj.piCvssImSzTW2EVvOi02QUfxRe4seLv3vpddea X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16B417.6030507@netconfcentral.com> Date: Wed, 02 Dec 2009 10:38:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] FYI; arch draft deleted X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 18:39:54 -0000 Hi, The arch draft has expired, so it was automatically deleted from the NETMOD charter page. A search of the ID tracker shows it in 'Expired' state. I'm a big fan of automation, but this is a bit much. Is there a way to bring back the -02 draft or is there going to be a -03 instead? Andy From andy@netconfcentral.com Wed Dec 2 11:14: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 575513A69C4 for ; Wed, 2 Dec 2009 11:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, UNPARSEABLE_RELAY=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 Yqqk2F9aGpNC for ; Wed, 2 Dec 2009 11:14:30 -0800 (PST) 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 7FF953A67DB for ; Wed, 2 Dec 2009 11:14:30 -0800 (PST) Received: (qmail 2177 invoked from network); 2 Dec 2009 19:14:19 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 02 Dec 2009 11:14:19 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: k98T2nIVM1kNWTbP3hjM4ONELT8YP9EKB_skiTiG.vA1yvK90AxaUy74R9SNMvRiTb0JEnaw30vJ.uXzlzm8m2Emhoy3A5UfMZjFxyIQqbA7ht5kGTdOhhVg93Q21Rd7xvb9djMsV9x9iZyyUNCqFKRywupF8IL2VhM829cQUIF2RJhdBvopJR5gWjaArJpdGUz4Q1F96GULUErEDB1RegfQA8icwNrggjUlS7WCiqw4B36vhuvYr7zYmjQEGXmhUERNHkMzO8TzQSlLE1R9HcgNZ5f25rLw_o8NvljSfRpRglTB1TBIM63Zn9c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16BCAC.4010508@netconfcentral.com> Date: Wed, 02 Dec 2009 11:14:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <1259742094.22111.98.camel@missotis> <20091202.095246.240237381.mbj@tail-f.com> <4B163004.8020304@bwijnen.net> <20091202.103053.188403128.mbj@tail-f.com> In-Reply-To: <20091202.103053.188403128.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] when 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, 02 Dec 2009 19:14:31 -0000 Martin Bjorklund wrote: > "Bert (IETF) Wijnen" wrote: >>>>>> 1. The schema-based constraints are checked first, independently of the >>>>>> remaining two steps. >>>>>> >>>>> leaf-list x { >>>>> type int32; >>>>> min-entries 1; >>>>> when "../y > 1"; >>>>> } >>>>> leaf y { >>>>> type int32; >>>>> } >>>>> >>>>> Does your rule 1 mean that first I should check min-entries, >>>>> regardless of the 'when' statement? So this instance doc will fail: >>>>> >>>>> 2 >>>>> >>>> Yes. >>>> >>> But it is valid! When y > 1, no x should exist. When y <= 1, at >>> least 1 x must exist. >>> >> Martin, I am not up to speed in YANG as you guys are, >> >> but did you not mean >> >> When y <= 1, no x should exist. When y > 1, at >> least 1 x must exist. > > Yes! Thanks for catching this. Negation is tricky... > > So my original example and question should be: > > With this data model: > > leaf-list x { > type int32; > min-entries 1; > when "../y <= 1"; > } > leaf y { > type int32; > } > > Does your rule 1 mean that first I should check min-entries, > regardless of the 'when' statement? So this instance doc will fail: > > 2 > > It should not fail, since when y > 1, no x should exist. When y <= 1, > at least 1 x must exist. > This is part of the validation sequence done for edit-config on running, or commit of the candidate. As such, these outcome should be predictable. One implementation strategy (YMMV): 1 - server deletes all the nodes that have false 'when' results (e.g., go through all the nodes with 'when-stmts' and keep doing it until no nodes at all are deleted in the loop. Avoids deadlock due to XPath cross-references completely.) 2 - server verifies mandatory and other constraints on the nodes that are left Another way of looking at it -- go ahead and create /x entries, but if you don't get /y right before the commit, the server will delete all the /x entries and not commit them. The same logic applies to when+default. Even if the server creates the default in the candidate, it will get deleted in the commit if the when expression is false. > > > /martin Andy From andy@netconfcentral.com Wed Dec 2 11:33: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 EB1943A6971 for ; Wed, 2 Dec 2009 11:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 Zx1u1DdoA5eW for ; Wed, 2 Dec 2009 11:33:27 -0800 (PST) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id 7BC573A68D9 for ; Wed, 2 Dec 2009 11:33:27 -0800 (PST) Received: (qmail 7784 invoked from network); 2 Dec 2009 19:33:17 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 02 Dec 2009 11:33:17 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: WkL1WlYVM1kSs9Ul7kYAz1AyvN9DkUdAwpsr0UC7BuFg..SVjyRa1Mj_k.t1QyzIGF8SGLjcRrBQ6gN9pTn7e_ktSHJTCdhXAzP_sCclTSvBiIh4VASMAAMZ2.hplAAkqAzi5V1yyteaT9jAay9LRTRuyqPL0WUQ459Lk5C5u4Si1Cbgjx9jSJc_ONzRYCZ4yiCPSqZS4G2l0kUJY7o31uHOgbz_jOekHhT0_R_rFaw6_RbqvYpwwSq9kZOuEr95 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16C11D.8090304@netconfcentral.com> Date: Wed, 02 Dec 2009 11:33:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 19:33:31 -0000 Hi, I noticed this change in yang-types-05: file "ietf-yang-types.yang" module ietf-yang-types { The problem with this variant is that there should be nothing but 'extra' whitespace added to the 'CODE'. For legal reasons, and for consistency for tools that process generically in any I-D or RFC, the file "filename" stuff needs to be removed. Besides, the file is really ietf-yang-types.2009-11-10.yang, according to the YANG spec, which also does this: file "yang.abnf" If every WG decides to add different extra text to the normative text tagged as 'CODE', then we will have a mess before long. I suggest getting the generic changed so standard meta-data can be added, such as 'file': This makes it more XML-ish, and from a legal POV, makes it clear what characters constitute 'CODE', and which do not. Andy From mehmet.ersue@nsn.com Wed Dec 2 12:06: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 94DDD3A696C for ; Wed, 2 Dec 2009 12:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, 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 tqQkFoO4yn6R for ; Wed, 2 Dec 2009 12:06:41 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id B378A3A696B for ; Wed, 2 Dec 2009 12:06:40 -0800 (PST) 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 nB2K6TkY012284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2009 21:06:29 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nB2K6Tci024316; Wed, 2 Dec 2009 21:06:29 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 21:06:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA738A.EE8A2FFD" Date: Wed, 2 Dec 2009 21:06:27 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64209CE3@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Having a Normative Reference "For every (single) reference statement" Thread-Index: Acpziu5ze1qRXJs3TgS+NKg390CmAA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "NETMOD Working Group" X-OriginalArrivalTime: 02 Dec 2009 20:06:28.0774 (UTC) FILETIME=[EF1BD460:01CA738A] Cc: ext Mark Scott Subject: [netmod] Having a Normative Reference "For every (single) reference 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: Wed, 02 Dec 2009 20:06:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA738A.EE8A2FFD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, the usage guideline document says: "For every reference statement which appears in a module contained in the specification, which identifies a separate document, a corresponding normative reference to that document SHOULD appear in the Normative References section." This is contradicting with the definition in RFC 3967: "a normative reference specifies a document that must be read to fully understand or implement the subject matter in the new RFC, or whose contents are effectively part of the new RFC, as its omission would leave the new RFC incompletely specified." Following the usage guideline document NETCONF Monitoring draft has=20 normative references for __all__ documents referenced in identity statements=20 for the SSH, SOAP, BEEP and TLS drafts as well as for XSD, RNG, YANG, YIN. E.g. identity netconf-tls { base transport; reference "RFC 5539 : NETCONF over Transport Layer Security (TLS)"; } Where I understand a normative reference in the "Normative References" chapter for XSD, RNG, YANG and YIN for compliancy reasons I do not=20 understand the normative references for SSH, SOAP, BEEP and TLS.=20 YANG and XSD define a format which can be seen as normative.=20 BEEP and TLS define a transport which is only referred. The identities for SSH, SOAP, BEEP and TLS are there only to complete=20 the list of identities for NETCONF transports. The SSH, SOAP, BEEP and=20 TLS documents are not necessary to read to understand nor to implement=20 the monitoring YANG module. And they don't have any XSD or YANG module defined. Nobody needs to be compliant with the content of these RFCs. Do we really need normative references "For every (single) reference statement" in a YANG module or only for those who are referenced because of compliance=20 reasons or define a YANG or XSD module which is imported or important=20 for the referring module? I actually could go with it but I'm still trying hard to find a logical=20 reason without success . . . Cheers, Mehmet ------_=_NextPart_001_01CA738A.EE8A2FFD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having a Normative Reference "For every (single) reference = statement"

Dear All,

the usage guideline document = says:

"For every reference statement which appears in a = module contained in
the specification, which identifies a separate document, a
corresponding normative reference to that document SHOULD appear in
the Normative References section."

This is contradicting with the = definition in RFC 3967:

"a normative reference = specifies a document that must be read to fully
understand or implement the = subject matter in the new RFC, or whose
contents are effectively part of = the new RFC, as its omission would
leave the new RFC incompletely = specified."

Following the usage guideline = document NETCONF Monitoring draft has
normative references for __all__ = documents referenced in identity statements
for the SSH, SOAP, BEEP and TLS = drafts as well as for XSD, RNG, YANG, YIN.

E.g.
  identity netconf-tls = {
    base transport;
    reference
      "RFC 5539: NETCONF over Transport Layer Security = (TLS)";
  }
Where I understand a normative = reference in the "Normative References"
chapter for XSD, RNG, YANG and = YIN for compliancy reasons I do not
understand the normative = references for SSH, SOAP, BEEP and TLS.
YANG and XSD define a format = which can be seen as normative.
BEEP and TLS define a transport = which is only referred.

The identities for SSH, SOAP, = BEEP and TLS are there only to complete
the list of identities for = NETCONF transports. The SSH, SOAP, BEEP and
TLS documents are not necessary = to read to understand nor to implement
the monitoring YANG module. And = they don't have any XSD or YANG module
defined. Nobody needs to be = compliant with the content of these RFCs.

Do we really need normative = references "For = every (single) reference statement"
in a YANG module or only for = those who are referenced because of compliance
reasons or define a YANG or XSD = module which is imported or important
for the referring module?

I actually could go with it but = I'm still trying hard to find a logical
reason without success . . = .

Cheers,
Mehmet

------_=_NextPart_001_01CA738A.EE8A2FFD-- From phil@juniper.net Wed Dec 2 12:11: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 DC9F228C0E4 for ; Wed, 2 Dec 2009 12:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 6rc7j+wa5cSR for ; Wed, 2 Dec 2009 12:11:11 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 665643A6403 for ; Wed, 2 Dec 2009 12:11:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSxbJ1uswpdgmjah0gD4dhxcwAt9HQGw6@postini.com; Wed, 02 Dec 2009 12:11:03 PST 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.393.1; Wed, 2 Dec 2009 11:28:04 -0800 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, 2 Dec 2009 11:28:03 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 11:28:03 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 11:28:02 -0800 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 nB2JS2j54066; Wed, 2 Dec 2009 11:28:02 -0800 (PST) (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 nB2JEOVd011586; Wed, 2 Dec 2009 19:14:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912021914.nB2JEOVd011586@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B16B417.6030507@netconfcentral.com> Date: Wed, 2 Dec 2009 14:14:24 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Dec 2009 19:28:02.0943 (UTC) FILETIME=[90B9F0F0:01CA7385] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] FYI; arch draft deleted X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 20:11:15 -0000 Andy Bierman writes: >I'm a big fan of automation, but this >is a bit much. Is there a way to bring back >the -02 draft or is there going to be a -03 instead? I'll get an -03 out asap. Thanks, Phil From phil@juniper.net Wed Dec 2 12:22: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 742833A68B9 for ; Wed, 2 Dec 2009 12:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 3C6tQRBn2ndx for ; Wed, 2 Dec 2009 12:22:33 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id BCE203A68C8 for ; Wed, 2 Dec 2009 12:22:32 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSxbMgJ3UOK9QjfmothUkbJ4HqujUREIG@postini.com; Wed, 02 Dec 2009 12:22:26 PST 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.393.1; Wed, 2 Dec 2009 11:41:37 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 11:41:37 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 11:41:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 11:41:36 -0800 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 nB2JfZj66740; Wed, 2 Dec 2009 11:41:35 -0800 (PST) (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 nB2JRvdH011844; Wed, 2 Dec 2009 19:27:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912021927.nB2JRvdH011844@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B16C11D.8090304@netconfcentral.com> Date: Wed, 2 Dec 2009 14:27:57 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Dec 2009 19:41:36.0068 (UTC) FILETIME=[7562F840:01CA7387] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 20:22:34 -0000 Andy Bierman writes: >The problem with this variant is that there should be nothing >but 'extra' whitespace added to the 'CODE'. For legal reasons, >and for consistency for tools that process >generically in any I-D or RFC, the file "filename" stuff >needs to be removed. Okay, I'm not a lawyer. Please explain how lawyers will get involved if you use the "" in this way. > >This makes it more XML-ish, and from a legal POV, >makes it clear what characters constitute 'CODE', >and which do not. I would avoid the "XML attribute"-like way since this tag is definitely _not_ XML. We should help anyone to think that this is XML. IMHO we should not be using chevrons at all, but maybe this is a "legal issue" also. Thanks, Phil From andy@netconfcentral.com Wed Dec 2 12:47: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 4539F3A695F for ; Wed, 2 Dec 2009 12:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 soZEEdOl23Lr for ; Wed, 2 Dec 2009 12:47:18 -0800 (PST) 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 71BB43A657C for ; Wed, 2 Dec 2009 12:47:18 -0800 (PST) Received: (qmail 10586 invoked from network); 2 Dec 2009 20:47:08 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 02 Dec 2009 12:47:08 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: qswiBFYVM1lgvlnIrjzEKXnzkrWjpnVjYNajVR83HVfPGb5lKTU3c0rdJC6wj7unXbeTL3CA9Y0E2tcyCFtiEdWPrMRkJWCo8P4BdXsAV.Z2JzbOii.gX6C2FYZbyy6jUEf9XIgHjK7VURg5tBOIpzRkRsN5Sfoix.Qa3xJXLM6T0u_aUBpSZ...BOuZC0muwqxVnwDywHxNG8ixr1d6e.YbGP8NtDc7dQpd.c4_2NG4cpAWmEoTEDXlzVvig4XCxg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16D26D.8080001@netconfcentral.com> Date: Wed, 02 Dec 2009 12:47:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912021927.nB2JRvdH011844@idle.juniper.net> In-Reply-To: <200912021927.nB2JRvdH011844@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 20:47:19 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The problem with this variant is that there should be nothing >> but 'extra' whitespace added to the 'CODE'. For legal reasons, >> and for consistency for tools that process >> generically in any I-D or RFC, the file "filename" stuff >> needs to be removed. > > Okay, I'm not a lawyer. Please explain how lawyers will > get involved if you use the "" in this way. > Read the IETF TLP. It says everything between and is code. The extra stuff (file "name") is not part of the YANG language. It is not code. It needs to be removed. The IETF does not need to standardize the file names used by some tool or person saving RFC fragments to external storage. The file name is not mentioned anywhere in the document. Is it important? Is it normative? Why is it even there? >> >> This makes it more XML-ish, and from a legal POV, >> makes it clear what characters constitute 'CODE', >> and which do not. > > I would avoid the "XML attribute"-like way since this > tag is definitely _not_ XML. We should help anyone > to think that this is XML. IMHO we should not be using > chevrons at all, but maybe this is a "legal issue" also. > Fine. Then just should be used, as specified in the TLP. > Thanks, > Phil > Andy From phil@juniper.net Wed Dec 2 13: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 1DEC23A6976 for ; Wed, 2 Dec 2009 13:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 v+WYq1VCCNFO for ; Wed, 2 Dec 2009 13:03:06 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 8736E3A68B5 for ; Wed, 2 Dec 2009 13:03:05 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSxbWAdduHcK73EK9/SD6QK7HY3FGp/Og@postini.com; Wed, 02 Dec 2009 13:02:58 PST 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.393.1; Wed, 2 Dec 2009 12:59:00 -0800 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, 2 Dec 2009 12:59:00 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 12:59:00 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 12:59:00 -0800 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 nB2Kwxj13382; Wed, 2 Dec 2009 12:58:59 -0800 (PST) (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 nB2KjLge012416; Wed, 2 Dec 2009 20:45:21 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912022045.nB2KjLge012416@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B16D26D.8080001@netconfcentral.com> Date: Wed, 2 Dec 2009 15:45:21 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Dec 2009 20:59:00.0099 (UTC) FILETIME=[4571DD30:01CA7392] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 21:03:07 -0000 Andy Bierman writes: >Read the IETF TLP. >It says everything between and is code. >The extra stuff (file "name") is not part of the YANG language. >It is not code. It needs to be removed. To the IETF, this means only that text appearing between the and is a "code component" and the IETF "grants to each person who wishes to exercise such rights", etc etc. I'm sure we will happily give these rights to the string at the end of the line. I don't see lawyers getting involved in this. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Dec 2 15:14: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 97BC03A692E for ; Wed, 2 Dec 2009 15:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.227, 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 ioQW+HpLBU7G for ; Wed, 2 Dec 2009 15:14:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 958E23A69A5 for ; Wed, 2 Dec 2009 15:14:25 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25962C0035; Thu, 3 Dec 2009 00:14:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ceb4LFxFIHZP; Thu, 3 Dec 2009 00:14:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48D2CC000E; Thu, 3 Dec 2009 00:14:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9ED13E421FB; Thu, 3 Dec 2009 00:14:15 +0100 (CET) Date: Thu, 3 Dec 2009 00:14:15 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20091202231415.GA8055@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , NETMOD Working Group , ext Mark Scott References: <80A0822C5E9A4440A5117C2F4CD36A64209CE3@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64209CE3@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ext Mark Scott , NETMOD Working Group Subject: Re: [netmod] Having a Normative Reference "For every (single) reference statement" 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, 02 Dec 2009 23:14:29 -0000 On Wed, Dec 02, 2009 at 09:06:27PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear All, > > the usage guideline document says: > > "For every reference statement which appears in a module contained in > the specification, which identifies a separate document, a > corresponding normative reference to that document SHOULD appear in > the Normative References section." Yes, I think this goes to far by saying the reference should be normative. Here is a data point: The draft-ietf-netmod-yang-types-05 has about 32 informative references because of 'reference' statements. [If we make all these references normative, the YANG data types document will likely never ever leave Proposed Standard status and all documents importing one of the data types likely never leave Proposed Standard as well. :-] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Dec 2 15:20: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 BB15D3A69BA for ; Wed, 2 Dec 2009 15:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 A02NEFMMP6CU for ; Wed, 2 Dec 2009 15:20:04 -0800 (PST) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id C06BF3A69B1 for ; Wed, 2 Dec 2009 15:20:03 -0800 (PST) Received: (qmail 80654 invoked from network); 2 Dec 2009 23:19:52 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 02 Dec 2009 15:19:52 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: ys6jQ6gVM1nfu6O6Tl9vPe87qlB0ppv.p.ylO8AfxfXuokO66ahChH4m6MqspzheuhbJ6HCTcGs6CVyrUrTEujYSFlVRq2a2KH8bxHNVFNn89.Nn5rHEf_cTCn24NiWSJM3WeaXmD7Vgu8qiRGlcNCMQcrkXeZ5OOIWybnjhEkcgD1Bg3ceo.haPuCcEwLyuYzKWZpARzQC6f_znZ0sRxH3s3AznZU904h83Mw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16F63A.1090906@netconfcentral.com> Date: Wed, 02 Dec 2009 15:20:26 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" , NETMOD Working Group , ext Mark Scott References: <80A0822C5E9A4440A5117C2F4CD36A64209CE3@DEMUEXC006.nsn-intra.net> <20091202231415.GA8055@elstar.local> In-Reply-To: <20091202231415.GA8055@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Having a Normative Reference "For every (single) reference 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: Wed, 02 Dec 2009 23:20:06 -0000 Juergen Schoenwaelder wrote: > On Wed, Dec 02, 2009 at 09:06:27PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Dear All, >> >> the usage guideline document says: >> >> "For every reference statement which appears in a module contained in >> the specification, which identifies a separate document, a >> corresponding normative reference to that document SHOULD appear in >> the Normative References section." > > Yes, I think this goes to far by saying the reference should be > normative. Here is a data point: The draft-ietf-netmod-yang-types-05 > has about 32 informative references because of 'reference' statements. > > [If we make all these references normative, the YANG data types > document will likely never ever leave Proposed Standard status and > all documents importing one of the data types likely never leave > Proposed Standard as well. :-] > I can just remove that paragraph, and not say anything about object reference statements. Or change SHOULD to MAY, and normative to informative: For every reference statement which appears in a module contained in the specification, which identifies a separate document, a corresponding informative reference to that document MAY appear in the Informative References section." > /js > Andy From j.schoenwaelder@jacobs-university.de Wed Dec 2 15:28: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 7BBF73A68AF for ; Wed, 2 Dec 2009 15:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.218, 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 My14Enbrw6bp for ; Wed, 2 Dec 2009 15:28:50 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 40FC63A67A2 for ; Wed, 2 Dec 2009 15:28:50 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 238A3C000E; Thu, 3 Dec 2009 00:28:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LO0WAL22S-mR; Thu, 3 Dec 2009 00:28:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43C07C000D; Thu, 3 Dec 2009 00:28:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9CF6FE42287; Thu, 3 Dec 2009 00:28:39 +0100 (CET) Date: Thu, 3 Dec 2009 00:28:39 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091202232839.GB8055@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16D26D.8080001@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B16D26D.8080001@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] convention 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, 02 Dec 2009 23:28:51 -0000 On Wed, Dec 02, 2009 at 09:47:41PM +0100, Andy Bierman wrote: > Read the IETF TLP. I did. > It says everything between and is code. > The extra stuff (file "name") is not part of the YANG language. > It is not code. It needs to be removed. OK, lets read it together. Here is the text from the FAQ : 3.2 Must I do anything special if I include code in my IETF Contribution? If you include code in an IETF Contribution, you are encouraged to label it with markers such as and , though these markers are not strictly required. Rather, any types of common code components included in IETF Contributions and listed at http://trustee.ietf.org/policyandprocedures.html are automatically treated as ?Code Components? for purposes of the TLP. And here is the relevant quote from the IETF Trust Legal Provisions Relating to IETF Documents Effective Date: September 12, 2009: 4. License to Code Components. a. Definition. IETF Contributions and IETF Documents often include components intended to be directly processed by a computer (?Code Components?). A list of common Code Components can be found at http://trustee.ietf.org/license-info/. b. Identification. Text in IETF Contributions and IETF Documents of the types identified in Section 4.a above shall constitute ?Code Components?. In addition, any text found between the markers and , or otherwise clearly labeled as a Code Component, shall be considered a ?Code Component?. Both, YANG and ABNF are listed in http://trustee.ietf.org/license-info/. According to my reading of the IETF TLP and its FAQ, we do not even need and markers to have the YANG modules and ABNF covered by an appropriate license. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Dec 2 15:33: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 D373B3A68E7 for ; Wed, 2 Dec 2009 15:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.209, 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 dF90y++HsYUA for ; Wed, 2 Dec 2009 15:33:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A98913A68D9 for ; Wed, 2 Dec 2009 15:33:48 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8922EC000E; Thu, 3 Dec 2009 00:33:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Xf3mVJyPEDhQ; Thu, 3 Dec 2009 00:33:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D687C000D; Thu, 3 Dec 2009 00:33:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9B3B3E42304; Thu, 3 Dec 2009 00:33:38 +0100 (CET) Date: Thu, 3 Dec 2009 00:33:38 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091202233338.GC8055@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , NETMOD Working Group , ext Mark Scott References: <80A0822C5E9A4440A5117C2F4CD36A64209CE3@DEMUEXC006.nsn-intra.net> <20091202231415.GA8055@elstar.local> <4B16F63A.1090906@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B16F63A.1090906@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ext Mark Scott , NETMOD Working Group Subject: Re: [netmod] Having a Normative Reference "For every (single) reference statement" 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, 02 Dec 2009 23:33:49 -0000 On Thu, Dec 03, 2009 at 12:20:26AM +0100, Andy Bierman wrote: > I can just remove that paragraph, and not say anything > about object reference statements. Or change SHOULD to MAY, > and normative to informative: > > For every reference statement which appears in a module contained in > the specification, which identifies a separate document, a > corresponding informative reference to that document MAY appear in > the Informative References section." I believe the RFC editor checks that all quotes of the form RFC NNNN resolve to a reference in the document. The MAY does not make any sense - of course any reference MAY be in the references. The decision whether such a reference in normative or not should be taken by the document author and not prescribed. Hence my preferred version: For every reference statement which appears in a module contained in the specification, which identifies a separate document, a corresponding reference to that document SHOULD appear in the References section. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Dec 2 15:45: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 5EC6328C0E9 for ; Wed, 2 Dec 2009 15:45:42 -0800 (PST) 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.082, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 nKo3-OA6+ZzV for ; Wed, 2 Dec 2009 15:45:41 -0800 (PST) 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 A310D3A6920 for ; Wed, 2 Dec 2009 15:45:41 -0800 (PST) Received: (qmail 75226 invoked from network); 2 Dec 2009 23:45:32 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 02 Dec 2009 15:45:31 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: uPY0oy8VM1lZ2JnXXplkJ0v93_Mb1l4qR25PfyXoAaCdcrPNPq9WVAylJdErkJHoQXe6.nfWouklVujtlTIUDInkHNP7Ov1ospoIy3dQkYg3s9aFPVSDFcY58Gjvuifn7zMOSiNVNyQo7L5n9GtK57_MntAf0v9dqHskMGbOYD.l8QsheGquX__dX_A56zRscKYyZF29vtf_jhX.rJl5f.SXL7Vwr0n1bPv38_fvdL3rnT9.bGPUu4LrPs.Kr0bJLBUheHCJKS6IZvq8QtRlhm0KMV.jB6MqedfstfUobUx4t8yt8tlFGnqsQQUA2jwepfputkCg_KEkNpEPq.u9po0vb8oxEz2Zr50_QkNn6qBLag-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B16FC3D.4080909@netconfcentral.com> Date: Wed, 02 Dec 2009 15:46:05 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16D26D.8080001@netconfcentral.com> <20091202232839.GB8055@elstar.local> In-Reply-To: <20091202232839.GB8055@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2009 23:45:42 -0000 Juergen Schoenwaelder wrote: > On Wed, Dec 02, 2009 at 09:47:41PM +0100, Andy Bierman wrote: > >> Read the IETF TLP. > > I did. > >> It says everything between and is code. >> The extra stuff (file "name") is not part of the YANG language. >> It is not code. It needs to be removed. > > OK, lets read it together. Here is the text from the FAQ > : > > 3.2 Must I do anything special if I include code in my IETF Contribution? > > If you include code in an IETF Contribution, you are encouraged to > label it with markers such as and , though > these markers are not strictly required. Rather, any types of > common code components included in IETF Contributions and listed at > http://trustee.ietf.org/policyandprocedures.html are automatically > treated as ?Code Components? for purposes of the TLP. > > And here is the relevant quote from the IETF Trust Legal Provisions > Relating to IETF Documents Effective Date: September 12, 2009: > > 4. License to Code Components. > > a. Definition. IETF Contributions and IETF Documents often include > components intended to be directly processed by a computer (?Code > Components?). A list of common Code Components can be found at > http://trustee.ietf.org/license-info/. > > b. Identification. Text in IETF Contributions and IETF Documents of > the types identified in Section 4.a above shall constitute ?Code > Components?. In addition, any text found between the markers > and , or otherwise clearly labeled as a > Code Component, shall be considered a ?Code Component?. > > Both, YANG and ABNF are listed in http://trustee.ietf.org/license-info/. > According to my reading of the IETF TLP and its FAQ, we do not even > need and markers to have the YANG modules > and ABNF covered by an appropriate license. > We don't need (file "filename") either. What's your point? As long as every YANG author gets to choose what to put in their draft, that's fine. Others may choose to follow the IETF guidelines, even if they are not strictly mandatory. > /js > Andy From j.schoenwaelder@jacobs-university.de Wed Dec 2 16:02: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 B8E2E3A689A for ; Wed, 2 Dec 2009 16:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.194, 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 7EJavYs8Y5tw for ; Wed, 2 Dec 2009 16:02:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B8D093A6872 for ; Wed, 2 Dec 2009 16:02:08 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A102C000E; Thu, 3 Dec 2009 01:02:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hYdFkzOqDIE0; Thu, 3 Dec 2009 01:01:59 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7A87C000D; Thu, 3 Dec 2009 01:01:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C77EE42512; Thu, 3 Dec 2009 01:01:59 +0100 (CET) Date: Thu, 3 Dec 2009 01:01:59 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091203000159.GF8055@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16D26D.8080001@netconfcentral.com> <20091202232839.GB8055@elstar.local> <4B16FC3D.4080909@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B16FC3D.4080909@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] convention 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, 03 Dec 2009 00:02:09 -0000 On Thu, Dec 03, 2009 at 12:46:05AM +0100, Andy Bierman wrote: > We don't need (file "filename") either. What's your point? The file name is practically useful for automatically extracting a code component and putting it into a sensible file. This probably makes it a bad idea since there are ways of doing this manually. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.partain@ericsson.com Thu Dec 3 00:45: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 5321B3A68AD for ; Thu, 3 Dec 2009 00:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OWlWSdh8FK1 for ; Thu, 3 Dec 2009 00:45:22 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 572F93A6877 for ; Thu, 3 Dec 2009 00:45:22 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-5b-4b177a95f974 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 7D.21.14961.59A771B4; Thu, 3 Dec 2009 09:45:09 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 09:43:11 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 09:43:10 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 3 Dec 2009 09:43:10 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912030943.10320.david.partain@ericsson.com> X-OriginalArrivalTime: 03 Dec 2009 08:43:10.0826 (UTC) FILETIME=[A4D72CA0:01CA73F4] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: YANG - A data modeling language for NETCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2009 08:45:23 -0000 Dear all, This is a two-week 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-09.txt This WGLC will end on December 17, 2009. Please review the document and post your comments on the mailing list. Please use an appropriate Subject line so that the chairs and editor can easily keep track of the issues that need to be dealt with. The chairs believe that we have reached the point of diminishing returns. We can of course keep improving the current version but believe it is time to have a published stable version. Thereafter, operational experience will give us the input we need to work on a version 2 at some later date. Thanks. David^2 From lhotka@cesnet.cz Thu Dec 3 01:47: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 8FEAA3A6A0D for ; Thu, 3 Dec 2009 01:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAvDrvIZA9qE for ; Thu, 3 Dec 2009 01:47:17 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BD1F93A6846 for ; Thu, 3 Dec 2009 01:47:17 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id EB391D800F6; Thu, 3 Dec 2009 10:47:04 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200912021927.nB2JRvdH011844@idle.juniper.net> References: <200912021927.nB2JRvdH011844@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 03 Dec 2009 10:47:03 +0100 Message-ID: <1259833623.30400.102.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2009 09:47:18 -0000 Phil Shafer píše v St 02. 12. 2009 v 14:27 -0500: > Andy Bierman writes: > >The problem with this variant is that there should be nothing > >but 'extra' whitespace added to the 'CODE'. For legal reasons, > >and for consistency for tools that process > >generically in any I-D or RFC, the file "filename" stuff > >needs to be removed. > > Okay, I'm not a lawyer. Please explain how lawyers will > get involved if you use the "" in this way. > > > > >This makes it more XML-ish, and from a legal POV, > >makes it clear what characters constitute 'CODE', > >and which do not. > > I would avoid the "XML attribute"-like way since this > tag is definitely _not_ XML. We should help anyone > to think that this is XML. IMHO we should not be using > chevrons at all, but maybe this is a "legal issue" also. IETF Trust Legal Provisions say that '..., any text found between the markers and , or otherwise clearly labeled as a Code Component, shall be considered a "Code Component"'. So even the chevrons are not strictly required. In any case, it is IMO irrelevant whether the file name is considered part of the code component or not. Lada > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Thu Dec 3 09:50: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 D7FB43A6890 for ; Thu, 3 Dec 2009 09:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 9IHO99f81YaY for ; Thu, 3 Dec 2009 09:50:33 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 84AD63A672F for ; Thu, 3 Dec 2009 09:50:32 -0800 (PST) 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 nB3HoLjf003794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2009 18:50:21 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nB3HoL0r028844; Thu, 3 Dec 2009 18:50:21 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 18:50:20 +0100 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, 3 Dec 2009 18:50:19 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64241F0A@DEMUEXC006.nsn-intra.net> In-Reply-To: <20091202233338.GC8055@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Having a Normative Reference "For every (single) reference statement" Thread-Index: Acpzp+Go7tszp5rXRXaLrDvYnI8f2QAmQBQQ References: <80A0822C5E9A4440A5117C2F4CD36A64209CE3@DEMUEXC006.nsn-intra.net> <20091202231415.GA8055@elstar.local> <4B16F63A.1090906@netconfcentral.com> <20091202233338.GC8055@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Andy Bierman" X-OriginalArrivalTime: 03 Dec 2009 17:50:20.0483 (UTC) FILETIME=[14D74930:01CA7441] Cc: ext Mark Scott , NETMOD Working Group Subject: Re: [netmod] Having a Normative Reference "For every (single) reference 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, 03 Dec 2009 17:50:33 -0000 Sounds good. This lets it open and the main guidance is given in RFC 3967. Cheers, Mehmet =20 > -----Original Message----- > From: ext Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, December 03, 2009 12:34 AM > To: Andy Bierman > Cc: Ersue, Mehmet (NSN - DE/Munich); NETMOD Working Group;=20 > ext Mark Scott > Subject: Re: [netmod] Having a Normative Reference "For every=20 > (single) reference statement" >=20 > On Thu, Dec 03, 2009 at 12:20:26AM +0100, Andy Bierman wrote: > =20 > > I can just remove that paragraph, and not say anything > > about object reference statements. Or change SHOULD to MAY, > > and normative to informative: > >=20 > > For every reference statement which appears in a module=20 > contained in > > the specification, which identifies a separate document, a > > corresponding informative reference to that document MAY=20 > appear in > > the Informative References section." >=20 > I believe the RFC editor checks that all quotes of the form RFC NNNN > resolve to a reference in the document. The MAY does not make any > sense - of course any reference MAY be in the references. The decision > whether such a reference in normative or not should be taken by the > document author and not prescribed. Hence my preferred version: >=20 > For every reference statement which appears in a module contained=20 > in the specification, which identifies a separate document, a > corresponding reference to that document SHOULD appear in > the References section. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From david.partain@ericsson.com Fri Dec 4 00:02: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 80A573A67AE for ; Fri, 4 Dec 2009 00:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.753 X-Spam-Level: X-Spam-Status: No, score=-5.753 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 6BIeOvYdcAya for ; Fri, 4 Dec 2009 00:02:07 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 516BB3A6778 for ; Fri, 4 Dec 2009 00:02:07 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-9b-4b18c1f3a098 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8D.DC.02357.3F1C81B4; Fri, 4 Dec 2009 09:01:55 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 09:01:49 +0100 Received: from selic023.ki.sw.ericsson.se ([147.214.22.152]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 09:01:49 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 3 Dec 2009 16:45:35 +0100 User-Agent: KMail/1.9.10 References: <4B16C11D.8090304@netconfcentral.com> In-Reply-To: <4B16C11D.8090304@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200912031645.36064.david.partain@ericsson.com> X-OriginalArrivalTime: 04 Dec 2009 08:01:49.0803 (UTC) FILETIME=[0872DBB0:01CA74B8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2009 08:02:08 -0000 On Wednesday 02 December 2009 20.33.49 Andy Bierman wrote: > Hi, > > I noticed this change in yang-types-05: > > file "ietf-yang-types.yang" > > module ietf-yang-types { > > > The problem with this variant is that there should be nothing > but 'extra' whitespace added to the 'CODE'. For legal reasons, > and for consistency for tools that process > generically in any I-D or RFC, the file "filename" stuff > needs to be removed. Hi, I don't see that the text implies we can't put stuff in that is helpful (as I think this is). I think the filenames are useful. David From david.partain@ericsson.com Fri Dec 4 00:02: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 118D23A687D for ; Fri, 4 Dec 2009 00:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 fNpP9NmbCpRF for ; Fri, 4 Dec 2009 00:02:14 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E7ED63A6778 for ; Fri, 4 Dec 2009 00:02:12 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-b8-4b18c1f60115 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 31.EC.02357.6F1C81B4; Fri, 4 Dec 2009 09:01:58 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 09:01:51 +0100 Received: from selic023.ki.sw.ericsson.se ([147.214.22.152]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 09:01:51 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 3 Dec 2009 16:49:40 +0100 User-Agent: KMail/1.9.10 References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> In-Reply-To: <20091203000159.GF8055@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200912031649.40763.david.partain@ericsson.com> X-OriginalArrivalTime: 04 Dec 2009 08:01:51.0366 (UTC) FILETIME=[09615A60:01CA74B8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2009 08:02:15 -0000 On Thursday 03 December 2009 01.01.59 Juergen Schoenwaelder wrote: > On Thu, Dec 03, 2009 at 12:46:05AM +0100, Andy Bierman wrote: > > We don't need (file "filename") either. What's your point? > > The file name is practically useful for automatically extracting a > code component and putting it into a sensible file. This probably > makes it a bad idea since there are ways of doing this manually. At the risk of being overly zealous and repetitive, I would like to keep it. Having watched the mess of the filenames for SNMP MIBs, I really really think this is a good idea. David From andy@netconfcentral.com Fri Dec 4 02:15: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 E4D643A6906 for ; Fri, 4 Dec 2009 02:15:56 -0800 (PST) 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.060, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 IRiIgP+ZYfQJ for ; Fri, 4 Dec 2009 02:15:55 -0800 (PST) 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 9A76C3A69D4 for ; Fri, 4 Dec 2009 02:15:55 -0800 (PST) Received: (qmail 56009 invoked from network); 4 Dec 2009 10:15:44 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 04 Dec 2009 02:15:44 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: nL5VKgsVM1m4axS_STwaxPqHmZECWYUqg9B9EC1GLE.FF9M0KMqyY1xTOwYY0Ot_U0_9jtFAgtzIKrhtXYRz2wNHN5ap4ZXK4jKIwiJ_oI_ii4Bhz1Rr9LkRqhmsMElHIg7dPWHnBLqkkgBhzGRz.YhGJZvLts2AbXQeNs4V8ZuXyNUxlyjl.iclkhU1z96uLtn.olxshFPBTv6qS5qQ4W0kAj509iVVF8P4nmQAjjS3Och9X5o3bm3hUP8S39pc X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B18E17E.80908@netconfcentral.com> Date: Fri, 04 Dec 2009 02:16:30 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Partain References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> In-Reply-To: <200912031649.40763.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2009 10:15:57 -0000 David Partain wrote: > On Thursday 03 December 2009 01.01.59 Juergen Schoenwaelder wrote: >> On Thu, Dec 03, 2009 at 12:46:05AM +0100, Andy Bierman wrote: >>> We don't need (file "filename") either. What's your point? >> The file name is practically useful for automatically extracting a >> code component and putting it into a sensible file. This probably >> makes it a bad idea since there are ways of doing this manually. > > At the risk of being overly zealous and repetitive, I would like to keep it. > Having watched the mess of the filenames for SNMP MIBs, I really really think > this is a good idea. > I would like to know why the file naming conventions defined in yang-09, sec 5.2 are being ignored by this undocumented and undefined CODE BEGINS convention. I find it harmful to see drafts with examples that don't even follow the established guidelines. People will copy this wrong way of naming YANG files. > David Andy From j.schoenwaelder@jacobs-university.de Fri Dec 4 03:10: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 324013A6860 for ; Fri, 4 Dec 2009 03:10:40 -0800 (PST) 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 X+LQJoMlD+cL for ; Fri, 4 Dec 2009 03:10:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 70A9B3A69E1 for ; Fri, 4 Dec 2009 03:10:32 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C14FC0014; Fri, 4 Dec 2009 12:10:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AfNxgfDah8ng; Fri, 4 Dec 2009 12:10:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB7A3C0012; Fri, 4 Dec 2009 12:10:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B89CE45DAE; Fri, 4 Dec 2009 12:10:21 +0100 (CET) Date: Fri, 4 Dec 2009 12:10:20 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091204111020.GE12835@elstar.local> Mail-Followup-To: Andy Bierman , David Partain , "netmod@ietf.org" References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> <4B18E17E.80908@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B18E17E.80908@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] convention 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, 04 Dec 2009 11:10:40 -0000 On Fri, Dec 04, 2009 at 11:16:30AM +0100, Andy Bierman wrote: > I would like to know why the file naming conventions > defined in yang-09, sec 5.2 are being ignored by > this undocumented and undefined CODE BEGINS convention. > I find it harmful to see drafts with examples that don't even > follow the established guidelines. People will copy > this wrong way of naming YANG files. Thanks for pointing out the inconsistency. I agree that we have to fix the file names to follow the YANG specs. I note, however, that the square brackets likely indicate that the [ '.' revision-data ] part is optional and there is no text in 5.2 explaining this further, that is there is no text saying that this part must be present if there is a revision statement (in case that was the intention). Anyway, I agree that we should get this right and include revision-date in the file names. (Personally, I am still not happy with the choice of the '.' as a separator but that is a separate issue. I have to read the list discussion about this again.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Fri Dec 4 08:00: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 020253A680D for ; Fri, 4 Dec 2009 08:00:00 -0800 (PST) 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.057, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 7K+339om71lv for ; Fri, 4 Dec 2009 07:59:59 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 15D2A3A68C5 for ; Fri, 4 Dec 2009 07:59:59 -0800 (PST) Received: (qmail 26013 invoked from network); 4 Dec 2009 15:59:48 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 04 Dec 2009 07:59:47 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: S0qo_J4VM1mexYdQaXM6MEvS5bDtw6fWhDOhTARlf3wg.Ao._j1AbomYcE_fhJ6DzQv8awkoRH26E6LfeE4YpBPiK3_BOiZ034alAfIShjKsg6kCATHf8a1A_eNae1FHYottCS2qkhmMyVA576uVCm12iOlrQ1zuFMgCcYhDScUyEt6YrtyhanTrQ_gKfZDO83.3PLxOQHJaf5xuqGckvPEoCMqEVpi3W.VtgA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B193224.5010703@netconfcentral.com> Date: Fri, 04 Dec 2009 08:00:36 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , David Partain , "netmod@ietf.org" References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> <4B18E17E.80908@netconfcentral.com> <20091204111020.GE12835@elstar.local> In-Reply-To: <20091204111020.GE12835@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2009 16:00:00 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 04, 2009 at 11:16:30AM +0100, Andy Bierman wrote: > >> I would like to know why the file naming conventions >> defined in yang-09, sec 5.2 are being ignored by >> this undocumented and undefined CODE BEGINS convention. >> I find it harmful to see drafts with examples that don't even >> follow the established guidelines. People will copy >> this wrong way of naming YANG files. > > Thanks for pointing out the inconsistency. I agree that we have to fix > the file names to follow the YANG specs. I note, however, that the > square brackets likely indicate that the [ '.' revision-data ] part is > optional and there is no text in 5.2 explaining this further, that is > there is no text saying that this part must be present if there is a > revision statement (in case that was the intention). Anyway, I agree > that we should get this right and include revision-date in the file > names. > I went looking for the '-' vs. '.' thread and found other emails that reminded me that the optional usage of revisions is still a concern to me. >>>>**** THE FOLLOWING IS A WGLC COMMENT ****<<<<< It does not make any sense to talk about different versions of a YANG [sub]module without a new revision date. There is no way to even distinguish which is the old version and which is the new version in a standard way. Sec 10: For any published change, a new "revision" statement (Section 7.1.9) SHOULD be included in front of the existing revision statements. Edit 1: s/SHOULD/MUST Edit 2: state (somewhere in sec. 10) that a module without revisions MUST NOT change (ever) Either that, or add text that explains how the standard is used to distinguish different versions of a conceptual YANG [sub]module, by some means other than the revision date. > (Personally, I am still not happy with the choice of the '.' as a > separator but that is a separate issue. I have to read the list > discussion about this again.) I thought you were the one who objected to '-' and wanted it changed to '.'. > > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Dec 4 10:16: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 760213A6870 for ; Fri, 4 Dec 2009 10:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2EECan+Nkvl for ; Fri, 4 Dec 2009 10:16:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A03653A677D for ; Fri, 4 Dec 2009 10:16:33 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6352CC0015; Fri, 4 Dec 2009 19:16:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9p0DEYv5ZGI7; Fri, 4 Dec 2009 19:16:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1080EC0012; Fri, 4 Dec 2009 19:16:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7CBFCE46BBC; Fri, 4 Dec 2009 19:16:20 +0100 (CET) Date: Fri, 4 Dec 2009 19:16:19 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091204181619.GB928@elstar.local> Mail-Followup-To: Andy Bierman , David Partain , "netmod@ietf.org" References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> <4B18E17E.80908@netconfcentral.com> <20091204111020.GE12835@elstar.local> <4B193224.5010703@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B193224.5010703@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] convention 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, 04 Dec 2009 18:16:34 -0000 On Fri, Dec 04, 2009 at 05:00:36PM +0100, Andy Bierman wrote: : I thought you were the one who objected to '-' and : wanted it changed to '.'. I think we should avoid characters that are frequently used for other purposes. The '.' is conventionally used to separate the file type suffix from a file name. The '-' is frequently used in module names. Hence, I would avoid both of them. I would prefer to use say '_' as used by the Debian package names. If we want to be absolutely safe of conflicts, we would pick a separator that is not allowed to appear in a module name. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Fri Dec 4 12:17: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 E6E4F3A6A48 for ; Fri, 4 Dec 2009 12:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 7XJZxgc56kxL for ; Fri, 4 Dec 2009 12:17:36 -0800 (PST) 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 4BCB83A6919 for ; Fri, 4 Dec 2009 12:17:36 -0800 (PST) Received: (qmail 52039 invoked from network); 4 Dec 2009 20:17:24 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 04 Dec 2009 12:17:24 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Jc7Z2q0VM1koWls3miwCg6VylyMlZLI06c.3Esys2brmJ4iu2fO9YYdXe8ndPWripyexgyhCAFDtQajmjGKg7mt51sQaWnp9HkzjiVBt7q94WFGjTEkr_5wLJQk3kj1WaJBVi4HNFt_KFFtJ79GRoXuRF5n8U1R7_G5USH1Zh6zwv_f.hFU23fo4rZEbF8JixKoAMB5yMbEPzdzv_Mtm6Xd_Y3KqmNLn3wFSg_ynBZE6S07_wmAVAdS2wLkwgNhd X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B196E85.7050506@netconfcentral.com> Date: Fri, 04 Dec 2009 12:18:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , David Partain , "netmod@ietf.org" References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> <4B18E17E.80908@netconfcentral.com> <20091204111020.GE12835@elstar.local> <4B193224.5010703@netconfcentral.com> <20091204181619.GB928@elstar.local> In-Reply-To: <20091204181619.GB928@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2009 20:17:37 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 04, 2009 at 05:00:36PM +0100, Andy Bierman wrote: > > : I thought you were the one who objected to '-' and > : wanted it changed to '.'. > > I think we should avoid characters that are frequently used for other > purposes. The '.' is conventionally used to separate the file type > suffix from a file name. The '-' is frequently used in module names. > Hence, I would avoid both of them. I would prefer to use say '_' as > used by the Debian package names. If we want to be absolutely safe of > conflicts, we would pick a separator that is not allowed to appear in > a module name. > yep -- I begged the WG (early on) to reserve 1 printable character from identifiers, but people insisted they need the freedom to use every legal XML identifier value. When I read sec. 5.2, I wonder: If foo and foo.2009-01-01 are both legal module names, then how do I know for sure which form of the filename is really present? And if these are both legal module names, then what happens if there is a version of the 'foo' module released on 2009-01-01? Baked-in fragility is not a good idea. Engineers usually try to avoid such fragile SW design. > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Dec 4 12:22: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 3915A3A67F2 for ; Fri, 4 Dec 2009 12:22:18 -0800 (PST) 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 pHKUmY-lHu2j for ; Fri, 4 Dec 2009 12:22:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E98513A68AB for ; Fri, 4 Dec 2009 12:22:16 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C204DC0017; Fri, 4 Dec 2009 21:22:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IVDaiv+Jzg8e; Fri, 4 Dec 2009 21:22:06 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA7E6C0012; Fri, 4 Dec 2009 21:22:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 88087E46F88; Fri, 4 Dec 2009 21:22:04 +0100 (CET) Date: Fri, 4 Dec 2009 21:22:04 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091204202204.GA1395@elstar.local> Mail-Followup-To: Andy Bierman , David Partain , "netmod@ietf.org" References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> <4B18E17E.80908@netconfcentral.com> <20091204111020.GE12835@elstar.local> <4B193224.5010703@netconfcentral.com> <20091204181619.GB928@elstar.local> <4B196E85.7050506@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B196E85.7050506@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] convention 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, 04 Dec 2009 20:22:18 -0000 On Fri, Dec 04, 2009 at 09:18:13PM +0100, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Dec 04, 2009 at 05:00:36PM +0100, Andy Bierman wrote: > > > > : I thought you were the one who objected to '-' and > > : wanted it changed to '.'. > > > > I think we should avoid characters that are frequently used for other > > purposes. The '.' is conventionally used to separate the file type > > suffix from a file name. The '-' is frequently used in module names. > > Hence, I would avoid both of them. I would prefer to use say '_' as > > used by the Debian package names. If we want to be absolutely safe of > > conflicts, we would pick a separator that is not allowed to appear in > > a module name. > > yep -- I begged the WG (early on) to reserve 1 printable > character from identifiers, but people insisted they need > the freedom to use every legal XML identifier value. My keyboard still has characters left that are not allowed in a legal YANG identifier - so I do not see this as a hard engineering challenge. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Fri Dec 4 12:25: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 682083A6A0E for ; Fri, 4 Dec 2009 12:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 79No37a8ad4R for ; Fri, 4 Dec 2009 12:25:58 -0800 (PST) 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 9C55C3A68F3 for ; Fri, 4 Dec 2009 12:25:58 -0800 (PST) Received: (qmail 15998 invoked from network); 4 Dec 2009 20:25:48 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 04 Dec 2009 12:25:48 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: ef3vHoYVM1kzepxiaGLZFQHG.rberJx_k..j1uXF1xKepOZ9WV0o_bHQ05BO4Y68pIEtnLf5zhgVXRRN3wpRO7MygOMhs3N48dUNKxQeNs1UExtMUmaNLa85Nk34UbSMt_EGQpSr2sahA9gmnfqnm2iLTMAyBGeFwnFhvPr1aVkYfmr6kuAALIh9dK4oFp4l8kFGdYzVFnNMkF8rjBawqegKN23jDHyOB8GzMQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B19707E.8090902@netconfcentral.com> Date: Fri, 04 Dec 2009 12:26:38 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , David Partain , "netmod@ietf.org" References: <200912021927.nB2JRvdH011844@idle.juniper.net> <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> <4B18E17E.80908@netconfcentral.com> <20091204111020.GE12835@elstar.local> <4B193224.5010703@netconfcentral.com> <20091204181619.GB928@elstar.local> <4B196E85.7050506@netconfcentral.com> <20091204202204.GA1395@elstar.local> In-Reply-To: <20091204202204.GA1395@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2009 20:25:59 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 04, 2009 at 09:18:13PM +0100, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, Dec 04, 2009 at 05:00:36PM +0100, Andy Bierman wrote: >>> >>> : I thought you were the one who objected to '-' and >>> : wanted it changed to '.'. >>> >>> I think we should avoid characters that are frequently used for other >>> purposes. The '.' is conventionally used to separate the file type >>> suffix from a file name. The '-' is frequently used in module names. >>> Hence, I would avoid both of them. I would prefer to use say '_' as >>> used by the Debian package names. If we want to be absolutely safe of >>> conflicts, we would pick a separator that is not allowed to appear in >>> a module name. >> yep -- I begged the WG (early on) to reserve 1 printable >> character from identifiers, but people insisted they need >> the freedom to use every legal XML identifier value. > > My keyboard still has characters left that are not allowed in a legal > YANG identifier - so I do not see this as a hard engineering challenge. > Really? So which characters are available that are present on every keyboard, and are not special characters in any operating system filespec? > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Dec 4 12: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 F16203A6A2B for ; Fri, 4 Dec 2009 12:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, 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 zYWUzETyTMeZ for ; Fri, 4 Dec 2009 12:34:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CCB4A3A6A0E for ; Fri, 4 Dec 2009 12:34:07 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDB59C0017; Fri, 4 Dec 2009 21:33:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7MzZNrJOE26Y; Fri, 4 Dec 2009 21:33:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10082C0012; Fri, 4 Dec 2009 21:33:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BDBD2E470E1; Fri, 4 Dec 2009 21:33:55 +0100 (CET) Date: Fri, 4 Dec 2009 21:33:55 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091204203355.GB1395@elstar.local> Mail-Followup-To: Andy Bierman , David Partain , "netmod@ietf.org" References: <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> <4B18E17E.80908@netconfcentral.com> <20091204111020.GE12835@elstar.local> <4B193224.5010703@netconfcentral.com> <20091204181619.GB928@elstar.local> <4B196E85.7050506@netconfcentral.com> <20091204202204.GA1395@elstar.local> <4B19707E.8090902@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B19707E.8090902@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] convention 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, 04 Dec 2009 20:34:09 -0000 On Fri, Dec 04, 2009 at 09:26:38PM +0100, Andy Bierman wrote: > >> yep -- I begged the WG (early on) to reserve 1 printable > >> character from identifiers, but people insisted they need > >> the freedom to use every legal XML identifier value. > > > > My keyboard still has characters left that are not allowed in a legal > > YANG identifier - so I do not see this as a hard engineering challenge. > > Really? > So which characters are available that are > present on every keyboard, and are not special > characters in any operating system filespec? I assume every keyboard has a '+' for example. And I was not talking about "any operating system filespec". I was talking about (a) picking a character that is not a legal module name character and (b) avoiding the '.' since it is used by major OSes as a separator for the file type suffix. I am not insisting on '+', perhaps '@' could also work or '%' or ... I have quite a few such keys left on my keyboard. /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 Dec 5 09:50: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 7FDF63A67E7 for ; Sat, 5 Dec 2009 09:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 EzAJds21UIkv for ; Sat, 5 Dec 2009 09:50:14 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 7AF703A66B4 for ; Sat, 5 Dec 2009 09:50:14 -0800 (PST) Received: (qmail 23553 invoked from network); 5 Dec 2009 17:50:02 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 05 Dec 2009 09:50:02 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: LZC2VsEVM1kU1GLPh44xSjt5dUdvbWoghYSM_drW0Bfu3oVxlG_wchmyJehWTl8TehBLrNat1EJx5gPK4KVjg0bgQFmBGZVdU0iJnMJrZ4nm8RfS4Yc0ogV6xL0vtmfVCoNaUMBlfnR77W5gpQFITlA_2S0DIDz0gEueHgVn4Hy6QGZs_daoVAI4UrjNIIXc6r_PY0XgbVU90WW40ih0fcKHsiQZ19OY8CuTzA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1A9D83.7090509@netconfcentral.com> Date: Sat, 05 Dec 2009 09:50:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , David Partain , "netmod@ietf.org" References: <4B16FC3D.4080909@netconfcentral.com> <20091203000159.GF8055@elstar.local> <200912031649.40763.david.partain@ericsson.com> <4B18E17E.80908@netconfcentral.com> <20091204111020.GE12835@elstar.local> <4B193224.5010703@netconfcentral.com> <20091204181619.GB928@elstar.local> <4B196E85.7050506@netconfcentral.com> <20091204202204.GA1395@elstar.local> <4B19707E.8090902@netconfcentral.com> <20091204203355.GB1395@elstar.local> In-Reply-To: <20091204203355.GB1395@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] convention X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2009 17:50:15 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 04, 2009 at 09:26:38PM +0100, Andy Bierman wrote: > >>>> yep -- I begged the WG (early on) to reserve 1 printable >>>> character from identifiers, but people insisted they need >>>> the freedom to use every legal XML identifier value. >>> My keyboard still has characters left that are not allowed in a legal >>> YANG identifier - so I do not see this as a hard engineering challenge. >> Really? >> So which characters are available that are >> present on every keyboard, and are not special >> characters in any operating system filespec? > > I assume every keyboard has a '+' for example. And I was not talking > about "any operating system filespec". I was talking about (a) picking > a character that is not a legal module name character and (b) avoiding > the '.' since it is used by major OSes as a separator for the file > type suffix. I am not insisting on '+', perhaps '@' could also work or > '%' or ... I have quite a few such keys left on my keyboard. > After a few minutes playing around with bash, it seems either '+' or '@' will work on linux, although @ will be escaped wrt/ tab completion. But '+' is special in printf formatting and regular expressions. I would support changing the field separator to '@' instead of '.', unless it breaks common tools somehow. > /js > Andy From andy@netconfcentral.com Sun Dec 6 15:12: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 B86013A69DF for ; Sun, 6 Dec 2009 15:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 o7pKRy+G2puk for ; Sun, 6 Dec 2009 15:12:41 -0800 (PST) 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 E5DA83A69DC for ; Sun, 6 Dec 2009 15:12:40 -0800 (PST) Received: (qmail 81215 invoked from network); 6 Dec 2009 23:12:28 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 06 Dec 2009 15:12:28 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: LzEOV1UVM1kJYRpFU9WR1SjTJ6Mgpl_wujL9ARAVtZeKGxMutX_dRsDJaG4_9MpvteNNhuV6V7pbELPmYdVp2Iu4Ov5Z0XMnlMsIR07VYs0G_NnQ4WCX4.l7etHDAHox7EgNZPT8MDbKHM1VWJL_2ZxVunyacbCEdY_ioSEez6xLPGhXBYfMNIdNAHvQrH5ztgN5uFQ6oBreCNPkUXyUXUk6.rhrS5vgJbC3tUoxfvUeniYZr2rTby9sRjJVb3GP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1C3A53.5010800@netconfcentral.com> Date: Sun, 06 Dec 2009 15:12:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-09, YIN 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, 06 Dec 2009 23:12:41 -0000 Hi, I think sec. 11 needs some minor changes: sec 11.1, para 5: OLD: The argument of a YANG statement is encoded in YIN either as an XML attribute or a subelement of the keyword element. NEW: The argument of a YANG statement is encoded in YIN either as an unqualified XML attribute or a subelement of the keyword element. ^^^^^^^^^^^ also: o If the argument is encoded as an attribute, this attribute has no namespace. Not sure if 'no namespace' is as clear as 'unqualified attribute'. ------------------------------------------ sec 11.1, para 6: Substatements of a YANG statement are encoded as (additional) children of the keyword element and their relative order MUST be the same as the order of substatements in YANG. This is only true if yin-element=true for the associated keyword. XML attributes are unordered and tools such as libxml2 do not preserve attribute order. -------------------------------------------- OLD: sec 11, para 3: The mapping between YANG and YIN does not modify the information content of the model. Comments and whitespace are not preserved. sec 11.1, para 7: Comments in YANG MAY be mapped to XML comments. Suggest this text be combined into sec 11, para 3, and fixed: NEW: sec 11, para 3: The mapping between YANG and YIN does not modify the information content of the model. Whitespace is not preserved. Comments in YANG MAY be mapped to XML comments. ---------------------------------------------- Andy From andy@netconfcentral.com Sun Dec 6 18: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 E5CC73A697F for ; Sun, 6 Dec 2009 18:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, UNPARSEABLE_RELAY=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 otHgr4XnEUzB for ; Sun, 6 Dec 2009 18:53:13 -0800 (PST) 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 539FF3A6801 for ; Sun, 6 Dec 2009 18:53:13 -0800 (PST) Received: (qmail 44827 invoked from network); 7 Dec 2009 02:53:01 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 06 Dec 2009 18:53:01 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: e7UZ0HwVM1mddf9fqFZe6fn.PEf.DcRGTGCXlsw0jTUcVMRDw8qwUrh_wWFUr_Igi.HMb3SV2J2WtESBUCZEy67lycEEBSUKl5J8llArYPU6hjJPCanoo1WvF1lf5loAYYTC2RTWFxQcDOe1flZdopl2OWCFdTqv1x57Ao81pwjui7xeU2DoOqUYn4VPiV6.ldKtMRYDrCYLzvx9Jk83JjTQNm16kh4hj1goSlk8pQCTx3fBvMfr_C81EDDFoVoI X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1C6E03.5070708@netconfcentral.com> Date: Sun, 06 Dec 2009 18:52:51 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-09, sec 11.1, YIN mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2009 02:53:14 -0000 Hi, Some of the YIN mapping rules seem rather random to me. Why is reference-stmt encoded as an attribute but description-stmt is encoded as a element? And contact, organization, etc. are encoded as an element? I propose that all the purely descriptive YANG statements that are unrestricted strings all be encoded as an element called . OLD entries: | contact | info | true | | description | text | true | | error-message | value | true | | organization | info | true | | reference | info | false | NEW entries: | contact | text | true | | description | text | true | | error-message | text | true | | organization | text | true | | reference | text | true | This also allows the xml:lang attribute to be applied, if desired. Andy From phil@juniper.net Sun Dec 6 19:05: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 9434F3A68BA for ; Sun, 6 Dec 2009 19:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.836 X-Spam-Level: X-Spam-Status: No, score=-5.836 tagged_above=-999 required=5 tests=[AWL=-0.726, 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 E9lcjIkCvfcl for ; Sun, 6 Dec 2009 19:05:06 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 986D63A659A for ; Sun, 6 Dec 2009 19:05:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSxxw1qboyVq81jxYxK0uojMY1ae0WFw/@postini.com; Sun, 06 Dec 2009 19:04:56 PST 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.393.1; Sun, 6 Dec 2009 19:03:34 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 19:03:33 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 19:03:33 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 19:03:32 -0800 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 nB733Uj26020; Sun, 6 Dec 2009 19:03:30 -0800 (PST) (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 nB72nmGx058345; Mon, 7 Dec 2009 02:49:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912070249.nB72nmGx058345@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B1C3A53.5010800@netconfcentral.com> Date: Sun, 6 Dec 2009 21:49:48 -0500 From: Phil Shafer X-OriginalArrivalTime: 07 Dec 2009 03:03:32.0846 (UTC) FILETIME=[DC4530E0:01CA76E9] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-09, YIN 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, 07 Dec 2009 03:05:07 -0000 Andy Bierman writes: >Not sure if 'no namespace' is as clear as 'unqualified attribute'. I don't think "unqualified attribute" was a clear meaning. It's not in the XML or XML Namespace TRs, but the definition for "qualified attribute" is: http://www.w3.org/TR/xml-names/#concepts Definition: A qualified name is a name subject to namespace interpretation. So an unqualified attribute would assumably be a name which is not subject to namespace interpretation, which is not a good thing. In addition: In documents conforming to this specification, element and attribute names appear as qualified names. Syntactically, they are either prefixed names or unprefixed names. So every attribute name in a compliant document is a qname. Either way, we should avoid "unqualified attribute" unless we can find a clear definition for it. > The mapping between YANG and YIN does not modify the information > content of the model. Whitespace is not preserved. > Comments in YANG MAY be mapped to XML comments. Does this imply that comments are preserved? Do XML comments in YIN get mapped to YANG comments? IMHO, stick with old sec 11, para 3, and drop the old sec 11.1, para 7. If we're trying to say they aren't preserved, then say it and no more. Thanks, Phil From mbj@tail-f.com Sun Dec 6 23:22: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 AABD73A6886 for ; Sun, 6 Dec 2009 23:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, 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 UA00Bl-CvjQ4 for ; Sun, 6 Dec 2009 23:22:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E20B53A6863 for ; Sun, 6 Dec 2009 23:22:02 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0DB3976C685; Mon, 7 Dec 2009 08:21:52 +0100 (CET) Date: Mon, 07 Dec 2009 08:21:51 +0100 (CET) Message-Id: <20091207.082151.219043844.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1C3A53.5010800@netconfcentral.com> References: <4B1C3A53.5010800@netconfcentral.com> X-Mailer: Mew version 6.2.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-09, YIN 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, 07 Dec 2009 07:22:03 -0000 Andy Bierman wrote: > ------------------------------------------ > sec 11.1, para 6: > > Substatements of a YANG statement are encoded as (additional) > children of the keyword element and their relative order MUST be the > same as the order of substatements in YANG. > > This is only true if yin-element=true for the associated keyword. > XML attributes are unordered and tools such as libxml2 do > not preserve attribute order. No the text is correct. yin-element only refers to how the *argument* to the YANG keyword is encoded. Each YANG statement is mapped to a YIN XML element. /martin From mbj@tail-f.com Sun Dec 6 23:23: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 364A93A6976 for ; Sun, 6 Dec 2009 23:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=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 1fK3eccJxNMs for ; Sun, 6 Dec 2009 23:23:05 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6B5FF3A6916 for ; Sun, 6 Dec 2009 23:23:05 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4109976C685; Mon, 7 Dec 2009 08:22:55 +0100 (CET) Date: Mon, 07 Dec 2009 08:22:55 +0100 (CET) Message-Id: <20091207.082255.88175214.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1C6E03.5070708@netconfcentral.com> References: <4B1C6E03.5070708@netconfcentral.com> X-Mailer: Mew version 6.2.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-09, sec 11.1, YIN mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2009 07:23:06 -0000 Andy Bierman wrote: > Hi, > > Some of the YIN mapping rules seem rather random to me. > > Why is reference-stmt encoded as an attribute > but description-stmt is encoded as a element? > And contact, organization, etc. are encoded as an > element? > > I propose that all the purely descriptive YANG statements > that are unrestricted strings all be encoded as an > element called . I agree. > OLD entries: > > | contact | info | true | > | description | text | true | > | error-message | value | true | > | organization | info | true | > | reference | info | false | > > > NEW entries: > > | contact | text | true | > | description | text | true | > | error-message | text | true | > | organization | text | true | > | reference | text | true | > > > This also allows the xml:lang attribute to be applied, if desired. /martin From andy@netconfcentral.com Mon Dec 7 06:46: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 9CC3E3A6A4C for ; Mon, 7 Dec 2009 06:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 sTtOMTk45riU for ; Mon, 7 Dec 2009 06:46:09 -0800 (PST) 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 194953A6A55 for ; Mon, 7 Dec 2009 06:46:08 -0800 (PST) Received: (qmail 83811 invoked from network); 7 Dec 2009 14:45:59 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 07 Dec 2009 06:45:59 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: jxYpD2cVM1mkUKlkmwFvlpBUcKwPMvaR.3Bodp.qwjPVDDmNbA1Fy8phCbpnb41ErLBcnus_OaoT7CqOCmfOc_zpOMPNZ31fecrtWstVB0LupgXnjOwjhZH1ryncCkB7wH0EMzEWzonDwF1U8.lTEuTFK35QBnLlCOY7DQ14pRTZ4xxLT9LH7_X5udvp.yooM32cli0OUh2WvhYW1B4nJF0SFJ37TGRFDs6X4I4ZPwI_gL.ll4Krhs5jzjWi63SpkbvLIEg8DJAbvNcDRPZOmD.9xgyWWzvmPoZCOhqL6uWnElyLOvLpzvATTBYhyA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D149F.405@netconfcentral.com> Date: Mon, 07 Dec 2009 06:43:43 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1C3A53.5010800@netconfcentral.com> <20091207.082151.219043844.mbj@tail-f.com> In-Reply-To: <20091207.082151.219043844.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09, YIN 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, 07 Dec 2009 14:46:09 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> ------------------------------------------ >> sec 11.1, para 6: >> >> Substatements of a YANG statement are encoded as (additional) >> children of the keyword element and their relative order MUST be the >> same as the order of substatements in YANG. >> >> This is only true if yin-element=true for the associated keyword. >> XML attributes are unordered and tools such as libxml2 do >> not preserve attribute order. > > No the text is correct. yin-element only refers to how the *argument* > to the YANG keyword is encoded. Each YANG statement is mapped to a > YIN XML element. > oops --- never mind > > > /martin > Andy From andy@netconfcentral.com Mon Dec 7 06:51: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 9DDEF3A6A5A for ; Mon, 7 Dec 2009 06:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 vPkAI-9VXc0M for ; Mon, 7 Dec 2009 06:51:55 -0800 (PST) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id C6C633A6A10 for ; Mon, 7 Dec 2009 06:51:55 -0800 (PST) Received: (qmail 10999 invoked from network); 7 Dec 2009 14:51:43 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 06:51:43 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: sgSZEJUVM1n6qIaQ5NOuPjnfSZYvKQ9YCo0yTKRRowcWBhyrZFBwsBA1i0sH3wYBM35nO23wEbbenygGwOnQ6nWzq8Ci1JxuIC1uYPgjF69nJ5a3uaCTd3vost.rB_UhHZs67LZhggN66.0hLpF8WHOwGk2RHMjPrciq.0AwbzUKgqu9yr7Y6jVYo0uethg9tY8B05cfLdBFGF3l._n4Wb8FzH0xj3M3NoOzxUBrj9nSy3NRmbEdH1v.3iNrh0BUQCWzdZHrc7jqSsYzmxMI96MBp2Wx1pwwdYrAE.kxOJOhMjhXF2JSI3Uspnbcut_YCkSR_nIwKCjsYdqCTwCAWG5Z8CzRuHQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D15F7.4000907@netconfcentral.com> Date: Mon, 07 Dec 2009 06:49:27 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912070249.nB72nmGx058345@idle.juniper.net> In-Reply-To: <200912070249.nB72nmGx058345@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-09, YIN 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, 07 Dec 2009 14:51:56 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Not sure if 'no namespace' is as clear as 'unqualified attribute'. > > I don't think "unqualified attribute" was a clear meaning. It's not > in the XML or XML Namespace TRs, but the definition for "qualified attribute" > is: > > http://www.w3.org/TR/xml-names/#concepts > > Definition: A qualified name is a name subject to namespace interpretation. > > So an unqualified attribute would assumably be a name which is not > subject to namespace interpretation, which is not a good thing. So we want to support this: .... instead of: The attribute is supposed to be in 'no namespace' according to the YANG text > > In addition: > > In documents conforming to this specification, element and > attribute names appear as qualified names. Syntactically, they > are either prefixed names or unprefixed names. > > So every attribute name in a compliant document is a qname. Either > way, we should avoid "unqualified attribute" unless we can find a > clear definition for it. > >> The mapping between YANG and YIN does not modify the information >> content of the model. Whitespace is not preserved. >> Comments in YANG MAY be mapped to XML comments. > > Does this imply that comments are preserved? Do XML comments in > YIN get mapped to YANG comments? IMHO, stick with old sec 11, para 3, > and drop the old sec 11.1, para 7. If we're trying to say they > aren't preserved, then say it and no more. > The current text is wrong. 1 sentence says comments are ignored and another says they MAY get converted. I think even whitespace MAY be converted somehow. It is not required, and the client cannot expect it, but it is certainly not an error if the tool does convert either whitespace or comments. > Thanks, > Phil > Andy From andy@netconfcentral.com Mon Dec 7 07:06: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 2D9B03A6A45 for ; Mon, 7 Dec 2009 07:06:18 -0800 (PST) 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.048, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 bGW-qMjxxW+L for ; Mon, 7 Dec 2009 07:06:14 -0800 (PST) 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 5E21F3A67FB for ; Mon, 7 Dec 2009 07:06:14 -0800 (PST) Received: (qmail 28835 invoked from network); 7 Dec 2009 15:06:04 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 07:06:04 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: yVU1d_YVM1mibm114JWXj2Pc18oKUUGLhR0q7WN.3JxzJD5L0lwoqdQ3HDvfCHiUHCNhHQoScdupRwCeZYQV98WTUnCAp4PH8UcsuzlingjI9bNjm0hh7ka8Bh7yXcATgyz7TRFLoXb2t89dQveXGXLvt8wZwCds38i2q0h4WeDo5pS58uLrToQNcEQNfQuf6r80EGAYx48axQRhGgeCliHSKKwU8GY..hcbyg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D19CE.8010603@netconfcentral.com> Date: Mon, 07 Dec 2009 07:05:50 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] YIN as 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: Mon, 07 Dec 2009 15:06:18 -0000 Hi, Maybe this is out of scope for the standard, but I want to make sure... A 'YANG tool' MAY choose to convert YIN to YANG first, and not process YIN directly as input. This will only impact out-of-scope line numbers and other text in error/warning messages. Andy From phil@juniper.net Mon Dec 7 07:11: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 2E2243A6A58 for ; Mon, 7 Dec 2009 07:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 g6pIR8bCmRZz for ; Mon, 7 Dec 2009 07:11:28 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 7177B3A6837 for ; Mon, 7 Dec 2009 07:11:27 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSx0bFRDlj21HbLqfHiXDVF1XZJsfFHjt@postini.com; Mon, 07 Dec 2009 07:11:18 PST 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.393.1; Mon, 7 Dec 2009 07:03:35 -0800 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, 7 Dec 2009 07:03:35 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 07:03:34 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 07:03:34 -0800 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 nB7F3Yj20655; Mon, 7 Dec 2009 07:03:34 -0800 (PST) (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 nB7Enptv062557; Mon, 7 Dec 2009 14:49:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912071449.nB7Enptv062557@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B1D15F7.4000907@netconfcentral.com> Date: Mon, 7 Dec 2009 09:49:51 -0500 From: Phil Shafer X-OriginalArrivalTime: 07 Dec 2009 15:03:34.0735 (UTC) FILETIME=[729A4DF0:01CA774E] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-09, YIN 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, 07 Dec 2009 15:11:29 -0000 Andy Bierman writes: >The attribute is supposed to be in 'no namespace' according >to the YANG text This is fine, I'm just saying adding the term "unqualified attribute" is not a good thing. >The current text is wrong. >1 sentence says comments are ignored >and another says they MAY get converted. >I think even whitespace MAY be converted somehow. >It is not required, and the client cannot expect it, >but it is certainly not an error if the tool >does convert either whitespace or comments. The YANG->YIN->YANG mapping does not preserve comments or whitespace. Any features a particular toolset adds over the standard mapping (even stuff like indentation) are outside the standard. If your tool can roundtrip comments, that's fine, but it's not part of the standard as written. I think just saying "does not preserve" is fine. Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Dec 7 07:28: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 ACE2F3A68B7 for ; Mon, 7 Dec 2009 07:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.145, 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 iwfqZFWMQ8EC for ; Mon, 7 Dec 2009 07:28:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AD54D28C19B for ; Mon, 7 Dec 2009 07:28:46 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E087C002A; Mon, 7 Dec 2009 16:28:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 52m-KLMnimoy; Mon, 7 Dec 2009 16:28:35 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F47EC0019; Mon, 7 Dec 2009 16:28:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D24C0ECFCE8; Mon, 7 Dec 2009 16:28:33 +0100 (CET) Date: Mon, 7 Dec 2009 16:28:33 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091207152833.GA14588@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4B1D19CE.8010603@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1D19CE.8010603@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] YIN as input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 15:28:51 -0000 On Mon, Dec 07, 2009 at 04:05:50PM +0100, Andy Bierman wrote: > Hi, > > Maybe this is out of scope for the standard, > but I want to make sure... > > A 'YANG tool' MAY choose to convert YIN to YANG first, > and not process YIN directly as input. This will > only impact out-of-scope line numbers and other text > in error/warning messages. As far as I am concerned, a YANG parser only needs to be able to parse YANG modules. Something that can parse YIN modules natively I would call a YIN parser. I do not have a definition of "YANG tool" - but I would expect that such a tool supports and YANG parser (and I would leave it open what happens if you feed YIN into it ;-). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Mon Dec 7 07:31: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 EB2463A6A63 for ; Mon, 7 Dec 2009 07:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 GKtY7cF9NkdH for ; Mon, 7 Dec 2009 07:31:00 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id C54C53A6816 for ; Mon, 7 Dec 2009 07:30:59 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSx0fqcp69wvoLtkaiNHiZxhX+nY9y9M+@postini.com; Mon, 07 Dec 2009 07:30:51 PST 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.393.1; Mon, 7 Dec 2009 07:24:53 -0800 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, 7 Dec 2009 07:24:53 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 07:24:52 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 07:24:52 -0800 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 nB7FOpj29179; Mon, 7 Dec 2009 07:24:52 -0800 (PST) (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 nB7FB9AH062779; Mon, 7 Dec 2009 15:11:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912071511.nB7FB9AH062779@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B1D19CE.8010603@netconfcentral.com> Date: Mon, 7 Dec 2009 10:11:09 -0500 From: Phil Shafer X-OriginalArrivalTime: 07 Dec 2009 15:24:52.0563 (UTC) FILETIME=[6C3F6230:01CA7751] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] YIN as 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: Mon, 07 Dec 2009 15:31:02 -0000 Andy Bierman writes: >A 'YANG tool' MAY choose to convert YIN to YANG first, >and not process YIN directly as input. This will >only impact out-of-scope line numbers and other text >in error/warning messages. Yup, I could make an XSLT script that converts YANG modules to C code, and it would only handle YIN input. This is a tools issue. Thanks, Phil From andy@netconfcentral.com Mon Dec 7 08:09: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 BDA3C3A68A4 for ; Mon, 7 Dec 2009 08:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 5cH3lbC7SYik for ; Mon, 7 Dec 2009 08:09:10 -0800 (PST) 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 0FC3D3A6853 for ; Mon, 7 Dec 2009 08:09:10 -0800 (PST) Received: (qmail 51270 invoked from network); 7 Dec 2009 16:08:57 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 08:08:57 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: natr.FYVM1kejA3sCZPx9x4VhdhnEoALQ_ZtZQVPz78AVi27Nits7hIF97GB05xSswUVt3n5utzD0sZWT_8lY9f930gaq5bRqcqpIGDVed.rbWql4BoLG2cK.MYIh3VOzCwoWm3QR8n9Ws2IqpHL3Ifw36lI2G6PCpBSV0iHhUYM75mLUWWDUQJl_tPdGJYPPNQJi1uLMCzxUFHdHmBHIXZV_7rEWvGX5IEuK86uY4WjWq62LXrNViEnjMiNscBe X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D288A.4030106@netconfcentral.com> Date: Mon, 07 Dec 2009 08:08:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <4B1D19CE.8010603@netconfcentral.com> <20091207152833.GA14588@elstar.local> In-Reply-To: <20091207152833.GA14588@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YIN as 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: Mon, 07 Dec 2009 16:09:10 -0000 Juergen Schoenwaelder wrote: > On Mon, Dec 07, 2009 at 04:05:50PM +0100, Andy Bierman wrote: >> Hi, >> >> Maybe this is out of scope for the standard, >> but I want to make sure... >> >> A 'YANG tool' MAY choose to convert YIN to YANG first, >> and not process YIN directly as input. This will >> only impact out-of-scope line numbers and other text >> in error/warning messages. > > As far as I am concerned, a YANG parser only needs to be able to parse > YANG modules. Something that can parse YIN modules natively I would > call a YIN parser. > > I do not have a definition of "YANG tool" - but I would expect that > such a tool supports and YANG parser (and I would leave it open what > happens if you feed YIN into it ;-). > I agree with you, but these seems to be some expectation (by others) that the 2 forms are conceptually equivalent for all 'YANG RFC' compliant tools. The filename shows a YANG module extension as (.yang | .yin), and Balazs has said he wants tools to accept either form. I agree the standards requirement is that there is a loss-less mapping between the 2 forms, and the standard does not say anything about which tools must use which form. > /js > Andy From lhotka@cesnet.cz Mon Dec 7 09:47: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 EA6C63A681A for ; Mon, 7 Dec 2009 09:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkkBGwIrgIgW for ; Mon, 7 Dec 2009 09:47:39 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F27043A67B5 for ; Mon, 7 Dec 2009 09:47:38 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BE7A5D80095 for ; Mon, 7 Dec 2009 18:47:27 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4B1C3A53.5010800@netconfcentral.com> References: <4B1C3A53.5010800@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 07 Dec 2009 18:47:25 +0100 Message-ID: <1260208045.1816.128.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] yang-09, YIN 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, 07 Dec 2009 17:47:40 -0000 Andy Bierman píše v Ne 06. 12. 2009 v 15:12 -0800: > Hi, > > I think sec. 11 needs some minor changes: > > sec 11.1, para 5: > > OLD: > > The argument of a YANG statement is encoded in YIN either as an XML > attribute or a subelement of the keyword element. > > NEW: > > The argument of a YANG statement is encoded in YIN either as an > unqualified XML attribute or a subelement of the keyword element. > ^^^^^^^^^^^ > > also: > > o If the argument is encoded as an attribute, this attribute has no > namespace. > > Not sure if 'no namespace' is as clear as 'unqualified attribute'. I am against the change, 'no namespace' must be sufficiently clear to anybody with at least a faint idea about XML namespaces. Lada > > ------------------------------------------ > sec 11.1, para 6: > > Substatements of a YANG statement are encoded as (additional) > children of the keyword element and their relative order MUST be the > same as the order of substatements in YANG. > > This is only true if yin-element=true for the associated keyword. > XML attributes are unordered and tools such as libxml2 do > not preserve attribute order. > > -------------------------------------------- > > OLD: > > sec 11, para 3: > > The mapping between YANG and YIN does not modify the information > content of the model. Comments and whitespace are not preserved. > > sec 11.1, para 7: > > Comments in YANG MAY be mapped to XML comments. > > Suggest this text be combined into sec 11, para 3, and fixed: > > NEW: > > sec 11, para 3: > > The mapping between YANG and YIN does not modify the information > content of the model. Whitespace is not preserved. > Comments in YANG MAY be mapped to XML comments. > > ---------------------------------------------- > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Dec 7 09:57: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 57CA03A67B5 for ; Mon, 7 Dec 2009 09:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.141, 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 mUVAn+SrsXnh for ; Mon, 7 Dec 2009 09:57:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 381803A68DB for ; Mon, 7 Dec 2009 09:57:03 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08CE6C006D; Mon, 7 Dec 2009 18:56:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GBpDE-S1TeeR; Mon, 7 Dec 2009 18:56:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D4EDC0079; Mon, 7 Dec 2009 18:56:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6B8D2ED9D61; Mon, 7 Dec 2009 18:56:49 +0100 (CET) Date: Mon, 7 Dec 2009 18:56:48 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091207175648.GB14588@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4B1D19CE.8010603@netconfcentral.com> <20091207152833.GA14588@elstar.local> <4B1D288A.4030106@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1D288A.4030106@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] YIN as input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 17:57:04 -0000 On Mon, Dec 07, 2009 at 05:08:42PM +0100, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Mon, Dec 07, 2009 at 04:05:50PM +0100, Andy Bierman wrote: > >> Hi, > >> > >> Maybe this is out of scope for the standard, > >> but I want to make sure... > >> > >> A 'YANG tool' MAY choose to convert YIN to YANG first, > >> and not process YIN directly as input. This will > >> only impact out-of-scope line numbers and other text > >> in error/warning messages. > > > > As far as I am concerned, a YANG parser only needs to be able to parse > > YANG modules. Something that can parse YIN modules natively I would > > call a YIN parser. > > > > I do not have a definition of "YANG tool" - but I would expect that > > such a tool supports and YANG parser (and I would leave it open what > > happens if you feed YIN into it ;-). > > > > I agree with you, but these seems to be some > expectation (by others) that the 2 forms are > conceptually equivalent for all 'YANG RFC' compliant tools. > > The filename shows a YANG module extension as (.yang | .yin), > and Balazs has said he wants tools to accept either form. > > I agree the standards requirement is that there is a loss-less > mapping between the 2 forms, and the standard does not say > anything about which tools must use which form. I had some private interaction about this with Martin and I am going to post a separate last call comment in order to make this clearer. But give me a few more days of reading time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Dec 7 10:06: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 EB5D13A6A99 for ; Mon, 7 Dec 2009 10:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=0.282, 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 OLL9QtMe4COy for ; Mon, 7 Dec 2009 10:06:04 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C9C593A680D for ; Mon, 7 Dec 2009 10:06:03 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D065BD80095; Mon, 7 Dec 2009 19:05:53 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B1D15F7.4000907@netconfcentral.com> References: <200912070249.nB72nmGx058345@idle.juniper.net> <4B1D15F7.4000907@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 07 Dec 2009 19:05:51 +0100 Message-ID: <1260209151.1816.139.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-09, YIN 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, 07 Dec 2009 18:06:05 -0000 Andy Bierman píše v Po 07. 12. 2009 v 06:49 -0800: > Phil Shafer wrote: > > Andy Bierman writes: > >> Not sure if 'no namespace' is as clear as 'unqualified attribute'. > > > > I don't think "unqualified attribute" was a clear meaning. It's not > > in the XML or XML Namespace TRs, but the definition for "qualified attribute" > > is: > > > > http://www.w3.org/TR/xml-names/#concepts > > > > Definition: A qualified name is a name subject to namespace interpretation. > > > > So an unqualified attribute would assumably be a name which is not > > subject to namespace interpretation, which is not a good thing. > > So we want to support this: > > .... I believe this is not allowed. Only the attribute value in a default namespace declaration may be empty. > > instead of: > > > > The attribute is supposed to be in 'no namespace' according > to the YANG text This attribute is in no namespace according to the rules of XML namespaces. Lada > > > > > > In addition: > > > > In documents conforming to this specification, element and > > attribute names appear as qualified names. Syntactically, they > > are either prefixed names or unprefixed names. > > > > So every attribute name in a compliant document is a qname. Either > > way, we should avoid "unqualified attribute" unless we can find a > > clear definition for it. > > > >> The mapping between YANG and YIN does not modify the information > >> content of the model. Whitespace is not preserved. > >> Comments in YANG MAY be mapped to XML comments. > > > > Does this imply that comments are preserved? Do XML comments in > > YIN get mapped to YANG comments? IMHO, stick with old sec 11, para 3, > > and drop the old sec 11.1, para 7. If we're trying to say they > > aren't preserved, then say it and no more. > > > > The current text is wrong. > 1 sentence says comments are ignored > and another says they MAY get converted. > I think even whitespace MAY be converted somehow. > It is not required, and the client cannot expect it, > but it is certainly not an error if the tool > does convert either whitespace or comments. > > > > Thanks, > > Phil > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Dec 7 10:19: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 41C8A3A6940 for ; Mon, 7 Dec 2009 10:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 OettcMi66h+5 for ; Mon, 7 Dec 2009 10:19:32 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 635803A694A for ; Mon, 7 Dec 2009 10:19:32 -0800 (PST) Received: (qmail 76923 invoked from network); 7 Dec 2009 18:19:20 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 10:19:19 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: TXDr9WMVM1k9jis8_GlDiKO9dJYo943pOmDDvgqMsn7el3GAhCkgSboGLRaoVB2iL9DCfGXAP7mQfM2GUnpomT3ejJBNk0oJWt9eTpki6J3nJxG3IVGRtr99cw8EGhxRDfjXCGqR3_4o_Jz_RorbwdtzmL4C2MW0wdCg2Ao2gqZF7n_Z81eoR5ASWYcaiorkj4fGcVCDgSYbkZaU3_DMPyXeHMmvgtIaWC9desnYr9AFUsjkO_56HUmjSn9gF8Re X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D469D.5030203@netconfcentral.com> Date: Mon, 07 Dec 2009 10:17:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <4B1D19CE.8010603@netconfcentral.com> <20091207152833.GA14588@elstar.local> <4B1D288A.4030106@netconfcentral.com> <20091207175648.GB14588@elstar.local> In-Reply-To: <20091207175648.GB14588@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YIN as 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: Mon, 07 Dec 2009 18:19:33 -0000 Juergen Schoenwaelder wrote: > On Mon, Dec 07, 2009 at 05:08:42PM +0100, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Mon, Dec 07, 2009 at 04:05:50PM +0100, Andy Bierman wrote: >>>> Hi, >>>> >>>> Maybe this is out of scope for the standard, >>>> but I want to make sure... >>>> >>>> A 'YANG tool' MAY choose to convert YIN to YANG first, >>>> and not process YIN directly as input. This will >>>> only impact out-of-scope line numbers and other text >>>> in error/warning messages. >>> As far as I am concerned, a YANG parser only needs to be able to parse >>> YANG modules. Something that can parse YIN modules natively I would >>> call a YIN parser. >>> >>> I do not have a definition of "YANG tool" - but I would expect that >>> such a tool supports and YANG parser (and I would leave it open what >>> happens if you feed YIN into it ;-). >>> >> I agree with you, but these seems to be some >> expectation (by others) that the 2 forms are >> conceptually equivalent for all 'YANG RFC' compliant tools. >> >> The filename shows a YANG module extension as (.yang | .yin), >> and Balazs has said he wants tools to accept either form. >> >> I agree the standards requirement is that there is a loss-less >> mapping between the 2 forms, and the standard does not say >> anything about which tools must use which form. > > I had some private interaction about this with Martin and I am going > to post a separate last call comment in order to make this clearer. > But give me a few more days of reading time. > Sure. We also need to resolve the other WGLC comments: - change rules wrt/ revisions - filename separator char (. or @ or +) IMO, there is nothing to test wrt/ YIN compliance except the translation between YIN and YANG format. If I am wrong, please point out the text that defines more YIN requirements. A YANG compiler follows the YANG ABNF. I don't know what normative syntax a YIN compiler would use. The YIN to YANG translation is not exactly spelled out either. Also, I suggest showing a complete example for YIN, starting from the top-level element: ... ... put the current leaf example here Also, a translator is probably going to want to declare the same XML prefixes as used in all the import-stmts: e.g. import ietf-yang-types { prefix inet; } ... module contents This does not have to be done in the top-level element of course. > /js > Andy From andy@netconfcentral.com Mon Dec 7 11:05: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 4AAB83A676A for ; Mon, 7 Dec 2009 11:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 FXNuIpjTY+KU for ; Mon, 7 Dec 2009 11:05:42 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 7A7B43A66B4 for ; Mon, 7 Dec 2009 11:05:42 -0800 (PST) Received: (qmail 32994 invoked from network); 7 Dec 2009 19:05:30 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 11:05:29 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: _EJHdwAVM1l8Op4ZgBNf_T7Kx913aQeDief4N3_ODGspy8AOpcQIfZ8qkfwmoor1KD0FJrIkdlYmromEqLgsxuz0jnxq8QzmeaTQzCZL7591L.YWEPUclBJYF8eOOkYimJbOlXlgaC55tZXORdrCm4JWaRbvb_XB8cTYnM_vCNUlC3o8DeOGIhwDju6g3PhWJz.FHyMgKNV_f27QB7EI1.REO_HYNr8xqQs4HjgW9A7emvOu5x4qGawUg27CgqP9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D51EA.6000407@netconfcentral.com> Date: Mon, 07 Dec 2009 11:05:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-09, sec.10, revision rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2009 19:05:43 -0000 Hi, [this WGLC comment got lost in the wrong thread] It does not make any sense to talk about different versions of a YANG [sub]module without a new revision date. There is no way to even distinguish which is the old version and which is the new version in a standard way. Sec 10: For any published change, a new "revision" statement (Section 7.1.9) SHOULD be included in front of the existing revision statements. Edit 1: s/SHOULD/MUST Edit 2: state (somewhere in sec. 10) that a module without revisions MUST NOT change (ever) Summary: - if you use a revision in the first publication, you have to keep using revisions correctly every time the module is changed. - if you choose not to use revisions, then there is only one revision (ala no namespace in XML) that is possible. Therefore no changes to the module are allowed at all. Either that, or add text that explains how the standard is used to distinguish different versions of a conceptual YANG [sub]module, by some means other than the revision date. Andy From mbj@tail-f.com Mon Dec 7 11:44: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 4FA2428C1A7 for ; Mon, 7 Dec 2009 11:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, 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 8KpvY0KSH5i1 for ; Mon, 7 Dec 2009 11:44:01 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 766B728C14C for ; Mon, 7 Dec 2009 11:44:01 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7528076C685; Mon, 7 Dec 2009 20:43:50 +0100 (CET) Date: Mon, 07 Dec 2009 20:43:49 +0100 (CET) Message-Id: <20091207.204349.232554715.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1D51EA.6000407@netconfcentral.com> References: <4B1D51EA.6000407@netconfcentral.com> X-Mailer: Mew version 6.2.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-09, sec.10, revision rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2009 19:44:02 -0000 Andy Bierman wrote: > Hi, > > [this WGLC comment got lost in the wrong thread] > > > It does not make any sense to talk about different versions > of a YANG [sub]module without a new revision date. There is no way > to even distinguish which is the old version and which is > the new version in a standard way. > > Sec 10: > > For any published change, a new "revision" statement (Section 7.1.9) > SHOULD be included in front of the existing revision statements. > > Edit 1: s/SHOULD/MUST I agree. > Edit 2: state (somewhere in sec. 10) that a module without > revisions MUST NOT change (ever) I don't think this is necessary, but I'm ok with adding it. /martin From mbj@tail-f.com Mon Dec 7 11:56: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 A81623A67AE for ; Mon, 7 Dec 2009 11:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=-1.206, 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 Bv3OHm-e5xCt for ; Mon, 7 Dec 2009 11:56:51 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A56F63A67A1 for ; Mon, 7 Dec 2009 11:56:51 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 43DB976C685; Mon, 7 Dec 2009 20:56:41 +0100 (CET) Date: Mon, 07 Dec 2009 20:56:40 +0100 (CET) Message-Id: <20091207.205640.262259259.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund X-Mailer: Mew version 6.2.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: [netmod] Filename recommendation (Was: convention) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2009 19:56:52 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 04, 2009 at 09:26:38PM +0100, Andy Bierman wrote: > > > >> yep -- I begged the WG (early on) to reserve 1 printable > > >> character from identifiers, but people insisted they need > > >> the freedom to use every legal XML identifier value. > > > > > > My keyboard still has characters left that are not allowed in a legal > > > YANG identifier - so I do not see this as a hard engineering challenge. > > > > Really? > > So which characters are available that are > > present on every keyboard, and are not special > > characters in any operating system filespec? > > I assume every keyboard has a '+' for example. And I was not talking > about "any operating system filespec". I was talking about (a) picking > a character that is not a legal module name character and (b) avoiding > the '.' since it is used by major OSes as a separator for the file > type suffix. Which major OS will have a problem with this? The Wikipedia article on Filenames (http://en.wikipedia.org/wiki/Filenames)says this on '.': allowed but the last occurrence will be interpreted to be the extension separator in VMS, MS-DOS and Windows. In other OSes, usually considered as part of the filename, and more than one full stop may be allowed. Using the filename [.].yang is just a recommendation anyway. Modules need not be stored in files. /martin From andy@netconfcentral.com Mon Dec 7 11:59: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 C81003A67F4 for ; Mon, 7 Dec 2009 11:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_05=-1.11, UNPARSEABLE_RELAY=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 vBWAVq1PFyS6 for ; Mon, 7 Dec 2009 11:59:49 -0800 (PST) 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 D8CEC3A67A1 for ; Mon, 7 Dec 2009 11:59:49 -0800 (PST) Received: (qmail 36996 invoked from network); 7 Dec 2009 19:59:37 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 11:59:37 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: ZKITjhEVM1kD3sDDCJBXrQ3wM.fkR5jkmbYAFLF3yFLEcjGSiKDnYZM3C.5woQ0dCTdB4LaeECJLPniok8QS0v4J_xMRhzl1pK5rveq_OZkbfqXe9f1d3bNv78R2WpFKX1dIEGMLae8_8DQ3sqVVA2rXEM1CTE5z5O.xEjhJQdaunOXlWdWTsXQt.Da6_tLqjYz.VWtSGYel9xSGYSqBCyNmzv0WDM6b_8WgDZElYtQutwAoFUOkuxpJzrHxZ3oo7gt0pcJDXDCqzAdFjA_cS2YSkO0WIJPRaTGSWL.7SIYUxQL7Hkp.lhLFfiWrXTJXHmwC6A9gfFmXm.2mra_HS_Eh9UaNw6aX2DmVQ7FacS2tuecpJlA2eRLJwRhqFzsR3A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D5E98.4040600@netconfcentral.com> Date: Mon, 07 Dec 2009 11:59:20 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091207.205640.262259259.mbj@tail-f.com> In-Reply-To: <20091207.205640.262259259.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Filename recommendation (Was: convention) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2009 19:59:50 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Fri, Dec 04, 2009 at 09:26:38PM +0100, Andy Bierman wrote: >> >>>>> yep -- I begged the WG (early on) to reserve 1 printable >>>>> character from identifiers, but people insisted they need >>>>> the freedom to use every legal XML identifier value. >>>> My keyboard still has characters left that are not allowed in a legal >>>> YANG identifier - so I do not see this as a hard engineering challenge. >>> Really? >>> So which characters are available that are >>> present on every keyboard, and are not special >>> characters in any operating system filespec? >> I assume every keyboard has a '+' for example. And I was not talking >> about "any operating system filespec". I was talking about (a) picking >> a character that is not a legal module name character and (b) avoiding >> the '.' since it is used by major OSes as a separator for the file >> type suffix. > > Which major OS will have a problem with this? The Wikipedia article > on Filenames (http://en.wikipedia.org/wiki/Filenames)says this on '.': > > allowed but the last occurrence will be interpreted to be the > extension separator in VMS, MS-DOS and Windows. In other OSes, > usually considered as part of the filename, and more than one full > stop may be allowed. > > Using the filename [.].yang is just a recommendation > anyway. Modules need not be stored in files. > If we are going to have a recommendation at all, then we should have one that actually works. It should be obvious that the separator char between the module name and the revision-date cannot be a valid module name character. > > /martin > Andy From mbj@tail-f.com Mon Dec 7 12:10: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 F166F3A6808 for ; Mon, 7 Dec 2009 12:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.161, 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 uI0nQBdecrQP for ; Mon, 7 Dec 2009 12:10:47 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A82DA3A6967 for ; Mon, 7 Dec 2009 12:10:47 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 472D876C685; Mon, 7 Dec 2009 21:10:37 +0100 (CET) Date: Mon, 07 Dec 2009 21:10:36 +0100 (CET) Message-Id: <20091207.211036.17465594.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1D5E98.4040600@netconfcentral.com> References: <20091207.205640.262259259.mbj@tail-f.com> <4B1D5E98.4040600@netconfcentral.com> X-Mailer: Mew version 6.2.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] Filename recommendation X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2009 20:10:49 -0000 Andy Bierman wrote: > If we are going to have a recommendation at all, > then we should have one that actually works. > It should be obvious that the separator char > between the module name and the revision-date > cannot be a valid module name character. When you say that it doesn't work, do you mean because with the current scheme, you cannot have revision '2009-04-01' of the module 'foo' in the same directory as you have the module with the name 'foo.2009-04-01'? /martin From andy@netconfcentral.com Mon Dec 7 12:19: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 33ADB3A6963 for ; Mon, 7 Dec 2009 12:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 bvVCXIifZsMZ for ; Mon, 7 Dec 2009 12:19:49 -0800 (PST) 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 76EF93A692F for ; Mon, 7 Dec 2009 12:19:49 -0800 (PST) Received: (qmail 12121 invoked from network); 7 Dec 2009 20:19:37 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 07 Dec 2009 12:19:37 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: abSW6wkVM1k7iGSZ6TlTOFHuPh6ssgMNw1gpU2JgXKiMBP.3rpLXrfFFNHw1xopeyhuBcy6VFLSjqtO07KmrlnLQA4vwi2IVvul56H5_VsN4NqAQaSzqnJ2WNexN_M1sTC8fSg93ZhfM8Hbv6VLj3D89DDGrrjP5Zjl4cSGGUdCiSIpvRT1nGApQoWv1SlqW.k8nidKcOoMjy09bs9nS2ak0.45wLwEFYnkGp3PaaMmRGqSn1AdYLrNt3cg_rh9cdv56O9nxJSaRYWD9uvtgb_7g90RlO2a.BPqe0Yxulxu8ZXrvD7u12Ftv.Sw0iA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D62D1.1060702@netconfcentral.com> Date: Mon, 07 Dec 2009 12:17:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091207.205640.262259259.mbj@tail-f.com> <4B1D5E98.4040600@netconfcentral.com> <20091207.211036.17465594.mbj@tail-f.com> In-Reply-To: <20091207.211036.17465594.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Filename recommendation X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2009 20:19:50 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> If we are going to have a recommendation at all, >> then we should have one that actually works. >> It should be obvious that the separator char >> between the module name and the revision-date >> cannot be a valid module name character. > > When you say that it doesn't work, do you mean because with the > current scheme, you cannot have revision '2009-04-01' of the module > 'foo' in the same directory as you have the module with the name > 'foo.2009-04-01'? > yes. I think @ is a legal file name char, but it is not a legal module name char, so a module named foo.2009-01-01 can never collide with module foo@2009-01-01. > > /martin > Andy From j.schoenwaelder@jacobs-university.de Mon Dec 7 12:31: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 C311B3A677D for ; Mon, 7 Dec 2009 12:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 cvfZYz5CK8yE for ; Mon, 7 Dec 2009 12:31:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C54A33A67A5 for ; Mon, 7 Dec 2009 12:31:36 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BD46C0072; Mon, 7 Dec 2009 21:31:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4Xc4FriM+mzM; Mon, 7 Dec 2009 21:31:25 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D13AEC006D; Mon, 7 Dec 2009 21:31:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F168EECAFA; Mon, 7 Dec 2009 21:31:24 +0100 (CET) Date: Mon, 7 Dec 2009 21:31:24 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091207203124.GA62625@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <20091207.205640.262259259.mbj@tail-f.com> <4B1D5E98.4040600@netconfcentral.com> <20091207.211036.17465594.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091207.211036.17465594.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Filename recommendation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:31:37 -0000 On Mon, Dec 07, 2009 at 09:10:36PM +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > If we are going to have a recommendation at all, > > then we should have one that actually works. > > It should be obvious that the separator char > > between the module name and the revision-date > > cannot be a valid module name character. > > When you say that it doesn't work, do you mean because with the > current scheme, you cannot have revision '2009-04-01' of the module > 'foo' in the same directory as you have the module with the name > 'foo.2009-04-01'? For me, this is indeed a concern about corner case that can be easily avoided by choosing a separator character not allowed in a module name. This is the technical argument; which character to pick is probably more a matter of taste. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Dec 7 12:36: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 BD3F73A6936 for ; Mon, 7 Dec 2009 12:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.153, 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 dN-st7KuW2vN for ; Mon, 7 Dec 2009 12:36:06 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7AABF3A691A for ; Mon, 7 Dec 2009 12:36:06 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 29B7C76C685; Mon, 7 Dec 2009 21:35:56 +0100 (CET) Date: Mon, 07 Dec 2009 21:35:55 +0100 (CET) Message-Id: <20091207.213555.143897599.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1D469D.5030203@netconfcentral.com> References: <4B1D288A.4030106@netconfcentral.com> <20091207175648.GB14588@elstar.local> <4B1D469D.5030203@netconfcentral.com> X-Mailer: Mew version 6.2.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] YIN as 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: Mon, 07 Dec 2009 20:36:07 -0000 Andy Bierman wrote: > IMO, there is nothing to test wrt/ YIN compliance except > the translation between YIN and YANG format. If I > am wrong, please point out the text that defines more > YIN requirements. > > A YANG compiler follows the YANG ABNF. I don't know what > normative syntax a YIN compiler would use. > > The YIN to YANG translation is not exactly spelled out either. The idea is that YIN is explained as an alternative *syntax* for YANG. For each statement it is described what it looks like in YIN. We could of course include e.g. a RelaxNG schema for YIN, if the WG thinks it is necessary. I don't think it is; I think the current rules are sufficient. Ladislav wrote down the RNG and RNC schemas, using the draft, they are available from http://www.yang-central.org/twiki/bin/view/Main/YangTools > Also, I suggest showing a complete example for YIN, > starting from the top-level element: > > > name="acme-foo" > xmlns="urn:ietf:params:xml:ns:yang:yin:1"> > > > ... > ... put the current leaf example here > Ok. I can add that, giving this: The following YANG module: module acme-foo { namespace "http://acme.example.com/foo"; prefix "acfoo"; import my-extensions { prefix "myext"; } list interface { key "name"; leaf name { type string; } leaf mtu { type uint32; description "The MTU of the interface."; myext:c-define "MY_MTU"; } } } where the extension "c-define" is defined in ^extension-example^, is translated into the following YIN: The MTU of the interface. /martin From andy@netconfcentral.com Mon Dec 7 12:51: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 DAB4C3A6936 for ; Mon, 7 Dec 2009 12:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 NsaJLOV9UrkK for ; Mon, 7 Dec 2009 12:51:24 -0800 (PST) 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 C93DA3A68E1 for ; Mon, 7 Dec 2009 12:51:24 -0800 (PST) Received: (qmail 84391 invoked from network); 7 Dec 2009 20:51:12 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 07 Dec 2009 12:51:11 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: K39eX9YVM1nok12LamsWBGoPc44o71weugvXu75oDEQ00gUO3dPmOLNcefsvC.qDMMtH_uYmGPr4.MqaBEuvIdNU.GwBdr41skvgl7PUExaty7CZIkh4UIfLpJGkzwaNSi2UCa8_NBmdzN.8dxhk_sWhqr8Xn7hjTHv4oxozC6XknRpMfC2BjebPJx6lPypZsjiFj9wsLXBa6LQtyjpF6cReAkeyRgQWljiciF6688u2k6ILpVc3NB7KFZbu1v4BORZEi0Xn5.mAXdsKGlxWDdIN6bhtklhwivFEO1zwmxhvMxBcrZFI.pJ3wApCVNkpObJBydPlRg3j9ANwACQJJujDrBpdaaLYoCRWkpCcHuoBal49p4EfuKEpIpA5c.38Mtesyx.9pa.fYmCKRsBhFXipJUYlMwfmUF4vqy9Db0PPyj0N3PKdiMku3F1sxsDXsZw1nnEkHG19 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D6A35.9050003@netconfcentral.com> Date: Mon, 07 Dec 2009 12:48:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1D288A.4030106@netconfcentral.com> <20091207175648.GB14588@elstar.local> <4B1D469D.5030203@netconfcentral.com> <20091207.213555.143897599.mbj@tail-f.com> In-Reply-To: <20091207.213555.143897599.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YIN as 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: Mon, 07 Dec 2009 20:51:26 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO, there is nothing to test wrt/ YIN compliance except >> the translation between YIN and YANG format. If I >> am wrong, please point out the text that defines more >> YIN requirements. >> >> A YANG compiler follows the YANG ABNF. I don't know what >> normative syntax a YIN compiler would use. >> >> The YIN to YANG translation is not exactly spelled out either. > > The idea is that YIN is explained as an alternative *syntax* for > YANG. For each statement it is described what it looks like in YIN. > We could of course include e.g. a RelaxNG schema for YIN, if the WG > thinks it is necessary. I don't think it is; I think the current > rules are sufficient. I do not think the draft defines any formal mechanisms to support YIN as input. There is only a YANG to YIN algorithm defined. I do not see a table that translates XML elements and attributes to YANG keywords and arguments. IMO, supporting YIN directly as input, without translating to YANG first, is a tools detail outside the scope of this document. Andy > > Ladislav wrote down the RNG and RNC schemas, using the draft, they are > available from > http://www.yang-central.org/twiki/bin/view/Main/YangTools > >> Also, I suggest showing a complete example for YIN, >> starting from the top-level element: >> >> >> > name="acme-foo" >> xmlns="urn:ietf:params:xml:ns:yang:yin:1"> >> >> >> ... >> ... put the current leaf example here >> > > Ok. I can add that, giving this: > > > The following YANG module: > > module acme-foo { > namespace "http://acme.example.com/foo"; > prefix "acfoo"; > > import my-extensions { > prefix "myext"; > } > > list interface { > key "name"; > leaf name { > type string; > } > > leaf mtu { > type uint32; > description "The MTU of the interface."; > myext:c-define "MY_MTU"; > } > } > } > > where the extension "c-define" is defined in ^extension-example^, is > translated into the following YIN: > > xmlns="urn:ietf:params:xml:ns:yang:yin:1" > xmlns:acfoo="http://acme.example.com/foo" > xmlns:myext="http://example.com/my-extensions"> > > > > > > > > > > > > > > > > > > The MTU of the interface. > > > > > > > > > /martin > From mbj@tail-f.com Mon Dec 7 13:05: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 7396728C1B7 for ; Mon, 7 Dec 2009 13:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[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 nitVnDjocgmR for ; Mon, 7 Dec 2009 13:05:55 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 952F828C1B1 for ; Mon, 7 Dec 2009 13:05:55 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 813EF76C685; Mon, 7 Dec 2009 22:05:44 +0100 (CET) Date: Mon, 07 Dec 2009 22:05:43 +0100 (CET) Message-Id: <20091207.220543.143985162.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1D6A35.9050003@netconfcentral.com> References: <4B1D469D.5030203@netconfcentral.com> <20091207.213555.143897599.mbj@tail-f.com> <4B1D6A35.9050003@netconfcentral.com> X-Mailer: Mew version 6.2.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] YIN as 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: Mon, 07 Dec 2009 21:05:56 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> IMO, there is nothing to test wrt/ YIN compliance except > >> the translation between YIN and YANG format. If I > >> am wrong, please point out the text that defines more > >> YIN requirements. > >> > >> A YANG compiler follows the YANG ABNF. I don't know what > >> normative syntax a YIN compiler would use. > >> > >> The YIN to YANG translation is not exactly spelled out either. > > > > The idea is that YIN is explained as an alternative *syntax* for > > YANG. For each statement it is described what it looks like in YIN. > > We could of course include e.g. a RelaxNG schema for YIN, if the WG > > thinks it is necessary. I don't think it is; I think the current > > rules are sufficient. > > > I do not think the draft defines any formal > mechanisms to support YIN as input. There is only > a YANG to YIN algorithm defined. I do not see > a table that translates XML elements and attributes > to YANG keywords and arguments. In version -04, the algorithmic description was rewritten (by Lada) to a declarative style. I think the current text is clear on how a YIN element is supposed to be interpreted: There is a one-to-one correspondence between YANG keywords and YIN elements. The local name of a YIN element is identical to the corresponding YANG keyword. [...] YIN elements corresponding to the core YANG keywords belong to the namespace whose associated URI is "urn:ietf:params:xml:ns:yang:yin:1" > IMO, supporting YIN directly as input, without > translating to YANG first, is a tools detail > outside the scope of this document. If we want to talk about conformance for tools, that's a separate issue. The rules for what YIN is need to be clear in any case. /martin From andy@netconfcentral.com Mon Dec 7 13:33: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 C82103A6856 for ; Mon, 7 Dec 2009 13:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 jXu9ZbFBND4Q for ; Mon, 7 Dec 2009 13:33:57 -0800 (PST) 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 160663A67B0 for ; Mon, 7 Dec 2009 13:33:57 -0800 (PST) Received: (qmail 22035 invoked from network); 7 Dec 2009 21:33:45 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 07 Dec 2009 13:33:45 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Ur5hvwMVM1keLcFBHXCVY8kfouYpC7rSbFKyXyB32eai_Ei._gbK9HS5.QVIIA2DaW1nTFZbe.SQJz8KxJwklZ2XfKbL3YizUj1Y2R5PqBKIrt1e5Bu72ugCwm8QrgO5eHkHOgwDZXd2jIow84QQkqMeg8I4QIMMD4PNDclD5ws13i4a7N0819ulyl2.KDIHNSnX47zPWO6jA6Z8YMEgnK61pHweyLQNWZ3AaAOCX8p06AaWZ.ZaRgmtKb3sKBe8zsVkGOXMkNs9I0qtrJvVnvf34oIqNnpEzkVOXdO.jGCBgc_lovkDRvp7_iDn4Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D74A9.9050201@netconfcentral.com> Date: Mon, 07 Dec 2009 13:33:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1D469D.5030203@netconfcentral.com> <20091207.213555.143897599.mbj@tail-f.com> <4B1D6A35.9050003@netconfcentral.com> <20091207.220543.143985162.mbj@tail-f.com> In-Reply-To: <20091207.220543.143985162.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YIN as 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: Mon, 07 Dec 2009 21:33:57 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> IMO, there is nothing to test wrt/ YIN compliance except >>>> the translation between YIN and YANG format. If I >>>> am wrong, please point out the text that defines more >>>> YIN requirements. >>>> >>>> A YANG compiler follows the YANG ABNF. I don't know what >>>> normative syntax a YIN compiler would use. >>>> >>>> The YIN to YANG translation is not exactly spelled out either. >>> The idea is that YIN is explained as an alternative *syntax* for >>> YANG. For each statement it is described what it looks like in YIN. >>> We could of course include e.g. a RelaxNG schema for YIN, if the WG >>> thinks it is necessary. I don't think it is; I think the current >>> rules are sufficient. >> >> I do not think the draft defines any formal >> mechanisms to support YIN as input. There is only >> a YANG to YIN algorithm defined. I do not see >> a table that translates XML elements and attributes >> to YANG keywords and arguments. > > In version -04, the algorithmic description was rewritten (by Lada) > to a declarative style. I think the current text is clear on how a > YIN element is supposed to be interpreted: > > There is a one-to-one correspondence between YANG keywords and YIN > elements. The local name of a YIN element is identical to the > corresponding YANG keyword. [...] > > YIN elements corresponding to the core YANG keywords belong to the > namespace whose associated URI is > "urn:ietf:params:xml:ns:yang:yin:1" > >> IMO, supporting YIN directly as input, without >> translating to YANG first, is a tools detail >> outside the scope of this document. > > If we want to talk about conformance for tools, that's a separate > issue. The rules for what YIN is need to be clear in any case. > What about the rules for attributes? Not every XML attribute translates into a YANG keyword. But I don't really think the YIN to YANG translation is too hard to figure out, so I don't have any edits to offer. Just change the mappings for descriptive statements to be all the same (text/true). > > /martin > Andy From washam.fan@gmail.com Tue Dec 8 06:15: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 6E1233A69F0 for ; Tue, 8 Dec 2009 06:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 A3mxi2LTCY19 for ; Tue, 8 Dec 2009 06:15:13 -0800 (PST) Received: from mail-vw0-f184.google.com (mail-vw0-f184.google.com [209.85.212.184]) by core3.amsl.com (Postfix) with ESMTP id 3C21F28C13B for ; Tue, 8 Dec 2009 06:15:13 -0800 (PST) Received: by vws14 with SMTP id 14so2619899vws.32 for ; Tue, 08 Dec 2009 06:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ZFG9TiGNWny/XZx2abbl1tptgxAsPkuAoWUxQnGNgMc=; b=AmlmM4Nqtgl8EAxhqkDrbFqPJ3TL+towR8lpBIr1Ogg1Wua02XTwdhOl9JVdbl/Eni zrhXRb8BIMjljIV7l/5MEldWRhk4bDGeTnUmW1v6tp4dCnBYZ591rVw1xQ4dWSNTOwWZ bL4nj6rQU4fJngq/EqayMhlArYdHRpRxlXP84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=W9XxlBMJhX4yNR1zgCz5L8cnT5EEiAEprKHU2wr9uI88NsefhrdB6bb7YkEKJG9iL3 m2e8dcuRdaSKGf+zQfOlIM8KQUT4S49aHFtKttfB24sUmKi9kxa57/tlFq3Yp++5KxHH OHShj5LgN7CyXPEIFKtbCkb72hiq/MC0pS578= MIME-Version: 1.0 Received: by 10.220.3.211 with SMTP id 19mr335902vco.67.1260281699974; Tue, 08 Dec 2009 06:14:59 -0800 (PST) Date: Tue, 8 Dec 2009 22:14:59 +0800 Message-ID: From: Washam Fan To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] yang-09, sec.10, revision rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2009 14:15:14 -0000 Hi Martin, > Andy Bierman wrote: > > Hi, > > > > [this WGLC comment got lost in the wrong thread] > > > > > > It does not make any sense to talk about different versions > > of a YANG [sub]module without a new revision date. =A0There is no way > > to even distinguish which is the old version and which is > > the new version in a standard way. > > > > Sec 10: > > > > =A0 For any published change, a new "revision" statement (Section 7.1.9= ) > > =A0 SHOULD be included in front of the existing revision statements. > > > > Edit 1: =A0s/SHOULD/MUST > > I agree. > > > Edit 2: =A0state (somewhere in sec. 10) that a module without > > =A0 =A0 =A0 =A0 =A0revisions MUST NOT change (ever) > > I don't think this is necessary, but I'm ok with adding it. Could you elaborate on why this is unecessary? Personally, I think, it would mess up if no indication for (sub)module change. washam From mbj@tail-f.com Tue Dec 8 12:08: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 1AF573A68D0 for ; Tue, 8 Dec 2009 12:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.138, 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 F39rzOieGA0e for ; Tue, 8 Dec 2009 12:08:42 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4F9F63A690A for ; Tue, 8 Dec 2009 12:08:42 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AD302616002; Tue, 8 Dec 2009 21:08:30 +0100 (CET) Date: Tue, 08 Dec 2009 21:08:30 +0100 (CET) Message-Id: <20091208.210830.126712632.mbj@tail-f.com> To: washam.fan@gmail.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] yang-09, sec.10, revision rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2009 20:08:43 -0000 Washam Fan wrote: > Hi Martin, > = > > Andy Bierman wrote: > > > Hi, > > > > > > [this WGLC comment got lost in the wrong thread] > > > > > > > > > It does not make any sense to talk about different versions > > > of a YANG [sub]module without a new revision date. =A0There is no= way > > > to even distinguish which is the old version and which is > > > the new version in a standard way. > > > > > > Sec 10: > > > > > > =A0 For any published change, a new "revision" statement (Section= 7.1.9) > > > =A0 SHOULD be included in front of the existing revision statemen= ts. > > > > > > Edit 1: =A0s/SHOULD/MUST > > > > I agree. > > > > > Edit 2: =A0state (somewhere in sec. 10) that a module without > > > =A0 =A0 =A0 =A0 =A0revisions MUST NOT change (ever) > > > > I don't think this is necessary, but I'm ok with adding it. > = > Could you elaborate on why this is unecessary? Personally, I think, > it would mess up if no indication for (sub)module change. It is not sufficient for guaranteed module import / submodule inclusion; for this you need import/inlcude by revision, and we have already agreed that we will not make that mandatory to use. And I expect all standard modules to have a revision history; this is already a MUST in the guidelines doc. Even if this is a MUST, it will be hard to detect if a vendor chooses to not use revisions and modifies a module. /martin From andy@netconfcentral.com Tue Dec 8 12:56: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 A77193A6A68 for ; Tue, 8 Dec 2009 12:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 VrOPk1uGBy6h for ; Tue, 8 Dec 2009 12:56:27 -0800 (PST) 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 DCBC73A692C for ; Tue, 8 Dec 2009 12:56:26 -0800 (PST) Received: (qmail 27536 invoked from network); 8 Dec 2009 20:56:14 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 08 Dec 2009 12:56:13 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .dFhi4gVM1nmt.llU1CGh1794._I_vF6gjotGC0zx4MOZ1sNrSdKo9hfPd.IYYAa6i5qUqxi8gqx43EJbJMM1fSp_pjVPxXOurmB2KQduWoURBSW0KF93VzEQNd5TRWPHUIu4hhQXnK3O3ggfipvKhxqMQH3Vcvs7iJ9C7W4jrBqrKl51iH9WaBpY16g5PMxFGxVwRSGHecwspzV0eBgoxy3Fn_S26Bp.bXT4jW8sR6l3cZ0Xfal0L.uBKmIUPFOGhvp.NJ.1Lxw6Npw.jt3tQxaE_8ipBzHkGw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1EBCDC.3030002@netconfcentral.com> Date: Tue, 08 Dec 2009 12:53:48 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091208.210830.126712632.mbj@tail-f.com> In-Reply-To: <20091208.210830.126712632.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09, sec.10, revision rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2009 20:56:27 -0000 Martin Bjorklund wrote: > Washam Fan wrote: >> Hi Martin, >> >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> [this WGLC comment got lost in the wrong thread] >>>> >>>> >>>> It does not make any sense to talk about different versions >>>> of a YANG [sub]module without a new revision date. There is no way >>>> to even distinguish which is the old version and which is >>>> the new version in a standard way. >>>> >>>> Sec 10: >>>> >>>> For any published change, a new "revision" statement (Section 7.1.9) >>>> SHOULD be included in front of the existing revision statements. >>>> >>>> Edit 1: s/SHOULD/MUST >>> I agree. >>> >>>> Edit 2: state (somewhere in sec. 10) that a module without >>>> revisions MUST NOT change (ever) >>> I don't think this is necessary, but I'm ok with adding it. >> Could you elaborate on why this is unecessary? Personally, I think, >> it would mess up if no indication for (sub)module change. > > It is not sufficient for guaranteed module import / submodule > inclusion; for this you need import/inlcude by revision, and we have > already agreed that we will not make that mandatory to use. > > And I expect all standard modules to have a revision history; this is > already a MUST in the guidelines doc. > > Even if this is a MUST, it will be hard to detect if a vendor > chooses to not use revisions and modifies a module. > This is incorrect. It is quite possible to diff 2 YANG modules that claim to be the same, and tell if that is true or not. The issue is conformance to a standard that actually works. There is no way to tell 2 module versions apart except for the standard revision mechanism. I am strongly opposed to any unspecified mechanisms being considered to be within the standard. If a vendor wants to ignore revisions and the rules in sec. 10, then they have to be non-compliant to do that. > > /martin Andy From washam.fan@gmail.com Wed Dec 9 04:40: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 141323A687B for ; Wed, 9 Dec 2009 04:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 pOln0637G+qo for ; Wed, 9 Dec 2009 04:40:45 -0800 (PST) Received: from mail-px0-f177.google.com (mail-px0-f177.google.com [209.85.216.177]) by core3.amsl.com (Postfix) with ESMTP id 4E8563A67E2 for ; Wed, 9 Dec 2009 04:40:45 -0800 (PST) Received: by pxi7 with SMTP id 7so786404pxi.31 for ; Wed, 09 Dec 2009 04:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=RU248lspMmkjzyrsdfXMUWMsytADk4VZxXyh+vQh3Oo=; b=w5+uDRESjZmBXcP63E79IGLn/6hpB3RtdLhCsGeztD5rbcEmEVpekXpD9zyz+548sW rbrCniZa8jOr5LqD9mgPrXC8QF2g2d5+QR0i3v4Wo055AetvdUBWYiLsZ/efGPHj+d3h aFPSWIreTPTnPCHESCkdmjEABCJGrhzox1Kws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=l/RFnenT6FpcquiqPOQvwG5b4NO2rEJsywSJRe1dRxuknEghqIVFXTdcEBVaZQCwCj Cqe+NqYCV8rb9BDRAGu7IUCFXVSpXBvOW5wckX88k2ywM7l2kIpdos23aVwSo6cqSxHC PSjtiad+dFk0enehEy4ZraEebXVhz9VQ4EyFk= MIME-Version: 1.0 Received: by 10.142.61.33 with SMTP id j33mr1203663wfa.236.1260362431538; Wed, 09 Dec 2009 04:40:31 -0800 (PST) In-Reply-To: <4B1EBCDC.3030002@netconfcentral.com> References: <20091208.210830.126712632.mbj@tail-f.com> <4B1EBCDC.3030002@netconfcentral.com> Date: Wed, 9 Dec 2009 20:40:31 +0800 Message-ID: From: Washam Fan To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] yang-09, sec.10, revision rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2009 12:40:46 -0000 Hi, >>>>> Edit 2: =A0state (somewhere in sec. 10) that a module without >>>>> =A0 =A0 =A0 =A0 =A0revisions MUST NOT change (ever) >>>> I don't think this is necessary, but I'm ok with adding it. >>> Could you elaborate on why this is unecessary? Personally, I think, >>> it would mess up if no indication for (sub)module change. >> >> It is not sufficient for guaranteed module import / submodule >> inclusion; for this you need import/inlcude by revision, and we have >> already agreed that we will not make that mandatory to use. >> >> And I expect all standard modules to have a revision history; this is >> already a MUST in the guidelines doc. >> >> Even if this is a MUST, it will be hard to detect if a vendor >> chooses to not use revisions and modifies a module. >> > > This is incorrect. > It is quite possible to diff 2 YANG modules that > claim to be the same, and tell if that is true or not. Is it realistic the client retrieves every module without revision from the server to check if it is the same as the local counterpart? > The issue is conformance to a standard that actually works. > There is no way to tell 2 module versions apart except > for the standard revision mechanism. =A0I am strongly opposed > to any unspecified mechanisms being considered to > be within the standard. Either revision statement or other ways should be used to tell the module change, IMO. washam > If a vendor wants to ignore revisions and the rules in sec. 10, > then they have to be non-compliant to do that. > > >> >> /martin > > > Andy > From washam.fan@gmail.com Wed Dec 9 05:23: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 2D8E928C191 for ; Wed, 9 Dec 2009 05:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 emaz5ifLLSKR for ; Wed, 9 Dec 2009 05:23:56 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 2339F28C17C for ; Wed, 9 Dec 2009 05:23:56 -0800 (PST) Received: by pwi20 with SMTP id 20so2724128pwi.29 for ; Wed, 09 Dec 2009 05:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XF3zJYjnA3cV7RV5G84PoA8zhS0ANU7TfkA0th6/UPM=; b=PTog+LhT0E+L5+prXovX2fvGcwnQKfF2XX3cNQ0XN/G6+NaeeeniCkkjk8RZGj248G pfy+Td8tTXmd7OfanFHoAAwVnVErhgl88FLfaHQJPk24VlXFibQmmccNWxDnAaHgPQwF s50zMvfZSCPVs0mHb8nFWD8c7hrGGbJz8LU9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=VLl/Vd+nElN7LKFDXXR7165/FArhSgVAYS2i81gDsR81Ioh4NTtO5v3sTk7yUTcN20 yUmMpMzXSVrX5NXl+cCu4yreLPYu0EqohOHlK95W3wnrvP6Dt7JyK7fhWATXtRA3pBK/ iswxGzGQA9+aKeYYGqoN6uYrl53GHUfHHBXSA= MIME-Version: 1.0 Received: by 10.142.75.21 with SMTP id x21mr1167914wfa.150.1260365022541; Wed, 09 Dec 2009 05:23:42 -0800 (PST) In-Reply-To: <20091208.214441.139196284.mbj@tail-f.com> References: <4B1E80AC.1090306@netconfcentral.com> <20091208.214441.139196284.mbj@tail-f.com> Date: Wed, 9 Dec 2009 21:23:42 +0800 Message-ID: From: Washam Fan To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] [Netconf] 4741bis, issue 18: lock and commit X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2009 13:23:57 -0000 Hi, 2009/12/9 Martin Bjorklund : > Andy Bierman wrote: >> Hi, >> >> There is an open issue regarding how the >> operation behaves if the candidate is locked by >> another session. >> >> There seems to be consensus that a lock on the >> running config by another session will cause >> the operation to fail. >> >> Since the contents of running will be the same as >> candidate (it it succeeds), it is not clear if >> this operation can ignore a lock on candidate or not. >> >> The WG needs to decide what to do here: >> >> =A0A) Add text to sec. 8.3.4.1 saying the commit MUST >> =A0 =A0 fail if the candidate is locked by a different session > > I prefer A. =A0This is what at least 3 implementations do (see the > thread starting at > http://www.ietf.org/mail-archive/web/netconf/current/msg04841.html) I agreed A makes more sense, but C is strictly compliant with the semantics. is to sync running with candidate, so should not violate the lock on candidate but the lock on running. Maybe, we can choose C, but recommended that grab locks on both runnning and candidate. washam > > > >> >> =A0B) Add text to sec. 8.3.4.1 saying it is implementation-specific >> =A0 =A0 whether the commit will be affected by a lock on candidate >> >> =A0C) Add text to sec. 8.3.4.1 saying the commit MUST NOT >> =A0 =A0 fail because the candidate is locked by a different session >> >> =A0D) Don't add any text; declare this to be a non-issue >> >> =A0E) ??? >> >> >> [ed. opinion: this seems like an artificial corner-case >> due to poor lock usage, so if this is implementation-specific, >> it will not really harm interoperability. favor choice (B)] >> >> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@netconfcentral.com Wed Dec 9 07:36: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 3DC7D28C138 for ; Wed, 9 Dec 2009 07:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 1uIDMb5EJhaR for ; Wed, 9 Dec 2009 07:36:21 -0800 (PST) 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 81E3628C137 for ; Wed, 9 Dec 2009 07:36:21 -0800 (PST) Received: (qmail 52313 invoked from network); 9 Dec 2009 15:36:08 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 09 Dec 2009 07:36:08 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: b8Xp5AcVM1l3IPhxZa_NwX3e4L3pjoh9a81.mJN9M5IIfZnqrnDc4ffhjvvCXQMqdnz671_cHxBbVEljDhEv.8FPgr__njdQbWad3.Lc9KaWK6xZolACWWSoT447QZ4yrv9MQNF_gk_smJt8wXPKKn1cLk_MQOnxegl29YscgHWWO_JiUVIWvEUKSFchZjz.DGsmsU2H6S9PzSBtgrpXQbuserizezhU0URFLQ98PMBk7WDIw9ZKfkc.MOPw2OMX X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1FC3CB.5090008@netconfcentral.com> Date: Wed, 09 Dec 2009 07:35:39 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Washam Fan References: <20091208.210830.126712632.mbj@tail-f.com> <4B1EBCDC.3030002@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09, sec.10, revision rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2009 15:36:22 -0000 Washam Fan wrote: > Hi, > >>>>>> Edit 2: state (somewhere in sec. 10) that a module without >>>>>> revisions MUST NOT change (ever) >>>>> I don't think this is necessary, but I'm ok with adding it. >>>> Could you elaborate on why this is unecessary? Personally, I think, >>>> it would mess up if no indication for (sub)module change. >>> It is not sufficient for guaranteed module import / submodule >>> inclusion; for this you need import/inlcude by revision, and we have >>> already agreed that we will not make that mandatory to use. >>> >>> And I expect all standard modules to have a revision history; this is >>> already a MUST in the guidelines doc. >>> >>> Even if this is a MUST, it will be hard to detect if a vendor >>> chooses to not use revisions and modifies a module. >>> >> This is incorrect. >> It is quite possible to diff 2 YANG modules that >> claim to be the same, and tell if that is true or not. > > Is it realistic the client retrieves every module without revision > from the server to check if it is the same as the local counterpart? > No -- that is exactly why modules without any revision date MUST NOT change. Even if the optional is supported, the client has no way to detect a mismatch in the [name, revision, namespace] tuple that uniquely identifies an advertised module. >> The issue is conformance to a standard that actually works. >> There is no way to tell 2 module versions apart except >> for the standard revision mechanism. I am strongly opposed >> to any unspecified mechanisms being considered to >> be within the standard. > > Either revision statement or other ways should be used to > tell the module change, IMO. > other ways? that isn't standard. There is only 1 standard way needed, and it is already defined. > washam > >> If a vendor wants to ignore revisions and the rules in sec. 10, >> then they have to be non-compliant to do that. >> >> >>> /martin >> >> Andy Andy From andy@netconfcentral.com Wed Dec 9 11:00: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 528A83A6A3B for ; Wed, 9 Dec 2009 11:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 AM7e7XtxlJvl for ; Wed, 9 Dec 2009 10:59:50 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 9EDAB3A69DD for ; Wed, 9 Dec 2009 10:59:50 -0800 (PST) Received: (qmail 81714 invoked from network); 9 Dec 2009 18:59:37 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 09 Dec 2009 10:59:37 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 4TV9OXAVM1kjXSqsSwLV9Tiz6LWjQWOfv9ESx9bymPDYWaEEI3MwoqmRozFZ8GJ_e9T9h5Y0xyFbDiOPg8BhUyNyjfo4AyplmnE5smOPeVkjyObx.YwAgmdkjhPxLNJnp_GqscQyRcTmeaET5AbkvSy07VA4j_7d1a9CUNvZzP6cNgsTvrUgeaxy9cCfDwwkXh5B4F6dmrS6lkHJbnNtMBG2TyWazPOD5COFqoDfLfdTuQZdR5L7SETyNR0yNLfv X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1FF37B.6030609@netconfcentral.com> Date: Wed, 09 Dec 2009 10:59:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-09; 7.19.5 when-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: Wed, 09 Dec 2009 19:00:01 -0000 Hi, Sec. 7.19.4 para 3 does not specify the context of the when-stmt for a uses-stmt. I am very concerned about the inherent complexity due to server implementation of the when-stmt constraints. The reason must-stmt is not a problem is that it cannot be inherited from uses or augment statements. This extreme example show that understanding the final object definition, and understanding which when-stmt will be evaluated in which XPath context can be very difficult. Implementing the XPath in a bullet-proof manner is somewhat challenging as well. grouping A { leaf a1 { when "/top-leaf > 4"; type string; } } grouping B { uses A { when "../b1"; } leaf b1 { type string; } container b2; } leaf top-leaf { type int32; } container foo { uses B { when "b2/bar = 'fred'"; augment b2 { when "/top-leaf < 3"; leaf bar { when "../a1 == 'barney'"; type leafref { path "../../top-leaf"; } } } } } IMO, the when-stmt should be removed from 'uses' and only allowed for 'augment'. This would improve interoperability and preserve the real use-case from SNMP (SPARSE-AUGMENTS). The complexity of the ripple effect is not worth the corner-case benefits it may provide. Andy From mbj@tail-f.com Wed Dec 9 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 00DF83A66B4 for ; Wed, 9 Dec 2009 13:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwVxyQ5gEMvL for ; Wed, 9 Dec 2009 13:00:17 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 28D6828C1D7 for ; Wed, 9 Dec 2009 13:00:16 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C246576C68B; Wed, 9 Dec 2009 22:00:04 +0100 (CET) Date: Wed, 09 Dec 2009 22:00:04 +0100 (CET) Message-Id: <20091209.220004.191203506.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B1FF37B.6030609@netconfcentral.com> References: <4B1FF37B.6030609@netconfcentral.com> X-Mailer: Mew version 6.2.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-09; 7.19.5 when-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: Wed, 09 Dec 2009 21:00:18 -0000 Andy Bierman wrote: > IMO, the when-stmt should be removed from 'uses' and only allowed > for 'augment'. Just a quick clarifying question. Do you want to remove 'when' from 'uses' or do you want 'when' to be allowed only in 'augment'? Note that you can have 'when' under any container/leaf/... /martin From andy@netconfcentral.com Wed Dec 9 13: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 010FA3A6937 for ; Wed, 9 Dec 2009 13:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 Ct4N8n+qOli4 for ; Wed, 9 Dec 2009 13:36:44 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 3D29C3A692E for ; Wed, 9 Dec 2009 13:36:44 -0800 (PST) Received: (qmail 28181 invoked from network); 9 Dec 2009 21:36:30 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 09 Dec 2009 13:36:30 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 37huQ5sVM1lSp_iupHS4SzHHdNnhLtBnJ5eG2irc1v_JYVzLmsmhrHBTunU0RImSTSyGfVJBlmUJFOGwNBosg9DMSiEZAoAp5gbqIOpklsAaa25LCY5Xer2SQka9vQxVjphyHzicutIWdHIUx5R23yNjUsPbH26c1PCsgDHLBLlMzuOaWSXYjT_r7bLc58IJTQ4h6hp5QOeUNMJdJX7Uj39xAF7twwlrSFI9o1zeohECzRYOx2PqEX0dLrhzekuuWg2OsY1qQTRXHt6ogRvcN787XY1xnxeIoFQQwYbPSk46.CQWr2ABqbEshnW47g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2017C4.2010608@netconfcentral.com> Date: Wed, 09 Dec 2009 13:33:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1FF37B.6030609@netconfcentral.com> <20091209.220004.191203506.mbj@tail-f.com> In-Reply-To: <20091209.220004.191203506.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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: Wed, 09 Dec 2009 21:36:45 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO, the when-stmt should be removed from 'uses' and only allowed >> for 'augment'. > > Just a quick clarifying question. Do you want to remove 'when' from > 'uses' or do you want 'when' to be allowed only in 'augment'? Note > that you can have 'when' under any container/leaf/... > Just remove it as a sub-statement of uses-stmt. This removes the complexity from N levels of inherited uses-when conditions, with up to N different context nodes. With this change, we will have all the flexibility that is really needed, and a constrained XPath model. Given that when-stmt is evaluated top-down because if the parent doesn't exist, then no need to check further, there are at most 2 when-stmts, both with the same context node as the target node. > > /martin > Andy From phil@juniper.net Wed Dec 9 15:00: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 2522B3A682F for ; Wed, 9 Dec 2009 15:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 nT5rh+I53EQU for ; Wed, 9 Dec 2009 15:00:22 -0800 (PST) Received: from chip3og57.obsmtp.com (chip3og57.obsmtp.com [64.18.14.179]) by core3.amsl.com (Postfix) with ESMTP id 20A9C3A68D0 for ; Wed, 9 Dec 2009 15:00:20 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob57.postini.com ([64.18.6.12]) with SMTP ID DSNKSyAr9xyWzs0/9dmcz0OAmscUCUNAON4P@postini.com; Wed, 09 Dec 2009 15:00:11 PST 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.393.1; Wed, 9 Dec 2009 14:55:41 -0800 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, 9 Dec 2009 14:55:41 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 14:55:41 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 14:55:41 -0800 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 nB9Mtcj52478; Wed, 9 Dec 2009 14:55:40 -0800 (PST) (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 nB9MfqVf000265; Wed, 9 Dec 2009 22:41:53 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912092241.nB9MfqVf000265@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B2017C4.2010608@netconfcentral.com> Date: Wed, 9 Dec 2009 17:41:52 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Dec 2009 22:55:41.0095 (UTC) FILETIME=[BB415370:01CA7922] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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: Wed, 09 Dec 2009 23:00:23 -0000 Andy Bierman writes: >Just remove it as a sub-statement of uses-stmt. >This removes the complexity from N levels of inherited uses-when >conditions, with up to N different context nodes. I see the uses/when as a key ingredient for the reusability of groupings. Please don't remove it. I don't see it as adding any sgnificant complexity, since "when" is already there and the implementations must already deal with it. Thanks, Phil From andy@netconfcentral.com Wed Dec 9 15: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 921993A6782 for ; Wed, 9 Dec 2009 15:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 Vk2hi+aEEPfU for ; Wed, 9 Dec 2009 15:33:23 -0800 (PST) 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 DFA9A3A6856 for ; Wed, 9 Dec 2009 15:33:23 -0800 (PST) Received: (qmail 46696 invoked from network); 9 Dec 2009 23:33:07 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 09 Dec 2009 15:33:07 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 5CDhHrUVM1mqAgbT.blEv0IKut9JDGih4mbgG8wv5JAm0LP0dyX3VmFN1rQzuaOM5HReMJewFCNm7VxAg6fQ4jUZTeDoXbG2d5NNHoQw3gxP10nEOifr7nUzVP.Y0lb7dH_Axolmw6d_HujESVYwC.s4bB7CiajSJNzr1jnmXG_fRm3.5OO9rpLfzyWfyTMkvnOZENJMV8eQxaPf3t5y_8rktDu.ulwo7kwoDObg0MHjPgtow8JAOfMtwPq3cCIk X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B203393.4020306@netconfcentral.com> Date: Wed, 09 Dec 2009 15:32:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912092241.nB9MfqVf000265@idle.juniper.net> In-Reply-To: <200912092241.nB9MfqVf000265@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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: Wed, 09 Dec 2009 23:33:24 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Just remove it as a sub-statement of uses-stmt. >> This removes the complexity from N levels of inherited uses-when >> conditions, with up to N different context nodes. > > I see the uses/when as a key ingredient for the reusability > of groupings. Please don't remove it. I don't see it as > adding any sgnificant complexity, since "when" is already > there and the implementations must already deal with it. > Sec. 7.19.4 para 3 does not specify the context of the when-stmt for a uses-stmt. Since this is so easy, why don't you write the text that is required to specify the context node for uses-stmt? This must be done in order to leave uses-when in the draft. > Thanks, > Phil > Andy From lhotka@cesnet.cz Wed Dec 9 23:41:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F1B3A68B4 for ; Wed, 9 Dec 2009 23:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=0.272, 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 IcHREC4VlYpb for ; Wed, 9 Dec 2009 23:41:57 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 767833A689F for ; Wed, 9 Dec 2009 23:41:57 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 18879D80096; Thu, 10 Dec 2009 08:41:45 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B1FF37B.6030609@netconfcentral.com> References: <4B1FF37B.6030609@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 10 Dec 2009 08:41:43 +0100 Message-ID: <1260430903.21259.46.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 07:41:58 -0000 Andy Bierman píše v St 09. 12. 2009 v 10:59 -0800: > Hi, > > Sec. 7.19.4 para 3 does not specify the context of the when-stmt > for a uses-stmt. > > I am very concerned about the inherent complexity due to > server implementation of the when-stmt constraints. > The reason must-stmt is not a problem is that it cannot > be inherited from uses or augment statements. > > This extreme example show that understanding the > final object definition, and understanding which > when-stmt will be evaluated in which XPath context > can be very difficult. Implementing the XPath in > a bullet-proof manner is somewhat challenging as well. I second this. If an implementation is about to parse an XML document, it should already know the schema for the document. With 'when', in order to know whether a given element must, may or mustn't appear in the document, the document must be parsed first. I believe this is a substrate for race conditions and should be avoided. That's why I proposed that grammatical constraints be declared as independent of any XPath evaluations in 'when' and 'must'. That is, the datastore schema must be derivable a priori from YANG modules and active features and must not depend on the datastore contents. In my view, the grammar (schema) is formed by all data node definition statements ('leaf', 'container' etc.) and also by 'mandatory', 'min/maxElements' and 'presence'. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Dec 10 00:30: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 A00D33A692D for ; Thu, 10 Dec 2009 00:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.103, 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 yxoOLnbB1fZo for ; Thu, 10 Dec 2009 00:30:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DEA043A68FE for ; Thu, 10 Dec 2009 00:30:41 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67DB9C0012; Thu, 10 Dec 2009 09:30:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o1YVw87UgQL3; Thu, 10 Dec 2009 09:30:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22202C000B; Thu, 10 Dec 2009 09:30:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 886FEF51E02; Thu, 10 Dec 2009 09:30:27 +0100 (CET) Date: Thu, 10 Dec 2009 09:30:27 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091210083027.GD61275@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <4B1FF37B.6030609@netconfcentral.com> <1260430903.21259.46.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1260430903.21259.46.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] yang-09; 7.19.5 when-stmt 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, 10 Dec 2009 08:30:43 -0000 On Thu, Dec 10, 2009 at 08:41:43AM +0100, Ladislav Lhotka wrote: > Andy Bierman p????e v St 09. 12. 2009 v 10:59 -0800: > > Hi, > > > > Sec. 7.19.4 para 3 does not specify the context of the when-stmt > > for a uses-stmt. > > > > I am very concerned about the inherent complexity due to > > server implementation of the when-stmt constraints. > > The reason must-stmt is not a problem is that it cannot > > be inherited from uses or augment statements. > > > > This extreme example show that understanding the > > final object definition, and understanding which > > when-stmt will be evaluated in which XPath context > > can be very difficult. Implementing the XPath in > > a bullet-proof manner is somewhat challenging as well. > > I second this. If an implementation is about to parse an XML document, > it should already know the schema for the document. With 'when', in > order to know whether a given element must, may or mustn't appear in the > document, the document must be parsed first. I believe this is a > substrate for race conditions and should be avoided. > > That's why I proposed that grammatical constraints be declared as > independent of any XPath evaluations in 'when' and 'must'. That is, the > datastore schema must be derivable a priori from YANG modules and active > features and must not depend on the datastore contents. > > In my view, the grammar (schema) is formed by all data node definition > statements ('leaf', 'container' etc.) and also by 'mandatory', > 'min/maxElements' and 'presence'. You are trying to convert semantic constraints expressed in XPATH statements into document grammar rules, which I think is the wrong approach. /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 Thu Dec 10 00:38: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 0C2993A69DB for ; Thu, 10 Dec 2009 00:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.107, 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 r88H4KB5oOM4 for ; Thu, 10 Dec 2009 00:38:27 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 309933A6A58 for ; Thu, 10 Dec 2009 00:38:27 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B8A2976C044; Thu, 10 Dec 2009 09:38:14 +0100 (CET) Date: Thu, 10 Dec 2009 09:38:14 +0100 (CET) Message-Id: <20091210.093814.25166080.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B203393.4020306@netconfcentral.com> References: <200912092241.nB9MfqVf000265@idle.juniper.net> <4B203393.4020306@netconfcentral.com> X-Mailer: Mew version 6.2.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-09; 7.19.5 when-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, 10 Dec 2009 08:38:28 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> Just remove it as a sub-statement of uses-stmt. > >> This removes the complexity from N levels of inherited uses-when > >> conditions, with up to N different context nodes. > > > > I see the uses/when as a key ingredient for the reusability > > of groupings. Please don't remove it. I don't see it as > > adding any sgnificant complexity, since "when" is already > > there and the implementations must already deal with it. > > > > Sec. 7.19.4 para 3 does not specify the context of the when-stmt > for a uses-stmt. > > Since this is so easy, why don't you write the text that > is required to specify the context node for uses-stmt? > This must be done in order to leave uses-when in the draft. when in uses has the same context node as when in choice, i.e. its parent. So we should extend the text in 7.19.5, bullet 2: OLD: o If the "when" statement is a child of a "choice" or "case" statement, then the context node is the closest ancestor node to the "choice" or "case" node which is also a data node. NEW: o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the "uses", "choice", or "case" node which is also a data node. /martin From lhotka@cesnet.cz Thu Dec 10 00:58: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 A6EFF3A6A89 for ; Thu, 10 Dec 2009 00:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=0.262, 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 QF9KszeWLduN for ; Thu, 10 Dec 2009 00:58:00 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C56D93A67FA for ; Thu, 10 Dec 2009 00:57:59 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6691AD800C8; Thu, 10 Dec 2009 09:57:48 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091210083027.GD61275@elstar.local> References: <4B1FF37B.6030609@netconfcentral.com> <1260430903.21259.46.camel@missotis> <20091210083027.GD61275@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 10 Dec 2009 09:57:46 +0100 Message-ID: <1260435466.21259.76.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 08:58:00 -0000 Juergen Schoenwaelder píše v Čt 10. 12. 2009 v 09:30 +0100: > On Thu, Dec 10, 2009 at 08:41:43AM +0100, Ladislav Lhotka wrote: > > Andy Bierman p????e v St 09. 12. 2009 v 10:59 -0800: > > > Hi, > > > > > > Sec. 7.19.4 para 3 does not specify the context of the when-stmt > > > for a uses-stmt. > > > > > > I am very concerned about the inherent complexity due to > > > server implementation of the when-stmt constraints. > > > The reason must-stmt is not a problem is that it cannot > > > be inherited from uses or augment statements. > > > > > > This extreme example show that understanding the > > > final object definition, and understanding which > > > when-stmt will be evaluated in which XPath context > > > can be very difficult. Implementing the XPath in > > > a bullet-proof manner is somewhat challenging as well. > > > > I second this. If an implementation is about to parse an XML document, > > it should already know the schema for the document. With 'when', in > > order to know whether a given element must, may or mustn't appear in the > > document, the document must be parsed first. I believe this is a > > substrate for race conditions and should be avoided. > > > > That's why I proposed that grammatical constraints be declared as > > independent of any XPath evaluations in 'when' and 'must'. That is, the > > datastore schema must be derivable a priori from YANG modules and active > > features and must not depend on the datastore contents. > > > > In my view, the grammar (schema) is formed by all data node definition > > statements ('leaf', 'container' etc.) and also by 'mandatory', > > 'min/maxElements' and 'presence'. > > You are trying to convert semantic constraints expressed in XPATH > statements into document grammar rules, which I think is the wrong > approach. Which of the data node definition statements, 'mandatory', 'min/maxElements' and 'presence' uses XPATH constraints? Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Dec 10 01:01: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 BB8783A6A79 for ; Thu, 10 Dec 2009 01:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hke84Uo1en5R for ; Thu, 10 Dec 2009 01:01:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A8D673A67FA for ; Thu, 10 Dec 2009 01:01:02 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5852CC0013; Thu, 10 Dec 2009 10:00:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id klWaEBQPBv7M; Thu, 10 Dec 2009 10:00:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 834FFC0003; Thu, 10 Dec 2009 10:00:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EEC44F521BF; Thu, 10 Dec 2009 10:00:48 +0100 (CET) Date: Thu, 10 Dec 2009 10:00:48 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091210090048.GA61538@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <4B1FF37B.6030609@netconfcentral.com> <1260430903.21259.46.camel@missotis> <20091210083027.GD61275@elstar.local> <1260435466.21259.76.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1260435466.21259.76.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] yang-09; 7.19.5 when-stmt 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, 10 Dec 2009 09:01:04 -0000 On Thu, Dec 10, 2009 at 09:57:46AM +0100, Ladislav Lhotka wrote: > Which of the data node definition statements, 'mandatory', > 'min/maxElements' and 'presence' uses XPATH constraints? What is the problem with these? The subject is about the 'when-stmt', no? /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 Thu Dec 10 01:17: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 DE1A93A69D6 for ; Thu, 10 Dec 2009 01:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=-0.491, 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 No0Ejwv2gdeO for ; Thu, 10 Dec 2009 01:17:58 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E2B803A6A8E for ; Thu, 10 Dec 2009 01:17:57 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 85A03D800C1; Thu, 10 Dec 2009 10:17:46 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091210090048.GA61538@elstar.local> References: <4B1FF37B.6030609@netconfcentral.com> <1260430903.21259.46.camel@missotis> <20091210083027.GD61275@elstar.local> <1260435466.21259.76.camel@missotis> <20091210090048.GA61538@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 10 Dec 2009 10:17:45 +0100 Message-ID: <1260436665.21259.89.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 09:17:59 -0000 Juergen Schoenwaelder píše v Čt 10. 12. 2009 v 10:00 +0100: > On Thu, Dec 10, 2009 at 09:57:46AM +0100, Ladislav Lhotka wrote: > > > Which of the data node definition statements, 'mandatory', > > 'min/maxElements' and 'presence' uses XPATH constraints? > > What is the problem with these? The subject is about the 'when-stmt', > no? Yes, but I want exactly the opposite of what you wrote, namely that 'when' statement must not cancel or relativize any of the above grammatical statements. For example: container x { leaf y { type uint8; } leaf z { mandatory true; when "../y > 0"; type empty; } } I claim that "0" is not a valid document, because the "mandatory true" constraint is not satisfied (parent exists but doesn't). Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Dec 10 01:22: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 666773A67FA for ; Thu, 10 Dec 2009 01:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.113, 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 8Z25O1fs1v5f for ; Thu, 10 Dec 2009 01:22:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 259FB3A677C for ; Thu, 10 Dec 2009 01:22:46 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C91DAC0012; Thu, 10 Dec 2009 10:22:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NjDJuxadyL51; Thu, 10 Dec 2009 10:22:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF595C0014; Thu, 10 Dec 2009 10:22:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 50807F52282; Thu, 10 Dec 2009 10:22:32 +0100 (CET) Date: Thu, 10 Dec 2009 10:22:32 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091210092232.GA61657@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <4B1FF37B.6030609@netconfcentral.com> <1260430903.21259.46.camel@missotis> <20091210083027.GD61275@elstar.local> <1260435466.21259.76.camel@missotis> <20091210090048.GA61538@elstar.local> <1260436665.21259.89.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1260436665.21259.89.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] yang-09; 7.19.5 when-stmt 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, 10 Dec 2009 09:22:47 -0000 On Thu, Dec 10, 2009 at 10:17:45AM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v ??t 10. 12. 2009 v 10:00 +0100: > > On Thu, Dec 10, 2009 at 09:57:46AM +0100, Ladislav Lhotka wrote: > > > > > Which of the data node definition statements, 'mandatory', > > > 'min/maxElements' and 'presence' uses XPATH constraints? > > > > What is the problem with these? The subject is about the 'when-stmt', > > no? > > Yes, but I want exactly the opposite of what you wrote, namely that > 'when' statement must not cancel or relativize any of the above > grammatical statements. For example: > > container x { > leaf y { > type uint8; > } > leaf z { > mandatory true; > when "../y > 0"; > type empty; > } > } > > I claim that "0" is not a valid document, because the > "mandatory true" constraint is not satisfied (parent exists but > doesn't). Yes - and where is the problem? /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 Thu Dec 10 01:32: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 055A03A6A92 for ; Thu, 10 Dec 2009 01:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=-0.475, 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 02HOPeld+qE0 for ; Thu, 10 Dec 2009 01:32:03 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 207B13A6A93 for ; Thu, 10 Dec 2009 01:32:03 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9B891D800C0 for ; Thu, 10 Dec 2009 10:31:51 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20091210092232.GA61657@elstar.local> References: <4B1FF37B.6030609@netconfcentral.com> <1260430903.21259.46.camel@missotis> <20091210083027.GD61275@elstar.local> <1260435466.21259.76.camel@missotis> <20091210090048.GA61538@elstar.local> <1260436665.21259.89.camel@missotis> <20091210092232.GA61657@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 10 Dec 2009 10:31:50 +0100 Message-ID: <1260437510.21259.97.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 09:32:04 -0000 Juergen Schoenwaelder píše v Čt 10. 12. 2009 v 10:22 +0100: > On Thu, Dec 10, 2009 at 10:17:45AM +0100, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v ??t 10. 12. 2009 v 10:00 +0100: > > > On Thu, Dec 10, 2009 at 09:57:46AM +0100, Ladislav Lhotka wrote: > > > > > > > Which of the data node definition statements, 'mandatory', > > > > 'min/maxElements' and 'presence' uses XPATH constraints? > > > > > > What is the problem with these? The subject is about the 'when-stmt', > > > no? > > > > Yes, but I want exactly the opposite of what you wrote, namely that > > 'when' statement must not cancel or relativize any of the above > > grammatical statements. For example: > > > > container x { > > leaf y { > > type uint8; > > } > > leaf z { > > mandatory true; > > when "../y > 0"; > > type empty; > > } > > } > > > > I claim that "0" is not a valid document, because the > > "mandatory true" constraint is not satisfied (parent exists but > > doesn't). > > Yes - and where is the problem? The problem is that Martin does not agree with it. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Dec 10 01: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 1AF293A6912 for ; Thu, 10 Dec 2009 01:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=-0.641, 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 6h4z99gq2oHT for ; Thu, 10 Dec 2009 01:41:16 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D84BE3A6886 for ; Thu, 10 Dec 2009 01:41:15 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 968D776C044; Thu, 10 Dec 2009 10:41:03 +0100 (CET) Date: Thu, 10 Dec 2009 10:41:03 +0100 (CET) Message-Id: <20091210.104103.32610959.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1260437510.21259.97.camel@missotis> References: <1260436665.21259.89.camel@missotis> <20091210092232.GA61657@elstar.local> <1260437510.21259.97.camel@missotis> X-Mailer: Mew version 6.2.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] yang-09; 7.19.5 when-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, 10 Dec 2009 09:41:17 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyIHDDrcWhZSB2IMSMdCAxMC4gMTIuIDIwMDkgdiAxMDoyMiArMDEwMDoNCj4gPiBP biBUaHUsIERlYyAxMCwgMjAwOSBhdCAxMDoxNzo0NUFNICswMTAwLCBMYWRpc2xhdiBMaG90a2Eg d3JvdGU6DQo+ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgcD8/Pz9lIHYgPz90IDEwLiAxMi4g MjAwOSB2IDEwOjAwICswMTAwOg0KPiA+ID4gPiBPbiBUaHUsIERlYyAxMCwgMjAwOSBhdCAwOTo1 Nzo0NkFNICswMTAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4gPiA+ICANCj4gPiA+ID4g PiBXaGljaCBvZiB0aGUgZGF0YSBub2RlIGRlZmluaXRpb24gc3RhdGVtZW50cywgJ21hbmRhdG9y eScsDQo+ID4gPiA+ID4gJ21pbi9tYXhFbGVtZW50cycgYW5kICdwcmVzZW5jZScgdXNlcyBYUEFU SCBjb25zdHJhaW50cz8NCj4gPiA+ID4gDQo+ID4gPiA+IFdoYXQgaXMgdGhlIHByb2JsZW0gd2l0 aCB0aGVzZT8gVGhlIHN1YmplY3QgaXMgYWJvdXQgdGhlICd3aGVuLXN0bXQnLA0KPiA+ID4gPiBu bz8NCj4gPiA+IA0KPiA+ID4gWWVzLCBidXQgSSB3YW50IGV4YWN0bHkgdGhlIG9wcG9zaXRlIG9m IHdoYXQgeW91IHdyb3RlLCBuYW1lbHkgdGhhdA0KPiA+ID4gJ3doZW4nIHN0YXRlbWVudCBtdXN0 IG5vdCBjYW5jZWwgb3IgcmVsYXRpdml6ZSBhbnkgb2YgdGhlIGFib3ZlDQo+ID4gPiBncmFtbWF0 aWNhbCBzdGF0ZW1lbnRzLiBGb3IgZXhhbXBsZToNCj4gPiA+IA0KPiA+ID4gY29udGFpbmVyIHgg ew0KPiA+ID4gICAgIGxlYWYgeSB7DQo+ID4gPiAgICAgICAgIHR5cGUgdWludDg7DQo+ID4gPiAg ICAgfQ0KPiA+ID4gICAgIGxlYWYgeiB7DQo+ID4gPiAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0K PiA+ID4gICAgICAgICB3aGVuICIuLi95ID4gMCI7DQo+ID4gPiAgICAgICAgIHR5cGUgZW1wdHk7 DQo+ID4gPiAgICAgfQ0KPiA+ID4gfQ0KPiA+ID4gDQo+ID4gPiBJIGNsYWltIHRoYXQgIjx4Pjx5 PjA8L3k+PC94PiIgaXMgbm90IGEgdmFsaWQgZG9jdW1lbnQsIGJlY2F1c2UgdGhlDQo+ID4gPiAi bWFuZGF0b3J5IHRydWUiIGNvbnN0cmFpbnQgaXMgbm90IHNhdGlzZmllZCAocGFyZW50IDx4PiBl eGlzdHMgYnV0IDx6Pg0KPiA+ID4gZG9lc24ndCkuDQo+ID4gDQo+ID4gWWVzIC0gYW5kIHdoZXJl IGlzIHRoZSBwcm9ibGVtPw0KPiANCj4gVGhlIHByb2JsZW0gaXMgdGhhdCBNYXJ0aW4gZG9lcyBu b3QgYWdyZWUgd2l0aCBpdC4NCg0KVGhlIGN1cnJlbnQgdGV4dCBzYXlzLCBpbiA4LjIgSGllcmFy Y2h5IG9mIENvbnN0cmFpbnRzOg0KDQogICAibXVzdCIsICJtYW5kYXRvcnkiLCAibWluLWVsZW1l bnRzIiwgYW5kICJtYXgtZWxlbWVudHMiIGNvbnN0cmFpbnRzDQogICBhcmUgbm90IGVuZm9yY2Vk IGlmIHRoZSBwYXJlbnQgbm9kZSBoYXMgYSAid2hlbiIgb3IgImlmLWZlYXR1cmUiDQogICBwcm9w ZXJ0eSB0aGF0IGlzIG5vdCBzYXRpc2ZpZWQgb24gdGhlIGN1cnJlbnQgZGV2aWNlLg0KDQpTbywg aW4gdGhpcyBjYXNlLCBzaW5jZSB0aGUgd2hlbiBleHByZXNzaW9uIGlzIGZhbHNlLCBsZWFmIHog aXMgbm90DQptYW5kYXRvcnkuDQoNCk1hbmRhdG9yeSBhbmQgbWluL21heCBlbGVtZW50cyBhcmUg YWxzbyBzZW1hbnRpY2FsIGNvbnN0cmFpbnRzLCBub3QNCmdyYW1tYXRpY2FsLiAgVGhlc2UgY29u c3RyYWludHMgbmVlZCB0byBiZSBzYXRpc2ZpZWQgaW4gYSB2YWxpZA0KY29uZmlndXJhdGlvbiBv bmx5LiAgSXQgaXMgcGVyZmVjdGx5IGxlZ2FsIGZvciBhIG1hbmRhdG9yeSBsZWFmIHRvIGJlDQph YnNlbnQgZnJvbSB0aGUgY2FuZGlkYXRlLg0KDQoNCi9tYXJ0aW4NCg== From lhotka@cesnet.cz Thu Dec 10 01:52: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 AA8163A6AB2 for ; Thu, 10 Dec 2009 01:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=-0.460, 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 gy76n28F9F8F for ; Thu, 10 Dec 2009 01:52:34 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D08773A69B5 for ; Thu, 10 Dec 2009 01:52:33 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A3527D80096; Thu, 10 Dec 2009 10:52:22 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091210.104103.32610959.mbj@tail-f.com> References: <1260436665.21259.89.camel@missotis> <20091210092232.GA61657@elstar.local> <1260437510.21259.97.camel@missotis> <20091210.104103.32610959.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 10 Dec 2009 10:52:21 +0100 Message-ID: <1260438741.21259.105.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 09:52:34 -0000 Martin Bjorklund píše v Čt 10. 12. 2009 v 10:41 +0100: > > > > > > > > container x { > > > > leaf y { > > > > type uint8; > > > > } > > > > leaf z { > > > > mandatory true; > > > > when "../y > 0"; > > > > type empty; > > > > } > > > > } > > > > > > > > I claim that "0" is not a valid document, because the > > > > "mandatory true" constraint is not satisfied (parent exists but > > > > doesn't). > > > > > > Yes - and where is the problem? > > > > The problem is that Martin does not agree with it. > > The current text says, in 8.2 Hierarchy of Constraints: > > "must", "mandatory", "min-elements", and "max-elements" constraints > are not enforced if the parent node has a "when" or "if-feature" > property that is not satisfied on the current device. Yes, I object to this section, too, but it doesn't apply to the present example anyway: it is not the parent node that has the 'when' statement. On the other hand, sec. 7.6.4 says (third bullet): o Otherwise, the leaf MUST exist if the ancestor node exists in the data tree. I see no ifs or whens here. > > So, in this case, since the when expression is false, leaf z is not > mandatory. > > Mandatory and min/max elements are also semantical constraints, not > grammatical. These constraints need to be satisfied in a valid > configuration only. It is perfectly legal for a mandatory leaf to be > absent from the candidate. I don't agree with this interpretation. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Dec 10 01:54: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 5D39F3A6ABE for ; Thu, 10 Dec 2009 01:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.256 X-Spam-Level: X-Spam-Status: No, score=0.256 tagged_above=-999 required=5 tests=[AWL=-0.908, 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 tRhAxzDMsFrq for ; Thu, 10 Dec 2009 01:54:01 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8761B3A6ABC for ; Thu, 10 Dec 2009 01:54:01 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 64A83D80096 for ; Thu, 10 Dec 2009 10:53:50 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <1260438741.21259.105.camel@missotis> References: <1260436665.21259.89.camel@missotis> <20091210092232.GA61657@elstar.local> <1260437510.21259.97.camel@missotis> <20091210.104103.32610959.mbj@tail-f.com> <1260438741.21259.105.camel@missotis> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 10 Dec 2009 10:53:48 +0100 Message-ID: <1260438828.21259.106.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 09:54:02 -0000 Ladislav Lhotka píše v Čt 10. 12. 2009 v 10:52 +0100: > On the other hand, sec. 7.6.4 says (third bullet): 7.6.5, sorry. Lada > > o Otherwise, the leaf MUST exist if the ancestor node exists in the > data tree. > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Dec 10 01:55: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 A59873A6AB3 for ; Thu, 10 Dec 2009 01:55:53 -0800 (PST) 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.108, 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 N4qpjHlhWC0W for ; Thu, 10 Dec 2009 01:55:52 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8DC443A6A88 for ; Thu, 10 Dec 2009 01:55:52 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 392FFC0003; Thu, 10 Dec 2009 10:55:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZuJOUu8p5ETx; Thu, 10 Dec 2009 10:55:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01263C000B; Thu, 10 Dec 2009 10:55:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6B216F5249C; Thu, 10 Dec 2009 10:55:38 +0100 (CET) Date: Thu, 10 Dec 2009 10:55:38 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091210095538.GA61812@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netmod@ietf.org" References: <1260436665.21259.89.camel@missotis> <20091210092232.GA61657@elstar.local> <1260437510.21259.97.camel@missotis> <20091210.104103.32610959.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091210.104103.32610959.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-09; 7.19.5 when-stmt 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, 10 Dec 2009 09:55:53 -0000 On Thu, Dec 10, 2009 at 10:41:03AM +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v ??t 10. 12. 2009 v 10:22 +0100: > > > On Thu, Dec 10, 2009 at 10:17:45AM +0100, Ladislav Lhotka wrote: > > > > Juergen Schoenwaelder p????e v ??t 10. 12. 2009 v 10:00 +0100: > > > > > On Thu, Dec 10, 2009 at 09:57:46AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > Which of the data node definition statements, 'mandatory', > > > > > > 'min/maxElements' and 'presence' uses XPATH constraints? > > > > > > > > > > What is the problem with these? The subject is about the 'when-stmt', > > > > > no? > > > > > > > > Yes, but I want exactly the opposite of what you wrote, namely that > > > > 'when' statement must not cancel or relativize any of the above > > > > grammatical statements. For example: > > > > > > > > container x { > > > > leaf y { > > > > type uint8; > > > > } > > > > leaf z { > > > > mandatory true; > > > > when "../y > 0"; > > > > type empty; > > > > } > > > > } > > > > > > > > I claim that "0" is not a valid document, because the > > > > "mandatory true" constraint is not satisfied (parent exists but > > > > doesn't). > > > > > > Yes - and where is the problem? > > > > The problem is that Martin does not agree with it. > > The current text says, in 8.2 Hierarchy of Constraints: > > "must", "mandatory", "min-elements", and "max-elements" constraints > are not enforced if the parent node has a "when" or "if-feature" > property that is not satisfied on the current device. > > So, in this case, since the when expression is false, leaf z is not > mandatory. > > Mandatory and min/max elements are also semantical constraints, not > grammatical. These constraints need to be satisfied in a valid > configuration only. It is perfectly legal for a mandatory leaf to be > absent from the candidate. [Lets leave out candidate since candidate since this scratch buffer can hold pretty arbitrary stuff anyway.] There seems to be a difference between 'if-feature' and 'when' - 'if-feature' is a global property of a session (features are announced via capabilities during session startup - lets ignore the capability change discussion for now) while 'when' expressions usually refer to the content of a datastore and I can see that this indeed makes it difficult to translate things to other schema languages (except by dropping all constraints and making everything optional). I think I do understand the problem now - I do not know what the right answer is though. /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 Thu Dec 10 02:06: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 743803A6886 for ; Thu, 10 Dec 2009 02:06:19 -0800 (PST) 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.327, 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 38+6IDnHnlJy for ; Thu, 10 Dec 2009 02:06:18 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 156C43A6ABA for ; Thu, 10 Dec 2009 02:06:18 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BAE5ED80096; Thu, 10 Dec 2009 11:06:06 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091210095538.GA61812@elstar.local> References: <1260436665.21259.89.camel@missotis> <20091210092232.GA61657@elstar.local> <1260437510.21259.97.camel@missotis> <20091210.104103.32610959.mbj@tail-f.com> <20091210095538.GA61812@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 10 Dec 2009 11:06:05 +0100 Message-ID: <1260439565.21259.113.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 10:06:19 -0000 Juergen Schoenwaelder píše v Čt 10. 12. 2009 v 10:55 +0100: > [Lets leave out candidate since candidate since this scratch buffer > can hold pretty arbitrary stuff anyway.] > > There seems to be a difference between 'if-feature' and 'when' - > 'if-feature' is a global property of a session (features are announced > via capabilities during session startup - lets ignore the capability > change discussion for now) while 'when' expressions usually refer to > the content of a datastore and I can see that this indeed makes it > difficult to translate things to other schema languages (except by > dropping all constraints and making everything optional). Absolutely, this is exactly my point. > > I think I do understand the problem now - I do not know what the right > answer is though. I propose these changes: **** Section 3.1 OLD A mandatory node is one of: NEW A data node is called mandatory if it satisfies one of the following grammatical constraints: **** Section 8 [New text at the beginning - before 8.1] YANG modules specify three types of constraints: 1. Grammatical constraints define the hierarchical structure (schema) of the data tree and ordinality or co-occurence conditions on all data nodes. 2. Data type constraints define the permitted set of values for the contents of all leaf nodes. 3. Semantic constraints use XPath expression [XPath] for defining any number of semantic rules and relations among data nodes in the entire configuration datastore. Grammatical constraints are primary and MUST be unconditionally satisfied. Semantic constraints MAY assume that all grammatical constraints hold. On the other hand, semantic constraints cannot override grammatical constraints - both types are verified independently. Therefore, module authors should construct the semantic conditions carefully in order to prevent any conflicts resulting from contradictory conditions in grammatical and semantic constraints. Semantic constraints are always verified against the conceptual data tree, which is a given configuration datastore complemented by all applicable default values that are defined by the YANG data model . **** Section 8.2 Use it only for 'if-feature' not for 'when'. **** Section 8.3.3 OLD When datastore processing is complete, the final contents MUST obey all validation constraints. NEW When datastore processing is complete, the final contents MUST obey all grammatical, data type and semantic constraints. ADD [as the first bullet item] o The data tree MUST satisfy all grammatical constraints. **** Section 7.9.15 OLD The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. The statement's argument is an XPath expression, which is used to formally specify this condition. If the XPath expression conceptually evaluates to "true" for a particular instance, then the node defined by the parent data definition statement is valid, otherwise it is not. NEW The "when" statement makes the data node defined by the parent statement semantically conditional, which means that the node may be present in a valid configuration only if condition specified by the "when" statement is satisfied. The statement's argument is an XPath expression, which is used to formally specify this condition. If the XPath expression conceptually evaluates to "true" for a particular instance, then the data node defined by the parent statement may be present in the instance, otherwise it must not be there. Note that 'when' statements do not override grammatical ordinality of data nodes, which is determined using the rules in Section 3.1. **** Section 7.5.3 [This subsection should probably be moved to sec. 7.19 because 'must' is a common statement.] OLD The "must" statement, which is optional, takes as an argument a string which contains an XPath expression. It is used to formally declare a constraint on valid data. The constraint is enforced according to the rules in Section 8. NEW The "must" statement, which is optional, takes as an argument a string which contains an XPath expression. It is used to formally declare a semantic constraint on valid data. The constraint is enforced according to the rules in Section 8. Note that semantic constraints expressed by 'must' statements do not override any grammatical constraints. **** Section 7.5.5 OLD The "presence" statement assigns a meaning to the presence of a container in the data tree. It takes as an argument a string which contains a textual description of what the node's presence means. NEW The "presence" statement assigns a meaning to the presence of a container in the data tree and makes the container optional (grammatical constraint). It takes as an argument a string which contains a textual description of what the node's presence means. **** Section 7.6.5 OLD The "mandatory" statement, which is optional, takes as an argument the string "true" or "false", and puts a constraint on valid data. If not specified, the default is "false". NEW The "mandatory" statement, which is optional, takes as an argument the string "true" or "false", and puts a grammatical constraint on valid data. If not specified, the default is "false". Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From washam.fan@gmail.com Thu Dec 10 04:51: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 0FB583A689F for ; Thu, 10 Dec 2009 04:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 fWUid-MB-0tO for ; Thu, 10 Dec 2009 04:51:14 -0800 (PST) Received: from mail-qy0-f188.google.com (mail-qy0-f188.google.com [209.85.221.188]) by core3.amsl.com (Postfix) with ESMTP id 9E4EC3A6809 for ; Thu, 10 Dec 2009 04:51:13 -0800 (PST) Received: by qyk26 with SMTP id 26so3792335qyk.5 for ; Thu, 10 Dec 2009 04:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=vmqfJu+lHY/NHKcmqUg3iRdvV6mDNL4c26KLuDX+Q5Q=; b=KJP1ljae5waBgoliXNy0kCB8TWcoJVW+GINde/vjHj+NfKncZJRO70CDlh80hCoeMr hEfF1EyQZAYZeH5cnQ0gOdUjVQqVJolIaZdIhzSkHODd50LKjTnMz3hHS/OCXlFpHqfr QFe1jK6m3MI1Z4MKaMttFN6orcSvD60aQwzrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=cXeCvrvqnN2lL48q+vF8PmDqrtsh4baU3GVNaVkSTWEFcKOrvSLKY3Cs8Bnjcb3I38 5ntDNTSrpgWAuirEI3fEpdqcIbo2xguf+8fE0CkBjPaCLv0ji4DDspSwnDFhjTvO4HNo ExbhwDGwmgaNPE41Z2xQNjnbv1zjlR6pnVp1M= MIME-Version: 1.0 Received: by 10.224.114.194 with SMTP id f2mr6473886qaq.68.1260449459541; Thu, 10 Dec 2009 04:50:59 -0800 (PST) In-Reply-To: <4B201670.7020506@netconfcentral.com> References: <4B1EC950.2010408@netconfcentral.com> <20091209.221452.236221846.mbj@tail-f.com> <4B201670.7020506@netconfcentral.com> Date: Thu, 10 Dec 2009 20:50:59 +0800 Message-ID: From: Washam Fan To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2009 12:51:15 -0000 Hi, >> =A0 The capabilities of a NETCONF server may change over time. =A0Howeve= r, >> =A0 once a NETCONF server has announced its capabilities in the >> =A0 message, the capabilities for that session MUST NOT change. =A0A >> =A0 server MUST reply with a 'capabilities-changed' error if the client >> =A0 sends a request which is affected by a modified capability. >> >> And maybe add: >> >> =A0 A server MAY choose to send 'capabilities-changed' as the response >> =A0 to any request other than if its capabilities has >> =A0 changed. >> >> > > > I agree with Phil that this is a vendor-specific > detail, and there are many mechanisms that might be used > to deal with changing capabilities, > or the specific operation > may not be affected by the capability change at all. As I pointed out long time ago, this might be where warning usage enters in. closing or re-initiating sessions might be costly when operations are not affected by the capability change, maybe casting a warning would suffice in this case. (Yes, warning usage is still up in the air) washam From j.schoenwaelder@jacobs-university.de Thu Dec 10 06:10: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 E7AA33A67E1 for ; Thu, 10 Dec 2009 06:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvi7aaWLrHz9 for ; Thu, 10 Dec 2009 06:10:37 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5245C3A685E for ; Thu, 10 Dec 2009 06:10:35 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8637FC0018; Thu, 10 Dec 2009 15:10:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id H06ixycBiCR9; Thu, 10 Dec 2009 15:10:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 924FAC0042; Thu, 10 Dec 2009 15:10:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 821FEF53BB3; Thu, 10 Dec 2009 15:10:20 +0100 (CET) Date: Thu, 10 Dec 2009 15:10:20 +0100 From: Juergen Schoenwaelder To: Washam Fan Message-ID: <20091210141020.GB467@elstar.local> Mail-Followup-To: Washam Fan , "netmod@ietf.org" References: <4B1EC950.2010408@netconfcentral.com> <20091209.221452.236221846.mbj@tail-f.com> <4B201670.7020506@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] [Netconf] 4741bis, issue 14, capabilities changed error 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, 10 Dec 2009 14:10:43 -0000 On Thu, Dec 10, 2009 at 01:50:59PM +0100, Washam Fan wrote: > As I pointed out long time ago, this might be where warning > usage enters in. closing or re-initiating sessions might be costly > when operations are not affected by the capability change, > maybe casting a warning would suffice in this case. (Yes, > warning usage is still up in the air) I don't think NETCONF has a working mechanism for warnings. /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 Dec 10 07:32: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 51B033A6A00 for ; Thu, 10 Dec 2009 07:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 LrEIkWaW2Bff for ; Thu, 10 Dec 2009 07:32:32 -0800 (PST) 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 91A2E3A69DB for ; Thu, 10 Dec 2009 07:32:32 -0800 (PST) Received: (qmail 55693 invoked from network); 10 Dec 2009 15:32:19 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 10 Dec 2009 07:32:19 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6el6W.AVM1kSusB2m.mPDaARdqzEWtwTgjEPBgAW9nY3gyW38Sgc1sM_azLMfHamM_TwcS8MtxKWLrXPQ6XT0.fEmBhqJhpvVtjqkIlMAeV.ZsyGkpeHMv5Vl9B8svry5UUhKEdYEX_IxtRe4LqEpHIj8_gf3A4ybcG36Y2o_Rtp2gyJLtWPfJyxDip1uYcae.sgmpM7XdvYoYyh6L6F.Cehz3f_bE684EQDxTH2CmGb.r5L71MvmRyMCc4aY2l9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B21145E.5090108@netconfcentral.com> Date: Thu, 10 Dec 2009 07:31:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1260436665.21259.89.camel@missotis> <20091210092232.GA61657@elstar.local> <1260437510.21259.97.camel@missotis> <20091210.104103.32610959.mbj@tail-f.com> <1260438741.21259.105.camel@missotis> In-Reply-To: <1260438741.21259.105.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 15:32:33 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Čt 10. 12. 2009 v 10:41 +0100: >>>>> container x { >>>>> leaf y { >>>>> type uint8; >>>>> } >>>>> leaf z { >>>>> mandatory true; >>>>> when "../y > 0"; >>>>> type empty; >>>>> } >>>>> } >>>>> >>>>> I claim that "0" is not a valid document, because the >>>>> "mandatory true" constraint is not satisfied (parent exists but >>>>> doesn't). >>>> Yes - and where is the problem? >>> The problem is that Martin does not agree with it. >> The current text says, in 8.2 Hierarchy of Constraints: >> >> "must", "mandatory", "min-elements", and "max-elements" constraints >> are not enforced if the parent node has a "when" or "if-feature" >> property that is not satisfied on the current device. > > Yes, I object to this section, too, but it doesn't apply to the present > example anyway: it is not the parent node that has the 'when' statement. > > On the other hand, sec. 7.6.4 says (third bullet): > > o Otherwise, the leaf MUST exist if the ancestor node exists in the > data tree. > > I see no ifs or whens here. > >> So, in this case, since the when expression is false, leaf z is not >> mandatory. >> >> Mandatory and min/max elements are also semantical constraints, not >> grammatical. These constraints need to be satisfied in a valid >> configuration only. It is perfectly legal for a mandatory leaf to be >> absent from the candidate. > > I don't agree with this interpretation. > But the candidate is part of NETCONF. It is just a scratchpad, not a real database. The YANG constraints apply to the running config for data nodes. The server must ignore when-stmt in the candidate, because the spec says it applies to a valid configuration. By design, that excludes the candidate config. > Lada > >> >> /martin > > Andy From andy@netconfcentral.com Thu Dec 10 08:05: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 1A7E33A6B0E for ; Thu, 10 Dec 2009 08:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 9i4FPSXfamJK for ; Thu, 10 Dec 2009 08:05:36 -0800 (PST) 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 3AC5D3A6A09 for ; Thu, 10 Dec 2009 08:05:34 -0800 (PST) Received: (qmail 10656 invoked from network); 10 Dec 2009 16:05:03 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 10 Dec 2009 08:05:03 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: dzsSgT0VM1lpYsxPuFG.tLEIfCJT5NL3k8OpAVrSCrrqr09glnzdqrlhMPIvaubkvQVXiz473KWYm6ALQMyfb5bCXn7PGQSD0bs2aSY17dErkhfXepopO4vk4Zsk1zR4uWWj2zOSWop5JIjrCcFtdbza1zBcSV7F.bpprJHt8GsOfErXscy5tVNOuSVH4CNwOjSURJ7BUjDPMsgeyE331mjSJPjjZfUCIVU30.KcrroC.nh7rVVqq4cVMqj_N3oooeCdnxwI99RBTvSj4wuqcKWeV1zWB6H7Pk9DYnCOl.1qR.ZKjeUjn1xRYQs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B211B90.6000704@netconfcentral.com> Date: Thu, 10 Dec 2009 08:02:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200912092241.nB9MfqVf000265@idle.juniper.net> <4B203393.4020306@netconfcentral.com> <20091210.093814.25166080.mbj@tail-f.com> In-Reply-To: <20091210.093814.25166080.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 16:05:40 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> Just remove it as a sub-statement of uses-stmt. >>>> This removes the complexity from N levels of inherited uses-when >>>> conditions, with up to N different context nodes. >>> I see the uses/when as a key ingredient for the reusability >>> of groupings. Please don't remove it. I don't see it as >>> adding any sgnificant complexity, since "when" is already >>> there and the implementations must already deal with it. >>> >> Sec. 7.19.4 para 3 does not specify the context of the when-stmt >> for a uses-stmt. >> >> Since this is so easy, why don't you write the text that >> is required to specify the context node for uses-stmt? >> This must be done in order to leave uses-when in the draft. > > when in uses has the same context node as when in choice, i.e. its > parent. > > So we should extend the text in 7.19.5, bullet 2: > > OLD: > > o If the "when" statement is a child of a "choice" or "case" > statement, then the context node is the closest ancestor node to > the "choice" or "case" node which is also a data node. > > NEW: > > o If the "when" statement is a child of a "uses", "choice", or > "case" statement, then the context node is the closest ancestor > node to the "uses", "choice", or "case" node which is also a > data node. > > This is fine. For data nodes inside the candidate config, the when-stmt is completely ignored (except for ). It only applies to data nodes in a valid configuration, e.g., applied during the operation. The text is not very clear about this point. False 'when' nodes get deleted during the commit, not after every to candidate. This is different than choice-stmt, which causes a case-stmt to be removed if another case is selected. The order that when-stmts are evaluated will influence the outcome of the validation process. It is rather difficult to evaluate an arbitrary set of when-stmts all at once. Expect servers to use a different implementation strategy, such as a top-down, left-to-right sequence. I never got an explanation why the description-stmt and reference-stmt are useful for must-stmt but not when-stmt. It looks like sloppy work to me, but if there's some reason these properties apply to 1 kind of XPath expression but not another one, it would be good to note that in the draft. > /martin > > > Andy From mbj@tail-f.com Thu Dec 10 09:20: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 5741C3A6897 for ; Thu, 10 Dec 2009 09:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lnSIAWeYYTX for ; Thu, 10 Dec 2009 09:20:54 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3BCB43A6801 for ; Thu, 10 Dec 2009 09:20:54 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D574576C044; Thu, 10 Dec 2009 18:20:41 +0100 (CET) Date: Thu, 10 Dec 2009 18:20:41 +0100 (CET) Message-Id: <20091210.182041.121803179.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B211B90.6000704@netconfcentral.com> References: <4B203393.4020306@netconfcentral.com> <20091210.093814.25166080.mbj@tail-f.com> <4B211B90.6000704@netconfcentral.com> X-Mailer: Mew version 6.2.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-09; 7.19.5 when-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, 10 Dec 2009 17:20:55 -0000 Andy Bierman wrote: > For data nodes inside the candidate config, > the when-stmt is completely ignored (except for ). > It only applies to data nodes in a valid configuration, > e.g., applied during the operation. > > The text is not very clear about this point. > False 'when' nodes get deleted during the commit, > not after every to candidate. > This is different than choice-stmt, which causes > a case-stmt to be removed if another case is selected. Actually, the draft says, in section 8.3.2: During processing: o If the NETCONF operation creates data nodes under a "choice", any existing nodes from other "case" branches are deleted by the server. o If the NETCONF operation modifies a data node such that any node's "when" expression becomes false, then that node is deleted by the server. So when is like choice in this regard. > I never got an explanation why the description-stmt and > reference-stmt are useful for must-stmt but not when-stmt. > It looks like sloppy work to me, but if there's some > reason these properties apply to 1 kind of XPath expression > but not another one, it would be good to note that in the draft. I think we can add these substatemnts to 'when'. /martin From andy@netconfcentral.com Thu Dec 10 09:46: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 7CF3E3A6ACD for ; Thu, 10 Dec 2009 09:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 ELN-HixELTlQ for ; Thu, 10 Dec 2009 09:46:04 -0800 (PST) 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 430473A6B53 for ; Thu, 10 Dec 2009 09:45:54 -0800 (PST) Received: (qmail 755 invoked from network); 10 Dec 2009 17:45:40 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 10 Dec 2009 09:45:40 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: JzzldSQVM1nYUO2BhTlRENPJlv4cRJYInMV2zPUwKlm3bIcEp.ls_1V2L5SBL7GBrpwJb5fe4VL7y3SD_hSfnRkf1cdalxGhyRCTejXkbzA1Y8khc3nTTBzJ657Ulo9pmzcr2chGAxIylHg5LUQXwuKev_JFPi.deOisbq0dKcEX23FTEgXp4ZRz7TolW6aW4JTAYT_w54fxdL1F85hwZFPba6QU.vHLGhPzzKKLy_O1g4W6EWzXUnY_MxnxTr8Dm44Zfk1x61OqjavQWJcwdE.MdXUxKYulBvlcsp_cKw9t0Pnux3FQsEBLWd2eeA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2133C4.6040108@netconfcentral.com> Date: Thu, 10 Dec 2009 09:45:40 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B203393.4020306@netconfcentral.com> <20091210.093814.25166080.mbj@tail-f.com> <4B211B90.6000704@netconfcentral.com> <20091210.182041.121803179.mbj@tail-f.com> In-Reply-To: <20091210.182041.121803179.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 17:46:05 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> For data nodes inside the candidate config, >> the when-stmt is completely ignored (except for ). >> It only applies to data nodes in a valid configuration, >> e.g., applied during the operation. >> >> The text is not very clear about this point. >> False 'when' nodes get deleted during the commit, >> not after every to candidate. >> This is different than choice-stmt, which causes >> a case-stmt to be removed if another case is selected. > > Actually, the draft says, in section 8.3.2: > > During processing: > > o If the NETCONF operation creates data nodes under a "choice", any > existing nodes from other "case" branches are deleted by the > server. > > o If the NETCONF operation modifies a data node such that any node's > "when" expression becomes false, then that node is deleted by the > server. > > So when is like choice in this regard. > oops -- I even coded it this way (!) I confused it with deleting empty NP containers, which I assume is OK to wait until the commit to delete. > >> I never got an explanation why the description-stmt and >> reference-stmt are useful for must-stmt but not when-stmt. >> It looks like sloppy work to me, but if there's some >> reason these properties apply to 1 kind of XPath expression >> but not another one, it would be good to note that in the draft. > > I think we can add these substatemnts to 'when'. > > > /martin > > Andy From j.schoenwaelder@jacobs-university.de Thu Dec 10 11:12: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 853753A685A for ; Thu, 10 Dec 2009 11:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 ytbWvB4BsDQO for ; Thu, 10 Dec 2009 11:12:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6E86F3A677E for ; Thu, 10 Dec 2009 11:12:49 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90702C001C; Thu, 10 Dec 2009 20:12:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yXVwRPMsXaxq; Thu, 10 Dec 2009 20:12:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C18CC000A; Thu, 10 Dec 2009 20:12:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B58F9F550B3; Thu, 10 Dec 2009 20:12:33 +0100 (CET) Date: Thu, 10 Dec 2009 20:12:33 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091210191233.GB1615@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <4B203393.4020306@netconfcentral.com> <20091210.093814.25166080.mbj@tail-f.com> <4B211B90.6000704@netconfcentral.com> <20091210.182041.121803179.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091210.182041.121803179.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-09; 7.19.5 when-stmt 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, 10 Dec 2009 19:12:50 -0000 On Thu, Dec 10, 2009 at 06:20:41PM +0100, Martin Bjorklund wrote: > o If the NETCONF operation modifies a data node such that any node's > "when" expression becomes false, then that node is deleted by the > server. This is pretty ambiguous - which node is deleted? Anyway, does the delete overwrite all other constraints like mandatory or rendering other must expressions invalid? Or does a server has to detect such situations before doing the delete and fail the request because of this? /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 Thu Dec 10 11:46:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD993A6830 for ; Thu, 10 Dec 2009 11:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7Fj7BQqW5xM for ; Thu, 10 Dec 2009 11:46:42 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D05B13A677E for ; Thu, 10 Dec 2009 11:46:41 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 53C9776C044; Thu, 10 Dec 2009 20:46:29 +0100 (CET) Date: Thu, 10 Dec 2009 20:46:28 +0100 (CET) Message-Id: <20091210.204628.104841167.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091210191233.GB1615@elstar.local> References: <4B211B90.6000704@netconfcentral.com> <20091210.182041.121803179.mbj@tail-f.com> <20091210191233.GB1615@elstar.local> X-Mailer: Mew version 6.2.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-09; 7.19.5 when-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, 10 Dec 2009 19:46:42 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 10, 2009 at 06:20:41PM +0100, Martin Bjorklund wrote: > > > o If the NETCONF operation modifies a data node such that any node's > > "when" expression becomes false, then that node is deleted by the > > server. > > This is pretty ambiguous - which node is deleted? The node with the when expression. > Anyway, does the > delete overwrite all other constraints like mandatory or rendering > other must expressions invalid? Section 8.2 says: "must", "mandatory", "min-elements", and "max-elements" constraints are not enforced if the parent node has a "when" or "if-feature" property that is not satisfied on the current device. > Or does a server has to detect such > situations before doing the delete and fail the request because of > this? Such an auto-delete is handled just like an explict delete by a client. If it modifies running, and would result in an invalid config, it is not executed. /martin From andy@netconfcentral.com Thu Dec 10 12:04:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6991C3A6958 for ; Thu, 10 Dec 2009 12:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 5n2l7b6vrru5 for ; Thu, 10 Dec 2009 12:04:09 -0800 (PST) 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 6D1E03A6954 for ; Thu, 10 Dec 2009 12:04:09 -0800 (PST) Received: (qmail 18295 invoked from network); 10 Dec 2009 20:03:55 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2009 12:03:55 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 12ILP08VM1maRtfWwOLBYCRhLPPsOR4_DDdX_fBTBsMFwKTlFjwSg7Qa3NK14K6T6.KOklnO9lr9EPRVs1kWNfOuk8UjNRvHz6.lykEDMeYJ9ytjAhHqUlV3Ym5MLvLVRbxXQKSO92JHFRFEipBriCaj9WZvywglRe0qojJA.T6_5HyRU.35m711Q4gNtMgodXIjYnCxAFYvMtMzbOpET.7PocXoZktxnnYiCSMoZgb7BIFq55owLhxOzNX1zchIvA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B21542C.7050707@netconfcentral.com> Date: Thu, 10 Dec 2009 12:03:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "netmod@ietf.org" References: <4B203393.4020306@netconfcentral.com> <20091210.093814.25166080.mbj@tail-f.com> <4B211B90.6000704@netconfcentral.com> <20091210.182041.121803179.mbj@tail-f.com> <20091210191233.GB1615@elstar.local> In-Reply-To: <20091210191233.GB1615@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 20:04:10 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 10, 2009 at 06:20:41PM +0100, Martin Bjorklund wrote: > >> o If the NETCONF operation modifies a data node such that any node's >> "when" expression becomes false, then that node is deleted by the >> server. > > This is pretty ambiguous - which node is deleted? Anyway, does the > delete overwrite all other constraints like mandatory or rendering > other must expressions invalid? Or does a server has to detect such > situations before doing the delete and fail the request because of > this? > Any node with a when-stmt (or augment/uses inherited when-stmt(s)) that evaluates to false. When you delete such a node, it is possible that a different when-stmt is now false, so there is a ripple effect to handle in the code. Of course, this is done before the semantic constraint validation (must/min/max/unique), since the deleted nodes may affect those results. Since the augment and uses 'objects' are not supposedly in the database, using their 'parent' as the context node is somewhat confusing, but it is just an implementation detail. > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Dec 10 12:20: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 0776F3A6907 for ; Thu, 10 Dec 2009 12:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 6+FPz0qIlR8G for ; Thu, 10 Dec 2009 12:20:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 792D13A68E0 for ; Thu, 10 Dec 2009 12:20:14 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90F63C001C; Thu, 10 Dec 2009 21:20:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4btvWtkU16Oc; Thu, 10 Dec 2009 21:20:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE5C3C0054; Thu, 10 Dec 2009 21:20:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A1BB3F5529B; Thu, 10 Dec 2009 21:19:59 +0100 (CET) Date: Thu, 10 Dec 2009 21:19:59 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091210201959.GA1791@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <4B211B90.6000704@netconfcentral.com> <20091210.182041.121803179.mbj@tail-f.com> <20091210191233.GB1615@elstar.local> <20091210.204628.104841167.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091210.204628.104841167.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-09; 7.19.5 when-stmt 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, 10 Dec 2009 20:20:16 -0000 On Thu, Dec 10, 2009 at 08:46:28PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Dec 10, 2009 at 06:20:41PM +0100, Martin Bjorklund wrote: > > > > > o If the NETCONF operation modifies a data node such that any node's > > > "when" expression becomes false, then that node is deleted by the > > > server. > > > > This is pretty ambiguous - which node is deleted? > > The node with the when expression. That what I assumed but we should be clear, that is s/that node/the node with the when expression/ > > Or does a server has to detect such > > situations before doing the delete and fail the request because of > > this? > > Such an auto-delete is handled just like an explict delete by a > client. If it modifies running, and would result in an invalid > config, it is not executed. May I assume "it" here means the "request to modify a node such that other node's "when" expressions became false that lead to an auto-remove that caused other must constraints to become invalid. /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 Thu Dec 10 12:21: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 A72883A6907 for ; Thu, 10 Dec 2009 12:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 YcGqxOtP6DpC for ; Thu, 10 Dec 2009 12:21:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C9F163A67A8 for ; Thu, 10 Dec 2009 12:21:55 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44485C001C; Thu, 10 Dec 2009 21:21:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gfWN28Akelwg; Thu, 10 Dec 2009 21:21:43 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62ADFC000A; Thu, 10 Dec 2009 21:21:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 483D1F5530A; Thu, 10 Dec 2009 21:21:41 +0100 (CET) Date: Thu, 10 Dec 2009 21:21:41 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091210202141.GB1791@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4B203393.4020306@netconfcentral.com> <20091210.093814.25166080.mbj@tail-f.com> <4B211B90.6000704@netconfcentral.com> <20091210.182041.121803179.mbj@tail-f.com> <20091210191233.GB1615@elstar.local> <4B21542C.7050707@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B21542C.7050707@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-09; 7.19.5 when-stmt 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, 10 Dec 2009 20:21:57 -0000 On Thu, Dec 10, 2009 at 09:03:56PM +0100, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Thu, Dec 10, 2009 at 06:20:41PM +0100, Martin Bjorklund wrote: > > > >> o If the NETCONF operation modifies a data node such that any node's > >> "when" expression becomes false, then that node is deleted by the > >> server. > > > > This is pretty ambiguous - which node is deleted? Anyway, does the > > delete overwrite all other constraints like mandatory or rendering > > other must expressions invalid? Or does a server has to detect such > > situations before doing the delete and fail the request because of > > this? > > > > Any node with a when-stmt (or augment/uses inherited when-stmt(s)) > that evaluates to false. When you delete such a node, it is possible > that a different when-stmt is now false, so there is a ripple effect > to handle in the code. Of course, this is done before the semantic > constraint validation (must/min/max/unique), since the deleted nodes > may affect those results. OK > Since the augment and uses 'objects' are not supposedly in the > database, using their 'parent' as the context node is somewhat > confusing, but it is just an implementation detail. Not sure I follow - where are the augment and uses 'objects' if not in the datastore? /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 Thu Dec 10 12:48: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 7CD033A6A44 for ; Thu, 10 Dec 2009 12:48:11 -0800 (PST) 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.118, 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 kR0bRrPcX2Ej for ; Thu, 10 Dec 2009 12:48:10 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AA7093A68DF for ; Thu, 10 Dec 2009 12:48:10 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 469CD76C044; Thu, 10 Dec 2009 21:47:58 +0100 (CET) Date: Thu, 10 Dec 2009 21:47:57 +0100 (CET) Message-Id: <20091210.214757.90155179.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091210201959.GA1791@elstar.local> References: <20091210191233.GB1615@elstar.local> <20091210.204628.104841167.mbj@tail-f.com> <20091210201959.GA1791@elstar.local> X-Mailer: Mew version 6.2.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-09; 7.19.5 when-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, 10 Dec 2009 20:48:11 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 10, 2009 at 08:46:28PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Dec 10, 2009 at 06:20:41PM +0100, Martin Bjorklund wrote: > > > > > > > o If the NETCONF operation modifies a data node such that any node's > > > > "when" expression becomes false, then that node is deleted by the > > > > server. > > > > > > This is pretty ambiguous - which node is deleted? > > > > The node with the when expression. > > That what I assumed but we should be clear, that is > s/that node/the node with the when expression/ Ok, fixed. > > > Or does a server has to detect such > > > situations before doing the delete and fail the request because of > > > this? > > > > Such an auto-delete is handled just like an explict delete by a > > client. If it modifies running, and would result in an invalid > > config, it is not executed. > > May I assume "it" here means the "request to modify a node such that > other node's "when" expressions became false that lead to an > auto-remove that caused other must constraints to become invalid. "it" means "an operation". /martin From andy@netconfcentral.com Thu Dec 10 13:14: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 BC38A3A6A4D for ; Thu, 10 Dec 2009 13:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 CXs2wY8b6zzs for ; Thu, 10 Dec 2009 13:14:34 -0800 (PST) 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 B98763A6A4B for ; Thu, 10 Dec 2009 13:14:34 -0800 (PST) Received: (qmail 29439 invoked from network); 10 Dec 2009 21:14:23 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2009 13:14:23 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: U7X7rbUVM1moo2OfDwOIwuWwGl26A2wVE.nOS.7XEJZaAswLu8TfoTJyzO8m3z5qQJRM93nA4vaNAL6EoYp0a8TKsu49WDBvcdpodZ4f7EKYjKW3h38oGN2rl7A80gJVTKyeGBF_Lf0BYESBL8P_Za2wmY43XD_dRMUNUjLkdkq0clpafz6jT6K7e55sB7A3p_ofgfwI8JQP9PBQbdT3vM2OWclr_n9sLwH47.GxMxrjzx9.x.ALv.SRAyWbgByn X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2164B0.2080102@netconfcentral.com> Date: Thu, 10 Dec 2009 13:14:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4B203393.4020306@netconfcentral.com> <20091210.093814.25166080.mbj@tail-f.com> <4B211B90.6000704@netconfcentral.com> <20091210.182041.121803179.mbj@tail-f.com> <20091210191233.GB1615@elstar.local> <4B21542C.7050707@netconfcentral.com> <20091210202141.GB1791@elstar.local> In-Reply-To: <20091210202141.GB1791@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang-09; 7.19.5 when-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, 10 Dec 2009 21:14:36 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 10, 2009 at 09:03:56PM +0100, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Dec 10, 2009 at 06:20:41PM +0100, Martin Bjorklund wrote: >>> >>>> o If the NETCONF operation modifies a data node such that any node's >>>> "when" expression becomes false, then that node is deleted by the >>>> server. >>> This is pretty ambiguous - which node is deleted? Anyway, does the >>> delete overwrite all other constraints like mandatory or rendering >>> other must expressions invalid? Or does a server has to detect such >>> situations before doing the delete and fail the request because of >>> this? >>> >> Any node with a when-stmt (or augment/uses inherited when-stmt(s)) >> that evaluates to false. When you delete such a node, it is possible >> that a different when-stmt is now false, so there is a ripple effect >> to handle in the code. Of course, this is done before the semantic >> constraint validation (must/min/max/unique), since the deleted nodes >> may affect those results. > > OK > >> Since the augment and uses 'objects' are not supposedly in the >> database, using their 'parent' as the context node is somewhat >> confusing, but it is just an implementation detail. > > Not sure I follow - where are the augment and uses 'objects' if not in > the datastore? They are in the datastore in the implementation. But there can never be an instance of these objects, like with a container or leaf. > > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Dec 11 05:25: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 07DBE3A69DC for ; Fri, 11 Dec 2009 05:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 SfVLz3tmXuVF for ; Fri, 11 Dec 2009 05:25:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C9DC33A6986 for ; Fri, 11 Dec 2009 05:24:59 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAF86C0021 for ; Fri, 11 Dec 2009 14:24:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RhvuoJH0DCK9; Fri, 11 Dec 2009 14:24:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 239E2C0010; Fri, 11 Dec 2009 14:24:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BD9C9F56E99; Fri, 11 Dec 2009 14:24:43 +0100 (CET) Date: Fri, 11 Dec 2009 14:24:43 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20091211132443.GA3304@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [netmod] type namespace clarification 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, 11 Dec 2009 13:25:01 -0000 Hi, we were trying to interpret the text in section 6.2.1. and we were not totally sure what it means. Here is an example: container a { typedef t; } container b { typedef t; } One interpretation of 6.2.1 is that this is illegal: 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. But then pyang does accept it. It seems the text in 6.2.1 says that all type identifiers are in a single global namespace, only the usage of the types is scoped. We actually are not sure what the second sentence tries to say - and this is like why sentence three tries to explain sentence two. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Fri Dec 11 06:28: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 ECE313A68BE for ; Fri, 11 Dec 2009 06:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Mkg-DOOdkrSo for ; Fri, 11 Dec 2009 06:28:16 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id A992D3A6A8C for ; Fri, 11 Dec 2009 06:28:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSyJW8aBqmM4W6UV18cPZV4tqry9CxWna@postini.com; Fri, 11 Dec 2009 06:28:04 PST 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.393.1; Fri, 11 Dec 2009 06:24:03 -0800 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, 11 Dec 2009 06:24:03 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 06:24:03 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 06:24:02 -0800 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 nBBEO2j81569; Fri, 11 Dec 2009 06:24:02 -0800 (PST) (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 nBBEAF91020320; Fri, 11 Dec 2009 14:10:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912111410.nBBEAF91020320@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091211132443.GA3304@elstar.local> Date: Fri, 11 Dec 2009 09:10:15 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2009 14:24:02.0930 (UTC) FILETIME=[968C9520:01CA7A6D] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] type namespace clarification X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 14:28:20 -0000 Juergen Schoenwaelder writes: > 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. typedefs are scoped to the parent node, so the parent in your example is "container a" and "container b". container a { typedef t { ... } leaf z { type t; } container c { typedef t { ... } // Illegal, since a's t is in scope leaf z { type t; } } container b { typedef t { ... } // Legal, since a's t is out of scope leaf z { type t; } } So the text says: (a) they share the same space (b) they are scoped (c) don't allow conflicts Scoping means the definitions move out of the namespace when they fall out of scope. Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Dec 11 07:11: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 DF0DC3A68FE for ; Fri, 11 Dec 2009 07:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 JxmxOrueAadf for ; Fri, 11 Dec 2009 07:11:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 77F273A69E3 for ; Fri, 11 Dec 2009 07:11:01 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB586C001E; Fri, 11 Dec 2009 16:10:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id p7yy2s7OqE0Y; Fri, 11 Dec 2009 16:10:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 159CBC000C; Fri, 11 Dec 2009 16:10:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9680FF572FB; Fri, 11 Dec 2009 16:10:46 +0100 (CET) Date: Fri, 11 Dec 2009 16:10:46 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20091211151046.GA3423@elstar.local> Mail-Followup-To: Phil Shafer , "netmod@ietf.org" References: <20091211132443.GA3304@elstar.local> <200912111410.nBBEAF91020320@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912111410.nBBEAF91020320@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] type namespace clarification 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, 11 Dec 2009 15:11:03 -0000 On Fri, Dec 11, 2009 at 03:10:15PM +0100, Phil Shafer wrote: > So the text says: > > (a) they share the same space > (b) they are scoped > (c) don't allow conflicts > > Scoping means the definitions move out of the namespace when they > fall out of scope. Good. One more questions - is shadowing allowed or not? container a { typedef t {} container b { typedef t {} } } I assume the text says this second typedef is not allowed. Your (c) is probably "shadowing is not allowed". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Fri Dec 11 07:40: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 A19C83A69DB for ; Fri, 11 Dec 2009 07:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 QdSUsBRsdDTf for ; Fri, 11 Dec 2009 07:40:40 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id DFE233A687B for ; Fri, 11 Dec 2009 07:40:39 -0800 (PST) Received: (qmail 71577 invoked from network); 11 Dec 2009 15:40:25 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 11 Dec 2009 07:40:25 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6hpftFwVM1keGfPx0ViIuo7r7f1htdYwrZNuxQAkxCiqeQJpORzuWfSmNeswt7.uAc2si3w0D.QzIVsLEABCAA5j6jklHDi98_EokKdiXOyumq7rfieuBP3Y.5HtADlUEY8WGhwUMh2CDh_lJSmay3OoDZLV167E5Q6mdQPl6oeweGKg7NCYSabWl0eISlPZWkuy6vLapSOP4xCeHSl4fJ2jUlK_KWe93S9ddXUyHdpcs1WwvgzamcmZA7NVQ4rm X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2267F2.4000704@netconfcentral.com> Date: Fri, 11 Dec 2009 07:40:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-usage-02; sec 3.6, references X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 15:40:40 -0000 Hi, The discussion on references has concluded. The following change to the text is proposed: 3.6, para 2: OLD: For every reference statement which appears in a module contained in the specification, which identifies a separate document, a corresponding normative reference to that document SHOULD appear in the Normative References section. The reference SHOULD correspond to the specific document version actually used within the specification. NEW: For every reference statement which appears in a module contained in the specification, which identifies a separate document, a corresponding reference to that document SHOULD appear in the References section. The reference SHOULD correspond to the specific document version actually used within the specification. Andy From phil@juniper.net Fri Dec 11 07:41: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 E56DF3A6992 for ; Fri, 11 Dec 2009 07:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 etxecccE6J1d for ; Fri, 11 Dec 2009 07:41:33 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 0C5AD3A68B0 for ; Fri, 11 Dec 2009 07:41:32 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSyJoH8QqNybTqZ7RpPhd+akb96q9Rrm3@postini.com; Fri, 11 Dec 2009 07:41:21 PST 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.393.1; Fri, 11 Dec 2009 07:36:34 -0800 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, 11 Dec 2009 07:36:33 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 07:36:33 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 07:36:33 -0800 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 nBBFaWj16563; Fri, 11 Dec 2009 07:36:32 -0800 (PST) (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 nBBFMkS8020907; Fri, 11 Dec 2009 15:22:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912111522.nBBFMkS8020907@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091211151046.GA3423@elstar.local> Date: Fri, 11 Dec 2009 10:22:45 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2009 15:36:33.0437 (UTC) FILETIME=[B7A744D0:01CA7A77] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] type namespace clarification X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 15:41:34 -0000 Juergen Schoenwaelder writes: >I assume the text says this second typedef is not allowed. Your (c) is >probably "shadowing is not allowed". Exactly. In adding and removing from the same namespace, shadow are errors. Thanks, Phil From andy@netconfcentral.com Fri Dec 11 07:55: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 C59543A6405 for ; Fri, 11 Dec 2009 07:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 nnAYieyAtOe4 for ; Fri, 11 Dec 2009 07:55:52 -0800 (PST) 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 EE3193A6805 for ; Fri, 11 Dec 2009 07:55:51 -0800 (PST) Received: (qmail 87271 invoked from network); 11 Dec 2009 15:55:37 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 11 Dec 2009 07:55:37 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 5gZSpQ8VM1kTp5wihmYY104VLCW9ej6KjI.TYqg_tWSoGBOeZNZBotWrXqIapukLqbZeICYoBOQPfzIB3Y6ExRCwuB33cEfDOWgpY8CbjGwzwNkWz.LhX977w9e3IqQQyUSX25THaGYR74BsC0Iifc1Zt.4VHqdpxm42zEt0CqGs6h4crTz14ijKSS9.Dg3bJ2.m4BCP_o5NuSJonGiXvjI8zQMoe.4VVn6AOF7ZFGJybjL_OFItMu5Gyww9Rtf3zw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B226B82.8090606@netconfcentral.com> Date: Fri, 11 Dec 2009 07:55:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 15:55:52 -0000 Hi, There was a request at the WG meeting to add text clarifying when import/include by revision should be used. The following text is proposed: sec 4.6, Header Contents, new para 2 and 3: If any modules are imported, then the same prefix value SHOULD be used, as defined in the imported module, unless there is another imported module already using that prefix. If any external typedefs or groupings are used, either imported from another module, or included from a submodule, then the revision date MUST be used in the import-stmt or include-stmt, to identify the specific revision of the external file. [ed.: extensions, unique-stmt, and XPath references do not need the revision-date because only the identifier QName is being referenced, which is never allowed to change. Currently, not one YANG module I have ever seen has used import-by-revision, so this guideline is not being followed at all. The import-without-revision is extremely fragile for groupings, typedefs, and defaults. This isn't like SMIv2 at all.] Andy From phil@juniper.net Fri Dec 11 08:09: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 6D30B3A67DF for ; Fri, 11 Dec 2009 08:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 g+0Lpzsse69V for ; Fri, 11 Dec 2009 08:09:29 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id AA40A3A68C4 for ; Fri, 11 Dec 2009 08:09:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSyJurBHPD+fqDu8YquVPtZYsWiZSL1yF@postini.com; Fri, 11 Dec 2009 08:09:18 PST 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.393.1; Fri, 11 Dec 2009 08:01:23 -0800 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, 11 Dec 2009 08:01:22 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 08:01:22 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 08:01:21 -0800 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 nBBG1Lj30463; Fri, 11 Dec 2009 08:01:21 -0800 (PST) (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 nBBFlYTX021178; Fri, 11 Dec 2009 15:47:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912111547.nBBFlYTX021178@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B2267F2.4000704@netconfcentral.com> Date: Fri, 11 Dec 2009 10:47:34 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2009 16:01:21.0949 (UTC) FILETIME=[2EE02CD0:01CA7A7B] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-usage-02; sec 3.6, references X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 16:09:30 -0000 Andy Bierman writes: > For every reference statement which appears in a module contained in > the specification, which identifies a separate document, a Nit: Remove the first comma on this line. Thanks, Phil From phil@juniper.net Fri Dec 11 08:16: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 71C363A679C for ; Fri, 11 Dec 2009 08:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 AJccyvfXbsw4 for ; Fri, 11 Dec 2009 08:16:03 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id CC0063A67DF for ; Fri, 11 Dec 2009 08:16:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSyJwNmq97FTe2Ez4TRWIWuvS5lun4h5l@postini.com; Fri, 11 Dec 2009 08:15:52 PST 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.393.1; Fri, 11 Dec 2009 08:06:00 -0800 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, 11 Dec 2009 08:05:59 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 08:05:59 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 08:05:59 -0800 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 nBBG5wj32658; Fri, 11 Dec 2009 08:05:58 -0800 (PST) (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 nBBFqB5a021205; Fri, 11 Dec 2009 15:52:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912111552.nBBFqB5a021205@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B226B82.8090606@netconfcentral.com> Date: Fri, 11 Dec 2009 10:52:11 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2009 16:05:59.0492 (UTC) FILETIME=[D44DE040:01CA7A7B] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 16:16:10 -0000 Andy Bierman writes: > If any modules are imported, then the same prefix value SHOULD > be used, as defined in the imported module, unless there is > another imported module already using that prefix. Nit: s/already // (since the timeline is not important here) Or use "another module imported using that prefix". > If any external typedefs or groupings are used, either imported > from another module, or included from a submodule, then the > revision date MUST be used in the import-stmt or include-stmt, > to identify the specific revision of the external file. MUST? This make import without revision pretty useless. IMHO this is a "guidlines" document issue. Thanks, Phil From andy@netconfcentral.com Fri Dec 11 08:27:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0F63A685A for ; Fri, 11 Dec 2009 08:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 rbOoIo2k9osv for ; Fri, 11 Dec 2009 08:27:50 -0800 (PST) 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 29CF53A69E8 for ; Fri, 11 Dec 2009 08:27:47 -0800 (PST) Received: (qmail 76255 invoked from network); 11 Dec 2009 16:27:34 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 11 Dec 2009 08:27:33 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 2t524GUVM1nz0epFSpY5gfn48.qHSTsVjNluJT25IKU5_FjEqQVxvbSFRYRytv.mAiv5NLRnFN2i0UfTyxCMR22YBy4O1QcxkG_x_byFWa8xWs7Bg6CYif6B1bCNAiq3grHglbe756MMIea3Cp7ahNmP5iaOFTjvNORdB3z7mQwS9vA5C7IUS.3t04MgvaSypXaennLpE8XzwocG3te2SphVwt_VDCTXz2krRhSJfpS_k3ZmtX87d1ABKq_AEeSh24B2LPRXwcmnU99ZZQVE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2272FF.30902@netconfcentral.com> Date: Fri, 11 Dec 2009 08:27:43 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912111552.nBBFqB5a021205@idle.juniper.net> In-Reply-To: <200912111552.nBBFqB5a021205@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 16:27:51 -0000 Phil Shafer wrote: > Andy Bierman writes: >> If any modules are imported, then the same prefix value SHOULD >> be used, as defined in the imported module, unless there is >> another imported module already using that prefix. > > Nit: s/already // (since the timeline is not important here) > Or use "another module imported using that prefix". > >> If any external typedefs or groupings are used, either imported >> from another module, or included from a submodule, then the >> revision date MUST be used in the import-stmt or include-stmt, >> to identify the specific revision of the external file. > > MUST? This make import without revision pretty useless. IMHO > this is a "guidlines" document issue. > Only IETF modules have to follow the guidelines. The RFC 2119 language usage is not based on how much bother it is to you or anybody else -- it is based on interoperability. There is no way to insure that an external file will not be changed in the future. The syntactic and semantic properties of a published YANG module MUST remain fixed, no matter what, for all time. Import without revision can cause the module to change any time an external grouping or typedef is changed. Import without revision is useless to the IETF. Always has been. > Thanks, > Phil > Andy From j.schoenwaelder@jacobs-university.de Fri Dec 11 10:07: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 7E6E73A68D8 for ; Fri, 11 Dec 2009 10:07:59 -0800 (PST) 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.108, 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 L87SlWmBeS45 for ; Fri, 11 Dec 2009 10:07:58 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8F2FA3A68A7 for ; Fri, 11 Dec 2009 10:07:58 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3179C000C; Fri, 11 Dec 2009 19:07:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WXKZU9502x1A; Fri, 11 Dec 2009 19:07:45 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2593C001D; Fri, 11 Dec 2009 19:07:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B9832F57AAC; Fri, 11 Dec 2009 19:07:42 +0100 (CET) Date: Fri, 11 Dec 2009 19:07:42 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091211180741.GB3925@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4B226B82.8090606@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B226B82.8090606@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision 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, 11 Dec 2009 18:07:59 -0000 On Fri, Dec 11, 2009 at 04:55:46PM +0100, Andy Bierman wrote: > Currently, not one YANG module I have ever seen has used > import-by-revision, so this guideline is not being followed at all. > The import-without-revision is extremely fragile for groupings, > typedefs, and defaults. This isn't like SMIv2 at all.] So far, I have not seen any _published_ YANG module - all we have are moving targets. But, yes, we need proper tools to check for such things when documents go through the YANG review cycle (I am avoiding the term "YANG doctors" - would be nice to have a better sounding name since it is much easier to sell that I spent time on the Security Directorate than it is to sell time spent as a MIB Doctor). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Fri Dec 11 10:47:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0D83A67D4 for ; Fri, 11 Dec 2009 10:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 eAdS+m9T4gN7 for ; Fri, 11 Dec 2009 10:47:02 -0800 (PST) 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 E4D873A67FE for ; Fri, 11 Dec 2009 10:47:01 -0800 (PST) Received: (qmail 53314 invoked from network); 11 Dec 2009 18:46:47 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 11 Dec 2009 10:46:47 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: D4rxRD4VM1kpHpL.RJbQj4pwXtFaZvCoh34sKS37BiI4T2ENMH6qRR_4ds5QxKgTJW7hBwpsa.o9DdSYWa.cyd0AQK_itTTLBrHepKPWWYAIcvi99WrP23j_JGobn9bCMNV0cLMBEenf8FnRCj05RhSqA7AvUZzFPgtJTvxZA9mGhlWII1_S5_EM3AW8R6jyUhlZ8Y0foqfLGhXyXnF5ebqPv_I5S6iQkAXkoSbyBC6O4LEH3oC9lBdSpsgCyNsz X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B229325.1010604@netconfcentral.com> Date: Fri, 11 Dec 2009 10:44:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <4B226B82.8090606@netconfcentral.com> <20091211180741.GB3925@elstar.local> In-Reply-To: <20091211180741.GB3925@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 18:47:02 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 11, 2009 at 04:55:46PM +0100, Andy Bierman wrote: > >> Currently, not one YANG module I have ever seen has used >> import-by-revision, so this guideline is not being followed at all. >> The import-without-revision is extremely fragile for groupings, >> typedefs, and defaults. This isn't like SMIv2 at all.] > > So far, I have not seen any _published_ YANG module - all we have are > moving targets. But, yes, we need proper tools to check for such > things when documents go through the YANG review cycle (I am avoiding > the term "YANG doctors" - would be nice to have a better sounding name > since it is much easier to sell that I spent time on the Security > Directorate than it is to sell time spent as a MIB Doctor). > True, we have no published modules yet. Maybe the revision dates just need to be added at the last step before RFC publication. Your yang-types draft is a good example. There have been lots of pattern bug-fixes, and a client would definitely want to know if the server was using a version with a pattern that has bugs or not. > /js > Andy From phil@juniper.net Fri Dec 11 12:06: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 EA8A13A68A6 for ; Fri, 11 Dec 2009 12:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 dn78ApUrF58X for ; Fri, 11 Dec 2009 12:06:06 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 42EC23A67A7 for ; Fri, 11 Dec 2009 12:06:05 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSyKmIENi7CyEHydoJj37RFUrrtXCsL5T@postini.com; Fri, 11 Dec 2009 12:05:54 PST 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.393.1; Fri, 11 Dec 2009 12:02:02 -0800 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, 11 Dec 2009 12:02:02 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 12:02:02 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 12:02:01 -0800 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 nBBK1wj62191; Fri, 11 Dec 2009 12:01:58 -0800 (PST) (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 nBBJmBjl022995; Fri, 11 Dec 2009 19:48:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912111948.nBBJmBjl022995@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B229325.1010604@netconfcentral.com> Date: Fri, 11 Dec 2009 14:48:11 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2009 20:02:01.0391 (UTC) FILETIME=[CD742BF0:01CA7A9C] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 20:06:07 -0000 Andy Bierman writes: >Your yang-types draft is a good example. >There have been lots of pattern bug-fixes, >and a client would definitely want to know >if the server was using a version with a pattern >that has bugs or not. This is a great example, since the moving module is a poor target to lock in to. Better to go revision-less until the yang types is published. Then you add your revision and all is well. Thanks, Phil From andy@netconfcentral.com Fri Dec 11 12:49: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 7A2023A6824 for ; Fri, 11 Dec 2009 12:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 HW8IfbRTfCPb for ; Fri, 11 Dec 2009 12:49:21 -0800 (PST) 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 67F253A659B for ; Fri, 11 Dec 2009 12:49:21 -0800 (PST) Received: (qmail 41360 invoked from network); 11 Dec 2009 20:49:07 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 11 Dec 2009 12:49:07 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: yYH9Am8VM1nGIoVk.5.vP2xD3JKA7g4Lktfmtf3bu_j1Kw3lVVViNolxZA_qZHox_y.rN7h1BJhq.i1xggZNyso5z61XIVlM43kRkSmivfQs4oNp0T1bLPWfhhB43rBLdHKVE7wCz2t2dLWZXVjOAxuLxMmE.6TO09VsFLCyP4VD6qrsSNRHRvbpz3IDh0CmxbQurQ.CfDnUumFGUWwk7eax_15tK.PjF9j9CjnDOSU.fiHtjWme0XAP.ydgKTFC X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B22B04D.7050601@netconfcentral.com> Date: Fri, 11 Dec 2009 12:49:17 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912111948.nBBJmBjl022995@idle.juniper.net> In-Reply-To: <200912111948.nBBJmBjl022995@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2009 20:49:22 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Your yang-types draft is a good example. >> There have been lots of pattern bug-fixes, >> and a client would definitely want to know >> if the server was using a version with a pattern >> that has bugs or not. > > This is a great example, since the moving module is a poor > target to lock in to. Better to go revision-less until the > yang types is published. Then you add your revision and > all is well. > You are right. The guidelines apply to published modules, which means RFC, not Internet Draft. After ietf-yang-types.yang is published, then an RFC that uses it (e.g, ietf-netconf-monitoring.yang) needs to pick a specific revision to import. IMO, I-Ds should use them as well, if the imported module is already published, and not a moving target. > Thanks, > Phil > Andy From andy@netconfcentral.com Sun Dec 13 11:29: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 0AE583A6919 for ; Sun, 13 Dec 2009 11:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_50=0.001, UNPARSEABLE_RELAY=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 48hd832WZQ+A for ; Sun, 13 Dec 2009 11:29:37 -0800 (PST) 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 48A6D3A6918 for ; Sun, 13 Dec 2009 11:29:37 -0800 (PST) Received: (qmail 92204 invoked from network); 13 Dec 2009 19:29:23 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 13 Dec 2009 11:29:22 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6sVyhPwVM1l41fBDe5gVy4_bm.b_4KZM0GueVoA8HInvlv8MgGUQECDHo9Y5Mnoo_axdcb8QKl1HOLYNP3jRyL1klA2xw5ZDiF.EvFnAkcd4oqiq2Zae0qdJ0T1qD7sn7rW0YB4lH1GEzQv4VCQel86oCuYADyO4r3kHJU3o4pXDATMJvbnQ6YwzP46ftOja_eQhoCqJQAccgxgsCOy9ryRym4o7kb.2Yml16bhH.PDORPsl0CZJoxGUIK4hQUi0Zg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2540B0.5000902@netconfcentral.com> Date: Sun, 13 Dec 2009 11:29:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2009 19:29:38 -0000 Hi, Now that I am bothering to implement YIN, I can't help notice that it is a CLR factory. I cannot find any meaningful rationale for picking yin-element == true or false. The decision to encode as an attribute seems completely arbitrary and pointless. Memorizing the table of hard-wired values in the draft seems like a waste of time. I also find the arbitrary names picked for the argument strings to be pointless and a just more CLRs. Every one of them could be called and it would make YIN easier to understand. These arbitrary argument names disappear in YANG. YIN should always use elements and not attributes. That would simplify encoding, reduce YANG CLRs, reduce implementation complexity, and simplify the extension-stmt (no need for yin-element sub-statement). Andy From mbj@tail-f.com Sun Dec 13 11:33:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DA93A6914 for ; Sun, 13 Dec 2009 11:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=-0.631, 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 C0M4x23ffVM2 for ; Sun, 13 Dec 2009 11:33:20 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 77ED63A67E1 for ; Sun, 13 Dec 2009 11:33:20 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C34A9616001; Sun, 13 Dec 2009 20:33:06 +0100 (CET) Date: Sun, 13 Dec 2009 20:33:06 +0100 (CET) Message-Id: <20091213.203306.94975409.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B226B82.8090606@netconfcentral.com> References: <4B226B82.8090606@netconfcentral.com> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2009 19:33:21 -0000 Andy Bierman wrote: > Hi, > > There was a request at the WG meeting to add text clarifying > when import/include by revision should be used. > The following text is proposed: > > sec 4.6, Header Contents, new para 2 and 3: > > If any modules are imported, then the same prefix value SHOULD > be used, as defined in the imported module, unless there is > another imported module already using that prefix. > > If any external typedefs or groupings are used, either imported > from another module, or included from a submodule, then the > revision date MUST be used in the import-stmt or include-stmt, > to identify the specific revision of the external file. I don't think it is correct to require import by revision. If my module imports ietf-inet-types and uses ipv6-address, why is it important to lock down the revision? If a bug fix or clarification is made in the future, I want my module to work with it. If we require import by revision for all ietf modules, we will end up in a situation where one bug fix ir clarification in one of the base module may require reublishing all other ietf modules. If module B imports A (without revision), and there exist multiple revisions of A, it is of course essential that a client knows which version is implemented in the server, but that is already covered with hello advertising (and schema discovery). I don't even think we should say SHOULD import by revision. It all depends on what you are using from a module. /martin From andy@netconfcentral.com Sun Dec 13 11:41: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 4D0603A6864 for ; Sun, 13 Dec 2009 11:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 aeWWUy8m6T36 for ; Sun, 13 Dec 2009 11:41:30 -0800 (PST) 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 6E4BE3A635F for ; Sun, 13 Dec 2009 11:41:30 -0800 (PST) Received: (qmail 1574 invoked from network); 13 Dec 2009 19:41:18 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 13 Dec 2009 11:41:17 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: i1UGuUoVM1mMLyBvjv_xAbZNGcK2GgTK2Sx2EPJBE0AEtSWd0jxDYK8xopqq9Dwld.qN7HMqeEE1c7lfUQ6mJIitnenf.KkMBNquah8V1_qnL2.qQuSJbc5n7Ue1geS0ANsziBniIrpJzkxpV9Mg0yze4B7yQyoGYFTNu7gt1cQMXJSzgqhD87bx5kAea2laliYlqVRrXX8THZsbqnHQr78CCHQGwhpHvM.kDI0P5c0O3SxqUcEaaeMsClNNythUPDy9Z0Ac1FSL6BVwhahsjVKOD7LRo7LbJFFW_uCKI3n.k2TLTAKWwMHV4iIQFA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B25437B.1050100@netconfcentral.com> Date: Sun, 13 Dec 2009 11:41:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B226B82.8090606@netconfcentral.com> <20091213.203306.94975409.mbj@tail-f.com> In-Reply-To: <20091213.203306.94975409.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2009 19:41:31 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> There was a request at the WG meeting to add text clarifying >> when import/include by revision should be used. >> The following text is proposed: >> >> sec 4.6, Header Contents, new para 2 and 3: >> >> If any modules are imported, then the same prefix value SHOULD >> be used, as defined in the imported module, unless there is >> another imported module already using that prefix. >> >> If any external typedefs or groupings are used, either imported >> from another module, or included from a submodule, then the >> revision date MUST be used in the import-stmt or include-stmt, >> to identify the specific revision of the external file. > > I don't think it is correct to require import by revision. If my > module imports ietf-inet-types and uses ipv6-address, why is it > important to lock down the revision? If a bug fix or clarification is > made in the future, I want my module to work with it. If we require > import by revision for all ietf modules, we will end up in a situation > where one bug fix ir clarification in one of the base module may > require reublishing all other ietf modules. > > If module B imports A (without revision), and there exist multiple > revisions of A, it is of course essential that a client knows which > version is implemented in the server, but that is already covered with > hello advertising (and schema discovery). > > I don't even think we should say SHOULD import by revision. It all > depends on what you are using from a module. > I disagree. It would be a significant change in IETF OPS-NM standards to publish an RFC that did not have static contents. The contents of data models MUST NOT drift over time. That may seem like a feature to you, but IMO it makes interoperability more difficult because the management objects that result from random imports may not be the same on any 2 implementations. > > > /martin > > > Andy From mbj@tail-f.com Sun Dec 13 11:59: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 45FD83A67E6 for ; Sun, 13 Dec 2009 11:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.133, 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 RMGO+vX52ETL for ; Sun, 13 Dec 2009 11:59:14 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4947C3A67E1 for ; Sun, 13 Dec 2009 11:59:14 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 17DA9616001; Sun, 13 Dec 2009 20:59:01 +0100 (CET) Date: Sun, 13 Dec 2009 20:59:00 +0100 (CET) Message-Id: <20091213.205900.252902877.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B25437B.1050100@netconfcentral.com> References: <4B226B82.8090606@netconfcentral.com> <20091213.203306.94975409.mbj@tail-f.com> <4B25437B.1050100@netconfcentral.com> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2009 19:59:15 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> There was a request at the WG meeting to add text clarifying > >> when import/include by revision should be used. > >> The following text is proposed: > >> > >> sec 4.6, Header Contents, new para 2 and 3: > >> > >> If any modules are imported, then the same prefix value SHOULD > >> be used, as defined in the imported module, unless there is > >> another imported module already using that prefix. > >> > >> If any external typedefs or groupings are used, either imported > >> from another module, or included from a submodule, then the > >> revision date MUST be used in the import-stmt or include-stmt, > >> to identify the specific revision of the external file. > > > > I don't think it is correct to require import by revision. If my > > module imports ietf-inet-types and uses ipv6-address, why is it > > important to lock down the revision? If a bug fix or clarification is > > made in the future, I want my module to work with it. If we require > > import by revision for all ietf modules, we will end up in a situation > > where one bug fix ir clarification in one of the base module may > > require reublishing all other ietf modules. > > > > If module B imports A (without revision), and there exist multiple > > revisions of A, it is of course essential that a client knows which > > version is implemented in the server, but that is already covered with > > hello advertising (and schema discovery). > > > > I don't even think we should say SHOULD import by revision. It all > > depends on what you are using from a module. > > > > I disagree. > It would be a significant change in IETF OPS-NM standards > to publish an RFC that did not have static contents. > > The contents of data models MUST NOT drift over time. You seem to assume that the contents of the _imported_ module drift over time. Are there any examples of problems because of this in (IETF MIBs for) SNMP? /martin From andy@netconfcentral.com Sun Dec 13 12:07: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 EB9DF3A6939 for ; Sun, 13 Dec 2009 12:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 10UXOalrfnEo for ; Sun, 13 Dec 2009 12:07:14 -0800 (PST) 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 2CFB83A680D for ; Sun, 13 Dec 2009 12:07:14 -0800 (PST) Received: (qmail 55285 invoked from network); 13 Dec 2009 20:07:00 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 13 Dec 2009 12:06:59 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: An7gelEVM1l.jrbjXHX5WkqsI756I.SVvaXPIAQVzacRVinj2fDaDpR_8VAZh44kTBcJB9FAGLXsT8CJE8WsslqfoC7hQNbB4JhTgv3nVjGFaPajHtS2ek.MN138VOTRg716mCgaKgVlWFzIDz2MbUyZRAEavnXWhiQFqLn4rpsvIbyLGPfF7zzKZoKRV6SssXUY.1GjRQ1yuOxGR8VwBTdd5yovr0mU80nnLN5tmcsvpgunJaFIOZUAp6Sqkb0dRfWdYrs6gSb0ml0DZ.WLOhHzEn_reh5a9YrU1B18No74_RhJNE5KvTXNN9cxNQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B254981.5030308@netconfcentral.com> Date: Sun, 13 Dec 2009 12:07:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B226B82.8090606@netconfcentral.com> <20091213.203306.94975409.mbj@tail-f.com> <4B25437B.1050100@netconfcentral.com> <20091213.205900.252902877.mbj@tail-f.com> In-Reply-To: <20091213.205900.252902877.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2009 20:07:15 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> There was a request at the WG meeting to add text clarifying >>>> when import/include by revision should be used. >>>> The following text is proposed: >>>> >>>> sec 4.6, Header Contents, new para 2 and 3: >>>> >>>> If any modules are imported, then the same prefix value SHOULD >>>> be used, as defined in the imported module, unless there is >>>> another imported module already using that prefix. >>>> >>>> If any external typedefs or groupings are used, either imported >>>> from another module, or included from a submodule, then the >>>> revision date MUST be used in the import-stmt or include-stmt, >>>> to identify the specific revision of the external file. >>> I don't think it is correct to require import by revision. If my >>> module imports ietf-inet-types and uses ipv6-address, why is it >>> important to lock down the revision? If a bug fix or clarification is >>> made in the future, I want my module to work with it. If we require >>> import by revision for all ietf modules, we will end up in a situation >>> where one bug fix ir clarification in one of the base module may >>> require reublishing all other ietf modules. >>> >>> If module B imports A (without revision), and there exist multiple >>> revisions of A, it is of course essential that a client knows which >>> version is implemented in the server, but that is already covered with >>> hello advertising (and schema discovery). >>> >>> I don't even think we should say SHOULD import by revision. It all >>> depends on what you are using from a module. >>> >> I disagree. >> It would be a significant change in IETF OPS-NM standards >> to publish an RFC that did not have static contents. >> >> The contents of data models MUST NOT drift over time. > > You seem to assume that the contents of the _imported_ module drift > over time. You seem to assume they won't. You seem to assume that even if they did, it would be a good thing for standards-track YANG modules. > > Are there any examples of problems because of this in (IETF MIBs for) > SNMP? > SMIv2 doesn't have groupings, and changes allowed to TEXTUAL-CONVENTION are extremely limited. SMIv2 has explicit conformance statements, so it is possible to define the module revision requirements in a precise and static manner. > > /martin > > > Andy From mbj@tail-f.com Sun Dec 13 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 537773A6951 for ; Sun, 13 Dec 2009 13:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.129, 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 T4+AFitW5zeW for ; Sun, 13 Dec 2009 13:14:46 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3283D3A6915 for ; Sun, 13 Dec 2009 13:14:46 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7ECB0616001; Sun, 13 Dec 2009 22:14:32 +0100 (CET) Date: Sun, 13 Dec 2009 22:14:31 +0100 (CET) Message-Id: <20091213.221431.40424153.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B254981.5030308@netconfcentral.com> References: <4B25437B.1050100@netconfcentral.com> <20091213.205900.252902877.mbj@tail-f.com> <4B254981.5030308@netconfcentral.com> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2009 21:14:47 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> Hi, > >>>> > >>>> There was a request at the WG meeting to add text clarifying > >>>> when import/include by revision should be used. > >>>> The following text is proposed: > >>>> > >>>> sec 4.6, Header Contents, new para 2 and 3: > >>>> > >>>> If any modules are imported, then the same prefix value SHOULD > >>>> be used, as defined in the imported module, unless there is > >>>> another imported module already using that prefix. > >>>> > >>>> If any external typedefs or groupings are used, either imported > >>>> from another module, or included from a submodule, then the > >>>> revision date MUST be used in the import-stmt or include-stmt, > >>>> to identify the specific revision of the external file. > >>> I don't think it is correct to require import by revision. If my > >>> module imports ietf-inet-types and uses ipv6-address, why is it > >>> important to lock down the revision? I would like to know your opinion on this. I think this is a common use case. > >>> I don't even think we should say SHOULD import by revision. It all > >>> depends on what you are using from a module. > >>> > >> I disagree. > >> It would be a significant change in IETF OPS-NM standards > >> to publish an RFC that did not have static contents. > >> > >> The contents of data models MUST NOT drift over time. > > > > You seem to assume that the contents of the _imported_ module drift > > over time. > > You seem to assume they won't. On the contrary; if an ietf module is not allowed to drift over time it is safe to use a typedef like ipv6-address without import by revision. > You seem to assume that even if they did, it would be > a good thing for standards-track YANG modules. No. > > Are there any examples of problems because of this in (IETF MIBs for) > > SNMP? > > > > SMIv2 doesn't have groupings This question is about typedefs. If a grouping is imported, I agree that import-by revision is probably correct in most cases. > and changes allowed > to TEXTUAL-CONVENTION are extremely limited. How is it different from what is allowed with a typedef in YANG? > SMIv2 has explicit conformance statements, so it is > possible to define the module revision requirements in a > precise and static manner. Can I require that a specific revision of a MIB module with a TEXTUAL-CONVENTION that I IMPORT be implemented if my module is implemented? Are you saying that no, there have not been such problems in SNMP, but only because of the strict rules? /martin From mbj@tail-f.com Sun Dec 13 13:28: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 EA8CD3A6853 for ; Sun, 13 Dec 2009 13:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=-1.082, 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 ZSaf9DW3rdvB for ; Sun, 13 Dec 2009 13:28:37 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 318E23A6452 for ; Sun, 13 Dec 2009 13:28:37 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 264D4616001; Sun, 13 Dec 2009 22:28:24 +0100 (CET) Date: Sun, 13 Dec 2009 22:28:23 +0100 (CET) Message-Id: <20091213.222823.188063071.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1260439565.21259.113.camel@missotis> References: <20091210.104103.32610959.mbj@tail-f.com> <20091210095538.GA61812@elstar.local> <1260439565.21259.113.camel@missotis> X-Mailer: Mew version 6.2.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-09; 7.19.5 when-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: Sun, 13 Dec 2009 21:28:38 -0000 Hi, Ladislav Lhotka wrote: > I propose these changes: [...] It seems you propose two things: 1. Introduce the term "grammatical constraint" and classify mandatory and presence as grammatical contraints. 2. Say that "when" MUST NOT be present on "mandatory" nodes. You say that a grammatical constraint MUST be unconditionally satisfied. This is not correct. They do not need to be satisfied in the candidate or in an edit-config PDU. As for 2, if that is what we want to do, we should say that explicitly. But if we do that, we take away the possibility to do data models like: leaf-list version { type enumeratoin { enum v1; enum v2c; enum v3; } } leaf engine-id { when "../version = 'v3'"; mandatory true; ... } /martin From phil@juniper.net Sun Dec 13 19:15: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 4A5513A68D2 for ; Sun, 13 Dec 2009 19:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 eKlxb8AuvkJY for ; Sun, 13 Dec 2009 19:15:02 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 74C083A657C for ; Sun, 13 Dec 2009 19:15:01 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSyWtqHw/YwdNs9iQDfART4yIe99g9RO5@postini.com; Sun, 13 Dec 2009 19:14:50 PST 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.393.1; Sun, 13 Dec 2009 19:11:57 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Dec 2009 19:11:57 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Dec 2009 19:11:57 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Dec 2009 19:11:56 -0800 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 nBE3Btj28022; Sun, 13 Dec 2009 19:11:55 -0800 (PST) (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 nBE2w6GU038814; Mon, 14 Dec 2009 02:58:07 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912140258.nBE2w6GU038814@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B2540B0.5000902@netconfcentral.com> Date: Sun, 13 Dec 2009 21:58:06 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Dec 2009 03:11:56.0716 (UTC) FILETIME=[317DE6C0:01CA7C6B] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 03:15:03 -0000 Andy Bierman writes: >The decision to encode as an attribute seems >completely arbitrary and pointless. It is based on expected use and content. >Memorizing the table of hard-wired values >in the draft seems like a waste of time. You are not required to comment them to memory. Any tests or quizes will be open book. >I also find the arbitrary names picked for >the argument strings to be pointless and >a just more CLRs. Every one of them >could be called and it would >make YIN easier to understand. These >arbitrary argument names disappear in YANG. The name is meant to be meaninful and to match the use. >YIN should always use elements and not attributes. >That would simplify encoding, reduce YANG CLRs, >reduce implementation complexity, and simplify the >extension-stmt (no need for yin-element sub-statement). -1. Leave it as is. Ship this baby. Thanks, Phil From andy@netconfcentral.com Sun Dec 13 19:42: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 532F53A6986 for ; Sun, 13 Dec 2009 19:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 hxCxAgs7aEFN for ; Sun, 13 Dec 2009 19:42:54 -0800 (PST) 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 876103A6983 for ; Sun, 13 Dec 2009 19:42:54 -0800 (PST) Received: (qmail 20730 invoked from network); 14 Dec 2009 03:42:39 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 13 Dec 2009 19:42:39 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 1pDkqssVM1loC7sXONZoqXo5tvlTBVgRSVIsMr9sxXAXeGbqW9BkF1csm45ZNsvgyPzg_KfMFUqGaCuAzcGdIqx.X6TCyDFoFveWjIw28Q5KpFMXq4yeHLdMrFKrQQ2NlHcdsPm5MHi5Rq6bHMWdys0BxuRWKHkKdMXDMQo0mXf5jm5h5lvSubn5_gRF1hTEBER3PffZq66UFd.XfK9ttkStq4PYk5H05EKBj3CTTPCoRrHNru593tPwuxmAN9vP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B25B450.7040703@netconfcentral.com> Date: Sun, 13 Dec 2009 19:43:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912140258.nBE2w6GU038814@idle.juniper.net> In-Reply-To: <200912140258.nBE2w6GU038814@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 03:42:55 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The decision to encode as an attribute seems >> completely arbitrary and pointless. > > It is based on expected use and content. > >> Memorizing the table of hard-wired values >> in the draft seems like a waste of time. > > You are not required to comment them to memory. Any > tests or quizes will be open book. > Yes, but only because I never intend to write modules in YIN. Since the WG thinks it is important to type modules in XML, they intend for YANG authors to memorize these pointless and arbitrary choices. >> I also find the arbitrary names picked for >> the argument strings to be pointless and >> a just more CLRs. Every one of them >> could be called and it would >> make YIN easier to understand. These >> arbitrary argument names disappear in YANG. > > The name is meant to be meaninful and to > match the use. > it is neither the use is a plain old argument string with no name in YANG. Adding arbitrary names to memorize in YIN is poor engineering. >> YIN should always use elements and not attributes. >> That would simplify encoding, reduce YANG CLRs, >> reduce implementation complexity, and simplify the >> extension-stmt (no need for yin-element sub-statement). > > -1. Leave it as is. Ship this baby. > > Thanks, > Phil > Andy From randy_presuhn@mindspring.com Sun Dec 13 19:43: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 2C77B3A6983 for ; Sun, 13 Dec 2009 19:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=-0.990, 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 1+kk1IG+5eEE for ; Sun, 13 Dec 2009 19:43:03 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 671593A687F for ; Sun, 13 Dec 2009 19:43:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LS3ZLIhJOGGydUuie2PegNX8HxRKpu8+OwIVXBy+OiC5JRKqjag1bULitHAHxCQW; 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 [76.254.55.58] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NK1pi-0005Qd-Cm for netmod@ietf.org; Sun, 13 Dec 2009 22:42:50 -0500 Message-ID: <002f01ca7c6f$c50c1d40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4B25437B.1050100@netconfcentral.com><20091213.205900.252902877.mbj@tail-f.com><4B254981.5030308@netconfcentral.com> <20091213.221431.40424153.mbj@tail-f.com> Date: Sun, 13 Dec 2009 19:44:40 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b409a8f530a07c455c35f95a714b39a6f7a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.55.58 Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 03:43:04 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Sunday, December 13, 2009 1:14 PM > Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision ... > Can I require that a specific revision of a MIB module with a > TEXTUAL-CONVENTION that I IMPORT be implemented if my module is > implemented? No, but the rules governing the possible changes to a MIB module make this unnecessary. > Are you saying that no, there have not been such problems in SNMP, but > only because of the strict rules? That's generally the case. - - - A comment on the notion of having lots of common definitions in a few common "library" modules - that was the idea behind ISO 10165-2. Not recommended. GDMO's change rules were more flexible than SNMP's, but not as loose as Yang's. This was enough to make versioning necessary, and made "library churn", especially of the supporting ASN.1 modules, a real problem. In retrospect, we would have been better off putting each "typedef" in its own module (which all might still "live" in the same standard), so that a tweak or bug fix wouldn't have forced cascading recompiles of everything under the sun. It's ultimately easier to manage an enormous number of incredibly simple modules than a smaller number of unwieldy ones. Randy From phil@juniper.net Sun Dec 13 20:15: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 7E55B3A68B7 for ; Sun, 13 Dec 2009 20:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 zjoVwiURZsqK for ; Sun, 13 Dec 2009 20:15:13 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id E03FA3A6999 for ; Sun, 13 Dec 2009 20:15:12 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSyW7w4ZebZcj7AiIuIV1ggH+tXBPWxgH@postini.com; Sun, 13 Dec 2009 20:15:01 PST 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.393.1; Sun, 13 Dec 2009 20:13:19 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Dec 2009 20:13:19 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Dec 2009 20:13:19 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Dec 2009 20:13:18 -0800 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 nBE4DHj51988; Sun, 13 Dec 2009 20:13:17 -0800 (PST) (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 nBE3xSlh039920; Mon, 14 Dec 2009 03:59:28 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912140359.nBE3xSlh039920@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B25B450.7040703@netconfcentral.com> Date: Sun, 13 Dec 2009 22:59:28 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Dec 2009 04:13:18.0637 (UTC) FILETIME=[C41675D0:01CA7C73] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 04:15:14 -0000 Andy Bierman writes: >Yes, but only because I never intend >to write modules in YIN. Since the WG >thinks it is important to type modules in XML, >they intend for YANG authors to memorize >these pointless and arbitrary choices. I won't speak for the WG, but there should be no assumption that "it is important to type modules in XML". The comments in the arch draft talk about how this is used when XML parsers are the only choice. The plan is that humans (including YANG authors) will use the YANG format but can use a distinct/offline YANG parser to make YIN that can be used in places where XML parsers are more easily available. Thanks, Phil From mbj@tail-f.com Mon Dec 14 00:27: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 39E453A6958 for ; Mon, 14 Dec 2009 00:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, 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 glBNgy45pYad for ; Mon, 14 Dec 2009 00:27:33 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6B5363A680C for ; Mon, 14 Dec 2009 00:27:33 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3FC2E616006; Mon, 14 Dec 2009 09:27:19 +0100 (CET) Date: Mon, 14 Dec 2009 09:27:18 +0100 (CET) Message-Id: <20091214.092718.97565918.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <002f01ca7c6f$c50c1d40$6801a8c0@oemcomputer> References: <4B254981.5030308@netconfcentral.com> <20091213.221431.40424153.mbj@tail-f.com> <002f01ca7c6f$c50c1d40$6801a8c0@oemcomputer> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 08:27:34 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Sunday, December 13, 2009 1:14 PM > > Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision > ... > > Can I require that a specific revision of a MIB module with a > > TEXTUAL-CONVENTION that I IMPORT be implemented if my module is > > implemented? > > No, but the rules governing the possible changes to a MIB module make > this unnecessary. > > > Are you saying that no, there have not been such problems in SNMP, but > > only because of the strict rules? > > That's generally the case. Ok, so which rules in YANG make this problematic (rules for typedefs)? /martin From bertietf@bwijnen.net Mon Dec 14 00:51: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 73E763A69B8 for ; Mon, 14 Dec 2009 00:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=1.768, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH+aU7qqthA6 for ; Mon, 14 Dec 2009 00:51:56 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id A3C943A67CF for ; Mon, 14 Dec 2009 00:51:56 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NK6ea-0006EI-0k for netmod@ietf.org; Mon, 14 Dec 2009 09:51:40 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id 034522F583 for ; Mon, 14 Dec 2009 09:51:40 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=guest-30.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NK6eZ-0007rz-UU for netmod@ietf.org; Mon, 14 Dec 2009 09:51:39 +0100 Message-ID: <4B25FC9B.4010908@bwijnen.net> Date: Mon, 14 Dec 2009 09:51:39 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: NETMOD Working Group References: <4B226B82.8090606@netconfcentral.com> <20091211180741.GB3925@elstar.local> In-Reply-To: <20091211180741.GB3925@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4744b3fa92a193c2afb50b41afc883707 Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 08:51:57 -0000 Yang Experts for YANG expert review? Bert Juergen Schoenwaelder wrote: > On Fri, Dec 11, 2009 at 04:55:46PM +0100, Andy Bierman wrote: > > >> Currently, not one YANG module I have ever seen has used >> import-by-revision, so this guideline is not being followed at all. >> The import-without-revision is extremely fragile for groupings, >> typedefs, and defaults. This isn't like SMIv2 at all.] >> > > So far, I have not seen any _published_ YANG module - all we have are > moving targets. But, yes, we need proper tools to check for such > things when documents go through the YANG review cycle (I am avoiding > the term "YANG doctors" - would be nice to have a better sounding name > since it is much easier to sell that I spent time on the Security > Directorate than it is to sell time spent as a MIB Doctor). > > /js > > From andy@netconfcentral.com Mon Dec 14 03:55: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 246783A69F9 for ; Mon, 14 Dec 2009 03:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 Ijel+CuKnBUM for ; Mon, 14 Dec 2009 03:55:00 -0800 (PST) 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 7DB783A69E5 for ; Mon, 14 Dec 2009 03:55:00 -0800 (PST) Received: (qmail 43081 invoked from network); 14 Dec 2009 11:54:45 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 14 Dec 2009 03:54:45 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: jy41wEEVM1kZZhq8aqpra3B_sZXnAvGONKAaWSwnY6rX8gVwrtgeeg4v9li4KrFF.OtIFxoc67FQ0e80VfyAzxXEc1H9TRfxo62kSVZAHO1GH1OO3zZ1BOoepU.Safa7vDPduYxH.RaQXKUzxT55jYCZsytodS8kEqXifLmoRiXymSfpt.FMo72ra4wuM_mfl36RQ0o.AGUqiLKb_kc9HPgdF0Rc1By6toN9ns4sB9iYJfN8bsWt7xi0En9lWrk_lFhRA8oh70pe.UEfAcsEr5egaaEzOw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2627A9.2040704@netconfcentral.com> Date: Mon, 14 Dec 2009 03:55:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B254981.5030308@netconfcentral.com> <20091213.221431.40424153.mbj@tail-f.com> <002f01ca7c6f$c50c1d40$6801a8c0@oemcomputer> <20091214.092718.97565918.mbj@tail-f.com> In-Reply-To: <20091214.092718.97565918.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 11:55:01 -0000 Martin Bjorklund wrote: > "Randy Presuhn" wrote: >> Hi - >> >>> From: "Martin Bjorklund" >>> To: >>> Cc: >>> Sent: Sunday, December 13, 2009 1:14 PM >>> Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision >> ... >>> Can I require that a specific revision of a MIB module with a >>> TEXTUAL-CONVENTION that I IMPORT be implemented if my module is >>> implemented? >> No, but the rules governing the possible changes to a MIB module make >> this unnecessary. >> >>> Are you saying that no, there have not been such problems in SNMP, but >>> only because of the strict rules? >> That's generally the case. > > Ok, so which rules in YANG make this problematic (rules for typedefs)? > Any change to a machine-readable clause could cause the typedef definition to change. Adding a default, changing a pattern, changing a range, etc. Even changing the semantics in the description clause is tightly controlled in SNMP. > > /martin Andy From andy@netconfcentral.com Mon Dec 14 04:00: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 84A663A6863 for ; Mon, 14 Dec 2009 04:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 4V8165sFW4Wh for ; Mon, 14 Dec 2009 04:00:56 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id C557A3A6892 for ; Mon, 14 Dec 2009 04:00:56 -0800 (PST) Received: (qmail 43575 invoked from network); 14 Dec 2009 12:00:41 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 14 Dec 2009 04:00:41 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: n.BTV_AVM1mbfuF266BYdrng9UpSZaC3LvPMWdsU5_Wu6IiAjDrRlpofedGLPoacaik1BlNBKVVVCee3MgOVeBbIbpv0kmiUo4WKjjJ.Q1z2JprK0blF_2H4FguzDBE3G_PnmOH9i.jtf8ITEd5h7WeOZ_.Wmle.4NONwf2pMKwQpdYIsuMdMEnHV6dQ0qHfO2EVe8tu08LPlbQjDFkUqY6x6psNS6YxsbnkjAt749zgcQqigvwkiZcLBvi4Oh27rA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B26290D.3000105@netconfcentral.com> Date: Mon, 14 Dec 2009 04:01:17 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912140359.nBE3xSlh039920@idle.juniper.net> In-Reply-To: <200912140359.nBE3xSlh039920@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 12:00:57 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Yes, but only because I never intend >> to write modules in YIN. Since the WG >> thinks it is important to type modules in XML, >> they intend for YANG authors to memorize >> these pointless and arbitrary choices. > > I won't speak for the WG, but there should be no assumption that > "it is important to type modules in XML". The comments in the arch > draft talk about how this is used when XML parsers are the only > choice. The plan is that humans (including YANG authors) will use > the YANG format but can use a distinct/offline YANG parser to make > YIN that can be used in places where XML parsers are more easily > available. > Well, IMO YIN is not important enough to worry about. Certainly not worth the trouble of implementing it. Nobody is going to use it, so the fact that it is poorly engineered is not that important. What a win! If it's just for machine translation, then the arbitrary choices are especially useless. Machines like boring, predictable, simple patterns, not ad-hoc, hard-wired tables that require the extension-stmts from all the imported modules to be parsed. > Thanks, > Phil > Andy From mbj@tail-f.com Mon Dec 14 04:09: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 000323A68AB for ; Mon, 14 Dec 2009 04:09:33 -0800 (PST) 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.055, 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 Zqr2l4+8YwlM for ; Mon, 14 Dec 2009 04:09:33 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2037D3A659C for ; Mon, 14 Dec 2009 04:09:33 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C741F616006; Mon, 14 Dec 2009 13:09:18 +0100 (CET) Date: Mon, 14 Dec 2009 13:09:18 +0100 (CET) Message-Id: <20091214.130918.165190776.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B2627A9.2040704@netconfcentral.com> References: <002f01ca7c6f$c50c1d40$6801a8c0@oemcomputer> <20091214.092718.97565918.mbj@tail-f.com> <4B2627A9.2040704@netconfcentral.com> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 12:09:34 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > "Randy Presuhn" wrote: > >> Hi - > >> > >>> From: "Martin Bjorklund" > >>> To: > >>> Cc: > >>> Sent: Sunday, December 13, 2009 1:14 PM > >>> Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision > >> ... > >>> Can I require that a specific revision of a MIB module with a > >>> TEXTUAL-CONVENTION that I IMPORT be implemented if my module is > >>> implemented? > >> No, but the rules governing the possible changes to a MIB module make > >> this unnecessary. > >> > >>> Are you saying that no, there have not been such problems in SNMP, but > >>> only because of the strict rules? > >> That's generally the case. > > > > Ok, so which rules in YANG make this problematic (rules for typedefs)? > > > > > Any change to a machine-readable clause could cause the typedef > definition to change. > > Adding a default This is not allowed in YANG. > changing a pattern, > changing a range, etc. In SMI, it is legal to expand the value space if the object is an enumerated integer or bits. In YANG it is legal to expand the value space for any type. Is this difference the reason we need to require import by revision for typedefs in YANG but not in SMI? > Even changing the semantics in > the description clause is tightly controlled in SNMP. Same in YANG. In fact, the YANG text is copied from RFC 2578 (2579 has different words). /martin From lhotka@cesnet.cz Mon Dec 14 06:10: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 17DD73A68D4 for ; Mon, 14 Dec 2009 06:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5OtjE2r6shL for ; Mon, 14 Dec 2009 06:10:40 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5B5C53A68B8 for ; Mon, 14 Dec 2009 06:10:39 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D558BD80096 for ; Mon, 14 Dec 2009 15:10:25 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4B2540B0.5000902@netconfcentral.com> References: <4B2540B0.5000902@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 14 Dec 2009 15:10:24 +0100 Message-ID: <1260799824.1825.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 14:10:42 -0000 Andy Bierman píše v Ne 13. 12. 2009 v 11:29 -0800: > Hi, > > Now that I am bothering to implement YIN, > I can't help notice that it is a CLR factory. > I cannot find any meaningful rationale for > picking yin-element == true or false. > The decision to encode as an attribute seems > completely arbitrary and pointless. > Memorizing the table of hard-wired values > in the draft seems like a waste of time. I don't agree, it is very consistent. yin-element is used only in those cases where the text might be inappropriately modified by the standard XML attribute normalization. I am using YIN as the primary source format for writing YANG modules and I like the current status. Of course, we could ignite another flame war regarding elements versus attributes but IMO it is irrelevant. Lada > > I also find the arbitrary names picked for > the argument strings to be pointless and > a just more CLRs. Every one of them > could be called and it would > make YIN easier to understand. These > arbitrary argument names disappear in YANG. > > YIN should always use elements and not attributes. > That would simplify encoding, reduce YANG CLRs, > reduce implementation complexity, and simplify the > extension-stmt (no need for yin-element sub-statement). > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Dec 14 06:26:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA663A680B for ; Mon, 14 Dec 2009 06:26:46 -0800 (PST) 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 UYWWiV5wHtvp for ; Mon, 14 Dec 2009 06:26:45 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 285483A67A7 for ; Mon, 14 Dec 2009 06:26:45 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E846ED80095; Mon, 14 Dec 2009 15:26:31 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B25B450.7040703@netconfcentral.com> References: <200912140258.nBE2w6GU038814@idle.juniper.net> <4B25B450.7040703@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 14 Dec 2009 15:26:30 +0100 Message-ID: <1260800790.1825.44.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 14:26:46 -0000 Andy Bierman píše v Ne 13. 12. 2009 v 19:43 -0800: > Phil Shafer wrote: > > Andy Bierman writes: > >> The decision to encode as an attribute seems > >> completely arbitrary and pointless. > > > > It is based on expected use and content. > > > >> Memorizing the table of hard-wired values > >> in the draft seems like a waste of time. > > > > You are not required to comment them to memory. Any > > tests or quizes will be open book. > > > > Yes, but only because I never intend > to write modules in YIN. Since the WG > thinks it is important to type modules in XML, > they intend for YANG authors to memorize > these pointless and arbitrary choices. I guess writing YIN (or any XML, for that matter) makes sense only with a schema-aware editor. I am using emacs with nxml-mode and don't need to memorize anything. And it is considerably faster than writing YANG compact syntax. Lada > > > >> I also find the arbitrary names picked for > >> the argument strings to be pointless and > >> a just more CLRs. Every one of them > >> could be called and it would > >> make YIN easier to understand. These > >> arbitrary argument names disappear in YANG. > > > > The name is meant to be meaninful and to > > match the use. > > > > > it is neither > > the use is a plain old argument string > with no name in YANG. Adding arbitrary names to > memorize in YIN is poor engineering. > > >> YIN should always use elements and not attributes. > >> That would simplify encoding, reduce YANG CLRs, > >> reduce implementation complexity, and simplify the > >> extension-stmt (no need for yin-element sub-statement). > > > > -1. Leave it as is. Ship this baby. > > > > Thanks, > > Phil > > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Dec 14 06:42:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3550D3A680B for ; Mon, 14 Dec 2009 06:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.879, 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 R1EBYrbLOluS for ; Mon, 14 Dec 2009 06:42:20 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 644C43A6781 for ; Mon, 14 Dec 2009 06:42:20 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A04A9616006; Mon, 14 Dec 2009 15:42:05 +0100 (CET) Date: Mon, 14 Dec 2009 15:42:05 +0100 (CET) Message-Id: <20091214.154205.60759140.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1260799824.1825.38.camel@missotis> References: <4B2540B0.5000902@netconfcentral.com> <1260799824.1825.38.camel@missotis> X-Mailer: Mew version 6.2.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] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 14:42:21 -0000 Ladislav Lhotka wrote: > I like the current status. Of course, we could ignite another flame war > regarding elements versus attributes but IMO it is irrelevant. I also think it is good enough as it is. /martin From lhotka@cesnet.cz Mon Dec 14 07:20: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 E7C083A68F1 for ; Mon, 14 Dec 2009 07:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=-0.630, 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 OyvHrI-qjWgX for ; Mon, 14 Dec 2009 07:20:35 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D4CE03A68EA for ; Mon, 14 Dec 2009 07:20:34 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0913FD80095; Mon, 14 Dec 2009 16:20:21 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091213.222823.188063071.mbj@tail-f.com> References: <20091210.104103.32610959.mbj@tail-f.com> <20091210095538.GA61812@elstar.local> <1260439565.21259.113.camel@missotis> <20091213.222823.188063071.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 14 Dec 2009 16:20:19 +0100 Message-ID: <1260804019.1825.92.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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, 14 Dec 2009 15:20:36 -0000 Martin Bjorklund píše v Ne 13. 12. 2009 v 22:28 +0100: > Hi, > > Ladislav Lhotka wrote: > > I propose these changes: > > [...] > > It seems you propose two things: > > 1. Introduce the term "grammatical constraint" and classify > mandatory and presence as grammatical contraints. Yes, because they can be determined only from the YANG module(s) and advertised features and put to the schema, unlike 'when' and 'must'. > > 2. Say that "when" MUST NOT be present on "mandatory" nodes. Such a CLR is not necessary. There can be no race condition or interoperability problem if someone does so. Right, it doesn't seem to make much sense, but the semantic constraints can be screwed up in many ways - in contrary to the grammatical constraints. > > > You say that a grammatical constraint MUST be unconditionally > satisfied. This is not correct. They do not need to be satisfied in > the candidate or in an edit-config PDU. The grammar/schema of candidate or edit-config is certainly different from that of running or startup. But actually by "unconditional" I mean that such a constraint is independent of the instance document and cannot be overriden by the semantic constraints. Of course, a better adjective may be used. > > As for 2, if that is what we want to do, we should say that > explicitly. But if we do that, we take away the possibility to do > data models like: > > leaf-list version { > type enumeratoin { > enum v1; > enum v2c; > enum v3; > } > } > > leaf engine-id { > when "../version = 'v3'"; > mandatory true; > ... > } > No, we don't: must "engine-id and version = 'v3' or " + "version != 'v3' and not(engine-id)"; leaf engine-id { ... } (engine-id is not mandatory here) I understand 'when' only as kind of syntactic sugar that can always be replaced by a 'must' expression (perhaps more complicated, as it is here). Lada > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Dec 14 07:24: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 7EBD728C125 for ; Mon, 14 Dec 2009 07:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 hh3LO0pr0rxX for ; Mon, 14 Dec 2009 07:24:28 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 7F41828C124 for ; Mon, 14 Dec 2009 07:24:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSyZYm2CTL9rY5aoGW2vdUg3XqTyLzVdz@postini.com; Mon, 14 Dec 2009 07:24:16 PST 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.393.1; Mon, 14 Dec 2009 07:20:18 -0800 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, 14 Dec 2009 07:20:17 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 07:20:17 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 07:20:15 -0800 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 nBEFKEj50148; Mon, 14 Dec 2009 07:20:14 -0800 (PST) (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 nBEF6OPo043635; Mon, 14 Dec 2009 15:06:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912141506.nBEF6OPo043635@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091214.154205.60759140.mbj@tail-f.com> Date: Mon, 14 Dec 2009 10:06:24 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Dec 2009 15:20:15.0289 (UTC) FILETIME=[EFDEFA90:01CA7CD0] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 15:24:29 -0000 Martin Bjorklund writes: >Ladislav Lhotka wrote: >> I like the current status. Of course, we could ignite another flame war >> regarding elements versus attributes but IMO it is irrelevant. >I also think it is good enough as it is. Amen. Ship it. Thanks, Phil From phil@juniper.net Mon Dec 14 07:47: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 4DE173A686E for ; Mon, 14 Dec 2009 07:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 8BO08vq3obhr for ; Mon, 14 Dec 2009 07:47:39 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 4A7473A67A6 for ; Mon, 14 Dec 2009 07:47:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSyZeCZHeibDt4XrrTi47CtJHpYsOXFvq@postini.com; Mon, 14 Dec 2009 07:47:26 PST 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.393.1; Mon, 14 Dec 2009 07:43:21 -0800 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, 14 Dec 2009 07:43:21 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 07:43:21 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 07:43:20 -0800 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 nBEFhIj61784; Mon, 14 Dec 2009 07:43:18 -0800 (PST) (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 nBEFTS6j044572; Mon, 14 Dec 2009 15:29:28 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912141529.nBEFTS6j044572@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1260804019.1825.92.camel@missotis> Date: Mon, 14 Dec 2009 10:29:28 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Dec 2009 15:43:20.0959 (UTC) FILETIME=[29CB70F0:01CA7CD4] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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, 14 Dec 2009 15:47:40 -0000 Ladislav Lhotka writes: >> 1. Introduce the term "grammatical constraint" and classify >> mandatory and presence as grammatical contraints. >Yes, because they can be determined only from the YANG module(s) and >advertised features and put to the schema, unlike 'when' and 'must'. I don't follow your meaning here. Can you elaborate? >> leaf engine-id { >> when "../version = 'v3'"; >> mandatory true; >> ... >> } > must "engine-id and version = 'v3' or " > + "version != 'v3' and not(engine-id)"; > leaf engine-id { > ... > } >I understand 'when' only as kind of syntactic sugar that can always be >replaced by a 'must' expression (perhaps more complicated, as it is >here). The "when" version carries more information that your "must" version and this information is vital to the smooth flow of the apps that will manipulate the config data. With the "when" version, my app can "grey out" the engine-id field unless the version field is set to "v3". If the user sets version to "v3", my app can know that engine-id is now mandatory so the user needs to provide a value. If the user sets version to "v2", my app knows that the engine-id field should not be set and should not be sent to the server. Instead of giving the user a copy of the must's error message, the app helps the user avoid the error completely. So saying that "when" is equivalent to "must" is not accurate. While both can describe the same constraints, using the appropriate mechanism will help tools channel users into better decisions and promote better data hygiene, reducing errors and making the world a better place. Thanks, Phil From lhotka@cesnet.cz Mon Dec 14 08:19: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 1FDA63A6A19 for ; Mon, 14 Dec 2009 08:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=0.316, 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 8wOBaNNnEEiT for ; Mon, 14 Dec 2009 08:19:30 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1A5E128C103 for ; Mon, 14 Dec 2009 08:19:27 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A1E9AD80095; Mon, 14 Dec 2009 17:19:13 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200912141529.nBEFTS6j044572@idle.juniper.net> References: <200912141529.nBEFTS6j044572@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 14 Dec 2009 17:19:12 +0100 Message-ID: <1260807552.1825.119.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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, 14 Dec 2009 16:19:31 -0000 Phil Shafer píše v Po 14. 12. 2009 v 10:29 -0500: > Ladislav Lhotka writes: > >> 1. Introduce the term "grammatical constraint" and classify > >> mandatory and presence as grammatical contraints. > >Yes, because they can be determined only from the YANG module(s) and > >advertised features and put to the schema, unlike 'when' and 'must'. > > I don't follow your meaning here. Can you elaborate? With mandatory and presence the occurrence constraint is known a priori and required for any instance document that conforms to a particular schema. With 'when' and 'must' the app may first have to parse the instance document and check some values in it in order to determine the schema. > > >> leaf engine-id { > >> when "../version = 'v3'"; > >> mandatory true; > >> ... > >> } > > must "engine-id and version = 'v3' or " > > + "version != 'v3' and not(engine-id)"; > > leaf engine-id { > > ... > > } > >I understand 'when' only as kind of syntactic sugar that can always be > >replaced by a 'must' expression (perhaps more complicated, as it is > >here). > > The "when" version carries more information that your "must" version > and this information is vital to the smooth flow of the apps that will > manipulate the config data. Sounds like marketing. :-) What is this "more information"? > > With the "when" version, my app can "grey out" the engine-id field > unless the version field is set to "v3". If the user sets version > to "v3", my app can know that engine-id is now mandatory so the > user needs to provide a value. If the user sets version to "v2", > my app knows that the engine-id field should not be set and should > not be sent to the server. Instead of giving the user a copy of > the must's error message, the app helps the user avoid the error > completely. I fail to see why the app couldn't do the same based on the 'must'. (I am not sure it is a good idea to let the server remove a part of the database after the manager changes a single value somewhere, but that's another story.) > > So saying that "when" is equivalent to "must" is not accurate. > While both can describe the same constraints, using the appropriate > mechanism will help tools channel users into better decisions and > promote better data hygiene, reducing errors and making the world > a better place. If 'when' were allowed to override the grammatical constraints, one would no more be able to write any schema that would validate all documents without false positives or negatives. Having a strict schema/grammar is essential exactly for the "better data hygiene". Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Dec 14 08:22: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 0E8D43A689E for ; Mon, 14 Dec 2009 08:22:43 -0800 (PST) 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.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 2FMY3n7ZTAwk for ; Mon, 14 Dec 2009 08:22:42 -0800 (PST) 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 847D93A68ED for ; Mon, 14 Dec 2009 08:22:39 -0800 (PST) Received: (qmail 59694 invoked from network); 14 Dec 2009 16:22:23 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 14 Dec 2009 08:22:22 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: x6UeboIVM1ltNAzGv9FxDruCNLCCtahzPcFIuKsUoKRkoA7agzFTzEGn0r3VbWIQ6p_eFA2dy97xIu8gqCjtwgBKXNwS4lXvSB.jH3lBXSnQa1oLBoke59fZ8jA6OV60LjvpE6cUIKuYjEX9bQ0j3_vmnJLk1LwHGBGs1TTBpbch7Pmb9s00CcPo26yBPwhdUng_ksepj4M87gsAcHYIRkM6_PnIVUnsUcwm9oUD5oqznNydyjXp5Fe6eVq8IDzfP0wuMCJNZCfmSktIsKICV1xZoQBVnlvpWuWjrjlEzNHF1iPgie_3 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B266665.2090806@netconfcentral.com> Date: Mon, 14 Dec 2009 08:23:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <002f01ca7c6f$c50c1d40$6801a8c0@oemcomputer> <20091214.092718.97565918.mbj@tail-f.com> <4B2627A9.2040704@netconfcentral.com> <20091214.130918.165190776.mbj@tail-f.com> In-Reply-To: <20091214.130918.165190776.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 16:22:43 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> "Randy Presuhn" wrote: >>>> Hi - >>>> >>>>> From: "Martin Bjorklund" >>>>> To: >>>>> Cc: >>>>> Sent: Sunday, December 13, 2009 1:14 PM >>>>> Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision >>>> ... >>>>> Can I require that a specific revision of a MIB module with a >>>>> TEXTUAL-CONVENTION that I IMPORT be implemented if my module is >>>>> implemented? >>>> No, but the rules governing the possible changes to a MIB module make >>>> this unnecessary. >>>> >>>>> Are you saying that no, there have not been such problems in SNMP, but >>>>> only because of the strict rules? >>>> That's generally the case. >>> Ok, so which rules in YANG make this problematic (rules for typedefs)? >>> >> >> Any change to a machine-readable clause could cause the typedef >> definition to change. >> >> Adding a default > > This is not allowed in YANG. making YANG default even more of a joke > >> changing a pattern, >> changing a range, etc. > > In SMI, it is legal to expand the value space if the object is an > enumerated integer or bits. In YANG it is legal to expand the value > space for any type. Is this difference the reason we need to require > import by revision for typedefs in YANG but not in SMI? > >> Even changing the semantics in >> the description clause is tightly controlled in SNMP. > > Same in YANG. In fact, the YANG text is copied from RFC 2578 (2579 > has different words). > I wll make the text say groupings MUST have import-by-revision and typedefs SHOULD have them. If you know for sure that the typedef will never be changed, then fine. Otherwise, IETF YANG module module writers need to use a revision date in the published module. > > /martin > Andy From andy@netconfcentral.com Mon Dec 14 08: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 4FB493A6900 for ; Mon, 14 Dec 2009 08:55:22 -0800 (PST) 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.235, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, UNPARSEABLE_RELAY=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 8xrYjYwCBwUM for ; Mon, 14 Dec 2009 08:55:21 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 8B37B3A6833 for ; Mon, 14 Dec 2009 08:55:21 -0800 (PST) Received: (qmail 77157 invoked from network); 14 Dec 2009 16:55:06 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 14 Dec 2009 08:55:06 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .yl5yqUVM1l8R_bEPKbFofyHh7y2Mcp_1FXTeNXWXUPyTAGTWIBJJbSn0ajMN7qH0HrhRU9uJPsSrkXmGDOoLYN4NKmiIvrYLBkL8enx_GODip.Zw4k.vPBjWoOckIXzuq9bGc.lYDxZ7Ovz3E4ocKUJc5EdZyWU6gpwH_EofMqQ3t6BG2JjYjIxUg4LmhP2CG1VYtgcilzevIIZwgPIlZ75Ibcoe8E8iYeP7NGVMpjEx7nIiFGyHdTcpNIXqC3v0yR5otKl5QLV6Y02OkrC0A9ZWIYKWU1FEPc6xufDRJl2aqlbSJiPCGeUvz3FfA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B266D94.3040600@netconfcentral.com> Date: Mon, 14 Dec 2009 08:53:40 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1C6E03.5070708@netconfcentral.com> <20091207.082255.88175214.mbj@tail-f.com> In-Reply-To: <20091207.082255.88175214.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09, sec 11.1, YIN mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 16:55:22 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Some of the YIN mapping rules seem rather random to me. >> >> Why is reference-stmt encoded as an attribute >> but description-stmt is encoded as a element? >> And contact, organization, etc. are encoded as an >> element? >> >> I propose that all the purely descriptive YANG statements >> that are unrestricted strings all be encoded as an >> element called . > > I agree. > >> OLD entries: >> >> | contact | info | true | >> | description | text | true | >> | error-message | value | true | >> | organization | info | true | >> | reference | info | false | >> >> >> NEW entries: >> >> | contact | text | true | >> | description | text | true | >> | error-message | text | true | >> | organization | text | true | >> | reference | text | true | >> >> >> This also allows the xml:lang attribute to be applied, if desired. > Are these changes going to be made? I think the table of arbitrary names and element/attributes is non-optimal, and YIN is over-engineered, but these are normal operating conditions in the IETF, so I will go back to ignoring the YIN syntax (like almost everybody else). > > /martin > Andy From phil@juniper.net Mon Dec 14 10: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 86A823A6904 for ; Mon, 14 Dec 2009 10:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 nSVVkdbYewNB for ; Mon, 14 Dec 2009 10:35:01 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id B64383A68F5 for ; Mon, 14 Dec 2009 10:35:00 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSyaFRd6YM2j/tSgBQ7TgZKyGnMy+J3Mb@postini.com; Mon, 14 Dec 2009 10:34:48 PST 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.393.1; Mon, 14 Dec 2009 10:32:35 -0800 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, 14 Dec 2009 10:32:35 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:32:34 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:32:33 -0800 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 nBEIWXj53719; Mon, 14 Dec 2009 10:32:33 -0800 (PST) (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 nBEIIhfM046901; Mon, 14 Dec 2009 18:18:43 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912141818.nBEIIhfM046901@idle.juniper.net> To: Andy Bierman In-Reply-To: <4B266D94.3040600@netconfcentral.com> Date: Mon, 14 Dec 2009 13:18:43 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Dec 2009 18:32:33.0858 (UTC) FILETIME=[CD64E220:01CA7CEB] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang-09, sec 11.1, YIN mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 18:35:03 -0000 Andy Bierman writes: >Are these changes going to be made? -1 for me. >I think the table of arbitrary names and element/attributes >is non-optimal, and YIN is over-engineered, but these are >normal operating conditions in the IETF, so I will go back >to ignoring the YIN syntax (like almost everybody else). You've said in previous emails that you "never intend to write modules in YIN", you think "YIN is not important enough to worry about", that it is "not worth the trouble of implementing", and that you think "Nobody is going to use it". I'm suspecting that you are not the target audience for YIN. Thanks, Phil From phil@juniper.net Mon Dec 14 10:42: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 8DBF43A690F for ; Mon, 14 Dec 2009 10:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 raX70CJdG12M for ; Mon, 14 Dec 2009 10:42:44 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 9C68F3A690B for ; Mon, 14 Dec 2009 10:42:44 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSyaHD1NwzF8Y/p1WHAOeyZWf6fTjFqcD@postini.com; Mon, 14 Dec 2009 10:42:32 PST 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.393.1; Mon, 14 Dec 2009 10:40:31 -0800 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, 14 Dec 2009 10:40:31 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:40:30 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:40:30 -0800 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 nBEIeMj57748; Mon, 14 Dec 2009 10:40:29 -0800 (PST) (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 nBEIQWku046987; Mon, 14 Dec 2009 18:26:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912141826.nBEIQWku046987@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1260807552.1825.119.camel@missotis> Date: Mon, 14 Dec 2009 13:26:32 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Dec 2009 18:40:30.0454 (UTC) FILETIME=[E977A960:01CA7CEC] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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, 14 Dec 2009 18:42:45 -0000 Ladislav Lhotka writes: >With mandatory and presence the occurrence constraint is known a priori >and required for any instance document that conforms to a particular >schema. With 'when' and 'must' the app may first have to parse the >instance document and check some values in it in order to determine the >schema. I find your use of "schema" here confusing. The schema is static information. It defines the hierarchy and containment. Mandatory, must, and when define constraints on the data modeled by that schema. "must" does not change the schema. >> The "when" version carries more information that your "must" version >> and this information is vital to the smooth flow of the apps that will >> manipulate the config data. > >Sounds like marketing. :-) What is this "more information"? I followed this claim with a paragraph explaining the information being carried, what can be done with it, and why I think it is important. If you want marketing, I'll add a claim that it's up to 20 times better or more. Thanks, Phil From andy@netconfcentral.com Mon Dec 14 11:20:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9EA28C14E for ; Mon, 14 Dec 2009 11:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 ym7K8MVqMzNd for ; Mon, 14 Dec 2009 11:20:19 -0800 (PST) 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 C6CE33A6956 for ; Mon, 14 Dec 2009 11:20:17 -0800 (PST) Received: (qmail 35455 invoked from network); 14 Dec 2009 19:19:56 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 14 Dec 2009 11:19:56 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: rkC.wlsVM1lU9Fu.D.OgYaURbaOK74nRVXGo_7uGboZx2hLlNmLVK5PalvoXU7jI.FlkKBIosDPa_dYcGqSVN2W2MaNQpL91P9UazuBXWh7g_mNxiqdGEjxbhGmFpmRBzfAqFbK9uhbNJaJHiWwcdRGgWYGOSYAyf3BzUBHa_.GljqO3W8cmN0jjbqd5BKptv2.ialRiQtOlmWC95oBu1LCQlBaLTQD3xQ1tbbdF5hqy08UalhD8qKP53GZouDTQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B269004.6070808@netconfcentral.com> Date: Mon, 14 Dec 2009 11:20:36 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912141818.nBEIIhfM046901@idle.juniper.net> In-Reply-To: <200912141818.nBEIIhfM046901@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09, sec 11.1, YIN mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 19:20:21 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Are these changes going to be made? > > -1 for me. > >> I think the table of arbitrary names and element/attributes >> is non-optimal, and YIN is over-engineered, but these are >> normal operating conditions in the IETF, so I will go back >> to ignoring the YIN syntax (like almost everybody else). > > You've said in previous emails that you "never intend to write > modules in YIN", you think "YIN is not important enough to worry > about", that it is "not worth the trouble of implementing", and > that you think "Nobody is going to use it". > > I'm suspecting that you are not the target audience for YIN. > right. I think the ratio between the effort put into YIN by the WG and its utility is already skewed in the wrong direction. I will drop the whole thing. I'm sorry I even bothered to read that section, let alone try to improve it. > Thanks, > Phil > Andy From mbj@tail-f.com Mon Dec 14 11:36: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 BE50B28C15F for ; Mon, 14 Dec 2009 11:36:30 -0800 (PST) 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.145, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=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 kgbqHub+u4Nf for ; Mon, 14 Dec 2009 11:36:30 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E7CB028C15C for ; Mon, 14 Dec 2009 11:36:29 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 08C0A616006; Mon, 14 Dec 2009 20:36:15 +0100 (CET) Date: Mon, 14 Dec 2009 20:36:14 +0100 (CET) Message-Id: <20091214.203614.147579351.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B266D94.3040600@netconfcentral.com> References: <4B1C6E03.5070708@netconfcentral.com> <20091207.082255.88175214.mbj@tail-f.com> <4B266D94.3040600@netconfcentral.com> X-Mailer: Mew version 6.2.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-09, sec 11.1, YIN mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 19:36:30 -0000 Andy Bierman wrote: > >> OLD entries: > >> > >> | contact | info | true | > >> | description | text | true | > >> | error-message | value | true | > >> | organization | info | true | > >> | reference | info | false | > >> > >> > >> NEW entries: > >> > >> | contact | text | true | > >> | description | text | true | > >> | error-message | text | true | > >> | organization | text | true | > >> | reference | text | true | > >> > >> > >> This also allows the xml:lang attribute to be applied, if desired. > > > > Are these changes going to be made? I plan to do these changes unless anyone object. I think it makes sense to harmonize these names. (Ok, saw now that Phil objects). /martin From j.schoenwaelder@jacobs-university.de Mon Dec 14 11:39: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 E2E6E28C166 for ; Mon, 14 Dec 2009 11:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[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 x2IcFzTuy7yj for ; Mon, 14 Dec 2009 11:39:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B71F828C16B for ; Mon, 14 Dec 2009 11:39:23 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3CEEC003A; Mon, 14 Dec 2009 20:39:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id b5FUaEgN9hR3; Mon, 14 Dec 2009 20:39:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0717C0029; Mon, 14 Dec 2009 20:39:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 06BFDF6F81E; Mon, 14 Dec 2009 20:39:06 +0100 (CET) Date: Mon, 14 Dec 2009 20:39:06 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091214193906.GC72602@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4B2540B0.5000902@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2540B0.5000902@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:39:30 -0000 On Sun, Dec 13, 2009 at 08:29:52PM +0100, Andy Bierman wrote: > Now that I am bothering to implement YIN, > I can't help notice that it is a CLR factory. > I cannot find any meaningful rationale for > picking yin-element == true or false. > The decision to encode as an attribute seems > completely arbitrary and pointless. [...] > I also find the arbitrary names picked for > the argument strings to be pointless and > a just more CLRs. So is there a guiding principle behind Table 1? Any advise how extension writers should use the yin-element statement? Note that we would not even need yin-element if there would be a simple translation rule (and note that the yin-element statement hard codes the rule for choosing the attribute name, which means what is in table 1 could have not been created with YANG extension statements - am I correct?). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Mon Dec 14 11:48: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 ACEA228C15C for ; Mon, 14 Dec 2009 11:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, UNPARSEABLE_RELAY=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 0vfhXEKBmI9M for ; Mon, 14 Dec 2009 11:48:34 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id E3F4728C150 for ; Mon, 14 Dec 2009 11:48:33 -0800 (PST) Received: (qmail 44234 invoked from network); 14 Dec 2009 19:48:21 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 14 Dec 2009 11:48:20 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: xUCy1OAVM1kkMSgV9hQwl_qK_rPtCzf7aF7owzd15CF.Y81erZICayTQ4MiBshoxel9WAKMUG2z516N_oTM3bh2fse4aahhyd1LUx5uwNCI5SZD2F1v9BgY9HaGTNjIRDczEDvRGqcFQpZz3KnRjWe_kSTcdXE81fI71ycAOi0J53zbFk.IDJf_3.RDHr1qRqaOkStJ2F6c.cuIFf81OMUWo0HicJUnivRPA3EUttw5Vv9Ym6VbThlRAMbL2ndeMSmIix6qZ_ZN4h9kK4wV5r5CwTCEIqShBjaRYY47Y0pIuDRK9wW9qH6Wf1lXYNA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2696AC.2080707@netconfcentral.com> Date: Mon, 14 Dec 2009 11:49:00 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1C6E03.5070708@netconfcentral.com> <20091207.082255.88175214.mbj@tail-f.com> <4B266D94.3040600@netconfcentral.com> <20091214.203614.147579351.mbj@tail-f.com> In-Reply-To: <20091214.203614.147579351.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09, sec 11.1, YIN mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 19:48:34 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>>> OLD entries: >>>> >>>> | contact | info | true | >>>> | description | text | true | >>>> | error-message | value | true | >>>> | organization | info | true | >>>> | reference | info | false | >>>> >>>> >>>> NEW entries: >>>> >>>> | contact | text | true | >>>> | description | text | true | >>>> | error-message | text | true | >>>> | organization | text | true | >>>> | reference | text | true | >>>> >>>> >>>> This also allows the xml:lang attribute to be applied, if desired. >> Are these changes going to be made? > > I plan to do these changes unless anyone object. I think it makes > sense to harmonize these names. (Ok, saw now that Phil objects). > reference as attribute is a bug, right? The YIN argument names are subjective, but all 5 of these seem the same to me. I guess after 25 years of writing C code, I am biased towards curly braces and against verbosity. > > /martin > Andy From mbj@tail-f.com Mon Dec 14 11:49: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 69C7A3A68C5 for ; Mon, 14 Dec 2009 11:49:00 -0800 (PST) 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 rB60a2uzFIOh for ; Mon, 14 Dec 2009 11:48:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 97CE83A6827 for ; Mon, 14 Dec 2009 11:48:59 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F411616006; Mon, 14 Dec 2009 20:48:46 +0100 (CET) Date: Mon, 14 Dec 2009 20:48:45 +0100 (CET) Message-Id: <20091214.204845.145933995.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091214193906.GC72602@elstar.local> References: <4B2540B0.5000902@netconfcentral.com> <20091214193906.GC72602@elstar.local> X-Mailer: Mew version 6.2.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] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 19:49:00 -0000 Juergen Schoenwaelder wrote: > So is there a guiding principle behind Table 1? Any advise how > extension writers should use the yin-element statement? Lada provided a guideline: yin-element is used only in those cases where the text might be inappropriately modified by the standard XML attribute normalization. > Note that we > would not even need yin-element if there would be a simple translation > rule (and note that the yin-element statement hard codes the rule for > choosing the attribute name, which means what is in table 1 could have > not been created with YANG extension statements - am I correct?). Do you mean that we could not define the yin-element statement itself with an extension? Or do you mean that we could not have defined the rest of the statements as extensions? The attribute name is the name of the argument: extension annotate { argument target; ... } /martin From mbj@tail-f.com Mon Dec 14 11:53: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 7C34F28C150 for ; Mon, 14 Dec 2009 11:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.155, 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 QmGq7ZJEjzeA for ; Mon, 14 Dec 2009 11:53:06 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BF54A3A6864 for ; Mon, 14 Dec 2009 11:53:06 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5EBC4616006; Mon, 14 Dec 2009 20:52:53 +0100 (CET) Date: Mon, 14 Dec 2009 20:52:52 +0100 (CET) Message-Id: <20091214.205252.258178429.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B2696AC.2080707@netconfcentral.com> References: <4B266D94.3040600@netconfcentral.com> <20091214.203614.147579351.mbj@tail-f.com> <4B2696AC.2080707@netconfcentral.com> X-Mailer: Mew version 6.2.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-09, sec 11.1, YIN mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 19:53:07 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > I plan to do these changes unless anyone object. I think it makes > > sense to harmonize these names. (Ok, saw now that Phil objects). > > > > reference as attribute is a bug, right? I think so. > The YIN argument names are subjective, but all 5 of these > seem the same to me. Agreed. /martin From andy@netconfcentral.com Mon Dec 14 12:12: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 83B4C3A692C for ; Mon, 14 Dec 2009 12:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=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 68Kqdw3jpG34 for ; Mon, 14 Dec 2009 12:12:51 -0800 (PST) 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 66D083A692B for ; Mon, 14 Dec 2009 12:12:47 -0800 (PST) Received: (qmail 60554 invoked from network); 14 Dec 2009 20:12:29 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 14 Dec 2009 12:12:29 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .w88gDwVM1msfNK8Z_uXTdjG_Qi5FKl.Y3vd3_J5SGticy9PnBkXg5m6XrHQeANuiWP4fbqmsYMae1tqlWgl1Dkw80.nQRSKg_QccxoqH9A_UQz4KIV3teOXTm8VuJVaSnSYidge7pZP.6h6xAmVrk0uypEhvoVCFxIDbqty80TGBqqqWnm9SRF_ibcMfjuoWK3Yu8vBIgesy733uXuAWD1MZ1NqEreZeh0XysUvk03C.7pHsR.DWi8ZsoZwdOEp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B269C55.1010406@netconfcentral.com> Date: Mon, 14 Dec 2009 12:13:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <4B2540B0.5000902@netconfcentral.com> <20091214193906.GC72602@elstar.local> In-Reply-To: <20091214193906.GC72602@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 20:12:54 -0000 Juergen Schoenwaelder wrote: > On Sun, Dec 13, 2009 at 08:29:52PM +0100, Andy Bierman wrote: > >> Now that I am bothering to implement YIN, >> I can't help notice that it is a CLR factory. >> I cannot find any meaningful rationale for >> picking yin-element == true or false. >> The decision to encode as an attribute seems >> completely arbitrary and pointless. > > [...] > >> I also find the arbitrary names picked for >> the argument strings to be pointless and >> a just more CLRs. > > So is there a guiding principle behind Table 1? Any advise how > extension writers should use the yin-element statement? Note that we > would not even need yin-element if there would be a simple translation > rule (and note that the yin-element statement hard codes the rule for > choosing the attribute name, which means what is in table 1 could have > not been created with YANG extension statements - am I correct?). > IMO, this is cleaner: keyword [arg] stmt-end foo It would be nice to have a simple fool-proof algorithm that does not require a tool to parse and understand all the imported extension-stmts. YANG fragment: module X { extension foo { argument bar { yin-element true; } } extension bar; container A { x:foo fred { x:bar; } } current YIN encoding: fred proposed YIN encoding: A fred It is not possible to guess 100% of the corner-cases using the current extension-stmt. I prefer: extension foo { argument true; } extension bar { argument false; } The mapping rules are simple: 1) YANG keywords map to elements in YIN namespace 2) all arguments map to keyword in YIN namespace 3) all extension keywords map to elements in the module namespace This is bullet-proof, simple, requires no knowledge of any YANG extension-stmts, and does not lead to the 'double element' problem that exists in the current solution. XML encoding and XML namespace rules are different for attributes than elements, and that complexity is also avoided. But if the people that actually want to use YIN like it so much just the way it is, then I don't think it should be changed. > /js > Andy From j.schoenwaelder@jacobs-university.de Mon Dec 14 12:19: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 4D88B3A682F for ; Mon, 14 Dec 2009 12:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, 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 TQcMx611dI8i for ; Mon, 14 Dec 2009 12:19:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2EB43A6924 for ; Mon, 14 Dec 2009 12:19:12 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F205C0011; Mon, 14 Dec 2009 21:18:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N7L-jDfmghxk; Mon, 14 Dec 2009 21:18:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3091FC000F; Mon, 14 Dec 2009 21:18:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A9C20F6F9BE; Mon, 14 Dec 2009 21:18:55 +0100 (CET) Date: Mon, 14 Dec 2009 21:18:55 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091214201855.GB72702@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <4B2540B0.5000902@netconfcentral.com> <20091214193906.GC72602@elstar.local> <20091214.204845.145933995.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091214.204845.145933995.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:19:35 -0000 On Mon, Dec 14, 2009 at 08:48:45PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > So is there a guiding principle behind Table 1? Any advise how > > extension writers should use the yin-element statement? > > Lada provided a guideline: > > yin-element is used only in those cases where the text might be > inappropriately modified by the standard XML attribute > normalization. What is the definition of "inappropriately modified"? Even text in elements gets modified. > > Note that we > > would not even need yin-element if there would be a simple translation > > rule (and note that the yin-element statement hard codes the rule for > > choosing the attribute name, which means what is in table 1 could have > > not been created with YANG extension statements - am I correct?). > > Do you mean that we could not define the yin-element statement itself > with an extension? Or do you mean that we could not have defined the > rest of the statements as extensions? > > The attribute name is the name of the argument: > > extension annotate { > argument target; > ... > } Yes, but for the contact statement, the yin attribute is called 'info' (OK, there is a proposal to change this). Since table lists different names for the attributes, it seems these statements could never have been defined using extension statements. If it is important for some reason (yet to be posted) to choose name/value/info/..., then perhaps this same reason might apply for extension statements as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Dec 14 14:16: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 AC83C3A6849 for ; Mon, 14 Dec 2009 14:16:35 -0800 (PST) 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=0.008, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwbRwuh4wrrg for ; Mon, 14 Dec 2009 14:16:34 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6468F3A635F for ; Mon, 14 Dec 2009 14:16:34 -0800 (PST) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C19C1D80095; Mon, 14 Dec 2009 23:16:20 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B269C55.1010406@netconfcentral.com> References: <4B2540B0.5000902@netconfcentral.com> <20091214193906.GC72602@elstar.local> <4B269C55.1010406@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 14 Dec 2009 23:16:19 +0100 Message-ID: <1260828979.1771.42.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 22:16:35 -0000 On Po, 2009-12-14 at 12:13 -0800, Andy Bierman wrote: > IMO, this is cleaner: > > keyword [arg] stmt-end > > > foo > > I becomes less clean if there are any substatements: foo bar ... As an attribute, the argument is clearly distinguished from the substatements. However, it seems attribute normalization may still be a problem for some statements with yin-element=false. For example, in the attribute value will get normalized to "foo bar" (single space), which may cause interoperability problems. So I guess Andy's proposal is worth considering. There are pros and cons in either case. Lada > It would be nice to have a simple fool-proof algorithm > that does not require a tool to parse and understand > all the imported extension-stmts. > > YANG fragment: > > module X { > > extension foo { > argument bar { > yin-element true; > } > } > > extension bar; > > container A { > x:foo fred { > x:bar; > } > } > > > current YIN encoding: > > > > fred > > > > > > proposed YIN encoding: > > > A > > fred > > > > > > It is not possible to guess 100% of the corner-cases > using the current extension-stmt. I prefer: > > > extension foo { > argument true; > } > > extension bar { > argument false; > } > > The mapping rules are simple: > 1) YANG keywords map to elements in YIN namespace > 2) all arguments map to keyword in YIN namespace > 3) all extension keywords map to elements in the module namespace > > This is bullet-proof, simple, requires no knowledge > of any YANG extension-stmts, and does not lead > to the 'double element' problem that exists in > the current solution. XML encoding and XML namespace rules > are different for attributes than elements, and that complexity > is also avoided. > > But if the people that actually want to use YIN like it > so much just the way it is, then I don't think it > should be changed. > > > > /js > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Dec 14 15:08: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 E48D23A68A8 for ; Mon, 14 Dec 2009 15:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.147, 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 heUF3l0mc7oV for ; Mon, 14 Dec 2009 15:08:47 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2B3C03A6898 for ; Mon, 14 Dec 2009 15:08:47 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D1D3A616006; Tue, 15 Dec 2009 00:08:32 +0100 (CET) Date: Tue, 15 Dec 2009 00:08:32 +0100 (CET) Message-Id: <20091215.000832.114195061.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1260828979.1771.42.camel@nomad> References: <20091214193906.GC72602@elstar.local> <4B269C55.1010406@netconfcentral.com> <1260828979.1771.42.camel@nomad> X-Mailer: Mew version 6.2.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] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 23:08:48 -0000 Ladislav Lhotka wrote: > However, it seems attribute normalization may still be a problem for > some statements with yin-element=false. For example, in > > > > the attribute value will get normalized to "foo bar" (single space), > which may cause interoperability problems. In the absense of a DTD, won't the attribute be treated as CDATA? If so, you will not get a single space, but tab etc will still be converted to space. > So I guess Andy's proposal is worth considering. There are pros and cons > in either case. Or we go through the list and make sure that all statements where attribute normalization can be a problem use elements. 'default' is one example. There are a few more. /martin From randy_presuhn@mindspring.com Mon Dec 14 15:49: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 B68B43A66B4 for ; Mon, 14 Dec 2009 15:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_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 I4+JOsZHlaej for ; Mon, 14 Dec 2009 15:49:12 -0800 (PST) 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 E4CB23A659B for ; Mon, 14 Dec 2009 15:49:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=S5mJvtb7nABXBXni12AE+3Sn2EW/QVVzVMDKMngMvsKDwEeEsh7xUzFJacPrNDE7; 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 [99.187.236.70] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NKKew-0003Ss-A7 for netmod@ietf.org; Mon, 14 Dec 2009 18:48:58 -0500 Message-ID: <003001ca7d18$44bb67a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <002f01ca7c6f$c50c1d40$6801a8c0@oemcomputer><20091214.092718.97565918.mbj@tail-f.com><4B2627A9.2040704@netconfcentral.com> <20091214.130918.165190776.mbj@tail-f.com> Date: Mon, 14 Dec 2009 15:50:50 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40a1d79ecfba646fcc03cd30b39b62e4d3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.236.70 Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 23:49:12 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: ; > Sent: Monday, December 14, 2009 4:09 AM > Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision ... > In SMI, it is legal to expand the value space if the object is an > enumerated integer or bits. Just permitting these limited revisions *has* caused some problems - they adversely interract with the WRITE-SYNTAX facility from RFC 2580. If the original version of a module using bits does not use WRITE-SYNTAX to spell out exactly which values must be supported by a conformant implementation, a subsequent expansion of the set of BITS will require that original module to be updated. Otherwise the semantics of the original module would effectively have been changed, and that is verboten. > In YANG it is legal to expand the value > space for any type. Is this difference the reason we need to require > import by revision for typedefs in YANG but not in SMI? It (and the fact that a higher percentage of the YANG-defined information will be writeable) makes problem more likely to occur. Randy From andy@netconfcentral.com Mon Dec 14 15:55: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 322073A67FB for ; Mon, 14 Dec 2009 15:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=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 UPBu81ABJo5s for ; Mon, 14 Dec 2009 15:55:51 -0800 (PST) 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 791193A67F7 for ; Mon, 14 Dec 2009 15:55:51 -0800 (PST) Received: (qmail 8745 invoked from network); 14 Dec 2009 23:55:37 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 14 Dec 2009 15:55:36 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 9nYJlCQVM1kR3pntgxnannDfpKesNOQNlqEZOPBlCG2ufgKFIESKPe1XuYOALsjnu8bhsgsgbSgLiDM97GkZl97w.hd1WDxfxkXR9kTuY6Y22M3bmF8xQJF.rkQR8B6Msi_i9sLdPIwzea0lMnThlh5wenAypPc.t11Ylw97Rn9tmjQMAd2iwX5KCoV7muuhJFHdU3Oyc8gMQFa4m9RGQqt6ygHvHSA5Bc3Iq2ycz4f_ai76DdI36ESjqIWc2PS9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B26D024.6000505@netconfcentral.com> Date: Mon, 14 Dec 2009 15:54:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <4B2540B0.5000902@netconfcentral.com> <20091214193906.GC72602@elstar.local> <4B269C55.1010406@netconfcentral.com> <1260828979.1771.42.camel@nomad> In-Reply-To: <1260828979.1771.42.camel@nomad> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2009 23:55:52 -0000 Ladislav Lhotka wrote: > On Po, 2009-12-14 at 12:13 -0800, Andy Bierman wrote: > >> IMO, this is cleaner: >> >> keyword [arg] stmt-end >> >> >> foo >> >> > > I becomes less clean if there are any substatements: > > > foo > > bar > > ... > > This always translates to keyword foo { subkw bar; } > As an attribute, the argument is clearly distinguished from the > substatements. > As long as the string 'arg' (or whatever) is never used as a YANG keyword, then there is no ambiguity. If there is a YANG argument, it will be the first child node of the keyword element. > However, it seems attribute normalization may still be a problem for > some statements with yin-element=false. For example, in > > > > the attribute value will get normalized to "foo bar" (single space), > which may cause interoperability problems. > > So I guess Andy's proposal is worth considering. There are pros and cons > in either case. > I was told a long time ago by you guys that attributes were bad, and that's why we never use them in the XML encoding of YANG. Now we are told XML attributes are good, and must be supported for YIN arguments. I think Juegen is right -- some clarification should be added why YANG does not support attributes yet YIN needs them. Even stuff like patterns, ranges and XPath expressions can have whitespace issues. Currently, the extension argument name can collide with another extension name, ala my example: x:foo fred { x:bar; } fred This seems like a problem to me, especially if the order of the elements is not preserved. fred This is never ambiguous, even when mis-ordered. > Lada Andy From lhotka@cesnet.cz Tue Dec 15 00:51: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 7A7303A69B2 for ; Tue, 15 Dec 2009 00:51:20 -0800 (PST) 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 rnX0g2nIhzLp for ; Tue, 15 Dec 2009 00:51:19 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9ADFB3A6980 for ; Tue, 15 Dec 2009 00:51:19 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DA8E9D800D1; Tue, 15 Dec 2009 09:51:05 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091215.000832.114195061.mbj@tail-f.com> References: <20091214193906.GC72602@elstar.local> <4B269C55.1010406@netconfcentral.com> <1260828979.1771.42.camel@nomad> <20091215.000832.114195061.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 15 Dec 2009 09:51:04 +0100 Message-ID: <1260867064.27840.46.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 08:51:20 -0000 Martin Bjorklund píše v Út 15. 12. 2009 v 00:08 +0100: > Ladislav Lhotka wrote: > > However, it seems attribute normalization may still be a problem for > > some statements with yin-element=false. For example, in > > > > > > > > the attribute value will get normalized to "foo bar" (single space), > > which may cause interoperability problems. > > In the absense of a DTD, won't the attribute be treated as CDATA? If > so, you will not get a single space, but tab etc will still be > converted to space. Well, XML 1.1 spec says in sec. 3.3.3: "If the attribute type is not CDATA, then the XML processor MUST further process the normalized attribute value by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character. ... All attributes for which no declaration has been read SHOULD be treated by a non-validating processor as if declared CDATA." I am wondering what this means for a validating parser which doesn't use DTD. I checked it with xmllint and it doesn't collapse multiple spaces even if the attribute is declared as "string" or "token" in RELAX NG. But in any case, tabs and newlines are always changed to spaces. > > > So I guess Andy's proposal is worth considering. There are pros and cons > > in either case. > > Or we go through the list and make sure that all statements where > attribute normalization can be a problem use elements. 'default' is > one example. There are a few more. Yes, it seems necessary for 'default', 'enum' 'must', 'path', 'pattern' and 'when'. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Dec 15 01:19: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 CF9AF3A6980 for ; Tue, 15 Dec 2009 01:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsLbJeb7oaOB for ; Tue, 15 Dec 2009 01:19:04 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id ED2923A6851 for ; Tue, 15 Dec 2009 01:19:03 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5F0F4D80096; Tue, 15 Dec 2009 10:18:50 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200912141826.nBEIQWku046987@idle.juniper.net> References: <200912141826.nBEIQWku046987@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 15 Dec 2009 10:18:49 +0100 Message-ID: <1260868729.27840.69.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-09; 7.19.5 when-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: Tue, 15 Dec 2009 09:19:04 -0000 Phil Shafer píše v Po 14. 12. 2009 v 13:26 -0500: > Ladislav Lhotka writes: > >With mandatory and presence the occurrence constraint is known a priori > >and required for any instance document that conforms to a particular > >schema. With 'when' and 'must' the app may first have to parse the > >instance document and check some values in it in order to determine the > >schema. > > I find your use of "schema" here confusing. The schema is static > information. It defines the hierarchy and containment. Mandatory, > must, and when define constraints on the data modeled by that schema. > "must" does not change the schema. Sorry, what I wrote was really confusing, the last sentence should have been: With 'when' and 'must', the app may first have to parse the instance document and check some values in it in order to determine the value of the XPath expression and this evaluation should not affect the schema. We are differing in the classification of 'mandatory' (and 'presence') but in fact it affects all data node definition statements, too, e.g. container foo { when "../../bar = 42"; ... } If I understand your interpretation of 'when', element "foo" must not be present if ../../bar != 42, so the app even doesn't know a priori the hierarchy. > > >> The "when" version carries more information that your "must" version > >> and this information is vital to the smooth flow of the apps that will > >> manipulate the config data. > > > >Sounds like marketing. :-) What is this "more information"? > > I followed this claim with a paragraph explaining the information > being carried, what can be done with it, and why I think it is > important. If you want marketing, I'll add a claim that it's > up to 20 times better or more. I still don't see the part of the information that you claim is missing in the 'must' statement. It says exactly this: engine-id is present if and only if version = 'v3'. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Dec 15 01:41: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 73C1F3A69C1 for ; Tue, 15 Dec 2009 01:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=-0.627, 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 BBA3FKvDlWEH for ; Tue, 15 Dec 2009 01:41:00 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B64113A681F for ; Tue, 15 Dec 2009 01:41:00 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0637176C53A; Tue, 15 Dec 2009 10:40:46 +0100 (CET) Date: Tue, 15 Dec 2009 10:40:45 +0100 (CET) Message-Id: <20091215.104045.193185231.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1260867064.27840.46.camel@missotis> References: <1260828979.1771.42.camel@nomad> <20091215.000832.114195061.mbj@tail-f.com> <1260867064.27840.46.camel@missotis> X-Mailer: Mew version 6.2.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] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 09:41:01 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMTUuIDEyLiAyMDA5IHYgMDA6MDggKzAxMDA6DQo+ID4gTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+IFNvIEkgZ3Vlc3MgQW5k eSdzIHByb3Bvc2FsIGlzIHdvcnRoIGNvbnNpZGVyaW5nLiBUaGVyZSBhcmUgcHJvcyBhbmQgY29u cw0KPiA+ID4gaW4gZWl0aGVyIGNhc2UuDQo+ID4gDQo+ID4gT3Igd2UgZ28gdGhyb3VnaCB0aGUg bGlzdCBhbmQgbWFrZSBzdXJlIHRoYXQgYWxsIHN0YXRlbWVudHMgd2hlcmUNCj4gPiBhdHRyaWJ1 dGUgbm9ybWFsaXphdGlvbiBjYW4gYmUgYSBwcm9ibGVtIHVzZSBlbGVtZW50cy4gICdkZWZhdWx0 JyBpcw0KPiA+IG9uZSBleGFtcGxlLiAgVGhlcmUgYXJlIGEgZmV3IG1vcmUuDQo+IA0KPiBZZXMs IGl0IHNlZW1zIG5lY2Vzc2FyeSBmb3IgJ2RlZmF1bHQnLCAnZW51bScgJ211c3QnLCAncGF0aCcs ICdwYXR0ZXJuJw0KPiBhbmQgJ3doZW4nLg0KDQpJIHByZWZlciB0byBmaXggdGhlIGN1cnJlbnQg ZGVzaWduLCBpLmUuIG1ha2UgdGhlIGFyZ3VtZW50IGZvciB0aGVzZQ0Ka2V5d29yZHMgZWxlbWVu dHMuDQoNClByb3ZpZGVkIHdlIGZpeCB0aGVzZSBwcm9ibGVtcywgSSB0aGluayBpdCBpcyBhIG1h dHRlciBvZiB0YXN0ZSB3aGljaA0KZGVzaWduIGlzIGJldHRlci4NCg0KDQovbWFydGluDQo= From lhotka@cesnet.cz Tue Dec 15 02:17: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 F3DD13A688C for ; Tue, 15 Dec 2009 02:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgq2RpEepuNa for ; Tue, 15 Dec 2009 02:17:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 153C83A67CF for ; Tue, 15 Dec 2009 02:17:02 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 69024D80095; Tue, 15 Dec 2009 11:16:48 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B26D024.6000505@netconfcentral.com> References: <4B2540B0.5000902@netconfcentral.com> <20091214193906.GC72602@elstar.local> <4B269C55.1010406@netconfcentral.com> <1260828979.1771.42.camel@nomad> <4B26D024.6000505@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 15 Dec 2009 11:16:47 +0100 Message-ID: <1260872207.27840.123.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 10:17:03 -0000 Andy Bierman píše v Po 14. 12. 2009 v 15:54 -0800: > Ladislav Lhotka wrote: > > On Po, 2009-12-14 at 12:13 -0800, Andy Bierman wrote: > > > >> IMO, this is cleaner: > >> > >> keyword [arg] stmt-end > >> > >> > >> foo > >> > >> > > > > I becomes less clean if there are any substatements: > > > > > > foo > > > > bar > > > > ... > > > > > > This always translates to > > keyword foo { > subkw bar; > } > Sure, but any more complex hierarchy will become completely unreadable, you have to care about subelement order etc. I don't agree that YIN may only be useful as an internal format for machine processing. ... > I was told a long time ago by you guys > that attributes were bad, and that's why we never > use them in the XML encoding of YANG. Attributes are not bad, they just have some limitations that have to be taken into account. > > Now we are told XML attributes are good, and > must be supported for YIN arguments. > > I think Juegen is right -- some clarification > should be added why YANG does not support attributes > yet YIN needs them. Even stuff like patterns, This is pretty clear: for containers it's out of question and making leafs into attributes would prevent adding attributes to them, e.g. to specify edit-config operation. For YIN, there are no such issues, except value normalization. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Dec 15 02:18: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 75E3A3A688C for ; Tue, 15 Dec 2009 02:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[AWL=-0.459, 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 CfR+oayA4FTo for ; Tue, 15 Dec 2009 02:18:07 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 87A683A6980 for ; Tue, 15 Dec 2009 02:18:07 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0BA2AD80095; Tue, 15 Dec 2009 11:17:54 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091215.104045.193185231.mbj@tail-f.com> References: <1260828979.1771.42.camel@nomad> <20091215.000832.114195061.mbj@tail-f.com> <1260867064.27840.46.camel@missotis> <20091215.104045.193185231.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 15 Dec 2009 11:17:52 +0100 Message-ID: <1260872272.27840.124.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 10:18:08 -0000 Martin Bjorklund píše v Út 15. 12. 2009 v 10:40 +0100: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 15. 12. 2009 v 00:08 +0100: > > > Ladislav Lhotka wrote: > > > > So I guess Andy's proposal is worth considering. There are pros and cons > > > > in either case. > > > > > > Or we go through the list and make sure that all statements where > > > attribute normalization can be a problem use elements. 'default' is > > > one example. There are a few more. > > > > Yes, it seems necessary for 'default', 'enum' 'must', 'path', 'pattern' > > and 'when'. > > I prefer to fix the current design, i.e. make the argument for these > keywords elements. +1. Lada > > Provided we fix these problems, I think it is a matter of taste which > design is better. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Dec 15 08:22: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 53ECA3A6A8F for ; Tue, 15 Dec 2009 08:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 k2EhlUUyc0Ag for ; Tue, 15 Dec 2009 08:22:41 -0800 (PST) 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 42E603A6A14 for ; Tue, 15 Dec 2009 08:22:40 -0800 (PST) Received: (qmail 5754 invoked from network); 15 Dec 2009 16:22:23 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 15 Dec 2009 08:22:23 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: GEI2Ol8VM1lWbRQGqTeIYWLsokDf6oG3HwwU40Mlu.PlDcOSTmWVDG_IxBvIim2sn5KeNXhHrPIh1SaqzJoriMePOrZwpivwkH.W7qPDoyICMdhFIe7dRJi6e4EX7qYncXUqvqFwdAB8vRUDrlJV87cXx9vBM5Rzc7wEeQN5JWv.l3dKQsVRCWD8Fimc.BBGV7y1S_s9AiZY2Hc3PFX..rLwgTFmPQmUJTy78IFbg.XKOP76LrmKWTEL6xRXHmUf1g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B27B774.701@netconfcentral.com> Date: Tue, 15 Dec 2009 08:21:08 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <4B2540B0.5000902@netconfcentral.com> <20091214193906.GC72602@elstar.local> <4B269C55.1010406@netconfcentral.com> <1260828979.1771.42.camel@nomad> <4B26D024.6000505@netconfcentral.com> <1260872207.27840.123.camel@missotis> In-Reply-To: <1260872207.27840.123.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 16:22:43 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 14. 12. 2009 v 15:54 -0800: >> Ladislav Lhotka wrote: >>> On Po, 2009-12-14 at 12:13 -0800, Andy Bierman wrote: >>> >>>> IMO, this is cleaner: >>>> >>>> keyword [arg] stmt-end >>>> >>>> >>>> foo >>>> >>>> >>> I becomes less clean if there are any substatements: >>> >>> >>> foo >>> >>> bar >>> >>> ... >>> >>> >> This always translates to >> >> keyword foo { >> subkw bar; >> } >> > > Sure, but any more complex hierarchy will become completely unreadable, > you have to care about subelement order etc. I don't agree that YIN may > only be useful as an internal format for machine processing. > I disagree. IMO the predictable algorithm makes it easier to read, and easier to remember what arbitrary name was used for the un-named argument string. > ... > >> I was told a long time ago by you guys >> that attributes were bad, and that's why we never >> use them in the XML encoding of YANG. > > Attributes are not bad, they just have some limitations that have to be > taken into account. > >> Now we are told XML attributes are good, and >> must be supported for YIN arguments. >> >> I think Juegen is right -- some clarification >> should be added why YANG does not support attributes >> yet YIN needs them. Even stuff like patterns, > > This is pretty clear: for containers it's out of question and making > leafs into attributes would prevent adding attributes to them, e.g. to > specify edit-config operation. > The keyword is always encoded as an element, so this is never a problem. The ad-hoc, random assignment of name and attr vs. element only applies to the optional argument string. I'm surprised the WG did not add alternate encodings for the keyword. It is static and predictable for some reason. > For YIN, there are no such issues, except value normalization. > > Lada > Andy From andy@netconfcentral.com Tue Dec 15 08:50: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 E2C523A6A9D for ; Tue, 15 Dec 2009 08:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 IZ-VEPFg70o6 for ; Tue, 15 Dec 2009 08:50:44 -0800 (PST) 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 F018C3A6AA7 for ; Tue, 15 Dec 2009 08:50:43 -0800 (PST) Received: (qmail 52685 invoked from network); 15 Dec 2009 16:50:27 -0000 Received: from adsl-67-121-105-196.dsl.irvnca.pacbell.net (andy@67.121.105.196 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 15 Dec 2009 08:50:27 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Pl4dES0VM1m6twbO2l7QQwfiKSozl4tgxrZzFxnOXZnt9DD_vLkULh4wnL6x35HyIp6_CVKUcHnIIRHZ2igfdPl1nNJ6SExPfaLhEFURF9z_LFpbK2XtHT.gUtsrMy_rGUTOT28hmHSD4ejUMc4lM5zXyzsrHIhcXLjZGDNDGgN4Qy3G6GTxuct1MuhYGMTMte3RsWo8ma.J5AsyPhF9uFA9NO8jEIkJdZA4rkXKIpSuV3MvTRC8g.SshUTe0pgYq0pwHdLVsuiBnvUZ5e2JJLcWFyKAb5UC3yGQsdA8BvkblA2EXZr5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B27BE83.1040803@netconfcentral.com> Date: Tue, 15 Dec 2009 08:51:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1260828979.1771.42.camel@nomad> <20091215.000832.114195061.mbj@tail-f.com> <1260867064.27840.46.camel@missotis> <20091215.104045.193185231.mbj@tail-f.com> <1260872272.27840.124.camel@missotis> In-Reply-To: <1260872272.27840.124.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yin-element is useless X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 16:50:45 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Út 15. 12. 2009 v 10:40 +0100: >> Ladislav Lhotka wrote: >>> Martin Bjorklund píše v Út 15. 12. 2009 v 00:08 +0100: >>>> Ladislav Lhotka wrote: >>>>> So I guess Andy's proposal is worth considering. There are pros and cons >>>>> in either case. >>>> Or we go through the list and make sure that all statements where >>>> attribute normalization can be a problem use elements. 'default' is >>>> one example. There are a few more. >>> Yes, it seems necessary for 'default', 'enum' 'must', 'path', 'pattern' >>> and 'when'. >> I prefer to fix the current design, i.e. make the argument for these >> keywords elements. > > +1. Lada > Maybe you can start with the functional requirements. - We have a conceptual field in a YIN-stmt. - It is optional. - There can be zero or one instance of this field. - There is no need for an assignable name for this field in YANG I do not understand why this field even needs an assignable name in YIN. - If there could be multiple arguments, then this would make sense. - If the name had any semantics at all associated with it, but it doesn't. - If there were not significant problems with assignable name collisions, like there are between keyword and argument name. - If there were some benefit from using XML attribute encoding over XML element encoding like the rest of YANG. (BTW, there are corner-cases introduced by encoding 'string' in an attribute in YIN, but an element in YANG. These are never explained in the draft.) I hope the WG does not solve these problems with more lame CLRs. I prefer algorithms that actually work, instead of pushing the problem on the user, with lots of CLRs that cover up the design holes. >> Provided we fix these problems, I think it is a matter of taste which >> design is better. >> >> >> /martin > > Andy From andyb@iwl.com Tue Dec 15 12:31: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 BB7123A6914 for ; Tue, 15 Dec 2009 12:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[AWL=0.046, 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 A0E8UIf79E-i for ; Tue, 15 Dec 2009 12:31:43 -0800 (PST) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id B77993A6910 for ; Tue, 15 Dec 2009 12:31:43 -0800 (PST) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 145D713D3371; Tue, 15 Dec 2009 15:31:29 -0500 (EST) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id DCC7913D3269; Tue, 15 Dec 2009 15:31:28 -0500 (EST) Message-ID: <4B27F252.9020203@iwl.com> Date: Tue, 15 Dec 2009 12:32:18 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] email address change X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:01:28 -0000 Hi, I am retiring andy@netconfcentral.com and using andyb@iwl.com from now on, because I have joined InterWorking Labs to fully develop my NETCONF/YANG implementation. The http://www.netconfcentral.org/ WEB site will continue to exist and provide free information and online tools for NETCONF and YANG. thanks, Andy From andyb@iwl.com Tue Dec 15 12:47: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 AC0C83A68F5 for ; Tue, 15 Dec 2009 12:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 F7qIcBamqCAP for ; Tue, 15 Dec 2009 12:47:04 -0800 (PST) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by core3.amsl.com (Postfix) with ESMTP id AFE323A68D8 for ; Tue, 15 Dec 2009 12:47:04 -0800 (PST) Received: from relay9.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id F2F4D1E336B; Tue, 15 Dec 2009 15:46:50 -0500 (EST) Received: by relay9.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AF56B1E6150; Tue, 15 Dec 2009 15:46:50 -0500 (EST) Message-ID: <4B27F5EC.3010501@iwl.com> Date: Tue, 15 Dec 2009 12:47:40 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] Yuma Tools announcement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:01:50 -0000 Hi, A new NETCONF/YANG toolkit is available called Yuma Tools. The binary license is free, and the most popular linux distributions (and MacOSX 10.5) will be supported. The toolkit includes: * yangcli: NETCONF-over-SSH client application * netconfd: NETCONF-over-SSH server for linux or MacOSX * netconf-subsystem: OpenSSH to netconfd thin client * yangdump: YANG compiler * yangdiff: YANG semantic comparison application * libtoaster: example modular server instrumentation library * PDF user manuals All current versions of all NETCONF/YANG drafts are supported, except the :url and :partial-lock capabilities, which will be implemented soon. Some proprietary content is also implemented, including a complete access control system called NACM. http://www.netconfcentral.org/modules/yuma-nacm/2009-10-21 More information is available at http://yuma.iwl.com/ thanks, Andy From andyb@iwl.com Tue Dec 15 13:27: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 3859E3A6B07 for ; Tue, 15 Dec 2009 13:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=0.953, 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 6bfN3xvzA3jV for ; Tue, 15 Dec 2009 13:27:16 -0800 (PST) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id 795043A6B04 for ; Tue, 15 Dec 2009 13:27:16 -0800 (PST) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 5443D27486B3; Tue, 15 Dec 2009 16:27:01 -0500 (EST) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2161F2748337; Tue, 15 Dec 2009 16:27:01 -0500 (EST) Message-ID: <4B27FF57.4040007@iwl.com> Date: Tue, 15 Dec 2009 13:27:51 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "netmod@ietf.org" References: <20091207.205640.262259259.mbj@tail-f.com> <4B1D5E98.4040600@netconfcentral.com> <20091207.211036.17465594.mbj@tail-f.com> <20091207203124.GA62625@elstar.local> In-Reply-To: <20091207203124.GA62625@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Filename recommendation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:27:17 -0000 Juergen Schoenwaelder wrote: > On Mon, Dec 07, 2009 at 09:10:36PM +0100, Martin Bjorklund wrote: >> Andy Bierman wrote: >>> If we are going to have a recommendation at all, >>> then we should have one that actually works. >>> It should be obvious that the separator char >>> between the module name and the revision-date >>> cannot be a valid module name character. >> When you say that it doesn't work, do you mean because with the >> current scheme, you cannot have revision '2009-04-01' of the module >> 'foo' in the same directory as you have the module with the name >> 'foo.2009-04-01'? > > For me, this is indeed a concern about corner case that can be easily > avoided by choosing a separator character not allowed in a module > name. This is the technical argument; which character to pick is > probably more a matter of taste. > I do not understand why we didn't catch this obvious bug in the first place, but it seems to me that the separator char needs to deterministic for the lowest interoperability cost. Using a valid field-char as the field-separator-char looks like a dumb bug to any high-school student, so why do we think it represents good standards practice? > /js > Andy From mbj@tail-f.com Tue Dec 15 13: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 11F913A6AFE for ; Tue, 15 Dec 2009 13:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.144, 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 bEMgEUFe3DHv for ; Tue, 15 Dec 2009 13:37:35 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2A7853A6AFB for ; Tue, 15 Dec 2009 13:37:35 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0870876C53A; Tue, 15 Dec 2009 22:37:20 +0100 (CET) Date: Tue, 15 Dec 2009 22:37:19 +0100 (CET) Message-Id: <20091215.223719.173186652.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B27FF57.4040007@iwl.com> References: <20091207.211036.17465594.mbj@tail-f.com> <20091207203124.GA62625@elstar.local> <4B27FF57.4040007@iwl.com> X-Mailer: Mew version 6.2.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] Filename recommendation X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 21:37:36 -0000 Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Mon, Dec 07, 2009 at 09:10:36PM +0100, Martin Bjorklund wrote: > >> Andy Bierman wrote: > >>> If we are going to have a recommendation at all, > >>> then we should have one that actually works. > >>> It should be obvious that the separator char > >>> between the module name and the revision-date > >>> cannot be a valid module name character. > >> When you say that it doesn't work, do you mean because with the > >> current scheme, you cannot have revision '2009-04-01' of the module > >> 'foo' in the same directory as you have the module with the name > >> 'foo.2009-04-01'? > > > > For me, this is indeed a concern about corner case that can be easily > > avoided by choosing a separator character not allowed in a module > > name. This is the technical argument; which character to pick is > > probably more a matter of taste. > > > > I do not understand why we didn't catch this obvious bug > in the first place, but it seems to me that the > separator char needs to deterministic for the lowest > interoperability cost. Ok. I agree we should use '@' as separator. /martin From andyb@iwl.com Tue Dec 15 14:25: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 B782E3A6B1C for ; Tue, 15 Dec 2009 14:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 CmetsoKhCvhI for ; Tue, 15 Dec 2009 14:25:42 -0800 (PST) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by core3.amsl.com (Postfix) with ESMTP id D77223A68DC for ; Tue, 15 Dec 2009 14:25:42 -0800 (PST) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 1364C1B4158; Tue, 15 Dec 2009 17:25:29 -0500 (EST) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id BF9E61B413B; Tue, 15 Dec 2009 17:25:28 -0500 (EST) Message-ID: <4B280D0B.6050605@iwl.com> Date: Tue, 15 Dec 2009 14:26:19 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091207.211036.17465594.mbj@tail-f.com> <20091207203124.GA62625@elstar.local> <4B27FF57.4040007@iwl.com> <20091215.223719.173186652.mbj@tail-f.com> In-Reply-To: <20091215.223719.173186652.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Filename recommendation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:25:43 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Juergen Schoenwaelder wrote: >> >>> On Mon, Dec 07, 2009 at 09:10:36PM +0100, Martin Bjorklund wrote: >>> >>>> Andy Bierman wrote: >>>> >>>>> If we are going to have a recommendation at all, >>>>> then we should have one that actually works. >>>>> It should be obvious that the separator char >>>>> between the module name and the revision-date >>>>> cannot be a valid module name character. >>>>> >>>> When you say that it doesn't work, do you mean because with the >>>> current scheme, you cannot have revision '2009-04-01' of the module >>>> 'foo' in the same directory as you have the module with the name >>>> 'foo.2009-04-01'? >>>> >>> For me, this is indeed a concern about corner case that can be easily >>> avoided by choosing a separator character not allowed in a module >>> name. This is the technical argument; which character to pick is >>> probably more a matter of taste. >>> >>> >> I do not understand why we didn't catch this obvious bug >> in the first place, but it seems to me that the >> separator char needs to deterministic for the lowest >> interoperability cost. >> > > Ok. I agree we should use '@' as separator. > > OK. Can we agree on some text for the revision issue? I prefer to have normative text, not just usage guidelines in this area. > /martin > Andy From andyb@iwl.com Tue Dec 15 14:36: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 D09433A6B24 for ; Tue, 15 Dec 2009 14:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=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 7NMfWvner+cV for ; Tue, 15 Dec 2009 14:36:23 -0800 (PST) Received: from smtp205.dfw.emailsrvr.com (smtp205.dfw.emailsrvr.com [67.192.241.205]) by core3.amsl.com (Postfix) with ESMTP id 15EBC3A68C7 for ; Tue, 15 Dec 2009 14:36:23 -0800 (PST) Received: from relay20.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay20.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 225052128E37 for ; Tue, 15 Dec 2009 17:36:09 -0500 (EST) Received: by relay20.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 05364212871B for ; Tue, 15 Dec 2009 17:36:08 -0500 (EST) Message-ID: <4B280F8B.7060504@iwl.com> Date: Tue, 15 Dec 2009 14:36:59 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:36:23 -0000 Hi, Here's another design hole in YIN: extension fubar { argument xmlns { yin-argument false; } } leaf X { type string; X:fubar "http://acme.com"; } The 'xmlns' name is special for attributes, but not elements. A YANG user might assume that YANG deals with this problem, like it deals with entity replacement and other XML details. That YANG user would be wrong. Andy From mbj@tail-f.com Tue Dec 15 14:46:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012223A6816 for ; Tue, 15 Dec 2009 14:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.140, 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 CSQZWNM7oilt for ; Tue, 15 Dec 2009 14:46:47 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BA7513A684A for ; Tue, 15 Dec 2009 14:46:46 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C505176C53A; Tue, 15 Dec 2009 23:46:31 +0100 (CET) Date: Tue, 15 Dec 2009 23:46:31 +0100 (CET) Message-Id: <20091215.234631.122444428.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <003001ca7d18$44bb67a0$6801a8c0@oemcomputer> References: <4B2627A9.2040704@netconfcentral.com> <20091214.130918.165190776.mbj@tail-f.com> <003001ca7d18$44bb67a0$6801a8c0@oemcomputer> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 22:46:48 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: ; > > Sent: Monday, December 14, 2009 4:09 AM > > Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision > ... > > In SMI, it is legal to expand the value space if the object is an > > enumerated integer or bits. > > Just permitting these limited revisions *has* caused some problems - > they adversely interract with the WRITE-SYNTAX facility from RFC 2580. > If the original version of a module using bits does not use WRITE-SYNTAX > to spell out exactly which values must be supported by a conformant > implementation, a subsequent expansion of the set of BITS will > require that original module to be updated. Otherwise the semantics > of the original module would effectively have been changed, and > that is verboten. And same for enumerations? So is it legal or not to add a bit to a definition in a module which doesn't specifiy a WRITE-SYNTAX? What kind of problems has this resulted in? Hmm - how does this apply to changes in TEXTUAL-CONVENTIONs? > > In YANG it is legal to expand the value > > space for any type. Is this difference the reason we need to require > > import by revision for typedefs in YANG but not in SMI? > > It (and the fact that a higher percentage of the YANG-defined information > will be writeable) makes problem more likely to occur. The idea so far has been that it is ok to expand the value space, which means that old clients trying to write can still do that, but they cannot necessarily understand the value read from the server. Because revisions are advertised, clients can know when this might happen, and can react accordingly. If we don't support this, but require both sides to have 100% same info, we either: 1. require import by revision 2. do not allow any changes to syntax or semantics (only editorial changes) for typedefs and groupings. A consequence of 2 is that we will se typdefs with embedded versioning, like: typedef ipv6-address { ... } typedef ipv6-address-2 { ... } // bugfixed pattern typedef ipv6-address-3 { ... } // bugfixed pattern ... as we have discussed before. Both these scenarios give ripple effects on published modules - if the ietf-foo module uses inet:ipv6-address, we probably need to publish a new revision of ietf-foo as soon as the new ietf-inet-types module is published. /martin From andyb@iwl.com Tue Dec 15 14:57: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 978CE3A6A2B for ; Tue, 15 Dec 2009 14:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=0.685, 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 WHS4Egfpy0lY for ; Tue, 15 Dec 2009 14:57:23 -0800 (PST) Received: from smtp185.dfw.emailsrvr.com (smtp185.dfw.emailsrvr.com [67.192.241.185]) by core3.amsl.com (Postfix) with ESMTP id ABDDA3A684A for ; Tue, 15 Dec 2009 14:57:23 -0800 (PST) Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id F0E2C16F1F0F; Tue, 15 Dec 2009 17:57:09 -0500 (EST) Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 99CF716F1D44; Tue, 15 Dec 2009 17:57:09 -0500 (EST) Message-ID: <4B281478.7060902@iwl.com> Date: Tue, 15 Dec 2009 14:58:00 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B2627A9.2040704@netconfcentral.com> <20091214.130918.165190776.mbj@tail-f.com> <003001ca7d18$44bb67a0$6801a8c0@oemcomputer> <20091215.234631.122444428.mbj@tail-f.com> In-Reply-To: <20091215.234631.122444428.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:57:24 -0000 Martin Bjorklund wrote: > "Randy Presuhn" wrote: > >> Hi - >> >> >>> From: "Martin Bjorklund" >>> To: >>> Cc: ; >>> Sent: Monday, December 14, 2009 4:09 AM >>> Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision >>> >> ... >> >>> In SMI, it is legal to expand the value space if the object is an >>> enumerated integer or bits. >>> >> Just permitting these limited revisions *has* caused some problems - >> they adversely interract with the WRITE-SYNTAX facility from RFC 2580. >> If the original version of a module using bits does not use WRITE-SYNTAX >> to spell out exactly which values must be supported by a conformant >> implementation, a subsequent expansion of the set of BITS will >> require that original module to be updated. Otherwise the semantics >> of the original module would effectively have been changed, and >> that is verboten. >> > > And same for enumerations? So is it legal or not to add a bit to a > definition in a module which doesn't specifiy a WRITE-SYNTAX? What > kind of problems has this resulted in? > > Hmm - how does this apply to changes in TEXTUAL-CONVENTIONs? > > >>> In YANG it is legal to expand the value >>> space for any type. Is this difference the reason we need to require >>> import by revision for typedefs in YANG but not in SMI? >>> >> It (and the fact that a higher percentage of the YANG-defined information >> will be writeable) makes problem more likely to occur. >> > > The idea so far has been that it is ok to expand the value space, > which means that old clients trying to write can still do that, but > they cannot necessarily understand the value read from the server. > Because revisions are advertised, clients can know when this might > happen, and can react accordingly. > > If we don't support this, but require both sides to have 100% same > info, we either: > > 1. require import by revision > 2. do not allow any changes to syntax or semantics (only editorial > changes) for typedefs and groupings. > > A consequence of 2 is that we will se typdefs with embedded > versioning, like: > > typedef ipv6-address { ... } > > typedef ipv6-address-2 { ... } // bugfixed pattern > > typedef ipv6-address-3 { ... } // bugfixed pattern > > ... as we have discussed before. > > Both these scenarios give ripple effects on published modules - if the > ietf-foo module uses inet:ipv6-address, we probably need to publish a > new revision of ietf-foo as soon as the new ietf-inet-types module is > published. > > > I think we want to improve on SMIv2 where we can, especially in this case because there are no formal conformance mechanisms in YANG that provide the same 'static contract' as SMIv2. Contracts are hard enough to understand when the words are not allowed to change. It is important (for compliance) that the contract implied by a YANG module capability URI is understood the same way by all tools. IMO, the 2119 term 'SHOULD' is most appropriate for typedefs because there are corner-cases that could be exempt from the rule without harm. The same is true for groupings as well. If the YANG author(s) can prove to the YANG Experts and IESG that their module is special, then import-by-revision doesn't have to be used. > /martin > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Tue Dec 15 15:08: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 A65C23A684A for ; Tue, 15 Dec 2009 15:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=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 BCdAfUDkfmjv for ; Tue, 15 Dec 2009 15:08:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DDEC93A67DF for ; Tue, 15 Dec 2009 15:08:58 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B472276C53F; Wed, 16 Dec 2009 00:08:44 +0100 (CET) Date: Wed, 16 Dec 2009 00:08:44 +0100 (CET) Message-Id: <20091216.000844.86401256.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B281478.7060902@iwl.com> References: <003001ca7d18$44bb67a0$6801a8c0@oemcomputer> <20091215.234631.122444428.mbj@tail-f.com> <4B281478.7060902@iwl.com> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2009 23:08:59 -0000 Andy Bierman wrote: > IMO, the 2119 term 'SHOULD' is most appropriate > for typedefs because there are corner-cases that > could be exempt from the rule without harm. > The same is true for groupings as well. > If the YANG author(s) can prove to the YANG Experts > and IESG that their module is special, then > import-by-revision doesn't have to be used. I am still not convinced that 'SHOULD' is correct, although I think I agree with the rest of what you're saying - essentially you need to know why you import with or without revision. Let's look at a concrete example, the one and only ietf-ipfix-psamp module. It imports the following types: yang:counter32 yang:counter64 yang:date-and-time inet:domain-name inet:ip-address inet:port-number inet:uri Do you think that using any of these types means that they should use import by revision? /martin From andyb@iwl.com Tue Dec 15 15:25: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 3BB4A3A6405 for ; Tue, 15 Dec 2009 15:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, J_CHICKENPOX_43=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 YnifaqHI+gri for ; Tue, 15 Dec 2009 15:25:43 -0800 (PST) Received: from smtp145.iad.emailsrvr.com (smtp145.iad.emailsrvr.com [207.97.245.145]) by core3.amsl.com (Postfix) with ESMTP id 588D63A68ED for ; Tue, 15 Dec 2009 15:25:43 -0800 (PST) Received: from relay4.r5.iad.mlsrvr.com (localhost [127.0.0.1]) by relay4.r5.iad.mlsrvr.com (SMTP Server) with ESMTP id 83B14CD34; Tue, 15 Dec 2009 18:25:29 -0500 (EST) Received: by relay4.r5.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id DBCD9CDB8; Tue, 15 Dec 2009 18:25:28 -0500 (EST) Message-ID: <4B281B1B.1050306@iwl.com> Date: Tue, 15 Dec 2009 15:26:19 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <003001ca7d18$44bb67a0$6801a8c0@oemcomputer> <20091215.234631.122444428.mbj@tail-f.com> <4B281478.7060902@iwl.com> <20091216.000844.86401256.mbj@tail-f.com> In-Reply-To: <20091216.000844.86401256.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 23:25:44 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> IMO, the 2119 term 'SHOULD' is most appropriate >> for typedefs because there are corner-cases that >> could be exempt from the rule without harm. >> The same is true for groupings as well. >> If the YANG author(s) can prove to the YANG Experts >> and IESG that their module is special, then >> import-by-revision doesn't have to be used. >> > > I am still not convinced that 'SHOULD' is correct, although I think I > agree with the rest of what you're saying - essentially you need to > know why you import with or without revision. > > Let's look at a concrete example, the one and only ietf-ipfix-psamp > module. It imports the following types: > > yang:counter32 > yang:counter64 > yang:date-and-time > > inet:domain-name > inet:ip-address > inet:port-number > inet:uri > > Do you think that using any of these types means that they should use > import by revision? > > Yes -- anything with a pattern, or anything that may ever change in the future. typedef RGB { type enumeration { enum red; enum green; enum blue. } } When the typedef is really simple and cannot conceptually change, then it is safe to omit the revision. An off-line validation tool needs to know what imports are really used for any given module. That alone makes it a SHOULD, IMO. Most importantly, we want to only allow intended, and controlled changes to IETF standards. The entire reason we added import-by-revision was so it could be used to prevent unintended 'drive-by changes' (as Phil put it). Since harm to interoperability is the normal outcome, not the corner-case, all standards-track modules SHOULD follow this rule. > /martin > Andy From j.schoenwaelder@jacobs-university.de Tue Dec 15 15:45: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 D86EF3A691F for ; Tue, 15 Dec 2009 15:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=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 0rmeTx2vIaM8 for ; Tue, 15 Dec 2009 15:45:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DA8D33A67B6 for ; Tue, 15 Dec 2009 15:45:35 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C935CC0015; Wed, 16 Dec 2009 00:45:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fmENswyE8-E4; Wed, 16 Dec 2009 00:45:20 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DED3BC0006; Wed, 16 Dec 2009 00:45:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2483DF746DE; Wed, 16 Dec 2009 00:45:17 +0100 (CET) Date: Wed, 16 Dec 2009 00:45:17 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091215234517.GA76986@elstar.local> Mail-Followup-To: Martin Bjorklund , "andyb@iwl.com" , "netmod@ietf.org" References: <003001ca7d18$44bb67a0$6801a8c0@oemcomputer> <20091215.234631.122444428.mbj@tail-f.com> <4B281478.7060902@iwl.com> <20091216.000844.86401256.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216.000844.86401256.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision 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, 15 Dec 2009 23:45:36 -0000 On Wed, Dec 16, 2009 at 12:08:44AM +0100, Martin Bjorklund wrote: > Let's look at a concrete example, the one and only ietf-ipfix-psamp > module. It imports the following types: > > yang:counter32 > yang:counter64 > yang:date-and-time > > inet:domain-name > inet:ip-address > inet:port-number > inet:uri > > Do you think that using any of these types means that they should use > import by revision? Such examples do not really help since we end up talking about predictions of the future - if I would be good at that, I would not be here. But even in this set of types, I can make a reasonably realistic case that perhaps the IETF decides that not carrying plain UTF8 in DNS was a mistake. Fixing this might then impact inet:domain-name. Sure, the question then for the YANG people would be whether the IETF likes to change inet:domain-name or create a new inet:utf8-domain-name - again we can only guess. Constants that were considered "will never change" have changed in the past and as long as the Internet is not replaced by something completely different, this will continue to be so. /js PS: The yang:date-and-time type carries a four digit year and has a built-in year 10k problem - at that time there is a clear need for a revision ;-) PS: We have been liberal in the interpretation of SMIv2 rules in order to fix bugs and it will at the end remain a judgement call whether a bug fix requires a new revision or not. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Tue Dec 15 16:15: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 A529B3A67AA for ; Tue, 15 Dec 2009 16:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 QlpHAOv0+kAF for ; Tue, 15 Dec 2009 16:15:06 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with SMTP id 1F1383A684F for ; Tue, 15 Dec 2009 16:15:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSygmfLBJwHeTUxGSWs2EPAEODLWMWgJM@postini.com; Tue, 15 Dec 2009 16:14:53 PST 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.393.1; Tue, 15 Dec 2009 16:13:56 -0800 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, 15 Dec 2009 16:13:56 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 16:13:56 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 16:13:56 -0800 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 nBG0Dtj43337; Tue, 15 Dec 2009 16:13:55 -0800 (PST) (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 nBG004Gx058430; Wed, 16 Dec 2009 00:00:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200912160000.nBG004Gx058430@idle.juniper.net> To: andyb@iwl.com In-Reply-To: <4B280F8B.7060504@iwl.com> Date: Tue, 15 Dec 2009 19:00:04 -0500 From: Phil Shafer X-OriginalArrivalTime: 16 Dec 2009 00:13:56.0026 (UTC) FILETIME=[A82171A0:01CA7DE4] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 00:15:07 -0000 Andy Bierman writes: >Here's another design hole in YIN: Not just YIN. This is another design hole in all of YANG. http://www.w3.org/TR/xml/ clearly says: Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification. Your comment applies here also: A YANG user might assume that YANG deals with this problem, like it deals with entity replacement and other XML details. That YANG user would be wrong. I guess our only choice is to fix this in the YANG spec by mirroring the TR's language. Thanks, Phil From mbj@tail-f.com Tue Dec 15 22:44: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 DD94E3A6817 for ; Tue, 15 Dec 2009 22:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=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 TGL4K0lf0-PE for ; Tue, 15 Dec 2009 22:44:55 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C1C1C3A67FC for ; Tue, 15 Dec 2009 22:44:54 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AC56376C53F; Wed, 16 Dec 2009 07:44:39 +0100 (CET) Date: Wed, 16 Dec 2009 07:44:39 +0100 (CET) Message-Id: <20091216.074439.189632350.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091215234517.GA76986@elstar.local> References: <4B281478.7060902@iwl.com> <20091216.000844.86401256.mbj@tail-f.com> <20091215234517.GA76986@elstar.local> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 06:44:56 -0000 Juergen Schoenwaelder wrote: > On Wed, Dec 16, 2009 at 12:08:44AM +0100, Martin Bjorklund wrote: > > > Let's look at a concrete example, the one and only ietf-ipfix-psamp > > module. It imports the following types: > > > > yang:counter32 > > yang:counter64 > > yang:date-and-time > > > > inet:domain-name > > inet:ip-address > > inet:port-number > > inet:uri > > > > Do you think that using any of these types means that they should use > > import by revision? > > Such examples do not really help since we end up talking about > predictions of the future We are discussing guidelines for YANG modules. In these guidelines, the proposal is to add a rule that says that modules SHOULD use import by revision. In trying to understand how this SHOULD should be applied, I think looking at a specific use case makes lots of sense. If we, who created the rule, cannot tell whether it applies or not for a given module, how can we expect others to do that? > But even in this set of types, I can make a reasonably realistic case > that perhaps the IETF decides that not carrying plain UTF8 in DNS was > a mistake. Fixing this might then impact inet:domain-name. Sure, the > question then for the YANG people would be whether the IETF likes to > change inet:domain-name or create a new inet:utf8-domain-name - again > we can only guess. > > Constants that were considered "will never change" have changed in > the past and as long as the Internet is not replaced by something > completely different, this will continue to be so. Exactly. Since we can adapt to the future, do we still need those very strict rules now? /martin From randy_presuhn@mindspring.com Tue Dec 15 23: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 7A6A53A686B for ; Tue, 15 Dec 2009 23:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.991, 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 orkszUDz0FlH for ; Tue, 15 Dec 2009 23:05:19 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5318D3A68B3 for ; Tue, 15 Dec 2009 23:05:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cTcRyGXZXab4vFNmzp5uovceESjHdCWi0ukSVHIsvZuUVYtA+srIH6tpcWcPAq5U; 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 [99.41.55.230] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NKnwX-0004d8-9e for netmod@ietf.org; Wed, 16 Dec 2009 02:05:05 -0500 Message-ID: <003e01ca7e1e$5eb4b420$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4B2627A9.2040704@netconfcentral.com><20091214.130918.165190776.mbj@tail-f.com><003001ca7d18$44bb67a0$6801a8c0@oemcomputer> <20091215.234631.122444428.mbj@tail-f.com> Date: Tue, 15 Dec 2009 23:07:02 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b40aad04ee35c9016486d5931d939afcd89350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.230 Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 07:05:20 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, December 15, 2009 2:46 PM > Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision > > "Randy Presuhn" wrote: > > Hi - > > > > > From: "Martin Bjorklund" > > > To: > > > Cc: ; > > > Sent: Monday, December 14, 2009 4:09 AM > > > Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision > > ... > > > In SMI, it is legal to expand the value space if the object is an > > > enumerated integer or bits. > > > > Just permitting these limited revisions *has* caused some problems - > > they adversely interract with the WRITE-SYNTAX facility from RFC 2580. > > If the original version of a module using bits does not use WRITE-SYNTAX > > to spell out exactly which values must be supported by a conformant > > implementation, a subsequent expansion of the set of BITS will > > require that original module to be updated. Otherwise the semantics > > of the original module would effectively have been changed, and > > that is verboten. > > And same for enumerations? So is it legal or not to add a bit to a > definition in a module which doesn't specifiy a WRITE-SYNTAX? What > kind of problems has this resulted in? It means that a WRITE-SYNTAX has to be added to the conformance material in the updated module so that the conformance material's semantics will be identical to those in the original module. Failure to do so would change the semantics, and that would be asking for interoperability trouble. > Hmm - how does this apply to changes in TEXTUAL-CONVENTIONs? Same issue. Making such a change to a TEXTUAL-CONVENTION can result in the need to add WRITE-SYNTAX to modules that failed to provide them in their original version. My recollection is that this has actually happened in IETF modules. > > > In YANG it is legal to expand the value > > > space for any type. Is this difference the reason we need to require > > > import by revision for typedefs in YANG but not in SMI? It's a question of being able to know *exactly* what the statement "conforms to foo" (where foo is some unit of conformance) means. > > It (and the fact that a higher percentage of the YANG-defined information > > will be writeable) makes problem more likely to occur. > > The idea so far has been that it is ok to expand the value space, > which means that old clients trying to write can still do that, but > they cannot necessarily understand the value read from the server. > Because revisions are advertised, clients can know when this might > happen, and can react accordingly. Is it ok for a conformance test to try to write a value from the expanded space? What it the unit under test doesn't accept such a value. Is it non-conformant? To what? I think the answer is that conformance is evaluated in terms of a specific version of a module, and that this has to be traced through the entire heirarchy of definitions used. Questions like these drove the SMI rules. Netconf doesn't need to have the same rules, but it does need to be absolutely clear about whatever its rules are. > If we don't support this, but require both sides to have 100% same > info, we either: This is asking about interoperability, rather than evaluating conformance. Though the two are related, they're not the same. It's important to understand both. > 1. require import by revision > 2. do not allow any changes to syntax or semantics (only editorial > changes) for typedefs and groupings. > > A consequence of 2 is that we will se typdefs with embedded > versioning, like: > > typedef ipv6-address { ... } > > typedef ipv6-address-2 { ... } // bugfixed pattern > > typedef ipv6-address-3 { ... } // bugfixed pattern > > ... as we have discussed before. > > Both these scenarios give ripple effects on published modules - if the > ietf-foo module uses inet:ipv6-address, we probably need to publish a s/need/want/ > new revision of ietf-foo as soon as the new ietf-inet-types module is > published. That's why I would lean towards 1. Though it means more work (one would have to consciously propagate the "ripples") there are no surprises, and it better reflects what can happen in multi-vendor architectures, especially if there is any kind of subagent-like delegation. (I don't know whether netconf is going to ever deal with systems where these issues arise.) But that's also why I'd lean towards a keeping "library" definitions one (or some number very close to 1) to a module, to minimize "colateral damage". Randy From j.schoenwaelder@jacobs-university.de Wed Dec 16 00:23: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 38F543A693E for ; Wed, 16 Dec 2009 00:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=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 o3q81ywTjSh8 for ; Wed, 16 Dec 2009 00:23:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DC75E3A67F2 for ; Wed, 16 Dec 2009 00:22:59 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 962FAC0006; Wed, 16 Dec 2009 09:22:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vtw379QR5Bp4; Wed, 16 Dec 2009 09:22:44 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67CD2C0004; Wed, 16 Dec 2009 09:22:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1BAAFF75382; Wed, 16 Dec 2009 09:22:41 +0100 (CET) Date: Wed, 16 Dec 2009 09:22:41 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091216082241.GA77894@elstar.local> Mail-Followup-To: Martin Bjorklund , "andyb@iwl.com" , "netmod@ietf.org" References: <4B281478.7060902@iwl.com> <20091216.000844.86401256.mbj@tail-f.com> <20091215234517.GA76986@elstar.local> <20091216.074439.189632350.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216.074439.189632350.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision 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, 16 Dec 2009 08:23:01 -0000 On Wed, Dec 16, 2009 at 07:44:39AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Dec 16, 2009 at 12:08:44AM +0100, Martin Bjorklund wrote: > > > > > Let's look at a concrete example, the one and only ietf-ipfix-psamp > > > module. It imports the following types: > > > > > > yang:counter32 > > > yang:counter64 > > > yang:date-and-time > > > > > > inet:domain-name > > > inet:ip-address > > > inet:port-number > > > inet:uri > > > > > > Do you think that using any of these types means that they should use > > > import by revision? > > > > Such examples do not really help since we end up talking about > > predictions of the future > > We are discussing guidelines for YANG modules. In these guidelines, > the proposal is to add a rule that says that modules SHOULD use import > by revision. In trying to understand how this SHOULD should be > applied, I think looking at a specific use case makes lots of sense. > > If we, who created the rule, cannot tell whether it applies or not for > a given module, how can we expect others to do that? My interpretation of SHOULD is that if you do not have a strong argument for not following the SHOULD, you should follow it. Applied to this case, if we do not have a strong argument otherwise, we import by revision. > > But even in this set of types, I can make a reasonably realistic case > > that perhaps the IETF decides that not carrying plain UTF8 in DNS was > > a mistake. Fixing this might then impact inet:domain-name. Sure, the > > question then for the YANG people would be whether the IETF likes to > > change inet:domain-name or create a new inet:utf8-domain-name - again > > we can only guess. > > > > Constants that were considered "will never change" have changed in > > the past and as long as the Internet is not replaced by something > > completely different, this will continue to be so. > > Exactly. Since we can adapt to the future, do we still need those > very strict rules now? Import by revision is an insurrance against future trouble. Whether an insurrance is needed always going to be a trade-off decision. A SHOULD essentially says that if you have no particular strong reason to not have an insurrance, pick one. /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 Dec 16 00: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 038E43A6782 for ; Wed, 16 Dec 2009 00:43:03 -0800 (PST) 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.138, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=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 4Wd9sPwwa8oj for ; Wed, 16 Dec 2009 00:43:02 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E92393A659C for ; Wed, 16 Dec 2009 00:43:01 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2FD1776C548; Wed, 16 Dec 2009 09:42:47 +0100 (CET) Date: Wed, 16 Dec 2009 09:42:46 +0100 (CET) Message-Id: <20091216.094246.120666073.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091216082241.GA77894@elstar.local> References: <20091215234517.GA76986@elstar.local> <20091216.074439.189632350.mbj@tail-f.com> <20091216082241.GA77894@elstar.local> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 08:43:03 -0000 Juergen Schoenwaelder wrote: > On Wed, Dec 16, 2009 at 07:44:39AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Wed, Dec 16, 2009 at 12:08:44AM +0100, Martin Bjorklund wrote: > > > > > > > Let's look at a concrete example, the one and only ietf-ipfix-psamp > > > > module. It imports the following types: > > > > > > > > yang:counter32 > > > > yang:counter64 > > > > yang:date-and-time > > > > > > > > inet:domain-name > > > > inet:ip-address > > > > inet:port-number > > > > inet:uri > > > > > > > > Do you think that using any of these types means that they should use > > > > import by revision? > > > > > > Such examples do not really help since we end up talking about > > > predictions of the future > > > > We are discussing guidelines for YANG modules. In these guidelines, > > the proposal is to add a rule that says that modules SHOULD use import > > by revision. In trying to understand how this SHOULD should be > > applied, I think looking at a specific use case makes lots of sense. > > > > If we, who created the rule, cannot tell whether it applies or not for > > a given module, how can we expect others to do that? > > My interpretation of SHOULD is that if you do not have a strong > argument for not following the SHOULD, you should follow it. Yes. > Applied > to this case, if we do not have a strong argument otherwise, we import > by revision. I am wondering if 'SHOULD' is correct by trying to apply the rule to this case. Personally, I don't think that this module should import ietf-yang-types or ietf-inet-types by revision. Suppose we find a bug in the ipv6 address pattern and fix it. Now, until we fix and republish ietf-ipfix-psamp, we force implementations to use the buggy pattern. Maybe the guidelines document for ietf modules should be more strict in how typedefs and groupings are allowed to be changed instead (I'm not really sure that it is necessary b/c I think we won't make random changes to these typdefs anyway...) > Import by revision is an insurrance against future trouble. Whether an > insurrance is needed always going to be a trade-off decision. A SHOULD > essentially says that if you have no particular strong reason to not > have an insurrance, pick one. I agree there is a trade-off, and I agree that you need to think about the problem, but I am not convinced that it is correct to give a guideline that says that import by revision is preferred. /martin From j.schoenwaelder@jacobs-university.de Wed Dec 16 01:17: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 C952C3A6977 for ; Wed, 16 Dec 2009 01:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[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 e1IdDbmkyFTw for ; Wed, 16 Dec 2009 01:17:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CD6063A67B2 for ; Wed, 16 Dec 2009 01:16:42 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF6F2C0006; Wed, 16 Dec 2009 10:16:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RXYg8L5l4VaM; Wed, 16 Dec 2009 10:16:27 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABAF5C0004; Wed, 16 Dec 2009 10:16:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E5931F7566B; Wed, 16 Dec 2009 10:16:24 +0100 (CET) Date: Wed, 16 Dec 2009 10:16:24 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091216091624.GA78090@elstar.local> Mail-Followup-To: Martin Bjorklund , "andyb@iwl.com" , "netmod@ietf.org" References: <20091215234517.GA76986@elstar.local> <20091216.074439.189632350.mbj@tail-f.com> <20091216082241.GA77894@elstar.local> <20091216.094246.120666073.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216.094246.120666073.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision 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, 16 Dec 2009 09:17:01 -0000 On Wed, Dec 16, 2009 at 09:42:46AM +0100, Martin Bjorklund wrote: > > Applied > > to this case, if we do not have a strong argument otherwise, we import > > by revision. > > I am wondering if 'SHOULD' is correct by trying to apply the rule to > this case. > > Personally, I don't think that this module should import > ietf-yang-types or ietf-inet-types by revision. Suppose we find a bug > in the ipv6 address pattern and fix it. Now, until we fix and > republish ietf-ipfix-psamp, we force implementations to use the buggy > pattern. The counter argument of course is that without import by revision, you simply do not know which version a device implements and which bugs to reasonably expect to be present. Not sure this makes interoperability simpler. Anyway, we get here into IETF process details and discussions we have probably every 2-3 years on how to improve things - so far without much changes resulting form such discussions. The question here is whether a republication of ietf-ipfix-psamp is needed or just of the delta. Are we ready to have another instantiation of this process discussion? > Maybe the guidelines document for ietf modules should be more strict > in how typedefs and groupings are allowed to be changed instead (I'm > not really sure that it is necessary b/c I think we won't make random > changes to these typdefs anyway...) We do not make random changes, but we do make random errors. The good news is that the SMIv2 core TCs have stabilized relatively quickly and thus the problem might in practice not pop up (but if it does, then we need to be creative). My only concern here is probably that the amount of technical review the yang data types document has enjoyed may not have been sufficient. > > Import by revision is an insurrance against future trouble. Whether an > > insurrance is needed always going to be a trade-off decision. A SHOULD > > essentially says that if you have no particular strong reason to not > > have an insurrance, pick one. > > I agree there is a trade-off, and I agree that you need to think about > the problem, but I am not convinced that it is correct to give a > guideline that says that import by revision is preferred. Its an insurrance and whether you need one or not or it bites you is hard to judge. The only way out could be text suggesting import by revision and requiring in case import by revision is not needed that text is added in an appropriate place why it is safe to not use import by revision. Since at the end, the judgement call depends on what is imported and how it is being used. Now, requesting such text is easily written down; implementing the necessary review of this is where the price for it is. /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 Dec 16 01:34: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 543483A69AA for ; Wed, 16 Dec 2009 01:34:04 -0800 (PST) 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 cT79aKJfLh2H for ; Wed, 16 Dec 2009 01:34:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 783B93A6809 for ; Wed, 16 Dec 2009 01:34:03 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A74976C548; Wed, 16 Dec 2009 10:33:49 +0100 (CET) Date: Wed, 16 Dec 2009 10:33:48 +0100 (CET) Message-Id: <20091216.103348.25470400.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091216091624.GA78090@elstar.local> References: <20091216082241.GA77894@elstar.local> <20091216.094246.120666073.mbj@tail-f.com> <20091216091624.GA78090@elstar.local> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 09:34:04 -0000 Juergen Schoenwaelder wrote: > On Wed, Dec 16, 2009 at 09:42:46AM +0100, Martin Bjorklund wrote: > > > > Applied > > > to this case, if we do not have a strong argument otherwise, we import > > > by revision. > > > > I am wondering if 'SHOULD' is correct by trying to apply the rule to > > this case. > > > > Personally, I don't think that this module should import > > ietf-yang-types or ietf-inet-types by revision. Suppose we find a bug > > in the ipv6 address pattern and fix it. Now, until we fix and > > republish ietf-ipfix-psamp, we force implementations to use the buggy > > pattern. > > The counter argument of course is that without import by revision, you > simply do not know which version a device implements and which bugs to > reasonably expect to be present. Yes you do - the device advertises all modules it implements. > Not sure this makes interoperability > simpler. Anyway, we get here into IETF process details and discussions > we have probably every 2-3 years on how to improve things - so far > without much changes resulting form such discussions. The question > here is whether a republication of ietf-ipfix-psamp is needed or just > of the delta. Are we ready to have another instantiation of this > process discussion? > > > Maybe the guidelines document for ietf modules should be more strict > > in how typedefs and groupings are allowed to be changed instead (I'm > > not really sure that it is necessary b/c I think we won't make random > > changes to these typdefs anyway...) > > We do not make random changes, but we do make random errors. And that's why it should be ok to import without revision. /martin From j.schoenwaelder@jacobs-university.de Wed Dec 16 01:58: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 918EC3A68A4 for ; Wed, 16 Dec 2009 01:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, 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 8Mlwr0x3f4TU for ; Wed, 16 Dec 2009 01:58:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7505D3A67DD for ; Wed, 16 Dec 2009 01:58:51 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C104C0015; Wed, 16 Dec 2009 10:58:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ytsNYJm8CLCz; Wed, 16 Dec 2009 10:58:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59D9FC0009; Wed, 16 Dec 2009 10:58:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2D2BCF7585D; Wed, 16 Dec 2009 10:58:33 +0100 (CET) Date: Wed, 16 Dec 2009 10:58:33 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091216095833.GA78160@elstar.local> Mail-Followup-To: Martin Bjorklund , "andyb@iwl.com" , "netmod@ietf.org" References: <20091216082241.GA77894@elstar.local> <20091216.094246.120666073.mbj@tail-f.com> <20091216091624.GA78090@elstar.local> <20091216.103348.25470400.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216.103348.25470400.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision 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, 16 Dec 2009 09:58:52 -0000 On Wed, Dec 16, 2009 at 10:33:48AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Dec 16, 2009 at 09:42:46AM +0100, Martin Bjorklund wrote: > > > > > > Applied > > > > to this case, if we do not have a strong argument otherwise, we import > > > > by revision. > > > > > > I am wondering if 'SHOULD' is correct by trying to apply the rule to > > > this case. > > > > > > Personally, I don't think that this module should import > > > ietf-yang-types or ietf-inet-types by revision. Suppose we find a bug > > > in the ipv6 address pattern and fix it. Now, until we fix and > > > republish ietf-ipfix-psamp, we force implementations to use the buggy > > > pattern. > > > > The counter argument of course is that without import by revision, you > > simply do not know which version a device implements and which bugs to > > reasonably expect to be present. > > Yes you do - the device advertises all modules it implements. Assuming the world is simple and everything is monolithic and using the same revisions of modules they import. Anyway, I am not fighting strongly in favour of a SHOULD. The point is more that module authors and reviewers need to understand the implications and like in the insurrance model, we likely will have continued discussions on this - unless your point is that import by revision is not needed at all. /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 Dec 16 02:06: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 561423A692C for ; Wed, 16 Dec 2009 02:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.161, 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 vXvcdO-EQ1hZ for ; Wed, 16 Dec 2009 02:06:49 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7FA323A6941 for ; Wed, 16 Dec 2009 02:06:49 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8097D76C548; Wed, 16 Dec 2009 11:06:34 +0100 (CET) Date: Wed, 16 Dec 2009 11:06:34 +0100 (CET) Message-Id: <20091216.110634.44083393.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091216095833.GA78160@elstar.local> References: <20091216091624.GA78090@elstar.local> <20091216.103348.25470400.mbj@tail-f.com> <20091216095833.GA78160@elstar.local> X-Mailer: Mew version 6.2.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-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 10:06:50 -0000 Juergen Schoenwaelder wrote: > Anyway, I am not fighting strongly in favour of a SHOULD. The point is > more that module authors and reviewers need to understand the > implications and like in the insurrance model, we likely will have > continued discussions on this - unless your point is that import by > revision is not needed at all. No. My point is that I don't think we should use 'SHOULD', and that: > [...] module authors and reviewers need to understand the > implications and like in the insurrance model /martin From andyb@iwl.com Wed Dec 16 03:01: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 C6C363A659C for ; Wed, 16 Dec 2009 03:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.587, 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 elLuPvaE0oQb for ; Wed, 16 Dec 2009 03:01:44 -0800 (PST) Received: from smtp185.dfw.emailsrvr.com (smtp185.dfw.emailsrvr.com [67.192.241.185]) by core3.amsl.com (Postfix) with ESMTP id 1F5E73A69C7 for ; Wed, 16 Dec 2009 03:01:44 -0800 (PST) Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 34E4A16F1D1A; Wed, 16 Dec 2009 06:01:30 -0500 (EST) Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id EC7A516F1B6E; Wed, 16 Dec 2009 06:01:29 -0500 (EST) Message-ID: <4B28BE41.60801@iwl.com> Date: Wed, 16 Dec 2009 03:02:25 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091216091624.GA78090@elstar.local> <20091216.103348.25470400.mbj@tail-f.com> <20091216095833.GA78160@elstar.local> <20091216.110634.44083393.mbj@tail-f.com> In-Reply-To: <20091216.110634.44083393.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-usage-02; sec 4.6, import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 11:01:44 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > >> Anyway, I am not fighting strongly in favour of a SHOULD. The point is >> more that module authors and reviewers need to understand the >> implications and like in the insurrance model, we likely will have >> continued discussions on this - unless your point is that import by >> revision is not needed at all. >> > > No. My point is that I don't think we should use 'SHOULD', and that: > > I think Juergen and Randy have explained why we want the conformance requirements for a particular revision of a particular module to be precise, and why SHOULD is the best default choice. IMO, SHOULD is very important here, especially since off-line validation is so important to the WG. I want to be able to extract a YANG module from any RFC and have an extremely high degree of confidence that every YANG tool in the world will parse the exact same YANG statements from this extracted module. Whether changes to the published module are bug fixes, enhancements, or a rewrite makes no difference. For conformance purposes, the 'RFC XXXX' version of the 'foo' module needs to mean exactly the same thing to every YANG implementation, even off-line validation tools. >> [...] module authors and reviewers need to understand the >> implications and like in the insurrance model >> > > > > /martin > Andy From andyb@iwl.com Wed Dec 16 05:02: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 2605B3A67FD for ; Wed, 16 Dec 2009 05:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.514, 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 tgtMVo1loChL for ; Wed, 16 Dec 2009 05:02:31 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 6B9413A68AB for ; Wed, 16 Dec 2009 05:02:31 -0800 (PST) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 636249088C1; Wed, 16 Dec 2009 08:02:07 -0500 (EST) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 330889087AC; Wed, 16 Dec 2009 08:02:07 -0500 (EST) Message-ID: <4B28DA87.4010504@iwl.com> Date: Wed, 16 Dec 2009 05:03:03 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200912160000.nBG004Gx058430@idle.juniper.net> In-Reply-To: <200912160000.nBG004Gx058430@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:02:32 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Here's another design hole in YIN: > > Not just YIN. This is another design hole in all of YANG. > http://www.w3.org/TR/xml/ clearly says: > > Names beginning with the string "xml", or with any string which > would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for > standardization in this or future versions of this specification. > > Your comment applies here also: > > A YANG user might assume that YANG deals with > this problem, like it deals with entity replacement > and other XML details. That YANG user would be wrong. > > I guess our only choice is to fix this in the YANG spec > by mirroring the TR's language. > This applies to all elements and attributes? Talk about CLRs! I guess the W3C can't avoid them either. So this would affect all YANG keywords, all extension names, and all extension argument names, right? It does not affect any other YANG argument string values, right? > Thanks, > Phil Andy From andyb@iwl.com Wed Dec 16 05:08: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 0EFB73A67E9 for ; Wed, 16 Dec 2009 05:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.457, 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 N2AKSEDgfuYc for ; Wed, 16 Dec 2009 05:08:08 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 5C44E3A6405 for ; Wed, 16 Dec 2009 05:08:08 -0800 (PST) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 84E7190876F; Wed, 16 Dec 2009 08:07:54 -0500 (EST) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 48CC1908663; Wed, 16 Dec 2009 08:07:54 -0500 (EST) Message-ID: <4B28DBE2.1050704@iwl.com> Date: Wed, 16 Dec 2009 05:08:50 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: andyb@iwl.com References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> In-Reply-To: <4B28DA87.4010504@iwl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:08:09 -0000 Andy Bierman wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>> Here's another design hole in YIN: >> Not just YIN. This is another design hole in all of YANG. >> http://www.w3.org/TR/xml/ clearly says: >> >> Names beginning with the string "xml", or with any string which >> would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for >> standardization in this or future versions of this specification. >> >> Your comment applies here also: >> >> A YANG user might assume that YANG deals with >> this problem, like it deals with entity replacement >> and other XML details. That YANG user would be wrong. >> >> I guess our only choice is to fix this in the YANG spec >> by mirroring the TR's language. >> > > This applies to all elements and attributes? > > Talk about CLRs! > I guess the W3C can't avoid them either. > > So this would affect all YANG keywords, > all extension names, and all extension argument names, right? > It does not affect any other YANG argument string values, right? > oops, forgot rpc-stmt and notification-stmt names. >> Thanks, >> Phil > > Andy Andy From mbj@tail-f.com Wed Dec 16 05:09: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 6ED0F3A6405 for ; Wed, 16 Dec 2009 05:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.151, 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 vhEL01PXBoN9 for ; Wed, 16 Dec 2009 05:09:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9652D3A63C9 for ; Wed, 16 Dec 2009 05:09:29 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B1A1F76C548; Wed, 16 Dec 2009 14:09:14 +0100 (CET) Date: Wed, 16 Dec 2009 14:09:14 +0100 (CET) Message-Id: <20091216.140914.162134266.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B28DA87.4010504@iwl.com> References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> X-Mailer: Mew version 6.2.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] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 13:09:30 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> Here's another design hole in YIN: > > > > Not just YIN. This is another design hole in all of YANG. > > http://www.w3.org/TR/xml/ clearly says: > > > > Names beginning with the string "xml", or with any string which > > would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for > > standardization in this or future versions of this specification. > > > > Your comment applies here also: > > > > A YANG user might assume that YANG deals with > > this problem, like it deals with entity replacement > > and other XML details. That YANG user would be wrong. > > > > I guess our only choice is to fix this in the YANG spec > > by mirroring the TR's language. > > > > This applies to all elements and attributes? > > Talk about CLRs! > I guess the W3C can't avoid them either. > > So this would affect all YANG keywords, > all extension names, and all extension argument names, right? > It does not affect any other YANG argument string values, right? Right. I think the simplest fix is to make this rule part of a 'identifier'. It is actually a bit too broad, since an 'identifier' for a choice or module, for example, could start with "xml" without any problem. The alternative is to introduce another type of identifier which we use for selected keywords. /martin From lhotka@cesnet.cz Wed Dec 16 05:22: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 A3CF43A6892 for ; Wed, 16 Dec 2009 05:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 LLaT0sA8V5Sh for ; Wed, 16 Dec 2009 05:22:18 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 912B63A6881 for ; Wed, 16 Dec 2009 05:22:18 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D8829D800D1; Wed, 16 Dec 2009 14:22:03 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091216.140914.162134266.mbj@tail-f.com> References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> <20091216.140914.162134266.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 16 Dec 2009 14:22:02 +0100 Message-ID: <1260969722.1514.72.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 13:22:19 -0000 Martin Bjorklund píše v St 16. 12. 2009 v 14:09 +0100: > Andy Bierman wrote: > > Phil Shafer wrote: > > > Andy Bierman writes: > > >> Here's another design hole in YIN: > > > > > > Not just YIN. This is another design hole in all of YANG. > > > http://www.w3.org/TR/xml/ clearly says: > > > > > > Names beginning with the string "xml", or with any string which > > > would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for > > > standardization in this or future versions of this specification. > > > > > > Your comment applies here also: > > > > > > A YANG user might assume that YANG deals with > > > this problem, like it deals with entity replacement > > > and other XML details. That YANG user would be wrong. > > > > > > I guess our only choice is to fix this in the YANG spec > > > by mirroring the TR's language. > > > > > > > This applies to all elements and attributes? > > > > Talk about CLRs! > > I guess the W3C can't avoid them either. > > > > So this would affect all YANG keywords, > > all extension names, and all extension argument names, right? > > It does not affect any other YANG argument string values, right? > > Right. I think the simplest fix is to make this rule part of a > 'identifier'. It is actually a bit too broad, since an 'identifier' > for a choice or module, for example, could start with "xml" without > any problem. The alternative is to introduce another type of > identifier which we use for selected keywords. > Actually, the XML Namespaces REC says that names like foo:xmlns are not reserved, but it is definitely better to state the rule as you suggest. Lada > /martin > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed Dec 16 05:37: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 528633A68A5 for ; Wed, 16 Dec 2009 05:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAl+4C073MJs for ; Wed, 16 Dec 2009 05:37:57 -0800 (PST) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id B95C43A688B for ; Wed, 16 Dec 2009 05:37:55 -0800 (PST) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 71CF517FED3; Wed, 16 Dec 2009 08:37:41 -0500 (EST) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3180E17FEC1; Wed, 16 Dec 2009 08:37:41 -0500 (EST) Message-ID: <4B28E2DE.3000104@iwl.com> Date: Wed, 16 Dec 2009 05:38:38 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> <20091216.140914.162134266.mbj@tail-f.com> <1260969722.1514.72.camel@missotis> In-Reply-To: <1260969722.1514.72.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:37:58 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v St 16. 12. 2009 v 14:09 +0100: >> Andy Bierman wrote: >>> Phil Shafer wrote: >>>> Andy Bierman writes: >>>>> Here's another design hole in YIN: >>>> Not just YIN. This is another design hole in all of YANG. >>>> http://www.w3.org/TR/xml/ clearly says: >>>> >>>> Names beginning with the string "xml", or with any string which >>>> would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for >>>> standardization in this or future versions of this specification. >>>> >>>> Your comment applies here also: >>>> >>>> A YANG user might assume that YANG deals with >>>> this problem, like it deals with entity replacement >>>> and other XML details. That YANG user would be wrong. >>>> >>>> I guess our only choice is to fix this in the YANG spec >>>> by mirroring the TR's language. >>>> >>> This applies to all elements and attributes? >>> >>> Talk about CLRs! >>> I guess the W3C can't avoid them either. >>> >>> So this would affect all YANG keywords, >>> all extension names, and all extension argument names, right? >>> It does not affect any other YANG argument string values, right? >> Right. I think the simplest fix is to make this rule part of a >> 'identifier'. It is actually a bit too broad, since an 'identifier' >> for a choice or module, for example, could start with "xml" without >> any problem. The alternative is to introduce another type of >> identifier which we use for selected keywords. >> > > Actually, the XML Namespaces REC says that names like foo:xmlns are not > reserved, but it is definitely better to state the rule as you suggest. > When does a container, leaf, leaf-list, or leaf name show up in an XML element or attribute name? container xml; I think it only applies to 'container' and 'name' in this example. > Lada > >> /martin >> Andy From andyb@iwl.com Wed Dec 16 05:40: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 09C6A3A6405 for ; Wed, 16 Dec 2009 05:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a38kl8SiSfA6 for ; Wed, 16 Dec 2009 05:40:50 -0800 (PST) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 4D8D73A6880 for ; Wed, 16 Dec 2009 05:40:50 -0800 (PST) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 55CF317FE72; Wed, 16 Dec 2009 08:40:36 -0500 (EST) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 237D117FECD; Wed, 16 Dec 2009 08:40:36 -0500 (EST) Message-ID: <4B28E38D.9040803@iwl.com> Date: Wed, 16 Dec 2009 05:41:33 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> <20091216.140914.162134266.mbj@tail-f.com> <1260969722.1514.72.camel@missotis> <4B28E2DE.3000104@iwl.com> In-Reply-To: <4B28E2DE.3000104@iwl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:40:51 -0000 Andy Bierman wrote: > Ladislav Lhotka wrote: > >> Martin Bjorklund píše v St 16. 12. 2009 v 14:09 +0100: >> >>> Andy Bierman wrote: >>> >>>> Phil Shafer wrote: >>>> >>>>> Andy Bierman writes: >>>>> >>>>>> Here's another design hole in YIN: >>>>>> >>>>> Not just YIN. This is another design hole in all of YANG. >>>>> http://www.w3.org/TR/xml/ clearly says: >>>>> >>>>> Names beginning with the string "xml", or with any string which >>>>> would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for >>>>> standardization in this or future versions of this specification. >>>>> >>>>> Your comment applies here also: >>>>> >>>>> A YANG user might assume that YANG deals with >>>>> this problem, like it deals with entity replacement >>>>> and other XML details. That YANG user would be wrong. >>>>> >>>>> I guess our only choice is to fix this in the YANG spec >>>>> by mirroring the TR's language. >>>>> >>>>> >>>> This applies to all elements and attributes? >>>> >>>> Talk about CLRs! >>>> I guess the W3C can't avoid them either. >>>> >>>> So this would affect all YANG keywords, >>>> all extension names, and all extension argument names, right? >>>> It does not affect any other YANG argument string values, right? >>>> >>> Right. I think the simplest fix is to make this rule part of a >>> 'identifier'. It is actually a bit too broad, since an 'identifier' >>> for a choice or module, for example, could start with "xml" without >>> any problem. The alternative is to introduce another type of >>> identifier which we use for selected keywords. >>> >>> >> Actually, the XML Namespaces REC says that names like foo:xmlns are not >> reserved, but it is definitely better to state the rule as you suggest. >> >> > > When does a container, leaf, leaf-list, or leaf name show up > in an XML element or attribute name? > > container xml; > > > > I think it only applies to 'container' and 'name' in this example. > > oops, never mind. NETCONF databases have identifiers encoded as element names. >> Lada >> >> >>> /martin >>> >>> > > Andy > Andy From mbj@tail-f.com Wed Dec 16 05:43: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 529AC3A65A5 for ; Wed, 16 Dec 2009 05:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 4qCowRUzTQtu for ; Wed, 16 Dec 2009 05:43:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 341273A6405 for ; Wed, 16 Dec 2009 05:43:03 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0CDF476C54C; Wed, 16 Dec 2009 14:42:49 +0100 (CET) Date: Wed, 16 Dec 2009 14:42:48 +0100 (CET) Message-Id: <20091216.144248.213279001.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B28E2DE.3000104@iwl.com> References: <20091216.140914.162134266.mbj@tail-f.com> <1260969722.1514.72.camel@missotis> <4B28E2DE.3000104@iwl.com> X-Mailer: Mew version 6.2.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] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 13:43:04 -0000 QW5keSBCaWVybWFuIDxhbmR5YkBpd2wuY29tPiB3cm90ZToNCj4gTGFkaXNsYXYgTGhvdGthIHdy b3RlOg0KPiA+IE1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgU3QgMTYuIDEyLiAyMDA5IHYgMTQ6 MDkgKzAxMDA6DQo+ID4+IEFuZHkgQmllcm1hbiA8YW5keWJAaXdsLmNvbT4gd3JvdGU6DQo+ID4+ PiBQaGlsIFNoYWZlciB3cm90ZToNCj4gPj4+PiBBbmR5IEJpZXJtYW4gd3JpdGVzOg0KPiA+Pj4+ PiBIZXJlJ3MgYW5vdGhlciBkZXNpZ24gaG9sZSBpbiBZSU46DQo+ID4+Pj4gTm90IGp1c3QgWUlO LiAgVGhpcyBpcyBhbm90aGVyIGRlc2lnbiBob2xlIGluIGFsbCBvZiBZQU5HLg0KPiA+Pj4+IGh0 dHA6Ly93d3cudzMub3JnL1RSL3htbC8gY2xlYXJseSBzYXlzOg0KPiA+Pj4+DQo+ID4+Pj4gICAg TmFtZXMgYmVnaW5uaW5nIHdpdGggdGhlIHN0cmluZyAieG1sIiwgb3Igd2l0aCBhbnkgc3RyaW5n IHdoaWNoDQo+ID4+Pj4gICAgd291bGQgbWF0Y2ggKCgnWCd8J3gnKSAoJ00nfCdtJykgKCdMJ3wn bCcpKSwgYXJlIHJlc2VydmVkIGZvcg0KPiA+Pj4+ICAgIHN0YW5kYXJkaXphdGlvbiBpbiB0aGlz IG9yIGZ1dHVyZSB2ZXJzaW9ucyBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQo+ID4+Pj4NCj4gPj4+ PiBZb3VyIGNvbW1lbnQgYXBwbGllcyBoZXJlIGFsc286DQo+ID4+Pj4NCj4gPj4+PiAgICBBIFlB TkcgdXNlciBtaWdodCBhc3N1bWUgdGhhdCBZQU5HIGRlYWxzIHdpdGgNCj4gPj4+PiAgICB0aGlz IHByb2JsZW0sIGxpa2UgaXQgZGVhbHMgd2l0aCBlbnRpdHkgcmVwbGFjZW1lbnQNCj4gPj4+PiAg ICBhbmQgb3RoZXIgWE1MIGRldGFpbHMuICBUaGF0IFlBTkcgdXNlciB3b3VsZCBiZSB3cm9uZy4N Cj4gPj4+Pg0KPiA+Pj4+IEkgZ3Vlc3Mgb3VyIG9ubHkgY2hvaWNlIGlzIHRvIGZpeCB0aGlzIGlu IHRoZSBZQU5HIHNwZWMNCj4gPj4+PiBieSBtaXJyb3JpbmcgdGhlIFRSJ3MgbGFuZ3VhZ2UuDQo+ ID4+Pj4NCj4gPj4+IFRoaXMgYXBwbGllcyB0byBhbGwgZWxlbWVudHMgYW5kIGF0dHJpYnV0ZXM/ DQo+ID4+Pg0KPiA+Pj4gVGFsayBhYm91dCBDTFJzIQ0KPiA+Pj4gSSBndWVzcyB0aGUgVzNDIGNh bid0IGF2b2lkIHRoZW0gZWl0aGVyLg0KPiA+Pj4NCj4gPj4+IFNvIHRoaXMgd291bGQgYWZmZWN0 IGFsbCBZQU5HIGtleXdvcmRzLA0KPiA+Pj4gYWxsIGV4dGVuc2lvbiBuYW1lcywgYW5kIGFsbCBl eHRlbnNpb24gYXJndW1lbnQgbmFtZXMsIHJpZ2h0Pw0KPiA+Pj4gSXQgZG9lcyBub3QgYWZmZWN0 IGFueSBvdGhlciBZQU5HIGFyZ3VtZW50IHN0cmluZyB2YWx1ZXMsIHJpZ2h0Pw0KPiA+PiBSaWdo dC4gIEkgdGhpbmsgdGhlIHNpbXBsZXN0IGZpeCBpcyB0byBtYWtlIHRoaXMgcnVsZSBwYXJ0IG9m IGENCj4gPj4gJ2lkZW50aWZpZXInLiAgSXQgaXMgYWN0dWFsbHkgYSBiaXQgdG9vIGJyb2FkLCBz aW5jZSBhbiAnaWRlbnRpZmllcicNCj4gPj4gZm9yIGEgY2hvaWNlIG9yIG1vZHVsZSwgZm9yIGV4 YW1wbGUsIGNvdWxkIHN0YXJ0IHdpdGggInhtbCIgd2l0aG91dA0KPiA+PiBhbnkgcHJvYmxlbS4g IFRoZSBhbHRlcm5hdGl2ZSBpcyB0byBpbnRyb2R1Y2UgYW5vdGhlciB0eXBlIG9mDQo+ID4+IGlk ZW50aWZpZXIgd2hpY2ggd2UgdXNlIGZvciBzZWxlY3RlZCBrZXl3b3Jkcy4NCj4gPj4NCj4gPiAN Cj4gPiBBY3R1YWxseSwgdGhlIFhNTCBOYW1lc3BhY2VzIFJFQyBzYXlzIHRoYXQgbmFtZXMgbGlr ZSBmb286eG1sbnMgYXJlIG5vdA0KPiA+IHJlc2VydmVkLCBidXQgaXQgaXMgZGVmaW5pdGVseSBi ZXR0ZXIgdG8gc3RhdGUgdGhlIHJ1bGUgYXMgeW91IHN1Z2dlc3QuDQo+ID4gDQo+IA0KPiBXaGVu IGRvZXMgYSBjb250YWluZXIsIGxlYWYsIGxlYWYtbGlzdCwgb3IgbGVhZiBuYW1lIHNob3cgdXAN Cj4gaW4gYW4gWE1MIGVsZW1lbnQgb3IgYXR0cmlidXRlIG5hbWU/DQoNCiAgbGVhZiBmb28geyAu Li4gfQ0KDQpJbiBORVRDT05GOg0KDQogIDxmb28+NDI8L2Zvbz4NCg0KDQovbWFydGluDQo= From lhotka@cesnet.cz Wed Dec 16 05:46: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 41F133A68A2 for ; Wed, 16 Dec 2009 05:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.024 X-Spam-Level: X-Spam-Status: No, score=-0.024 tagged_above=-999 required=5 tests=[AWL=-0.633, 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 Dp1L-7FtROp7 for ; Wed, 16 Dec 2009 05:46:35 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 68A3C3A6881 for ; Wed, 16 Dec 2009 05:46:35 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 15632D800D1; Wed, 16 Dec 2009 14:46:21 +0100 (CET) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4B28E2DE.3000104@iwl.com> References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> <20091216.140914.162134266.mbj@tail-f.com> <1260969722.1514.72.camel@missotis> <4B28E2DE.3000104@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 16 Dec 2009 14:46:18 +0100 Message-ID: <1260971178.1514.78.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2009 13:46:36 -0000 Andy Bierman píše v St 16. 12. 2009 v 05:38 -0800: > > When does a container, leaf, leaf-list, or leaf name show up > in an XML element or attribute name? In NETCONF PDUs. Instead of banning names starting with [xX][mM][lL], YANG XML encoding could require explicit prefixes for all node names. I don't think it is a good idea though. Lada > > container xml; > > > > I think it only applies to 'container' and 'name' in this example. > > > Lada > > > >> /martin > >> > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Dec 16 06:56: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 CE71A3A6934 for ; Wed, 16 Dec 2009 06:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.159, 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 6OxtLsMdIp5m for ; Wed, 16 Dec 2009 06:56:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D0F7A3A6930 for ; Wed, 16 Dec 2009 06:56:05 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F9A9C0028; Wed, 16 Dec 2009 15:55:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M362EQaTMEGB; Wed, 16 Dec 2009 15:55:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBBBCC0015; Wed, 16 Dec 2009 15:55:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E7EB4F77224; Wed, 16 Dec 2009 15:55:47 +0100 (CET) Date: Wed, 16 Dec 2009 15:55:47 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091216145547.GE79579@elstar.local> Mail-Followup-To: Martin Bjorklund , "andyb@iwl.com" , "netmod@ietf.org" References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> <20091216.140914.162134266.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216.140914.162134266.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] more fun with YIN 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, 16 Dec 2009 14:56:06 -0000 On Wed, Dec 16, 2009 at 02:09:14PM +0100, Martin Bjorklund wrote: > Right. I think the simplest fix is to make this rule part of a > 'identifier'. It is actually a bit too broad, since an 'identifier' > for a choice or module, for example, could start with "xml" without > any problem. The alternative is to introduce another type of > identifier which we use for selected keywords. If we do constrain identifiers to match XML constraints on element / attribute names, we should do this for all identifiers so we (a) less likely get it wrong and (b) do not have to continuously explain why identifiers are different and (c) we are future proof just in case something not originally intended to be shipped in XML elements / attributes suddenly needs to be shipped as XML elements / attributes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Dec 16 08:08: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 C31113A67E6 for ; Wed, 16 Dec 2009 08:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 XTrD3VummZPJ for ; Wed, 16 Dec 2009 08:08:30 -0800 (PST) Received: from smtp125.iad.emailsrvr.com (smtp125.iad.emailsrvr.com [207.97.245.125]) by core3.amsl.com (Postfix) with ESMTP id E82A03A67DF for ; Wed, 16 Dec 2009 08:08:29 -0800 (PST) Received: from relay22.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 62BD41B41A8; Wed, 16 Dec 2009 11:08:15 -0500 (EST) Received: by relay22.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1C6061B41A7; Wed, 16 Dec 2009 11:08:15 -0500 (EST) Message-ID: <4B290628.4030109@iwl.com> Date: Wed, 16 Dec 2009 08:09:12 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "netmod@ietf.org" References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> <20091216.140914.162134266.mbj@tail-f.com> <20091216145547.GE79579@elstar.local> In-Reply-To: <20091216145547.GE79579@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:08:30 -0000 Juergen Schoenwaelder wrote: > On Wed, Dec 16, 2009 at 02:09:14PM +0100, Martin Bjorklund wrote: > >> Right. I think the simplest fix is to make this rule part of a >> 'identifier'. It is actually a bit too broad, since an 'identifier' >> for a choice or module, for example, could start with "xml" without >> any problem. The alternative is to introduce another type of >> identifier which we use for selected keywords. > > If we do constrain identifiers to match XML constraints on element / > attribute names, we should do this for all identifiers so we (a) less > likely get it wrong and (b) do not have to continuously explain why > identifiers are different and (c) we are future proof just in case > something not originally intended to be shipped in XML elements / > attributes suddenly needs to be shipped as XML elements / attributes. > I don't think we have any other options. If 'xml' is reserved then the 'xmlns' problem is solved. If we ignore the XML rule even though we know about it, then the IESG is going to flag it with a DISCUSS. They have enough work to do already on this spec, so we have to fix this now. > /js > Andy From j.schoenwaelder@jacobs-university.de Wed Dec 16 08:51: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 EB5D23A69E0 for ; Wed, 16 Dec 2009 08:51:27 -0800 (PST) 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 Tr9g6IgGoMfG for ; Wed, 16 Dec 2009 08:51:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A07173A6977 for ; Wed, 16 Dec 2009 08:51:26 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0B5CC002F; Wed, 16 Dec 2009 17:51:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3EkBay2YRtYO; Wed, 16 Dec 2009 17:51:11 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11CC4C0020; Wed, 16 Dec 2009 17:51:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CEEA9F77720; Wed, 16 Dec 2009 17:51:08 +0100 (CET) Date: Wed, 16 Dec 2009 17:51:08 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091216165108.GA79993@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> <20091216.140914.162134266.mbj@tail-f.com> <20091216145547.GE79579@elstar.local> <4B290628.4030109@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B290628.4030109@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] more fun with YIN 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, 16 Dec 2009 16:51:28 -0000 On Wed, Dec 16, 2009 at 05:09:12PM +0100, Andy Bierman wrote: > I don't think we have any other options. > If 'xml' is reserved then the 'xmlns' problem is solved. > If we ignore the XML rule even though we know about it, > then the IESG is going to flag it with a DISCUSS. Your trust in the IESG is unbelievable. Please point me to other RFCs that use XML where I can find a template of the text to be added. I believe we management people tend to be more precise on such issues then most are people are... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Dec 16 09:17:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB09C3A6980 for ; Wed, 16 Dec 2009 09:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.446, 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 zxw5iG51GhrK for ; Wed, 16 Dec 2009 09:17:02 -0800 (PST) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id EF5BC3A696B for ; Wed, 16 Dec 2009 09:17:01 -0800 (PST) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 9983127480D7; Wed, 16 Dec 2009 12:16:47 -0500 (EST) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 5CE8F27480E1; Wed, 16 Dec 2009 12:16:47 -0500 (EST) Message-ID: <4B291639.2090901@iwl.com> Date: Wed, 16 Dec 2009 09:17:45 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "netmod@ietf.org" References: <200912160000.nBG004Gx058430@idle.juniper.net> <4B28DA87.4010504@iwl.com> <20091216.140914.162134266.mbj@tail-f.com> <20091216145547.GE79579@elstar.local> <4B290628.4030109@iwl.com> <20091216165108.GA79993@elstar.local> In-Reply-To: <20091216165108.GA79993@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] more fun with YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:17:02 -0000 Juergen Schoenwaelder wrote: > On Wed, Dec 16, 2009 at 05:09:12PM +0100, Andy Bierman wrote: > >> I don't think we have any other options. >> If 'xml' is reserved then the 'xmlns' problem is solved. >> If we ignore the XML rule even though we know about it, >> then the IESG is going to flag it with a DISCUSS. > > Your trust in the IESG is unbelievable. Please point me to other RFCs > that use XML where I can find a template of the text to be added. I > believe we management people tend to be more precise on such issues > then most are people are... > OK, so they just use XML by reference. We should do what we think will help implementors do the right thing. Putting the rule in the identifier rule seems like a good idea. The semantics are in comments anyway. Martin can just add a reminder in the comments, instead of adding cut-and-paste normative text. > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Dec 17 04:11: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 07FA53A6A04 for ; Thu, 17 Dec 2009 04:11:53 -0800 (PST) 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 ILPW7nITvYBY for ; Thu, 17 Dec 2009 04:11:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B37813A6935 for ; Thu, 17 Dec 2009 04:11:51 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 682C2C0031; Thu, 17 Dec 2009 13:11:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1jVpok3wPgpq; Thu, 17 Dec 2009 13:11:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A528C0030; Thu, 17 Dec 2009 13:11:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E15ACF79B96; Thu, 17 Dec 2009 13:11:32 +0100 (CET) Date: Thu, 17 Dec 2009 13:11:32 +0100 From: Juergen Schoenwaelder To: David Partain Message-ID: <20091217121132.GA81749@elstar.local> Mail-Followup-To: David Partain , "netmod@ietf.org" References: <200912030943.10320.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912030943.10320.david.partain@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Working Group Last Call: YANG - A data modeling language for NETCONF 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, 17 Dec 2009 12:11:53 -0000 On Thu, Dec 03, 2009 at 09:43:10AM +0100, David Partain wrote: > This is a two-week 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-09.txt > > This WGLC will end on December 17, 2009. Please review the document > and post your comments on the mailing list. Davids, how strict are you going to be on the deadline? You know, the document has ~180 pages, there was another overlapping NETCONF last call, it is December, and the day still has only 24 hours... If you accept reviews until lets say Dec. 28, then there is a chance to use the upcoming holidays to read the whole text. /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 Thu Dec 17 05:37: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 CDC783A67E9 for ; Thu, 17 Dec 2009 05:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.619, 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 StDbwqO-uTYf for ; Thu, 17 Dec 2009 05:37:05 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DAFFB3A685A for ; Thu, 17 Dec 2009 05:36:36 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E4818D800EF for ; Thu, 17 Dec 2009 14:36:21 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20091217121132.GA81749@elstar.local> References: <200912030943.10320.david.partain@ericsson.com> <20091217121132.GA81749@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 17 Dec 2009 14:36:20 +0100 Message-ID: <1261056980.13715.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Working Group Last Call: YANG - A data modeling language for NETCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Dec 2009 13:37:05 -0000 Juergen Schoenwaelder píše v Čt 17. 12. 2009 v 13:11 +0100: > On Thu, Dec 03, 2009 at 09:43:10AM +0100, David Partain wrote: > > > This is a two-week 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-09.txt > > > > This WGLC will end on December 17, 2009. Please review the document > > and post your comments on the mailing list. > > Davids, > > how strict are you going to be on the deadline? You know, the document > has ~180 pages, there was another overlapping NETCONF last call, it is > December, and the day still has only 24 hours... If you accept reviews > until lets say Dec. 28, then there is a chance to use the upcoming > holidays to read the whole text. Same here. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Dec 21 23:24: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 7C50C28C115 for ; Mon, 21 Dec 2009 23:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.151, 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 pVShSuVUPsT2 for ; Mon, 21 Dec 2009 23:24:24 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 37D4028C0FA for ; Mon, 21 Dec 2009 23:24:24 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7906A616002 for ; Tue, 22 Dec 2009 08:24:06 +0100 (CET) Date: Tue, 22 Dec 2009 08:24:06 +0100 (CET) Message-Id: <20091222.082406.16863265.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.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] YANG WGLC: edit-config clarifications X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Dec 2009 07:24:25 -0000 Hi, Triggered by Alan's email on the NETCONF list, http://www.ietf.org/mail-archive/web/netconf/current/msg05372.html, I checked the edit-config descriptions in the YANG document, and found some inconsistencies. I propose the following editorial changes + explicit mentioning of the error code returned: ---------------------------------------- Section 7.5.8, edit-config for a container NEW: (add to the end of the section) When a NETCONF server processes an request, the elements of procedure for the container node are: If the operation is "merge" or "replace", the node is created if it does not exist. If the operation is "create" the node is created if it does not exist. If the node already exists, a "data-exists" error is returned. If the operation is "delete" the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned. ---------------------------------------- Section 7.6.7, edit-config for leaf: OLD: If the operation is "merge", the node is created if it does not exist, and its value is set to the value found in the XML RPC data. If the operation is "replace", the node is created if it does not exist, and its value is set to the value found in the XML RPC data. If the operation is "create" the node is created if it does not exist. If the operation is "delete" the node is deleted if it exists. NEW: If the operation is "merge" or "replace", the node is created if it does not exist, and its value is set to the value found in the XML RPC data. If the operation is "create" the node is created if it does not exist. If the node already exists, a "data-exists" error is returned. If the operation is "delete" the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned. ---------------------------------------- Section 7.7.7, edit-config for leaf-list: OLD: If the operation is "merge" or "replace" the leaf-list entry is created if it does not exist. If the operation is "create" the leaf-list entry is created if it does not exist. If the operation is "delete" the entry is deleted from the leaf- list if it exists. NEW: If the operation is "merge" or "replace" the leaf-list entry is created if it does not exist. If the operation is "create" the leaf-list entry is created if it does not exist. If the leaf-list entry already exists, a "data-exists" error is returned. If the operation is "delete" the entry is deleted from the leaf- list if it exists. If the leaf-list entry does not exist, a "data-missing" error is returned. ---------------------------------------- Section 7.8.6, edit-config for lists: NEW: (add to the end of the section) When a NETCONF server processes an request, the elements of procedure for a list node are: If the operation is "merge" or "replace" the list entry is created if it does not exist. If the operation is "create" the list entry is created if it does not exist. If the list entry already exists, a "data-exists" error is returned. If the operation is "delete" the entry is deleted from the list if it exists. If the list entry does not exist, a "data-missing" error is returned. ---------------------------------------- Section 7.9.5., paragraph 4: OLD: Since only one of the choice's cases can be valid at any time, the creation of a node from one case implicitly deletes all nodes from all other cases. If an operation creates a node, the NETCONF server will delete any existing nodes that are defined in other cases inside the choice. NEW: Since only one of the choice's cases can be valid at any time, the creation of a node from one case implicitly deletes all nodes from all other cases. If an operation creates a node from a case, the NETCONF server will delete any existing nodes that are defined in other cases inside the choice. ---------------------------------------- Section 7.10.3, edit-config for anyxml: OLD: If the operation is "merge", the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data. If the operation is "replace", the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data. If the operation is "create" the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data. If the operation is "delete" the node is deleted if it exists. NEW: If the operation is "merge" or "replace", the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data. If the operation is "create" the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data. If the node already exists, a "data-exists" error is returned. If the operation is "delete" the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned. /martin From david.kessens@nsn.com Tue Dec 22 20:46: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 5C6203A6898 for ; Tue, 22 Dec 2009 20:46:16 -0800 (PST) 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 bI6AFaJID8TD for ; Tue, 22 Dec 2009 20:46:15 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 303E93A67F5 for ; Tue, 22 Dec 2009 20:46:14 -0800 (PST) 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 nBN4jsDp019661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Dec 2009 05:45:54 +0100 Received: from localhost.localdomain ([10.138.48.190]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nBN4jqx0029505; Wed, 23 Dec 2009 05:45:54 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id nBN4jqFv022481; Tue, 22 Dec 2009 20:45:52 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id nBN4jouG022479; Tue, 22 Dec 2009 20:45:50 -0800 X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f Date: Tue, 22 Dec 2009 20:45:50 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20091223044550.GA22408@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) Subject: [netmod] Working Group Last Call (Extended): YANG - A data modeling language for NETCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Dec 2009 04:46:16 -0000 All, Considering the holidays that are ahead for many of you, the lenght of the document in question and as requested by some of you, it seems reasonable to extend the Last Call for: - YANG - A data modeling language for NETCONF: http://tools.ietf.org/html/draft-ietf-netmod-yang-09.txt Therefore, we would like to formally extend the Last Call to the end of January 4th in a timezone of your choice. Just for the record, we don't plan on further extensions or more Last Calls so this will be your last chance to speak up. Enjoy the holidays! David & David --- ----- Forwarded message from ext David Partain ----- Date: Thu, 3 Dec 2009 09:43:10 +0100 From: David Partain To: netmod@ietf.org Subject: [netmod] Working Group Last Call: YANG - A data modeling language for NETCONF Dear all, This is a two-week 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-09.txt This WGLC will end on December 17, 2009. Please review the document and post your comments on the mailing list. Please use an appropriate Subject line so that the chairs and editor can easily keep track of the issues that need to be dealt with. The chairs believe that we have reached the point of diminishing returns. We can of course keep improving the current version but believe it is time to have a published stable version. Thereafter, operational experience will give us the input we need to work on a version 2 at some later date. Thanks. David^2 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ----- End forwarded message ----- David Kessens ---