From yang-bounces@ietf.org Sat Dec 01 08:57:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IySqs-0003D6-Mj; Sat, 01 Dec 2007 08:57:50 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IySqr-0003D0-NL for yang-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 08:57:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IySqm-0003CL-7i for yang@ietf.org; Sat, 01 Dec 2007 08:57:44 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IySqk-0000NX-9M for yang@ietf.org; Sat, 01 Dec 2007 08:57:44 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48A798A315; Sat, 1 Dec 2007 14:57:41 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02798-01; Sat, 1 Dec 2007 14:57: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 729B08A30D; Sat, 1 Dec 2007 14:57:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 13140404EE3; Sat, 1 Dec 2007 14:57:36 +0100 (CET) Date: Sat, 1 Dec 2007 14:57:35 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] Qs about keyref Message-ID: <20071201135735.GA15463@elstar.local> References: <20071130.225834.121728529.mbj@tail-f.com> <47508C44.4020303@andybierman.com> <20071130223536.GA14951@elstar.local> <20071201.002721.240670475.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071201.002721.240670475.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Sat, Dec 01, 2007 at 12:27:21AM +0100, Martin Bjorklund wrote: > OTOH, this problem came up when translating SNMP traps. One problem > there is the trap may look like this: > > OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } > > In this case, all three objects will be from the same ifEntry > instance. So the instance information is repeated 3 times (some may > say 4). But if we did this trap in YANG + leafref, we would > explicitly specify that they come from the same ifEntry: > > leaf ifIndex { > type leafref { > path "/if:interface/if:ifEntry/if:ifIndex"; > } > } > leaf ifAdminStatus { > type leafref { > path "/if:interface/if:ifEntry" > + "[ifIndex = $this/../ifIndex]/if:ifAdminStatus": > } > } > leaf ifOperStatus { > type leafref { > path "/if:interface/if:ifEntry" > + "[ifIndex = $this/../ifIndex]/if:ifOperStatus": > } > } But we can't do that; SNMP does not require that the instances in a notification are from the same row. And since there is not such rule in the SMIv2, we have to provide full instance information for each notification object, whether we like it or not. But that is all SMIv2 translation and of secondary importance. The question is how we would achieve the same thing in plain YANG and then the above may work except that it is terrible verbose (consider something which has a more complex key). > And an instance doc: > > > 2 > up > down > > > > The YANG spec obviously isn't perfect... but it is better than the > auto-generated one. > > As an alternative, I was thinking that maybe we somehow could point > out a list entry or container, and then just list the children we want > to include in the notification. This would be useful in notifications > and rpc-replies. > > Something like this (warning: just an idea) > > notification linkDown { > add-objects-from { > path "/if:interface/if:ifEntry"; > include ifIndex; // maybe the key is auto-added? No... > include ifAdminStatus; > include ifOperStatus; > include ifExtra/ifFooBar; // add from a container > } > } > > One problem is that the add-objects-from doesn't really work like the > rest of the data definition statements in YANG... And if you have > nested lists it's a bit trickier... But I think we need to think more along this line. In SMIng, we were also referencing attributes to include in a notification rather than defining new attributes that have magic types that somehow link to the things in question. Perhaps we need something "inverse" to the augment (link is not a good name): notification linkDown { link "/if:interface/if:ifEntry" { leaf ifIndex; leaf ifAdminStatus; leaf ifOperStatus; } } Something like this might also be handy to link parameters of RPCs to things in the data tree... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Dec 01 14:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXsT-0004DX-Fz; Sat, 01 Dec 2007 14:19:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyXsR-0003xH-Gu for yang-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:19:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXsR-0003t1-34 for yang@ietf.org; Sat, 01 Dec 2007 14:19:47 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyXsP-0002zT-KD for yang@ietf.org; Sat, 01 Dec 2007 14:19:47 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WU5nSIXJWmmhXKVDTObwL1B2Qqv4v6LHnDUjWKvcF/oWgZ7ze6fL16bhtn88qEDE; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.137.67] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IyXsP-0001TR-07 for yang@ietf.org; Sat, 01 Dec 2007 14:19:45 -0500 Message-ID: <001a01c8344f$604bcbe0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20071130.225834.121728529.mbj@tail-f.com><47508C44.4020303@andybierman.com><20071130223536.GA14951@elstar.local><20071201.002721.240670475.mbj@tail-f.com> <20071201135735.GA15463@elstar.local> Subject: Re: [YANG] Qs about keyref Date: Sat, 1 Dec 2007 11:21:28 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a88b133a13cf4f12ec10814bf8b80129e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.137.67 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Martin Bjorklund" > Cc: > Sent: Saturday, December 01, 2007 5:57 AM > Subject: Re: [YANG] Qs about keyref ... > But we can't do that; SNMP does not require that the instances in a > notification are from the same row. And since there is not such rule > in the SMIv2, we have to provide full instance information for each > notification object, whether we like it or not. But that is all SMIv2 > translation and of secondary importance. The question is how we would > achieve the same thing in plain YANG and then the above may work > except that it is terrible verbose (consider something which has a > more complex key). ... > But I think we need to think more along this line. In SMIng, we were > also referencing attributes to include in a notification rather than > defining new attributes that have magic types that somehow link to the > things in question. Perhaps we need something "inverse" to the augment > (link is not a good name): ... Perhaps it would be helpful to step back a bit a think about what a notification really is. Though the SNMP syntax was clearly better for implementation, the CMIP model captured the semantics a bit better. A notification says that something interesting has happened to some specific object(s), and carries helpful "interesting" attributes of the relevant object(s), and perhaps some additional information about the event itself. The SNMP SMI forced this information to be glommed together in an easy-to-implement but highly unnatural way. In looking at how to do this in netconf, it might be helpful to remind ourselves that the SNMP worldview (that everything is attributes and that objects are merely synthesized from them) isn't the only one. Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Dec 01 14:26:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXyc-0004tR-Ce; Sat, 01 Dec 2007 14:26:10 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyXyb-0004k8-6S for yang-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:26:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXya-0004g6-Og for yang@ietf.org; Sat, 01 Dec 2007 14:26:08 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyXyY-0003DI-SJ for yang@ietf.org; Sat, 01 Dec 2007 14:26:08 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53C4F8A187; Sat, 1 Dec 2007 20:26:06 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23861-07; Sat, 1 Dec 2007 20:26: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 E6F418A143; Sat, 1 Dec 2007 20:26:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9C5F94050A6; Sat, 1 Dec 2007 20:26:00 +0100 (CET) Date: Sat, 1 Dec 2007 20:26:00 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [YANG] Qs about keyref Message-ID: <20071201192600.GA15563@elstar.local> References: <20071201135735.GA15463@elstar.local> <001a01c8344f$604bcbe0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01c8344f$604bcbe0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Sat, Dec 01, 2007 at 11:21:28AM -0800, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Martin Bjorklund" > > Cc: > > Sent: Saturday, December 01, 2007 5:57 AM > > Subject: Re: [YANG] Qs about keyref > ... > > But we can't do that; SNMP does not require that the instances in a > > notification are from the same row. And since there is not such rule > > in the SMIv2, we have to provide full instance information for each > > notification object, whether we like it or not. But that is all SMIv2 > > translation and of secondary importance. The question is how we would > > achieve the same thing in plain YANG and then the above may work > > except that it is terrible verbose (consider something which has a > > more complex key). > ... > > But I think we need to think more along this line. In SMIng, we were > > also referencing attributes to include in a notification rather than > > defining new attributes that have magic types that somehow link to the > > things in question. Perhaps we need something "inverse" to the augment > > (link is not a good name): > ... > > Perhaps it would be helpful to step back a bit a think about what a > notification really is. Though the SNMP syntax was clearly better for > implementation, the CMIP model captured the semantics a bit better. > A notification says that something interesting has happened to some > specific object(s), and carries helpful "interesting" attributes of the > relevant object(s), and perhaps some additional information about > the event itself. The SNMP SMI forced this information to be glommed > together in an easy-to-implement but highly unnatural way. > > In looking at how to do this in netconf, it might be helpful to remind > ourselves that the SNMP worldview (that everything is attributes and > that objects are merely synthesized from them) isn't the only one. SMIng did associate events with objects (e.g. a linkDown would be an event associated with an interface object) and then the protocol mappings would specify how such events are mapped to notifications and this mapping would also specify which attributes are being send as part of the notification. I am not sure, though, we will end up with the same approach in YANG. Anyway, since SNMP's SMI is allows arbitrary data to go into a notification, I think the mappings should not make any assumptions are treat the SNMP notification varbinds as rather independent beings (like SNMP treats them as independent beings, each one carrying its own instance identifier). With pure YANG notifications, we can hopefully do better but I fear the fuzzyness of SNMP's SMI can be automagically be fixed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Dec 02 13:20:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytQX-0004Jj-QI; Sun, 02 Dec 2007 13:20:25 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IytQV-0003yR-8O for yang-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 13:20:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytQO-0003Lf-GT; Sun, 02 Dec 2007 13:20:16 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IytQN-0002Tu-HX; Sun, 02 Dec 2007 13:20:16 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A1E0A21310; Sun, 2 Dec 2007 19:20:14 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-27-4752f75e730a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 726452106A; Sun, 2 Dec 2007 19:20:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 19:20:14 +0100 Received: from [127.0.0.1] ([159.107.148.22]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 19:20:13 +0100 Message-ID: <4752F757.5030204@ericsson.com> Date: Sun, 02 Dec 2007 10:20:07 -0800 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Harrington References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> In-Reply-To: <241201c83366$9acf8070$6502a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2007 18:20:13.0959 (UTC) FILETIME=[FB750170:01C8350F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello, >> Q1) Why does NETCONF need a DML at all? If we have an IETF standard DML for NETCONF, device vendors (like my company) will be much more comfortable, much more willing to adapt NETCONF itself. With a standard DML we would see a better chance at having available 3rd party or even freeware toolkits for NETCONF. The above would be important even for a company which would not care about interoperability. Balazs David Harrington wrote: > >> Hi, >> >> There are a few questions that the IESG and others have asked, >> which I will try to address: >> >> Q1) Why does NETCONF need a DML at all? >> Q2) Why is NETCONF special? >> Q3) Why won't lots of other WGs want to define their own >> protocol-specific DMLs? >> Q4) Why isn't XSD or RelaxNG good enough? > > I'll take a whack at answering the same questions. > > A1) Why does NETCONF need a DML at all? > > to promote vendor-neutral interoperable management. > > It is much easier to develop standards when everybody uses the same > basic language to communicate; this "common language for shared > communication" is also reflected in the IETF decision to use English > text and ASCII documents. > > This is not just about being able to standardize **device > management**; it is a basic step to permit the standardization of > **network management** and possibly **services management". The DML is > a basic building block. > > A2) Why is NETCONF special? > > It is and it isn't. Netconf is only one protocol used for network > management. > > It has some unique requirements, such as using a document-based > approach and differentiating the data for config versus state and for > dealing with different time-defined contexts such as running and > startup configs. This differs from other network management protocols, > such as SNMP and syslog and ipfix, which use their own data formats, > and usually deal only with the currently-running config. Netconf is a > tool designed to meet the special requirements of configuration, and > the DML needs to support special features not found in other NM-DMLs. > > Netconf is not special, in that any language used for network > management is likely to have certain common requirements. NM data > models are commonly used directly by humans, in their raw form, such > as when they troubleshoot problems using network sniffers. NM data > models are also commonly used by NMS applications that can handle the > translations into a more human-readable format. Designers of NM tools > (e.g., protocols and data models) thus need to pay close attention to > who will use the information, and to assume that the data will be used > both directly by humans and by applications. Operators have complained > strongly that OIDs are very hard to work with in raw form, yet > operators frequently need to deal with the raw form of the data. > > A3) Why won't lots of other WGs want to define their own > protocol-specific DMLs? > > To paraphrase a wise man from the SNMP community, when you fill a room > with protocol designers and ask for a solution to a problem, is it a > surprise when they recommend designing a new protocol? > > The decision about whether to use an existing protocol/DML or develop > a new protocol/DML should be made after a careful analysis of the > requirements of the solution. SNMP was designed when CMIP was found to > not quite address the needs. The SMI was designed when ASN.1 was found > to not quite address the needs. XML was designed when other DMLs were > found to not quite address the needs. > > The decision to explore an XML-based DML and to explore a C-like DML > follows years and years and years of debate over the requiremnts of > network management, and configuration in particular. > > If every WG spends as much time analyzing the requirements that the > OPS area has spent considering this decision, it might be good for > ensuring no new protoocls are designed that are not really needed, but > the IETF would also grind to a halt, much as the OPS community has > done over our many years of debate. And the delay caused by our > debates has made IETF network management largely irrelevant to the > operator community (our customers). > > As always, we need to be vigilant and determine whether enough thought > has been given to reuse of existing protocols. We also need to > consider the tradeoffs between new protocols and reusing existing > protocols in ways they were not designed to be used. > > A4) Why isn't XSD or RelaxNG good enough? > > As mentioned in A2, NM data models need to be both machine- and > human-readable. XSD is machine-readable, but it is a tough language > for humans. RelaxNG seems better. > > As discussed further in a different email, Netconf will almost > certainly need a DML suited to its requirements, and if RelaxNG is > found to be human-friendly-enough, we would almost certainly still > need to select a subset and adapt it to meet configuration > requirements. So the benefit of using RelaxNG over a domain-specific > DML may be lost by using an adapted-subset of RelaxNG. > > Most operators already understand languages like Perl and C and > Javascript, because they already need to write lots of scripts to > manage their networks. Most implementers of NM support in > internetworking devices work in C or a variant of C. It makes a lot of > sense to use a language with a C-like syntax for these people, rather > than forcing them to learn yet another language that was designed for > some other purpose. > > [soap] > somebody commented that the designers of XSD and RelaxNG really > understand how to design DMLs, implying that the OPS community does > not. Many of the people involved in the ongoing DML discussions over > the years, and now, are MIB Doctors and operators and protocol > designers, and have had years of experience designing and working with > SMI and network management. They understand the requirements of a DML > for NM far more than the designers of XSD or RelaxNG, who were not > designing their DMLs for NM purposes. > [end soap] > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Dec 02 14:01:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyu3o-0006Ia-Bv; Sun, 02 Dec 2007 14:01:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Iyu3n-0006ID-Ak for yang-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:00:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyu3m-0006Gq-Th; Sun, 02 Dec 2007 14:00:59 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyu3l-0007WB-8V; Sun, 02 Dec 2007 14:00:58 -0500 Received: from [192.168.20.198] (c-24-91-195-79.hsd1.ma.comcast.net [24.91.195.79]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id lB2J0kgF005726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Dec 2007 13:00:47 -0600 In-Reply-To: <4752F757.5030204@ericsson.com> References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> <4752F757.5030204@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> From: Jon Saperia Date: Sun, 2 Dec 2007 14:00:43 -0500 To: balazs.lengyel@ericsson.com X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2101585437==" Errors-To: yang-bounces@ietf.org --===============2101585437== Content-Type: multipart/alternative; boundary=Apple-Mail-17--728488243 --Apple-Mail-17--728488243 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks /jon ---------------------- Jon Saperia TSP NM (mobil) 617-201-2655 (office) 978-461-0249 saperia@jdscons.com On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote: > Hello, > >> Q1) Why does NETCONF need a DML at all? > > If we have an IETF standard DML for NETCONF, device vendors (like > my company) will be much more comfortable, much more willing to > adapt NETCONF itself. With a standard DML we would see a better > chance at having available 3rd party or even freeware toolkits for > NETCONF. Yes, but does that mean that we will begin to develop a standard configuration objects for say, BGP or DiffServ that would work from one vendor to the next? It would be nice to think so, that would really help interoperability and should be the target of 'our' collective efforts. /jon > > The above would be important even for a company which would not > care about interoperability. > > Balazs > > David Harrington wrote: >> >>> Hi, >>> >>> There are a few questions that the IESG and others have asked, >>> which I will try to address: >>> >>> Q1) Why does NETCONF need a DML at all? >>> Q2) Why is NETCONF special? >>> Q3) Why won't lots of other WGs want to define their own >>> protocol-specific DMLs? >>> Q4) Why isn't XSD or RelaxNG good enough? >> I'll take a whack at answering the same questions. >> A1) Why does NETCONF need a DML at all? >> to promote vendor-neutral interoperable management. It is much >> easier to develop standards when everybody uses the same >> basic language to communicate; this "common language for shared >> communication" is also reflected in the IETF decision to use English >> text and ASCII documents. >> This is not just about being able to standardize **device >> management**; it is a basic step to permit the standardization of >> **network management** and possibly **services management". The >> DML is >> a basic building block. >> A2) Why is NETCONF special? >> It is and it isn't. Netconf is only one protocol used for network >> management. It has some unique requirements, such as using a >> document-based >> approach and differentiating the data for config versus state and for >> dealing with different time-defined contexts such as running and >> startup configs. This differs from other network management >> protocols, >> such as SNMP and syslog and ipfix, which use their own data formats, >> and usually deal only with the currently-running config. Netconf is a >> tool designed to meet the special requirements of configuration, and >> the DML needs to support special features not found in other NM- >> DMLs. Netconf is not special, in that any language used for network >> management is likely to have certain common requirements. NM data >> models are commonly used directly by humans, in their raw form, such >> as when they troubleshoot problems using network sniffers. NM data >> models are also commonly used by NMS applications that can handle the >> translations into a more human-readable format. Designers of NM tools >> (e.g., protocols and data models) thus need to pay close attention to >> who will use the information, and to assume that the data will be >> used >> both directly by humans and by applications. Operators have >> complained >> strongly that OIDs are very hard to work with in raw form, yet >> operators frequently need to deal with the raw form of the data. >> A3) Why won't lots of other WGs want to define their own >> protocol-specific DMLs? >> To paraphrase a wise man from the SNMP community, when you fill a >> room >> with protocol designers and ask for a solution to a problem, is it a >> surprise when they recommend designing a new protocol? >> The decision about whether to use an existing protocol/DML or develop >> a new protocol/DML should be made after a careful analysis of the >> requirements of the solution. SNMP was designed when CMIP was >> found to >> not quite address the needs. The SMI was designed when ASN.1 was >> found >> to not quite address the needs. XML was designed when other DMLs were >> found to not quite address the needs. >> The decision to explore an XML-based DML and to explore a C-like DML >> follows years and years and years of debate over the requiremnts of >> network management, and configuration in particular. If every WG >> spends as much time analyzing the requirements that the >> OPS area has spent considering this decision, it might be good for >> ensuring no new protoocls are designed that are not really needed, >> but >> the IETF would also grind to a halt, much as the OPS community has >> done over our many years of debate. And the delay caused by our >> debates has made IETF network management largely irrelevant to the >> operator community (our customers). >> As always, we need to be vigilant and determine whether enough >> thought >> has been given to reuse of existing protocols. We also need to >> consider the tradeoffs between new protocols and reusing existing >> protocols in ways they were not designed to be used. >> A4) Why isn't XSD or RelaxNG good enough? >> As mentioned in A2, NM data models need to be both machine- and >> human-readable. XSD is machine-readable, but it is a tough language >> for humans. RelaxNG seems better. As discussed further in a >> different email, Netconf will almost >> certainly need a DML suited to its requirements, and if RelaxNG is >> found to be human-friendly-enough, we would almost certainly still >> need to select a subset and adapt it to meet configuration >> requirements. So the benefit of using RelaxNG over a domain-specific >> DML may be lost by using an adapted-subset of RelaxNG. >> Most operators already understand languages like Perl and C and >> Javascript, because they already need to write lots of scripts to >> manage their networks. Most implementers of NM support in >> internetworking devices work in C or a variant of C. It makes a >> lot of >> sense to use a language with a C-like syntax for these people, rather >> than forcing them to learn yet another language that was designed for >> some other purpose. >> [soap] >> somebody commented that the designers of XSD and RelaxNG really >> understand how to design DMLs, implying that the OPS community does >> not. Many of the people involved in the ongoing DML discussions over >> the years, and now, are MIB Doctors and operators and protocol >> designers, and have had years of experience designing and working >> with >> SMI and network management. They understand the requirements of a DML >> for NM far more than the designers of XSD or RelaxNG, who were not >> designing their DMLs for NM purposes. >> [end soap] >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net > > --Apple-Mail-17--728488243 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
saperia@jdscons.com


=
On Dec 2, 2007, at 1:20 PM, Balazs Lengyel = wrote:

Hello,
>>=A0 =A0 = Q1) Why does NETCONF need a DML at all?

If we = have an IETF standard DML for NETCONF, device vendors (like my company) = will be much more comfortable, much more willing to adapt NETCONF = itself. With a standard DML we would see a better chance at having = available 3rd party or even freeware toolkits for = NETCONF.

Yes, but does that mean that we = will begin to develop a standard configuration objects for say, BGP or = DiffServ that would work from one vendor to the next? =A0It would be = nice to think so, that would really help interoperability and should be = the target of 'our' collective efforts.
/jon

The above would be important even for a company = which would not care about interoperability.


David Harrington wrote:

=A0

Hi,

There are a few questions that = the IESG and others have asked,
which I will = try to address:

=A0=A0 = Q1) Why does NETCONF need a DML at all?
=A0=A0 = Q2) Why is NETCONF special?
=A0=A0 Q3) Why won't lots of = other WGs want to define their own
=A0=A0 =A0 =A0 protocol-specific = DMLs?
=A0=A0 Q4) Why isn't XSD or = RelaxNG good enough?
I'll take a = whack at answering the same questions.
A1) Why = does NETCONF need a DML at all?
to promote = vendor-neutral interoperable management. It is much easier to develop = standards when everybody uses the same
basic = language to communicate; this "common language for shared
communication" is also reflected in the IETF = decision to use English
text and = ASCII documents.
This is not just about being = able to standardize **device
management**; = it is a basic step to permit the standardization of
**network management** and possibly **services = management". The DML is
a basic = building block.
A2) Why is NETCONF = special?
It is and it isn't. Netconf is = only one protocol used for network
management. = It has some unique requirements, such as using a = document-based
approach and differentiating the = data for config versus state and for
dealing with = different time-defined contexts such as running and
startup configs. This differs from other network = management protocols,
such as SNMP and syslog and = ipfix, which use their own data formats,
and = usually deal only with the currently-running config. Netconf is = a
tool designed to meet the special requirements = of configuration, and
the DML needs to support = special features not found in other NM-DMLs. Netconf is not special, in = that any language used for network
management is = likely to have certain common requirements. NM data
models are commonly used directly by humans, in = their raw form, such
as when they troubleshoot = problems using network sniffers. NM data
models = are also commonly used by NMS applications that can handle the
translations into a more human-readable format. = Designers of NM tools
(e.g., protocols and data = models) thus need to pay close attention to
who = will use the information, and to assume that the data will be = used
both directly by humans and by = applications. Operators have complained
strongly = that OIDs are very hard to work with in raw form, yet
operators frequently need to deal with the raw form = of the data. A3) Why won't lots of other WGs want to define their = own
=A0 =A0 =A0 =A0 protocol-specific = DMLs?
To paraphrase a wise man from = the SNMP community, when you fill a room
with = protocol designers and ask for a solution to a problem, is it = a
surprise when they recommend designing a new = protocol?
The decision about whether to = use an existing protocol/DML or develop
a new = protocol/DML should be made after a careful analysis of the
requirements of the solution. SNMP was designed when = CMIP was found to
not quite address the needs. The = SMI was designed when ASN.1 was found
to not = quite address the needs. XML was designed when other DMLs were
found to not quite address the needs.
The decision to explore an XML-based DML and to = explore a C-like DML
follows years and years and = years of debate over the requiremnts of
network = management, and configuration in particular. If every WG spends as much = time analyzing the requirements that the
OPS area = has spent considering this decision, it might be good for
ensuring no new protoocls are designed that are not = really needed, but
the IETF would also grind = to a halt, much as the OPS community has
done = over our many years of debate. And the delay caused by our
debates has made IETF network management largely = irrelevant to the
operator community (our = customers).
As always, we need to be = vigilant and determine whether enough thought
has been given to reuse of existing protocols. We = also need to
consider the tradeoffs between = new protocols and reusing existing
protocols in = ways they were not designed to be used.
A4) Why = isn't XSD or RelaxNG good enough?
As mentioned = in A2, NM data models need to be both machine- and
human-readable. XSD is machine-readable, but it is a = tough language
for humans. RelaxNG seems = better. As discussed further in a different email, Netconf will = almost
certainly need a DML suited to = its requirements, and if RelaxNG is
found to be = human-friendly-enough, we would almost certainly still
need to select a subset and adapt it to meet = configuration
requirements. So the benefit of = using RelaxNG over a domain-specific
DML may be = lost by using an adapted-subset of RelaxNG.
Most = operators already understand languages like Perl and C and
Javascript, because they already need to write lots = of scripts to
manage their networks. Most = implementers of NM support in
sense to use a language with a C-like syntax = for these people, rather
than forcing = them to learn yet another language that was designed for
some other purpose.
somebody commented that the = designers of XSD and RelaxNG really
understand = how to design DMLs, implying that the OPS community does
not. Many of the people involved in the ongoing DML = discussions over
the years, and now, are MIB = Doctors and operators and protocol
designers, = and have had years of experience designing and working with
SMI and network management. They understand the = requirements of a DML
for NM far more than the = designers of XSD or RelaxNG, who were not
[end = soap]
David Harrington


=

= --Apple-Mail-17--728488243-- --===============2101585437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============2101585437==-- From yang-bounces@ietf.org Sun Dec 02 15:19:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvHX-0007Vz-L6; Sun, 02 Dec 2007 15:19:15 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyvHW-0007VW-E8 for yang-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:19:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvHW-0007VN-4W; Sun, 02 Dec 2007 15:19:14 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyvHS-0000yD-85; Sun, 02 Dec 2007 15:19:14 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 900C020FD1; Sun, 2 Dec 2007 21:19:09 +0100 (CET) X-AuditID: c1b4fb3c-b0798bb0000030cf-c1-4753133da81f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 678C0205FE; Sun, 2 Dec 2007 21:19:09 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:19:09 +0100 Received: from [127.0.0.1] ([159.107.148.22]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:19:08 +0100 Message-ID: <47531335.9050800@ericsson.com> Date: Sun, 02 Dec 2007 12:19:01 -0800 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Jon Saperia References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> <4752F757.5030204@ericsson.com> <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> In-Reply-To: <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2007 20:19:08.0998 (UTC) FILETIME=[98458E60:01C83520] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello, Naturally our aim is to develop standard NETCONF configuration models, and the more people use NETCONF the easier that will be. Balazs Jon Saperia wrote: > > Thanks > /jon > ---------------------- > Jon Saperia > TSP NM > (mobil) 617-201-2655 > (office) 978-461-0249 > saperia@jdscons.com > > > > On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote: > >> Hello, >> >> Q1) Why does NETCONF need a DML at all? >> >> If we have an IETF standard DML for NETCONF, device vendors (like my >> company) will be much more comfortable, much more willing to adapt >> NETCONF itself. With a standard DML we would see a better chance at >> having available 3rd party or even freeware toolkits for NETCONF. > > Yes, but does that mean that we will begin to develop a standard > configuration objects for say, BGP or DiffServ that would work from one > vendor to the next? It would be nice to think so, that would really > help interoperability and should be the target of 'our' collective efforts. > /jon >> >> The above would be important even for a company which would not care >> about interoperability. >> >> Balazs >> >> David Harrington wrote: >>> >>> >>> >>>> Hi, >>>> >>>> There are a few questions that the IESG and others have asked, >>>> which I will try to address: >>>> >>>> Q1) Why does NETCONF need a DML at all? >>>> Q2) Why is NETCONF special? >>>> Q3) Why won't lots of other WGs want to define their own >>>> protocol-specific DMLs? >>>> Q4) Why isn't XSD or RelaxNG good enough? >>> I'll take a whack at answering the same questions. >>> A1) Why does NETCONF need a DML at all? >>> to promote vendor-neutral interoperable management. It is much easier >>> to develop standards when everybody uses the same >>> basic language to communicate; this "common language for shared >>> communication" is also reflected in the IETF decision to use English >>> text and ASCII documents. >>> This is not just about being able to standardize **device >>> management**; it is a basic step to permit the standardization of >>> **network management** and possibly **services management". The DML is >>> a basic building block. >>> A2) Why is NETCONF special? >>> It is and it isn't. Netconf is only one protocol used for network >>> management. It has some unique requirements, such as using a >>> document-based >>> approach and differentiating the data for config versus state and for >>> dealing with different time-defined contexts such as running and >>> startup configs. This differs from other network management protocols, >>> such as SNMP and syslog and ipfix, which use their own data formats, >>> and usually deal only with the currently-running config. Netconf is a >>> tool designed to meet the special requirements of configuration, and >>> the DML needs to support special features not found in other NM-DMLs. >>> Netconf is not special, in that any language used for network >>> management is likely to have certain common requirements. NM data >>> models are commonly used directly by humans, in their raw form, such >>> as when they troubleshoot problems using network sniffers. NM data >>> models are also commonly used by NMS applications that can handle the >>> translations into a more human-readable format. Designers of NM tools >>> (e.g., protocols and data models) thus need to pay close attention to >>> who will use the information, and to assume that the data will be used >>> both directly by humans and by applications. Operators have complained >>> strongly that OIDs are very hard to work with in raw form, yet >>> operators frequently need to deal with the raw form of the data. A3) >>> Why won't lots of other WGs want to define their own >>> protocol-specific DMLs? >>> To paraphrase a wise man from the SNMP community, when you fill a room >>> with protocol designers and ask for a solution to a problem, is it a >>> surprise when they recommend designing a new protocol? >>> The decision about whether to use an existing protocol/DML or develop >>> a new protocol/DML should be made after a careful analysis of the >>> requirements of the solution. SNMP was designed when CMIP was found to >>> not quite address the needs. The SMI was designed when ASN.1 was found >>> to not quite address the needs. XML was designed when other DMLs were >>> found to not quite address the needs. >>> The decision to explore an XML-based DML and to explore a C-like DML >>> follows years and years and years of debate over the requiremnts of >>> network management, and configuration in particular. If every WG >>> spends as much time analyzing the requirements that the >>> OPS area has spent considering this decision, it might be good for >>> ensuring no new protoocls are designed that are not really needed, but >>> the IETF would also grind to a halt, much as the OPS community has >>> done over our many years of debate. And the delay caused by our >>> debates has made IETF network management largely irrelevant to the >>> operator community (our customers). >>> As always, we need to be vigilant and determine whether enough thought >>> has been given to reuse of existing protocols. We also need to >>> consider the tradeoffs between new protocols and reusing existing >>> protocols in ways they were not designed to be used. >>> A4) Why isn't XSD or RelaxNG good enough? >>> As mentioned in A2, NM data models need to be both machine- and >>> human-readable. XSD is machine-readable, but it is a tough language >>> for humans. RelaxNG seems better. As discussed further in a different >>> email, Netconf will almost >>> certainly need a DML suited to its requirements, and if RelaxNG is >>> found to be human-friendly-enough, we would almost certainly still >>> need to select a subset and adapt it to meet configuration >>> requirements. So the benefit of using RelaxNG over a domain-specific >>> DML may be lost by using an adapted-subset of RelaxNG. >>> Most operators already understand languages like Perl and C and >>> Javascript, because they already need to write lots of scripts to >>> manage their networks. Most implementers of NM support in >>> internetworking devices work in C or a variant of C. It makes a lot of >>> sense to use a language with a C-like syntax for these people, rather >>> than forcing them to learn yet another language that was designed for >>> some other purpose. >>> [soap] >>> somebody commented that the designers of XSD and RelaxNG really >>> understand how to design DMLs, implying that the OPS community does >>> not. Many of the people involved in the ongoing DML discussions over >>> the years, and now, are MIB Doctors and operators and protocol >>> designers, and have had years of experience designing and working with >>> SMI and network management. They understand the requirements of a DML >>> for NM far more than the designers of XSD or RelaxNG, who were not >>> designing their DMLs for NM purposes. >>> [end soap] >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >> >> > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Dec 02 17:44:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxXn-000668-SO; Sun, 02 Dec 2007 17:44:11 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyxXl-00065N-6B for yang-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:44:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxXk-00064b-Oz; Sun, 02 Dec 2007 17:44:08 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyxXi-0003Di-Ox; Sun, 02 Dec 2007 17:44:08 -0500 Received: from [192.168.20.199] (c-24-91-195-79.hsd1.ma.comcast.net [24.91.195.79]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id lB2Mho91028679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Dec 2007 16:43:51 -0600 In-Reply-To: <47531335.9050800@ericsson.com> References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> <4752F757.5030204@ericsson.com> <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> <47531335.9050800@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <1319D660-EA6A-4C07-AE39-3F179C45B29A@jdscons.com> From: Jon Saperia Date: Sun, 2 Dec 2007 17:43:53 -0500 To: balazs.lengyel@ericsson.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.0 (-) X-Scan-Signature: 3419f078334bcda4102d3d704cee11c6 Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0034315223==" Errors-To: yang-bounces@ietf.org --===============0034315223== Content-Type: multipart/alternative; boundary=Apple-Mail-1--715098613 --Apple-Mail-1--715098613 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Wrong order - people will push (not just the vendors for convenience) when there is something that makes a real difference. On Dec 2, 2007, at 3:19 PM, Balazs Lengyel wrote: > Hello, > Naturally our aim is to develop standard NETCONF configuration > models, and the more people use NETCONF the easier that will be. > Balazs > > > Jon Saperia wrote: >> Thanks >> /jon >> ---------------------- >> Jon Saperia >> TSP NM >> (mobil) 617-201-2655 >> (office) 978-461-0249 >> saperia@jdscons.com >> On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote: >>> Hello, >>> >> Q1) Why does NETCONF need a DML at all? >>> >>> If we have an IETF standard DML for NETCONF, device vendors (like >>> my company) will be much more comfortable, much more willing to >>> adapt NETCONF itself. With a standard DML we would see a better >>> chance at having available 3rd party or even freeware toolkits >>> for NETCONF. >> Yes, but does that mean that we will begin to develop a standard >> configuration objects for say, BGP or DiffServ that would work >> from one vendor to the next? It would be nice to think so, that >> would really help interoperability and should be the target of >> 'our' collective efforts. >> /jon >>> >>> The above would be important even for a company which would not >>> care about interoperability. >>> >>> Balazs >>> >>> David Harrington wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> There are a few questions that the IESG and others have asked, >>>>> which I will try to address: >>>>> >>>>> Q1) Why does NETCONF need a DML at all? >>>>> Q2) Why is NETCONF special? >>>>> Q3) Why won't lots of other WGs want to define their own >>>>> protocol-specific DMLs? >>>>> Q4) Why isn't XSD or RelaxNG good enough? >>>> I'll take a whack at answering the same questions. >>>> A1) Why does NETCONF need a DML at all? >>>> to promote vendor-neutral interoperable management. It is much >>>> easier to develop standards when everybody uses the same >>>> basic language to communicate; this "common language for shared >>>> communication" is also reflected in the IETF decision to use >>>> English >>>> text and ASCII documents. >>>> This is not just about being able to standardize **device >>>> management**; it is a basic step to permit the standardization of >>>> **network management** and possibly **services management". The >>>> DML is >>>> a basic building block. >>>> A2) Why is NETCONF special? >>>> It is and it isn't. Netconf is only one protocol used for network >>>> management. It has some unique requirements, such as using a >>>> document-based >>>> approach and differentiating the data for config versus state >>>> and for >>>> dealing with different time-defined contexts such as running and >>>> startup configs. This differs from other network management >>>> protocols, >>>> such as SNMP and syslog and ipfix, which use their own data >>>> formats, >>>> and usually deal only with the currently-running config. Netconf >>>> is a >>>> tool designed to meet the special requirements of configuration, >>>> and >>>> the DML needs to support special features not found in other NM- >>>> DMLs. Netconf is not special, in that any language used for network >>>> management is likely to have certain common requirements. NM data >>>> models are commonly used directly by humans, in their raw form, >>>> such >>>> as when they troubleshoot problems using network sniffers. NM data >>>> models are also commonly used by NMS applications that can >>>> handle the >>>> translations into a more human-readable format. Designers of NM >>>> tools >>>> (e.g., protocols and data models) thus need to pay close >>>> attention to >>>> who will use the information, and to assume that the data will >>>> be used >>>> both directly by humans and by applications. Operators have >>>> complained >>>> strongly that OIDs are very hard to work with in raw form, yet >>>> operators frequently need to deal with the raw form of the data. >>>> A3) Why won't lots of other WGs want to define their own >>>> protocol-specific DMLs? >>>> To paraphrase a wise man from the SNMP community, when you fill >>>> a room >>>> with protocol designers and ask for a solution to a problem, is >>>> it a >>>> surprise when they recommend designing a new protocol? >>>> The decision about whether to use an existing protocol/DML or >>>> develop >>>> a new protocol/DML should be made after a careful analysis of the >>>> requirements of the solution. SNMP was designed when CMIP was >>>> found to >>>> not quite address the needs. The SMI was designed when ASN.1 was >>>> found >>>> to not quite address the needs. XML was designed when other DMLs >>>> were >>>> found to not quite address the needs. >>>> The decision to explore an XML-based DML and to explore a C-like >>>> DML >>>> follows years and years and years of debate over the requiremnts of >>>> network management, and configuration in particular. If every WG >>>> spends as much time analyzing the requirements that the >>>> OPS area has spent considering this decision, it might be good for >>>> ensuring no new protoocls are designed that are not really >>>> needed, but >>>> the IETF would also grind to a halt, much as the OPS community has >>>> done over our many years of debate. And the delay caused by our >>>> debates has made IETF network management largely irrelevant to the >>>> operator community (our customers). >>>> As always, we need to be vigilant and determine whether enough >>>> thought >>>> has been given to reuse of existing protocols. We also need to >>>> consider the tradeoffs between new protocols and reusing existing >>>> protocols in ways they were not designed to be used. >>>> A4) Why isn't XSD or RelaxNG good enough? >>>> As mentioned in A2, NM data models need to be both machine- and >>>> human-readable. XSD is machine-readable, but it is a tough language >>>> for humans. RelaxNG seems better. As discussed further in a >>>> different email, Netconf will almost >>>> certainly need a DML suited to its requirements, and if RelaxNG is >>>> found to be human-friendly-enough, we would almost certainly still >>>> need to select a subset and adapt it to meet configuration >>>> requirements. So the benefit of using RelaxNG over a domain- >>>> specific >>>> DML may be lost by using an adapted-subset of RelaxNG. >>>> Most operators already understand languages like Perl and C and >>>> Javascript, because they already need to write lots of scripts to >>>> manage their networks. Most implementers of NM support in >>>> internetworking devices work in C or a variant of C. It makes a >>>> lot of >>>> sense to use a language with a C-like syntax for these people, >>>> rather >>>> than forcing them to learn yet another language that was >>>> designed for >>>> some other purpose. >>>> [soap] >>>> somebody commented that the designers of XSD and RelaxNG really >>>> understand how to design DMLs, implying that the OPS community does >>>> not. Many of the people involved in the ongoing DML discussions >>>> over >>>> the years, and now, are MIB Doctors and operators and protocol >>>> designers, and have had years of experience designing and >>>> working with >>>> SMI and network management. They understand the requirements of >>>> a DML >>>> for NM far more than the designers of XSD or RelaxNG, who were not >>>> designing their DMLs for NM purposes. >>>> [end soap] >>>> David Harrington >>>> dbharrington@comcast.net >>>> ietfdbh@comcast.net >>> >>> > Thanks, /jon ---- Jon Saperia saperia@jdscons.com (mobil) 617-201-2655 (office) 978-461-0249 --Apple-Mail-1--715098613 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Wrong order - people will push (not just the vendors for convenience) = when there is something that makes a real difference.
On = Dec 2, 2007, at 3:19 PM, Balazs Lengyel wrote:

Hello,
Naturally our = aim is to develop standard NETCONF configuration models, and the more = people use NETCONF the easier that will be.


Jon = Saperia wrote:
/jon
----------------------
Jon = Saperia
TSP NM
(mobil) 617-201-2655
(office) = 978-461-0249
saperia@jdscons.com <mailto:saperia@jdscons.com>
On Dec 2, 2007, at 1:20 PM, Balazs Lengyel = wrote:
>>=A0 =A0 Q1) Why does NETCONF need = a DML at all?

If we have an IETF standard DML for NETCONF, device = vendors (like my company) will be much more comfortable, much more = willing to adapt NETCONF itself. With a standard DML we would see a = better chance at having available 3rd party or even freeware toolkits = for NETCONF.
Yes, but does = that mean that we will begin to develop a standard configuration objects = for say, BGP or DiffServ that would work from one vendor to the = next?=A0 It would be nice = to think so, that would really help interoperability and should be the = target of 'our' collective efforts.
/jon
=
The above would be important = even for a company which would not care about = interoperability.

Balazs

David Harrington wrote:
=
=A0

Hi,

There are a few questions that = the IESG and others have asked,
which I will = try to address:

=A0=A0 = Q1) Why does NETCONF need a DML at all?
=A0=A0 = Q2) Why is NETCONF special?
=A0=A0 Q3) Why won't lots of = other WGs want to define their own
=A0=A0 =A0 =A0 protocol-specific = DMLs?
=A0=A0 Q4) Why isn't XSD or = RelaxNG good enough?
I'll take a = whack at answering the same questions.
A1) Why = does NETCONF need a DML at all?
to promote = vendor-neutral interoperable management. It is much easier to develop = standards when everybody uses the same
basic = language to communicate; this "common language for shared
communication" is also reflected in the IETF = decision to use English
text and = ASCII documents.
This is not just about being = able to standardize **device
management**; = it is a basic step to permit the standardization of
**network management** and possibly **services = management". The DML is
a basic = building block.
A2) Why is NETCONF = special?
It is and it isn't. Netconf is = only one protocol used for network
management. = It has some unique requirements, such as using a = document-based
approach and differentiating the = data for config versus state and for
dealing with = different time-defined contexts such as running and
startup configs. This differs from other network = management protocols,
such as SNMP and syslog and = ipfix, which use their own data formats,
and = usually deal only with the currently-running config. Netconf is = a
tool designed to meet the special requirements = of configuration, and
the DML needs to support = special features not found in other NM-DMLs. Netconf is not special, in = that any language used for network
management is = likely to have certain common requirements. NM data
models are commonly used directly by humans, in = their raw form, such
as when they troubleshoot = problems using network sniffers. NM data
models = are also commonly used by NMS applications that can handle the
translations into a more human-readable format. = Designers of NM tools
(e.g., protocols and data = models) thus need to pay close attention to
who = will use the information, and to assume that the data will be = used
both directly by humans and by = applications. Operators have complained
strongly = that OIDs are very hard to work with in raw form, yet
operators frequently need to deal with the raw form = of the data. A3) Why won't lots of other WGs want to define their = own
=A0 =A0 =A0 =A0 protocol-specific = DMLs?
To paraphrase a wise man from = the SNMP community, when you fill a room
with = protocol designers and ask for a solution to a problem, is it = a
surprise when they recommend designing a new = protocol?
The decision about whether to = use an existing protocol/DML or develop
a new = protocol/DML should be made after a careful analysis of the
requirements of the solution. SNMP was designed when = CMIP was found to
not quite address the needs. The = SMI was designed when ASN.1 was found
to not = quite address the needs. XML was designed when other DMLs were
found to not quite address the needs.
The decision to explore an XML-based DML and to = explore a C-like DML
follows years and years and = years of debate over the requiremnts of
network = management, and configuration in particular. If every WG spends as much = time analyzing the requirements that the
OPS area = has spent considering this decision, it might be good for
ensuring no new protoocls are designed that are not = really needed, but
the IETF would also grind = to a halt, much as the OPS community has
done = over our many years of debate. And the delay caused by our
debates has made IETF network management largely = irrelevant to the
operator community (our = customers).
As always, we need to be = vigilant and determine whether enough thought
has been given to reuse of existing protocols. We = also need to
consider the tradeoffs between = new protocols and reusing existing
protocols in = ways they were not designed to be used.
A4) Why = isn't XSD or RelaxNG good enough?
As mentioned = in A2, NM data models need to be both machine- and
human-readable. XSD is machine-readable, but it is a = tough language
for humans. RelaxNG seems = better. As discussed further in a different email, Netconf will = almost
certainly need a DML suited to = its requirements, and if RelaxNG is
found to be = human-friendly-enough, we would almost certainly still
need to select a subset and adapt it to meet = configuration
requirements. So the benefit of = using RelaxNG over a domain-specific
DML may be = lost by using an adapted-subset of RelaxNG.
Most = operators already understand languages like Perl and C and
Javascript, because they already need to write lots = of scripts to
manage their networks. Most = implementers of NM support in
sense to use a language with a C-like syntax = for these people, rather
than forcing = them to learn yet another language that was designed for
some other purpose.
somebody commented that the = designers of XSD and RelaxNG really
understand = how to design DMLs, implying that the OPS community does
not. Many of the people involved in the ongoing DML = discussions over
the years, and now, are MIB = Doctors and operators and protocol
designers, = and have had years of experience designing and working with
SMI and network management. They understand the = requirements of a DML
for NM far more than the = designers of XSD or RelaxNG, who were not
[end = soap]
David Harrington
dbharrington@comcast.net <mailto:dbharrington@comcast.net>


=
saperia@jdscons.com
(mob= il) = 617-201-2655
(office) = 978-461-0249



= --Apple-Mail-1--715098613-- --===============0034315223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============0034315223==-- From yang-bounces@ietf.org Tue Dec 04 12:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izb8c-0005Uw-B9; Tue, 04 Dec 2007 12:00:50 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Izb8Q-000555-Vs for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izb8J-0004vL-TO for yang@ietf.org; Tue, 04 Dec 2007 12:00:32 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izb8I-0006aB-D7 for yang@ietf.org; Tue, 04 Dec 2007 12:00:31 -0500 Received: from [198.18.175.153] (unknown [207.236.117.226]) by office2.cesnet.cz (Postfix) with ESMTP id 2A1A0D80098 for ; Tue, 4 Dec 2007 18:00:22 +0100 (CET) From: Ladislav Lhotka To: yang Content-Type: text/plain Organization: CESNET Date: Tue, 04 Dec 2007 09:00:21 -0800 Message-Id: <1196787621.5745.23.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [YANG] key ambiguity? X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, is the following fragment legal in YANG? list lll { key id; container aaa { leaf id { ... } } container bbb { leaf id { ... } } } If so, then the key is ambiguous. Perhaps the key should contain an XPath expression? Cheers, Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 12:29:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbaF-0006wq-8b; Tue, 04 Dec 2007 12:29:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzbaE-0006wi-Mz for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:29:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbaE-0006wW-CY for yang@ietf.org; Tue, 04 Dec 2007 12:29:22 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzbaD-0005A9-VE for yang@ietf.org; Tue, 04 Dec 2007 12:29:22 -0500 Received: (qmail 48187 invoked from network); 4 Dec 2007 17:29:09 -0000 Received: from unknown (HELO dhcp-4049.ietf70.org) (andybierman@att.net@130.129.64.73 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2007 17:29:09 -0000 X-YMail-OSG: 2lV7X6YVM1mkbI23m5DnT2Wb8B9al55r5bCkD3T70k4qMH7t Message-ID: <47558E0E.1040205@andybierman.com> Date: Tue, 04 Dec 2007 09:27:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] key ambiguity? References: <1196787621.5745.23.camel@missotis> In-Reply-To: <1196787621.5745.23.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > is the following fragment legal in YANG? > > list lll { > key id; > container aaa { > leaf id { ... } > } > container bbb { > leaf id { ... } > } > } > > If so, then the key is ambiguous. Perhaps the key should contain an > XPath expression? > Yes -- this has been discussed and it is what I have implemented. The construct you defined in illegal in YANG right now, but I think there might be consensus to change it. The key "aaa/id bbb/id" would be valid with this change. > Cheers, Lada > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 12:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzboD-00028p-Ic; Tue, 04 Dec 2007 12:43:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzboC-00028W-O1 for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:43:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzboC-00028F-Di for yang@ietf.org; Tue, 04 Dec 2007 12:43:48 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzboC-0006fr-1q for yang@ietf.org; Tue, 04 Dec 2007 12:43:48 -0500 Received: from [198.18.175.153] (unknown [207.236.117.226]) by office2.cesnet.cz (Postfix) with ESMTP id C5ACBD800C8; Tue, 4 Dec 2007 18:43:46 +0100 (CET) Subject: Re: [YANG] key ambiguity? From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <47558E0E.1040205@andybierman.com> References: <1196787621.5745.23.camel@missotis> <47558E0E.1040205@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 04 Dec 2007 09:43:44 -0800 Message-Id: <1196790224.5745.33.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v =C3=9At 04. 12. 2007 v 09:27 -0800: > Ladislav Lhotka wrote: > > Hi, > > > > is the following fragment legal in YANG? > > > > list lll { > > key id; > > container aaa { > > leaf id { ... } > > } > > container bbb { > > leaf id { ... } > > } > > } > > > > If so, then the key is ambiguous. Perhaps the key should contain an > > XPath expression? > > =20 >=20 > Yes -- this has been discussed and it is what I have implemented. > The construct you defined in illegal in YANG right now, but I > think there might be consensus to change it. Why is it illegal, because of the key ambiguity or another reason? >=20 > The key "aaa/id bbb/id" would be valid with this change. Alternative option would be to indicate inside the leaf that it is a key for an enclosing list: leaf id { key ../lll; ... } Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 12:56:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc0S-0005Td-6W; Tue, 04 Dec 2007 12:56:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Izc0Q-0005TC-Fb for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:56:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc0Q-0005Sv-5I for yang@ietf.org; Tue, 04 Dec 2007 12:56:26 -0500 Received: from exprod7og109.obsmtp.com ([64.18.2.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izc0P-0007lW-L5 for yang@ietf.org; Tue, 04 Dec 2007 12:56:26 -0500 Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Dec 2007 09:56:14 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 09:55:57 -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 lB4HtuE73277; Tue, 4 Dec 2007 09:55:56 -0800 (PST) (envelope-from phil@idle.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 lB4HqcCb086059; Tue, 4 Dec 2007 17:52:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712041752.lB4HqcCb086059@idle.juniper.net> To: Ladislav Lhotka Subject: Re: [YANG] key ambiguity? In-reply-to: <1196790224.5745.33.camel@missotis> Date: Tue, 04 Dec 2007 12:52:38 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2007 17:55:57.0203 (UTC) FILETIME=[EBFD2E30:01C8369E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka writes: >Andy Bierman píše v Út 04. 12. 2007 v 09:27 -0800: >> Ladislav Lhotka wrote: >> > list lll { >> > key id; >> > container aaa { >> > leaf id { ... } >> > } >> > container bbb { >> > leaf id { ... } >> > } >> > } >Why is it illegal, because of the key ambiguity or another reason? "key id" is illegal, since there is no "id" leaf immediately under "lll". Your YANG parser should give you a compiler error. You'd need to qualify it as "aaa/id" or "bbb/id" or even "aaa/id bbb/id". >Alternative option would be to indicate inside the leaf that it is a key >for an enclosing list: > >leaf id { > key ../lll; > ... >} This would mean you'd need to look in multiple places to find the keys. Early in YANG, we did something like this, but moved to the current notation for this reason. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 13:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcNa-0002NL-GZ; Tue, 04 Dec 2007 13:20:22 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzcNY-0002Gs-Fv for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:20:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcNY-0002Gb-69 for yang@ietf.org; Tue, 04 Dec 2007 13:20:20 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcNX-0006BP-Ri for yang@ietf.org; Tue, 04 Dec 2007 13:20:20 -0500 Received: from [198.18.175.153] (unknown [207.236.117.226]) by office2.cesnet.cz (Postfix) with ESMTP id 212F6D800BD; Tue, 4 Dec 2007 19:20:15 +0100 (CET) Subject: Re: [YANG] key ambiguity? From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200712041752.lB4HqcCb086059@idle.juniper.net> References: <200712041752.lB4HqcCb086059@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 04 Dec 2007 10:20:14 -0800 Message-Id: <1196792414.5745.41.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v =C3=9At 04. 12. 2007 v 12:52 -0500: > >Why is it illegal, because of the key ambiguity or another reason? >=20 > "key id" is illegal, since there is no "id" leaf immediately under > "lll". Your YANG parser should give you a compiler error. You'd > need to qualify it as "aaa/id" or "bbb/id" or even "aaa/id bbb/id". The production rule for key-arg in Appendix D only allows sequence of identifiers. >=20 > >Alternative option would be to indicate inside the leaf that it is a k= ey > >for an enclosing list: > > > >leaf id { > > key ../lll; > > ... > >} >=20 > This would mean you'd need to look in multiple places to find > the keys. Early in YANG, we did something like this, but moved > to the current notation for this reason. On the other hand it makes life harder to the agent, e.g., when asked to delete a leaf, it would have to check the ancestry chain whether this leaf is not among the keys of some list. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 13:26:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcTq-0002ih-B1; Tue, 04 Dec 2007 13:26:50 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzcTp-0002hF-6u for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:26:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcTo-0002gd-Qw for yang@ietf.org; Tue, 04 Dec 2007 13:26:48 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzcTo-0002HR-Bt for yang@ietf.org; Tue, 04 Dec 2007 13:26:48 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Dec 2007 10:24:48 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 10:26: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 lB4IQXE82701; Tue, 4 Dec 2007 10:26:33 -0800 (PST) (envelope-from phil@idle.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 lB4INGKO086396; Tue, 4 Dec 2007 18:23:16 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712041823.lB4INGKO086396@idle.juniper.net> to: Ladislav Lhotka , yang Subject: Re: [YANG] key ambiguity? In-reply-to: <200712041752.lB4HqcCb086059@idle.juniper.net> Date: Tue, 04 Dec 2007 13:23:15 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2007 18:26:34.0457 (UTC) FILETIME=[3313E490:01C836A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer writes: >Your YANG parser should give you a compiler error. You'd >need to qualify it as "aaa/id" or "bbb/id" or even "aaa/id bbb/id". Martin points out that we don't support deep keys in YANG. We debated this for a while and ended up dumping them to keep the rule that keys must appear first in list entries. Sorry for the misinformation. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 13:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izca0-0007OD-RO; Tue, 04 Dec 2007 13:33:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzcZz-0007Jb-8P for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcZy-0007Iv-Ua for yang@ietf.org; Tue, 04 Dec 2007 13:33:10 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcZy-0007RQ-Jy for yang@ietf.org; Tue, 04 Dec 2007 13:33:10 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KtaVDUovoanzm4BzwO8IZZNSZNixKH7oIV4RzbDP2Y27OPvtgmj9lKEQYBMzOgqz; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.202.36] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IzcZx-0001fV-6y for yang@ietf.org; Tue, 04 Dec 2007 13:33:10 -0500 Message-ID: <002501c836a4$623472c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "yang" References: <200712041752.lB4HqcCb086059@idle.juniper.net> <1196792414.5745.41.camel@missotis> Subject: Re: [YANG] key ambiguity? Date: Tue, 4 Dec 2007 10:35:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a09fafbbc523b4ab404c31c4f1269bb17350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.202.36 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi - Perhaps it's time to recognize that containers are objects (forgive the language) and as such deserve instance names of their own, even if there might be only one with a particular parent. Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 13:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izcrr-0002ki-9Z; Tue, 04 Dec 2007 13:51:39 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Izcrq-0002kV-TP for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:51:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izcrq-0002jN-JC for yang@ietf.org; Tue, 04 Dec 2007 13:51:38 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izcrq-0000V3-8l for yang@ietf.org; Tue, 04 Dec 2007 13:51:38 -0500 Received: from [198.18.175.153] (unknown [207.236.117.226]) by office2.cesnet.cz (Postfix) with ESMTP id 4C8AED800C1 for ; Tue, 4 Dec 2007 19:51:37 +0100 (CET) Subject: Re: [YANG] key ambiguity? From: Ladislav Lhotka To: yang In-Reply-To: <200712041823.lB4INGKO086396@idle.juniper.net> References: <200712041823.lB4INGKO086396@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 04 Dec 2007 10:51:32 -0800 Message-Id: <1196794292.5745.58.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v =C3=9At 04. 12. 2007 v 13:23 -0500: > Phil Shafer writes: > >Your YANG parser should give you a compiler error. You'd > >need to qualify it as "aaa/id" or "bbb/id" or even "aaa/id bbb/id". >=20 > Martin points out that we don't support deep keys in YANG. We > debated this for a while and ended up dumping them to keep the > rule that keys must appear first in list entries. Sorry for the > misinformation. OK, then the draft should say that the key consists of identifiers of *child leafs*, and maybe also explain that if there is no such leaf (like in my example), it must be created. Anyway, this restriction is quite problematic - it actually seems to me that lists with structured items (containers) cannot be constructed at all. In such cases, the key simply cannot be a child of the list statement. Lada >=20 > Thanks, > Phil --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 14:19:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdIu-0007S9-ND; Tue, 04 Dec 2007 14:19:36 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzdIt-0007Qu-KP for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:19:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdIt-0007PG-AB for yang@ietf.org; Tue, 04 Dec 2007 14:19:35 -0500 Received: from smtp115.sbc.mail.sp1.yahoo.com ([69.147.64.88]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzdIs-00033z-S9 for yang@ietf.org; Tue, 04 Dec 2007 14:19:35 -0500 Received: (qmail 77456 invoked from network); 4 Dec 2007 19:19:34 -0000 Received: from unknown (HELO dhcp-16b6.ietf70.org) (andybierman@att.net@130.129.22.182 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2007 19:19:34 -0000 X-YMail-OSG: zggyRLAVM1mDW39S2Nfxca6uHE_.2QmWhwi0IpNcsQZp1yMT Message-ID: <4755A7EE.7060908@andybierman.com> Date: Tue, 04 Dec 2007 11:18:06 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] key ambiguity? References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis> In-Reply-To: <1196794292.5745.58.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Phil Shafer píše v Út 04. 12. 2007 v 13:23 -0500: > >> Phil Shafer writes: >> >>> Your YANG parser should give you a compiler error. You'd >>> need to qualify it as "aaa/id" or "bbb/id" or even "aaa/id bbb/id". >>> >> Martin points out that we don't support deep keys in YANG. We >> debated this for a while and ended up dumping them to keep the >> rule that keys must appear first in list entries. Sorry for the >> misinformation. >> > > OK, then the draft should say that the key consists of identifiers of > *child leafs*, and maybe also explain that if there is no such leaf > (like in my example), it must be created. Anyway, this restriction is > quite problematic - it actually seems to me that lists with structured > items (containers) cannot be constructed at all. In such cases, the key > simply cannot be a child of the list statement. > I do not agree that the leaf will be created if the identifier in the key does not exist. The compiler does not know the correct data type to use for the key. The identifier could be a typo, and a new leaf is not what the DM writer wanted at all. I want the ability to have deep keys. However , there are CLRs to consider. A nested key cannot be within a choice or another list. The key components need to be unambiguous and there must be exactly one instance of each key component. Therefore only leafs within containers could qualify. The use case is an important one. If a DM writer couples 2 leaves together (e.g. address, port) then this construct cannot be used as the key, and cut-and-paste will have to be used instead to 'undo' the container. In NCX, I (at first) allowed the container itself to be listed as the key (implying a sequence of leaf key components), but took this out because if the (external) container definition changed, this also changed the key definition for the list. The 'SMI way' of listing each index component, in order, seems the safest and most clear to readers. > Lada > Andy > >> Thanks, >> Phil >> _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 15:31:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzeQl-0006YB-GE; Tue, 04 Dec 2007 15:31:47 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzeQk-0006U4-DQ for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 15:31:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzeQk-0006TI-1y for yang@ietf.org; Tue, 04 Dec 2007 15:31:46 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzeQi-0008VG-8X for yang@ietf.org; Tue, 04 Dec 2007 15:31:46 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 219418A147; Tue, 4 Dec 2007 21:31:43 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08132-01; Tue, 4 Dec 2007 21:31:38 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD4B78654F; Tue, 4 Dec 2007 21:31:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F632409812; Tue, 4 Dec 2007 21:31:38 +0100 (CET) Date: Tue, 4 Dec 2007 21:31:38 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] key ambiguity? Message-ID: <20071204203138.GA21675@elstar.local> References: <1196787621.5745.23.camel@missotis> <47558E0E.1040205@andybierman.com> <1196790224.5745.33.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196790224.5745.33.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Tue, Dec 04, 2007 at 09:43:44AM -0800, Ladislav Lhotka wrote: > Alternative option would be to indicate inside the leaf that it is a key > for an enclosing list: > > leaf id { > key ../lll; > ... > } A reason for not going down this path was that we like to have reusable groupings where the keys can be defined when you use a grouping rather than being part of a reusable grouping. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 16:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfYz-0005st-Ob; Tue, 04 Dec 2007 16:44:21 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzfYy-0005rc-LL for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:44:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfYy-0005rS-BB for yang@ietf.org; Tue, 04 Dec 2007 16:44:20 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzfYx-0001Cm-VM for yang@ietf.org; Tue, 04 Dec 2007 16:44:20 -0500 Received: from [130.129.20.210] (dhcp-14d2.ietf70.org [130.129.20.210]) by office2.cesnet.cz (Postfix) with ESMTP id B9437D80098; Tue, 4 Dec 2007 22:44:18 +0100 (CET) Subject: Re: [YANG] key ambiguity? From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4755A7EE.7060908@andybierman.com> References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis> <4755A7EE.7060908@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 04 Dec 2007 13:44:16 -0800 Message-Id: <1196804656.5759.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v =C3=9At 04. 12. 2007 v 11:18 -0800: > I do not agree that the leaf will be created if the identifier in > the key does not exist. The compiler does not know the > correct data type to use for the key. The identifier could > be a typo, and a new leaf is not what the DM writer wanted > at all. Oh, I didn't mean that the key would be created automatically but rather by the model designer since the key is required for lists representing configuration. Without this requirement, many lists would naturally have only container items. =20 >=20 > I want the ability to have deep keys. It seems absolutely necessary - the only way I can see for creating lists other than leaf-lists is like this: 0 ... 1 ... ... where the ifIndex element is the key for the following (sibling) interface item, but this is ugly and error-prone. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 17:01:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfpm-0003aJ-AZ; Tue, 04 Dec 2007 17:01:42 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Izfpk-0003Zk-Nn for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:01:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfpk-0003Zb-EB for yang@ietf.org; Tue, 04 Dec 2007 17:01:40 -0500 Received: from smtp115.sbc.mail.sp1.yahoo.com ([69.147.64.88]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Izfpk-0007UW-0C for yang@ietf.org; Tue, 04 Dec 2007 17:01:40 -0500 Received: (qmail 68523 invoked from network); 4 Dec 2007 22:01:39 -0000 Received: from unknown (HELO dhcp-16b6.ietf70.org) (andybierman@att.net@130.129.22.182 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2007 22:01:39 -0000 X-YMail-OSG: nGpMg38VM1nW1xSBYSNHpeiovSk.g2uMQE4b0N.G61i8r99a Message-ID: <4755CDEA.9010603@andybierman.com> Date: Tue, 04 Dec 2007 14:00:10 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] key ambiguity? References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis> <4755A7EE.7060908@andybierman.com> <1196804656.5759.16.camel@missotis> In-Reply-To: <1196804656.5759.16.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Andy Bierman píše v Út 04. 12. 2007 v 11:18 -0800: > > >> I do not agree that the leaf will be created if the identifier in >> the key does not exist. The compiler does not know the >> correct data type to use for the key. The identifier could >> be a typo, and a new leaf is not what the DM writer wanted >> at all. >> > > Oh, I didn't mean that the key would be created automatically but rather > by the model designer since the key is required for lists representing > configuration. Without this requirement, many lists would naturally have > only container items. > > >> I want the ability to have deep keys. >> > > It seems absolutely necessary - the only way I can see for creating > lists other than leaf-lists is like this: > > > 0 > ... > 1 > ... > ... > > > where the ifIndex element is the key for the following (sibling) > interface item, but this is ugly and error-prone. > Why would you even model the interfaces table this way? We have been using the following example for a few years in the NETCONF WG: eth0 1 1500 Since ifIndex is part of the interface data, it is included within the interface element. > Lada > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 17:13:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg0v-0004VZ-PF; Tue, 04 Dec 2007 17:13:13 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Izg0u-0004VK-7o for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:13:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg0t-0004VB-U8 for yang@ietf.org; Tue, 04 Dec 2007 17:13:11 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izg0s-0008QS-CH for yang@ietf.org; Tue, 04 Dec 2007 17:13:11 -0500 Received: from [130.129.20.210] (dhcp-14d2.ietf70.org [130.129.20.210]) by office2.cesnet.cz (Postfix) with ESMTP id 637D8D800BD; Tue, 4 Dec 2007 23:13:05 +0100 (CET) Subject: Re: [YANG] key ambiguity? From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4755CDEA.9010603@andybierman.com> References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis> <4755A7EE.7060908@andybierman.com> <1196804656.5759.16.camel@missotis> <4755CDEA.9010603@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 04 Dec 2007 14:13:03 -0800 Message-Id: <1196806383.5759.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v =C3=9At 04. 12. 2007 v 14:00 -0800: > > > > 0 > > ... > > 1 > > ... > > ... > > > > > > where the ifIndex element is the key for the following (sibling) > > interface item, but this is ugly and error-prone. > > =20 >=20 > Why would you even model the interfaces table this way? Because it is the only way that the draft allows: each item MUST have a leaf key that is a direct child of the list statement. >=20 > We have been using the following example for a few years > in the NETCONF WG: Of course, this is the way to do it but you see - the key is deep here. >=20 > > > eth0 > 1 > 1500 > > >=20 > Since ifIndex is part of the interface data, it is included within > the interface element. >=20 Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 17:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg6S-0003VE-6i; Tue, 04 Dec 2007 17:18:56 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Izg6Q-0003RA-FR for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:18:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg6Q-0003Qh-3f for yang@ietf.org; Tue, 04 Dec 2007 17:18:54 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Izg6P-00048J-Br for yang@ietf.org; Tue, 04 Dec 2007 17:18:54 -0500 Received: (qmail 17818 invoked from network); 4 Dec 2007 22:18:52 -0000 Received: from unknown (HELO dhcp-16b6.ietf70.org) (andybierman@att.net@130.129.22.182 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2007 22:18:52 -0000 X-YMail-OSG: 4uq.vj8VM1kIk3KlObk2AVpdlT7ae_z7qx8mLSq12kxcxzIa Message-ID: <4755D1F3.6020200@andybierman.com> Date: Tue, 04 Dec 2007 14:17:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] key ambiguity? References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis> <4755A7EE.7060908@andybierman.com> <1196804656.5759.16.camel@missotis> <4755CDEA.9010603@andybierman.com> <1196806383.5759.22.camel@missotis> In-Reply-To: <1196806383.5759.22.camel@missotis> Content-Type: multipart/mixed; boundary="------------050201090908090505040903" X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org This is a multi-part message in MIME format. --------------050201090908090505040903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Ladislav Lhotka wrote: > Andy Bierman píše v Út 04. 12. 2007 v 14:00 -0800: > >>> >>> 0 >>> ... >>> 1 >>> ... >>> ... >>> >>> >>> where the ifIndex element is the key for the following (sibling) >>> interface item, but this is ugly and error-prone. >>> >>> >> Why would you even model the interfaces table this way? >> > > Because it is the only way that the draft allows: each item MUST have a > leaf key that is a direct child of the list statement. > See the attached YANG file, which is the start of an interfaces model. The 'name' and 'ifIndex' leafs are children of the list 'interface', which is legal in YANG. (The 'name' is the key, not ifIndex. Not sure if this is too controversial or not.) > >> We have been using the following example for a few years >> in the NETCONF WG: >> > > Of course, this is the way to do it but you see - the key is deep here. > > >> >> >> eth0 >> 1 >> 1500 >> >> >> >> Since ifIndex is part of the interface data, it is included within >> the interface element. >> >> > > Lada > > Andy --------------050201090908090505040903 Content-Type: text/plain; name="interfaces.yang" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="interfaces.yang" bW9kdWxlIGludGVyZmFjZXMgewogICAgbmFtZXNwYWNlICJ1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOnlhbmc6aW50ZXJmYWNlcyI7CiAgICBwcmVmaXggImlmIjsKCiAgICBvcmdhbml6YXRp b24KICAgICAgICAiWUFORyBMYW5ndWFnZSBEZXNpZ24gVGVhbSI7CgogICAgY29udGFjdAog ICAgICAgICJBbmR5IEJpZXJtYW4gPGlldGZAYW5keWJpZXJtYW4uY29tPiI7CgogICAgZGVz Y3JpcHRpb24KICAgICAgICAiVGhpcyBtb2R1bGUgY29udGFpbnMgYW4gaW50ZXJmYWNlcyB0 YWJsZS4iOwoKICAgIHJldmlzaW9uIDIwMDctMTItMDQgewogICAgICAgIGRlc2NyaXB0aW9u ICJJbml0aWFsIHJldmlzaW9uLiI7CiAgICB9CgogICAgaW1wb3J0IGlhbmFUeXBlcyB7IHBy ZWZpeCBpYW5hOyB9CgogICAgaW1wb3J0IGlmdHlwZXMgeyBwcmVmaXggaWZ0OyB9CgogICAg aW1wb3J0IHNtaSB7IHByZWZpeCBzbWk7IH0KCiAgICBsZWFmIGlmTnVtYmVyIHsKICAgICAg ICBkZXNjcmlwdGlvbgogICAgICAgICAgIlRoZSBudW1iZXIgb2YgbmV0d29yayBpbnRlcmZh Y2VzIChyZWdhcmRsZXNzIG9mIHRoZWlyCiAgICAgICAgICAgY3VycmVudCBzdGF0ZSkgcHJl c2VudCBvbiB0aGlzIHN5c3RlbS4iOwogICAgICAgIHR5cGUgaW50MzI7CiAgICAgICAgY29u ZmlnIGZhbHNlOwogICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgfQoKICAgIGxlYWYgaWZU YWJsZUxhc3RDaGFuZ2UgewogICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAiVGhlIHZh bHVlIG9mIHN5c1VwVGltZSBhdCB0aGUgdGltZSBvZiB0aGUgbGFzdCBjcmVhdGlvbiBvcgog ICAgICAgICAgIGRlbGV0aW9uIG9mIGFuIGVudHJ5IGluIHRoZSBpZlRhYmxlLiAgSWYgdGhl IG51bWJlciBvZgogICAgICAgICAgIGVudHJpZXMgaGFzIGJlZW4gdW5jaGFuZ2VkIHNpbmNl IHRoZSBsYXN0IHJlLWluaXRpYWxpemF0aW9uCiAgICAgICAgICAgb2YgdGhlIGxvY2FsIG5l dHdvcmsgbWFuYWdlbWVudCBzdWJzeXN0ZW0sIHRoZW4gdGhpcyBvYmplY3QKICAgICAgICAg ICBjb250YWlucyBhIHplcm8gdmFsdWUuIjsKICAgICAgICB0eXBlIHNtaTpUaW1lVGlja3M7 CiAgICAgICAgY29uZmlnIGZhbHNlOwogICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgfQoK ICAgIGNvbnRhaW5lciBpbnRlcmZhY2VzIHsKCiAgICAgIGxpc3QgaW50ZXJmYWNlIHsKICAK ICAgICAgICBrZXkgbmFtZTsKCiAgICAgICAgdW5pcXVlIGlmSW5kZXg7CgogICAgICAgIGxl YWYgbmFtZSB7CiAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiVGhlIGludGVyZmFjZSBuYW1l LiI7CiAgICAgICAgICAgICB0eXBlIHN0cmluZyB7CiAgICAgICAgICAgICAgIGxlbmd0aCAi MS4ubWF4IjsKICAgICAgICAgICB9CiAgICAgICAgfQoKICAgICAgICBsZWFmIElmSW5kZXgg ewogICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgIkEgdW5pcXVlIHZhbHVl LCBncmVhdGVyIHRoYW4gemVybywgZm9yIGVhY2ggaW50ZXJmYWNlLiAgSXQKICAgICAgICAg ICAgICBpcyByZWNvbW1lbmRlZCB0aGF0IHZhbHVlcyBhcmUgYXNzaWduZWQgY29udGlndW91 c2x5CiAgICAgICAgICAgICAgc3RhcnRpbmcgZnJvbSAxLiAgVGhlIHZhbHVlIGZvciBlYWNo IGludGVyZmFjZSBzdWItbGF5ZXIKICAgICAgICAgICAgICBtdXN0IHJlbWFpbiBjb25zdGFu dCBhdCBsZWFzdCBmcm9tIG9uZSByZS1pbml0aWFsaXphdGlvbiBvZgogICAgICAgICAgICAg IHRoZSBlbnRpdHkncyBuZXR3b3JrIG1hbmFnZW1lbnQgc3lzdGVtIHRvIHRoZSBuZXh0IHJl LQogICAgICAgICAgICAgIGluaXRpYWxpemF0aW9uLiI7CiAgICAgICAgICAgIHR5cGUgaXRm OkludGVyZmFjZUluZGV4OwogICAgICAgIH0KCiAgICAgICAgbGVhZiBJZkRlc2NyIHsKICAg ICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICJBIHRleHR1YWwgc3RyaW5nIGNv bnRhaW5pbmcgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAgICAgICAgICAgaW50ZXJmYWNl LiAgVGhpcyBzdHJpbmcgc2hvdWxkIGluY2x1ZGUgdGhlIG5hbWUgb2YgdGhlCiAgICAgICAg ICAgICAgbWFudWZhY3R1cmVyLCB0aGUgcHJvZHVjdCBuYW1lIGFuZCB0aGUgdmVyc2lvbiBv ZiB0aGUKICAgICAgICAgICAgICBpbnRlcmZhY2UgaGFyZHdhcmUvc29mdHdhcmUuIjsKICAg ICAgICAgICAgdHlwZSBzbWk6RGlzcGxheVN0cmluZyB7CiAgICAgICAgICAgICAgbGVuZ3Ro ICIwLi4yNTUiOwogICAgICAgICAgICB9CiAgICAgICAgICAgIGNvbmZpZyBmYWxzZTsKICAg ICAgICB9CgogICAgICAgIGxlYWYgSWZUeXBlIHsKICAgICAgICAgICAgZGVzY3JpcHRpb24K ICAgICAgICAgICAgICJUaGUgdHlwZSBvZiBpbnRlcmZhY2UuICBBZGRpdGlvbmFsIHZhbHVl cyBmb3IgaWZUeXBlIGFyZQogICAgICAgICAgICAgIGFzc2lnbmVkIGJ5IHRoZSBJbnRlcm5l dCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSAoSUFOQSksCiAgICAgICAgICAgICAgdGhy b3VnaCB1cGRhdGluZyB0aGUgc3ludGF4IG9mIHRoZSBJQU5BaWZUeXBlIHRleHR1YWwKICAg ICAgICAgICAgICBjb252ZW50aW9uLiI7CiAgICAgICAgICAgIHR5cGUgaWFuYTpJQU5BaWZU eXBlOwogICAgICAgICAgICBjb25maWcgZmFsc2U7CiAgICAgICAgfQogICAgICAKICAgICAg ICBsZWFmIElmTXR1IHsKICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICJU aGUgc2l6ZSBvZiB0aGUgbGFyZ2VzdCBwYWNrZXQgd2hpY2ggY2FuIGJlIHNlbnQvcmVjZWl2 ZWQKICAgICAgICAgICAgICBvbiB0aGUgaW50ZXJmYWNlLCBzcGVjaWZpZWQgaW4gb2N0ZXRz LiAgRm9yIGludGVyZmFjZXMgdGhhdAogICAgICAgICAgICAgIGFyZSB1c2VkIGZvciB0cmFu c21pdHRpbmcgbmV0d29yayBkYXRhZ3JhbXMsIHRoaXMgaXMgdGhlCiAgICAgICAgICAgICAg c2l6ZSBvZiB0aGUgbGFyZ2VzdCBuZXR3b3JrIGRhdGFncmFtIHRoYXQgY2FuIGJlIHNlbnQg b24gdGhlCiAgICAgICAgICAgICAgaW50ZXJmYWNlLiI7CiAgICAgICAgICAgIHR5cGUgaW50 MzI7CiAgICAgICAgICAgIGNvbmZpZyB0cnVlOwogICAgICAgIH0KCgovKgogICAgICAgICAg ICMgSWZTcGVlZCAgICAgICAgICAgICAgICAgaWZTcGVlZDsKICAgICAgICAgICAjIElmUGh5 c0FkZHJlc3MgICAgICAgICAgIGlmUGh5c0FkZHJlc3M7CiAgICAgICAgICAgIyBJZkFkbWlu U3RhdHVzICAgICAgICAgICBpZkFkbWluU3RhdHVzOwogICAgICAgICAgICMgSWZPcGVyU3Rh dHVzICAgICAgICAgICAgaWZPcGVyU3RhdHVzOwogICAgICAgICAgICMgSWZMYXN0Q2hhbmdl ICAgICAgICAgICAgaWZMYXN0Q2hhbmdlOwogICAgICAgICAgICMgSWZJbk9jdGV0cyAgICAg ICAgICAgICAgaWZJbk9jdGV0czsKICAgICAgICAgICAjIElmSW5VY2FzdFBrdHMgICAgICAg ICAgIGlmSW5VY2FzdFBrdHM7CiAgICAgICAgICAgIyBJZkluTlVjYXN0UGt0cyAgICAgICAg ICBpZkluTlVjYXN0UGt0czsgICAjIGRlcHJlY2F0ZWQKICAgICAgICAgICAjIElmSW5EaXNj YXJkcyAgICAgICAgICAgIGlmSW5EaXNjYXJkczsKICAgICAgICAgICAjIElmSW5FcnJvcnMg ICAgICAgICAgICAgIGlmSW5FcnJvcnM7CiAgICAgICAgICAgIyBJZkluVW5rbm93blByb3Rv cyAgICAgICBpZkluVW5rbm93blByb3RvczsKICAgICAgICAgICAjIElmT3V0T2N0ZXRzICAg ICAgICAgICAgIGlmT3V0T2N0ZXRzOwogICAgICAgICAgICMgSWZPdXRVY2FzdFBrdHMgICAg ICAgICAgaWZPdXRVY2FzdFBrdHM7CiAgICAgICAgICAgIyBJZk91dE5VY2FzdFBrdHMgICAg ICAgICBpZk91dE5VY2FzdFBrdHM7ICAjIGRlcHJlY2F0ZWQKICAgICAgICAgICAjIElmT3V0 RGlzY2FyZHMgICAgICAgICAgIGlmT3V0RGlzY2FyZHM7CiAgICAgICAgICAgIyBJZk91dEVy cm9ycyAgICAgICAgICAgICBpZk91dEVycm9yczsKICAgICAgICAgICAjIElmT3V0UUxlbiAg ICAgICAgICAgICAgIGlmT3V0UUxlbjsgICAgICAgICMgZGVwcmVjYXRlZAogICAgICAgICAg ICMgSWZTcGVjaWZpYyAgICAgICAgICAgICAgaWZTcGVjaWZpYzsgICAgICAgIyBkZXByZWNh dGVkCiovCgogICAgfQogIH0KfQoK --------------050201090908090505040903 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --------------050201090908090505040903-- From yang-bounces@ietf.org Tue Dec 04 17:35:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgM9-0000wk-Cu; Tue, 04 Dec 2007 17:35:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzgM7-0000sn-Cd for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:35:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgM7-0000sd-2H for yang@ietf.org; Tue, 04 Dec 2007 17:35:07 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzgM6-0005Vf-Ms for yang@ietf.org; Tue, 04 Dec 2007 17:35:06 -0500 Received: from [130.129.20.210] (dhcp-14d2.ietf70.org [130.129.20.210]) by office2.cesnet.cz (Postfix) with ESMTP id 83E3CD80098; Tue, 4 Dec 2007 23:35:05 +0100 (CET) Subject: Re: [YANG] key ambiguity? From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4755D1F3.6020200@andybierman.com> References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis> <4755A7EE.7060908@andybierman.com> <1196804656.5759.16.camel@missotis> <4755CDEA.9010603@andybierman.com> <1196806383.5759.22.camel@missotis> <4755D1F3.6020200@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 04 Dec 2007 14:35:03 -0800 Message-Id: <1196807704.5759.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v =C3=9At 04. 12. 2007 v 14:17 -0800: > > Because it is the only way that the draft allows: each item MUST have= a > > leaf key that is a direct child of the list statement. > > =20 >=20 > See the attached YANG file, which is the start of an interfaces model. > The 'name' and 'ifIndex' leafs are children of the list 'interface', > which is legal in YANG. (The 'name' is the key, not ifIndex. > Not sure if this is too controversial or not.) OK, sorry, it was my misunderstanding. I thought the YANG definition would be list interfaces { container interface { ... } } What confused me was that the list statement in fact defines content of an list item. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 17:46:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgXG-0008IB-2M; Tue, 04 Dec 2007 17:46:38 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzgXF-0008I6-Lg for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:46:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgXF-0008Hn-BW for yang@ietf.org; Tue, 04 Dec 2007 17:46:37 -0500 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzgXD-0002s4-N1 for yang@ietf.org; Tue, 04 Dec 2007 17:46:37 -0500 X-IronPort-AV: E=Sophos;i="4.23,250,1194201000"; d="scan'208";a="92445384" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 05 Dec 2007 17:25:34 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB4MkXsL012288; Wed, 5 Dec 2007 06:46:33 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB4MkTb6029811; Tue, 4 Dec 2007 22:46:31 GMT Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 06:46:29 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Subject: RE: [YANG] key ambiguity? Date: Wed, 5 Dec 2007 06:46:37 +0800 Message-ID: In-Reply-To: <4755CDEA.9010603@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [YANG] key ambiguity? Thread-Index: Acg2wVKvn6SGp+x4SIWVAv5j2bpcGgABZtMg References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis><4755A7EE.7060908@andybierman.com><1196804656.5759.16.camel@missotis> <4755CDEA.9010603@andybierman.com> From: "James Balestriere (jbalestr)" To: "Andy Bierman" X-OriginalArrivalTime: 04 Dec 2007 22:46:29.0918 (UTC) FILETIME=[82B263E0:01C836C7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2454; t=1196808393; x=1197672393; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jbalestr@cisco.com; z=From:=20=22James=20Balestriere=20(jbalestr)=22=20 |Subject:=20RE=3A=20[YANG]=20key=20ambiguity? |Sender:=20; bh=EC2QEp7WazjzGvEgCEjHOG61X66WJxs83l34hIXgvKs=; b=ZFM5ubB9tctNT75rdB8nKE7Zsn40E8iw9IZJ9/JIQxy04pllw5DCt9NoRI3swo9zMSbyEe++ JGMSRNNqcOw4x9jfSBkgioBc/0Fnt3LN1EiJqR9aV69Rueli/l/TBYhdCTX4tYDxGYiEBHbUEi nnUx0sZXUi/13F8FTG7yzgXDE=; Authentication-Results: hkg-dkim-2; header.From=jbalestr@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org I am bit confused by this example=20 eth0 1 1500 what does eth0 mean ? does it count something different to the ifIndex ? Also, if I have multiple cards with multiple ethernet ports would I have = to create another counter or something ? James. > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Wednesday, 5 December 2007 9:00 AM > To: Ladislav Lhotka > Cc: yang > Subject: Re: [YANG] key ambiguity? >=20 > Ladislav Lhotka wrote: > > Andy Bierman p=ED=B9e v =DAt 04. 12. 2007 v 11:18 -0800: > > > > =20 > >> I do not agree that the leaf will be created if the identifier in > >> the key does not exist. The compiler does not know the > >> correct data type to use for the key. The identifier could > >> be a typo, and a new leaf is not what the DM writer wanted > >> at all. > >> =20 > > > > Oh, I didn't mean that the key would be created=20 > automatically but rather > > by the model designer since the key is required for lists=20 > representing > > configuration. Without this requirement, many lists would=20 > naturally have > > only container items. > > =20 > > =20 > >> I want the ability to have deep keys. > >> =20 > > > > It seems absolutely necessary - the only way I can see for creating > > lists other than leaf-lists is like this: > > > > > > 0 > > ... > > 1 > > ... > > ... > > > > > > where the ifIndex element is the key for the following (sibling) > > interface item, but this is ugly and error-prone. > > =20 >=20 > Why would you even model the interfaces table this way? >=20 > We have been using the following example for a few years > in the NETCONF WG: >=20 > > > eth0 > 1 > 1500 > > >=20 > Since ifIndex is part of the interface data, it is included within > the interface element. >=20 >=20 > > Lada > > > > =20 > Andy >=20 >=20 >=20 > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang >=20 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 18:00:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgkZ-0001eD-FM; Tue, 04 Dec 2007 18:00:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzgkY-0001Zs-5z for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 18:00:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgkX-0001YV-QZ for yang@ietf.org; Tue, 04 Dec 2007 18:00:21 -0500 Received: from exprod7og101.obsmtp.com ([64.18.2.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzgkX-0007ig-7k for yang@ietf.org; Tue, 04 Dec 2007 18:00:21 -0500 Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Dec 2007 15:00:12 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 14:59:19 -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 lB4MxIE52861; Tue, 4 Dec 2007 14:59:18 -0800 (PST) (envelope-from phil@idle.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 lB4Mu0WH088375; Tue, 4 Dec 2007 22:56:01 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712042256.lB4Mu0WH088375@idle.juniper.net> To: Ladislav Lhotka Subject: Re: [YANG] key ambiguity? In-reply-to: <1196806383.5759.22.camel@missotis> Date: Tue, 04 Dec 2007 17:56:00 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2007 22:59:19.0263 (UTC) FILETIME=[4D431EF0:01C836C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka writes: >Of course, this is the way to do it but you see - the key is deep here. The leaf which is the key must currently be an immediate child of the list. The "deep keys" feature adds the ability to use leafs as keys which are nested in containers under the list. et-0/0/0 1400 et-0/0/1 1500 et-0/0/2 1024 The YANG for this would be: container interfaces { list interface { key name; leaf name { type junos:interface-name; } leaf mtu { type mtu; } } } An example of deep keys would be:
10.1.2.3
22
10.1.2.4
22000 4321
10.1.2.4
22
10.1.2.5
22000 43210 The YANG looks like: container flow-table { grouping endpoint { leaf address { type inet:address; } leaf port { type inet:port; } } list flow { key "source/address source/port destination/address destination/port"; container source { use endpoint; } container destination { use endpoint; } leaf packet-count { type uint32; } } } Deep keys would require looking into the "source" and "destination" containers to see the keys. The feature pits the benefits of reusing grouping and having reasonable looking XML against the benefit of simple keys and not having to buffer the contents of any additional non-key nodes under containers that hold key. For example, if I put a new hierarchy of containers under "source" in addition to the keys that are currently there, the NETCONF implementation will have to buffer this content until it has all the keys available. We didn't like this cost, and didn't like the set of rules that would be required to avoid scenarios that trigger this buffering. But it's not an easy trade-off and will likely be revisited. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 21:01:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjZV-0003BW-1F; Tue, 04 Dec 2007 21:01:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzjZS-0003Ah-No for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 21:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjZS-00039w-Dm for yang@ietf.org; Tue, 04 Dec 2007 21:01:06 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzjZQ-0007Tq-RH for yang@ietf.org; Tue, 04 Dec 2007 21:01:06 -0500 Received: (qmail 11691 invoked from network); 5 Dec 2007 02:01:04 -0000 Received: from unknown (HELO dhcp-16b6.ietf70.org) (andybierman@att.net@130.129.22.182 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 5 Dec 2007 02:01:04 -0000 X-YMail-OSG: Qy2V5gkVM1nsmN3oOVNuhlTY1PYDIKsGfZrfSOiQFhe8CRO3TGqc6MjxcgwFZCC29_9WC1PjAgq69VlR3Ejoyc9y Message-ID: <47560607.4060701@andybierman.com> Date: Tue, 04 Dec 2007 17:59:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: "James Balestriere (jbalestr)" Subject: Re: [YANG] key ambiguity? References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis><4755A7EE.7060908@andybierman.com><1196804656.5759.16.camel@missotis> <4755CDEA.9010603@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org James Balestriere (jbalestr) wrote: > I am bit confused by this example > > > > eth0 > 1 > 1500 > > > > > what does eth0 mean ? does it count something different to the ifIndex ? > Also, if I have multiple cards with multiple ethernet ports would I have to > create another counter or something ? > No. You would name your interface Ethernet0/0, etc. The higher level issue here is whether NETCONF should follow the IF-MIB letter for letter when we create an interfaces table for configuration. Some people say "toss it all and start over". I don't know what approach is best. That would be for a WG to decide. I prefer to take advantage of the features of NETCONF and XML to the fullest extent possible, and not be that concerned with the read-only IF-MIB from SNMP. > James. > Andy > > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Wednesday, 5 December 2007 9:00 AM >> To: Ladislav Lhotka >> Cc: yang >> Subject: Re: [YANG] key ambiguity? >> >> Ladislav Lhotka wrote: >> >>> Andy Bierman pí¹e v Út 04. 12. 2007 v 11:18 -0800: >>> >>> >>> >>>> I do not agree that the leaf will be created if the identifier in >>>> the key does not exist. The compiler does not know the >>>> correct data type to use for the key. The identifier could >>>> be a typo, and a new leaf is not what the DM writer wanted >>>> at all. >>>> >>>> >>> Oh, I didn't mean that the key would be created >>> >> automatically but rather >> >>> by the model designer since the key is required for lists >>> >> representing >> >>> configuration. Without this requirement, many lists would >>> >> naturally have >> >>> only container items. >>> >>> >>> >>>> I want the ability to have deep keys. >>>> >>>> >>> It seems absolutely necessary - the only way I can see for creating >>> lists other than leaf-lists is like this: >>> >>> >>> 0 >>> ... >>> 1 >>> ... >>> ... >>> >>> >>> where the ifIndex element is the key for the following (sibling) >>> interface item, but this is ugly and error-prone. >>> >>> >> Why would you even model the interfaces table this way? >> >> We have been using the following example for a few years >> in the NETCONF WG: >> >> >> >> eth0 >> 1 >> 1500 >> >> >> >> Since ifIndex is part of the interface data, it is included within >> the interface element. >> >> >> >>> Lada >>> >>> >>> >> Andy >> >> >> >> _______________________________________________ >> YANG mailing list >> YANG@ietf.org >> https://www1.ietf.org/mailman/listinfo/yang >> >> > > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 04 22:08:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izkca-0008QG-M0; Tue, 04 Dec 2007 22:08:24 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Izkca-0008Q9-2r for yang-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 22:08:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkcZ-0008Q1-M8 for yang@ietf.org; Tue, 04 Dec 2007 22:08:23 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzkcY-00067i-Gd for yang@ietf.org; Tue, 04 Dec 2007 22:08:23 -0500 Received: from [192.168.20.198] (c-24-91-195-79.hsd1.ma.comcast.net [24.91.195.79]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id lB538DBJ003115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Dec 2007 21:08:13 -0600 In-Reply-To: <47560607.4060701@andybierman.com> References: <200712041823.lB4INGKO086396@idle.juniper.net> <1196794292.5745.58.camel@missotis><4755A7EE.7060908@andybierman.com><1196804656.5759.16.camel@missotis> <4755CDEA.9010603@andybierman.com> <47560607.4060701@andybierman.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Jon Saperia Subject: Re: [YANG] key ambiguity? Date: Tue, 4 Dec 2007 22:08:10 -0500 To: Andy Bierman X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1340645284==" Errors-To: yang-bounces@ietf.org --===============1340645284== Content-Type: multipart/alternative; boundary=Apple-Mail-65--526441794 --Apple-Mail-65--526441794 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed On Dec 4, 2007, at 8:59 PM, Andy Bierman wrote: > James Balestriere (jbalestr) wrote: >> I am bit confused by this example >> >> >> eth0 >> 1 >> 1500 >> >> >> >> >> what does eth0 mean ? does it count something different to the =20 >> ifIndex ? >> Also, if I have multiple cards with multiple ethernet ports would =20 >> I have to >> create another counter or something ? >> > > No. You would name your interface Ethernet0/0, etc. > > The higher level issue here is whether NETCONF should follow > the IF-MIB letter for letter when we create an interfaces > table for configuration. Some people say "toss it all > and start over". I don't know what approach is best. > That would be for a WG to decide. > > I prefer to take advantage of the features of NETCONF and XML > to the fullest extent possible, and not be that concerned with the =20 > read-only > IF-MIB from SNMP. > > To the extent we have two methods, SNMP and NETCONF, there must be a =20 way for management applications to correctly correlate information =20 from, to use your example of IF-MIB with interface configuration. It =20= gets even more interesting with DiffServ. So the issue for me is not =20= whether NETCONF should follow letter for letter, but how one would =20 effectively correlate the two universes. I would trade some XML =20 advantages for better applications. >> James. >> > > Andy > >> >> >>> -----Original Message----- >>> From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Wednesday, =20= >>> 5 December 2007 9:00 AM >>> To: Ladislav Lhotka >>> Cc: yang >>> Subject: Re: [YANG] key ambiguity? >>> >>> Ladislav Lhotka wrote: >>> >>>> Andy Bierman p=ED=9Ae v =DAt 04. 12. 2007 v 11:18 -0800: >>>> >>>> >>>>> I do not agree that the leaf will be created if the identifier in >>>>> the key does not exist. The compiler does not know the >>>>> correct data type to use for the key. The identifier could >>>>> be a typo, and a new leaf is not what the DM writer wanted >>>>> at all. >>>>> >>>> Oh, I didn't mean that the key would be created >>> automatically but rather >>> >>>> by the model designer since the key is required for lists >>> representing >>> >>>> configuration. Without this requirement, many lists would >>> naturally have >>> >>>> only container items. >>>> >>>>> I want the ability to have deep keys. >>>>> >>>> It seems absolutely necessary - the only way I can see for creating >>>> lists other than leaf-lists is like this: >>>> >>>> >>>> 0 >>>> ... >>>> 1 >>>> ... >>>> ... >>>> >>>> >>>> where the ifIndex element is the key for the following (sibling) >>>> interface item, but this is ugly and error-prone. >>>> >>> Why would you even model the interfaces table this way? >>> >>> We have been using the following example for a few years >>> in the NETCONF WG: >>> >>> >>> >>> eth0 >>> 1 >>> 1500 >>> >>> >>> >>> Since ifIndex is part of the interface data, it is included within >>> the interface element. >>> >>> >>> >>>> Lada >>>> >>>> >>> Andy >>> >>> >>> >>> _______________________________________________ >>> YANG mailing list >>> YANG@ietf.org >>> https://www1.ietf.org/mailman/listinfo/yang >>> >>> >> >> >> > > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > --Apple-Mail-65--526441794 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252

=

On Dec 4, 2007, at 8:59 PM, Andy Bierman = wrote:

James Balestriere (jbalestr) = wrote:
I am bit = confused by this example=A0
=A0=A0 = <interfaces>
=A0=A0 =A0 = <interface>
=A0 =A0 =A0 =A0 = <name>eth0</name>
=A0 =A0 =A0 =A0 = <ifIndex>1</ifIndex>
=A0 =A0 =A0 =A0 = <ifMtu>1500</ifMtu>
=A0 =A0 = </interface>
=A0 </interfaces>


what does = eth0 mean ? does it count something different to the ifIndex ?
Also, if I have multiple cards with multiple = ethernet ports would I have to
create = another counter <ifCard> or something ?

=A0=A0


No. You = would name your interface Ethernet0/0, etc.

The higher = level issue here is whether NETCONF should follow
the IF-MIB letter for letter when we create an = interfaces
table for configuration. =A0 Some people say "toss it = all
and start over".=A0 I don't know what approach is = best.
That would be for a WG to = decide.

I prefer to take advantage of the features of = NETCONF and XML
to the fullest extent possible, = and not be that concerned with the read-only
IF-MIB from SNMP.



To the extent we have two = methods, SNMP and NETCONF, there must be a way for management = applications to correctly correlate information from, to use your = example of IF-MIB with interface configuration. =A0It gets even more = interesting with DiffServ. =A0So the issue for me is not whether NETCONF = should follow letter for letter, but how one would effectively correlate = the two universes. =A0I would trade some XML advantages for better = applications.

James.

=A0=A0



=
=A0=A0

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] = Sent: Wednesday, 5 December 2007 9:00 AM
To: = Ladislav Lhotka
Cc: yang
Subject: Re: [YANG] key ambiguity?

Ladislav = Lhotka wrote:

=A0=A0 = =A0

Andy Bierman p=ED=9Ae v =DAt 04. = 12. 2007 v 11:18 -0800:

=A0=A0 =A0 =A0 = =A0

I do not agree that the leaf = will be created if the identifier in
the key does = not exist.=A0 The compiler = does not know the
correct data type to use for the = key.=A0 The identifier = could
be a typo, and a new leaf is not = what the DM writer wanted
at = all.

=A0=A0 =A0 =A0 =A0 =A0 = =A0

Oh, I didn't mean that the key would be created=A0 =A0 =A0 =A0
=
automatically but rather

=A0=A0 =A0

by the model designer since the key is required for = lists=A0 =A0 =A0 =A0
=
representing

=A0=A0 =A0

configuration. Without this requirement, many lists = would=A0 =A0 =A0 =A0
=
naturally have

=A0=A0 =A0

only container items.

=A0 =A0 =A0 =A0 =A0

I want the ability to have deep keys.

=A0=A0 =A0 =A0 =A0 =A0 =A0

It seems absolutely necessary - the only way I can = see for creating
lists other than leaf-lists is = like this:

<interfaceList>
=A0 = <ifIndex>0</ifIndex>
=A0 = <interface>...</interface>
=A0 = <ifIndex>1</ifIndex>
=A0 = <interface>...</interface>
=A0 = ...
</interfaceList>

where = the ifIndex element is the key for the following (sibling)
interface item, but this is ugly and = error-prone.

=A0=A0 =A0 =A0 = =A0

Why would you even model the interfaces table this = way?

We have been using the following example for a few = years
in the NETCONF WG:

=A0 <interfaces>
=A0 =A0 = <interface>
=A0=A0 =A0 =A0 = <name>eth0</name>
=A0=A0 =A0 =A0 = <ifIndex>1</ifIndex>
=A0=A0 =A0 =A0 = <ifMtu>1500</ifMtu>
=A0=A0 = </interface>
=A0</interfaces>

Since = ifIndex is part of the interface data, it is included within
the interface element.


=A0=A0 = =A0

Lada

=A0=A0 =A0 =A0 =A0

Andy



YANG mailing list

=A0=A0 = =A0



=A0=A0




YANG mailing list


= --Apple-Mail-65--526441794-- --===============1340645284== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============1340645284==-- From yang-bounces@ietf.org Wed Dec 05 01:58:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzoCr-0004Cv-Ph; Wed, 05 Dec 2007 01:58:05 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IzoCp-0004Ca-FE for yang-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 01:58:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzoCo-0004CR-LF for yang@ietf.org; Wed, 05 Dec 2007 01:58:02 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzoCm-0001RJ-BM for yang@ietf.org; Wed, 05 Dec 2007 01:58:02 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5627B864D4; Wed, 5 Dec 2007 07:57:59 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14762-04; Wed, 5 Dec 2007 07:57:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 697E286267; Wed, 5 Dec 2007 07:57:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 45B59409F07; Wed, 5 Dec 2007 07:57:54 +0100 (CET) Date: Wed, 5 Dec 2007 07:57:54 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] key ambiguity? Message-ID: <20071205065754.GA22197@elstar.local> Mail-Followup-To: Andy Bierman , "James Balestriere (jbalestr)" , yang References: <200712041823.lB4INGKO086396@idle.juniper.net> <4755CDEA.9010603@andybierman.com> <47560607.4060701@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47560607.4060701@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Tue, Dec 04, 2007 at 05:59:35PM -0800, Andy Bierman wrote: > The higher level issue here is whether NETCONF should follow > the IF-MIB letter for letter when we create an interfaces > table for configuration. Some people say "toss it all > and start over". I don't know what approach is best. > That would be for a WG to decide. > > I prefer to take advantage of the features of NETCONF and XML to the > fullest extent possible, and not be that concerned with the > read-only IF-MIB from SNMP. So far, one guiding principle in YANG has been "if in doubt, follow the CLI approach rather the SNMP approach". This is probably not written down anywhere in the ID but I strongly believe into it and think it should actually be written down as a guiding principle. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Dec 09 11:39:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1PBe-0006Ny-FG; Sun, 09 Dec 2007 11:39:26 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J1PBd-0006Nr-D9 for yang-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 11:39:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1PBX-0006Mr-78 for yang@ietf.org; Sun, 09 Dec 2007 11:39:19 -0500 Received: from smtp105.sbc.mail.mud.yahoo.com ([68.142.198.204]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1PBV-0002qp-B4 for yang@ietf.org; Sun, 09 Dec 2007 11:39:18 -0500 Received: (qmail 44466 invoked from network); 9 Dec 2007 16:39:10 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 9 Dec 2007 16:39:10 -0000 X-YMail-OSG: k3bQhGAVM1kkBRbzROx.dj1JddV8Jv1n2d3o2aSzDq1YeQQY Message-ID: <475C1AA7.1010009@andybierman.com> Date: Sun, 09 Dec 2007 08:41:11 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Andy Bierman , "James Balestriere (jbalestr)" , yang Subject: Re: [YANG] key ambiguity? References: <200712041823.lB4INGKO086396@idle.juniper.net> <4755CDEA.9010603@andybierman.com> <47560607.4060701@andybierman.com> <20071205065754.GA22197@elstar.local> In-Reply-To: <20071205065754.GA22197@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Dec 04, 2007 at 05:59:35PM -0800, Andy Bierman wrote: > >> The higher level issue here is whether NETCONF should follow >> the IF-MIB letter for letter when we create an interfaces >> table for configuration. Some people say "toss it all >> and start over". I don't know what approach is best. >> That would be for a WG to decide. >> >> I prefer to take advantage of the features of NETCONF and XML to the >> fullest extent possible, and not be that concerned with the >> read-only IF-MIB from SNMP. > > So far, one guiding principle in YANG has been "if in doubt, follow > the CLI approach rather the SNMP approach". This is probably not > written down anywhere in the ID but I strongly believe into it and > think it should actually be written down as a guiding principle. > I think there are more factors than CLI that are of concern to people interested in a standard data modeling language for NETCONF, as demonstrated in the BoFs and hallways of IETF 70. The guiding principle is more of "go with what works", and CLI is what currently works. But the IETF also cares about security, interoperability, usability, overlap with other standards, etc. There are many terms in YANG that may seem purposefully inconsistent. Some terminology is from SMIv2/sming, some from C, some from XSD, some new stuff, and lastly, some existing terms that have different meanings in other languages. That probably makes it partly familiar and partly confusing, to everybody. > /js > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Dec 10 11:29:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lVK-0004ND-3R; Mon, 10 Dec 2007 11:29:14 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J1lVJ-0004N7-4F for yang-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 11:29:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lVD-0004Lw-Au for yang@ietf.org; Mon, 10 Dec 2007 11:29:07 -0500 Received: from smtp114.sbc.mail.mud.yahoo.com ([68.142.198.213]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1lVC-0008Ls-Tv for yang@ietf.org; Mon, 10 Dec 2007 11:29:07 -0500 Received: (qmail 89256 invoked from network); 10 Dec 2007 16:29:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.122 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2007 16:29:05 -0000 X-YMail-OSG: zDuPZt4VM1loLw9uA.bKvxS.lNaqCI8ODRcw0wZfZ1FDGP1l Message-ID: <475D68D5.50400@andybierman.com> Date: Mon, 10 Dec 2007 08:27:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang , NETCONF Goes On Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [YANG] YANG augment-stmt X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Looking at the ABNF for the all-powerful augment statement, I notice it can appear inside a list or inside an another augment, anywhere a data-def-stmt can go in fact. Since this clause does not instantiate any data where it located, but rather at the target specified by the augment-arg-str, the containment for the augment seems pretty much irrelevant, except that the augment could be nested within N different 'when' statements, nested inside obsolete nodes, etc. The key in a list with an augment-stmt has no affect on the target data, does it? What does it mean to have an augment inside a grouping, so that it is copied everywhere a 'uses' for that grouping is specified? What is the use-case for augment inside augment? That means while you are defining extra data to attach to /acme:foo you also define some extra data for /a:bar/b:baz? I have only seen augment examples that appear at the top-level. Are there real examples of data models that actually need to nest the augment-stmt anywhere and everywhere in the data model, even inside the 'input' clause for an RPC method definition? What are the requirements for WG or vendor data model augmentation exactly? Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Dec 10 16:50:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qWO-0002W6-OA; Mon, 10 Dec 2007 16:50:40 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J1qWO-0002Vr-9j for yang-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 16:50:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qWN-0002Vi-W0; Mon, 10 Dec 2007 16:50:39 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1qWL-0005DK-LL; Mon, 10 Dec 2007 16:50:39 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id B20541B80C6; Mon, 10 Dec 2007 22:50:35 +0100 (CET) Date: Mon, 10 Dec 2007 22:46:47 +0100 (CET) Message-Id: <20071210.224647.240363363.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] YANG augment-stmt From: Martin Bjorklund In-Reply-To: <475D68D5.50400@andybierman.com> References: <475D68D5.50400@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: yang@ietf.org, ngo@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Hi, > > Looking at the ABNF for the all-powerful augment statement, > I notice it can appear inside a list or inside an another augment, > anywhere a data-def-stmt can go in fact. > > Since this clause does not instantiate any data where it > located, but rather at the target specified by the augment-arg-str, > the containment for the augment seems pretty much irrelevant, > except that the augment could be nested within N different 'when' > statements, nested inside obsolete nodes, etc. > > The key in a list with an augment-stmt has no affect on the target data, > does it? I'm not sure I understand this question. > What does it mean to have an augment inside a grouping, so that > it is copied everywhere a 'uses' for that grouping is specified? > > What is the use-case for augment inside augment? The use case for augment inside anything but on the top-level is to be used in combination with 'uses'. The idea is that you can do 'uses foo', and then in a following augment add new nodes to the foo grouping: grouping server { leaf name { type string; } container address { leaf ip { type inet:ip-address; } } } container foo { uses server; augment address { leaf port { type inet:port-number; } } } Or the same thing as a reusable grouping: grouping server-with-port { uses server; augment address { leaf port { type inet:port-number; } } } This way extensions to groupings ("complex types":) can be defined. > That means while you are defining extra data to attach to /acme:foo > you also define some extra data for /a:bar/b:baz? Yes. > I have only seen augment examples that appear at the top-level. > Are there real examples of data models that actually need to > nest the augment-stmt anywhere and everywhere in the data model, > even inside the 'input' clause for an RPC method definition? > > What are the requirements for WG or vendor data model augmentation exactly? I'm not sure I understand this question either. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Dec 10 16:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qaA-0002bo-Ds; Mon, 10 Dec 2007 16:54:34 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J1qa9-0002bP-6i for yang-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 16:54:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qa8-0002bG-T6; Mon, 10 Dec 2007 16:54:32 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1qa8-0005JU-KZ; Mon, 10 Dec 2007 16:54:32 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 0DDDB1B80C6; Mon, 10 Dec 2007 22:54:32 +0100 (CET) Date: Mon, 10 Dec 2007 22:50:44 +0100 (CET) Message-Id: <20071210.225044.45846508.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] YANG augment-stmt From: Martin Bjorklund In-Reply-To: <20071210.224647.240363363.mbj@tail-f.com> References: <475D68D5.50400@andybierman.com> <20071210.224647.240363363.mbj@tail-f.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: yang@ietf.org, ngo@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, I don't think there are any reasons to cross post this thread to yang and ngo, so I suggest we keep the specific yang discussion on the yang list only. From now on then :) /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 11 07:10:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23wq-0000yg-7Z; Tue, 11 Dec 2007 07:10:52 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J23wp-0000yR-El for yang-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 07:10:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23wj-0000y9-FH; Tue, 11 Dec 2007 07:10:45 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J23wi-0003vl-Oj; Tue, 11 Dec 2007 07:10:45 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 918C620E81; Tue, 11 Dec 2007 13:10:43 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-c0-475e7e432935 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 51D502073A; Tue, 11 Dec 2007 13:10:43 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 13:10:43 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 13:10:42 +0100 Message-ID: <475E90E6.4040601@ericsson.com> Date: Tue, 11 Dec 2007 14:30:14 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] YANG augment-stmt References: <475D68D5.50400@andybierman.com> <20071210.224647.240363363.mbj@tail-f.com> In-Reply-To: <20071210.224647.240363363.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 12:10:42.0828 (UTC) FILETIME=[DA26A4C0:01C83BEE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: yang@ietf.org, ngo@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello, Certainly some uses of augment could be really confusing, so if we could restrict it without ugly CLRs to the two use-cases it would be nice. Something like either use top level augment or an augment augmenting direct siblings like in Martin's example? Imagine an augment within an augment both with a dynamic when condition or an augment within a choice etc. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Looking at the ABNF for the all-powerful augment statement, >> I notice it can appear inside a list or inside an another augment, >> anywhere a data-def-stmt can go in fact. >> >> Since this clause does not instantiate any data where it >> located, but rather at the target specified by the augment-arg-str, >> the containment for the augment seems pretty much irrelevant, >> except that the augment could be nested within N different 'when' >> statements, nested inside obsolete nodes, etc. >> >> The key in a list with an augment-stmt has no affect on the target data, >> does it? > > I'm not sure I understand this question. > >> What does it mean to have an augment inside a grouping, so that >> it is copied everywhere a 'uses' for that grouping is specified? >> >> What is the use-case for augment inside augment? > > The use case for augment inside anything but on the top-level is to be > used in combination with 'uses'. The idea is that you can do 'uses > foo', and then in a following augment add new nodes to the foo > grouping: > > grouping server { > leaf name { type string; } > container address { > leaf ip { type inet:ip-address; } > } > } > > container foo { > uses server; > augment address { > leaf port { type inet:port-number; } > } > } > > Or the same thing as a reusable grouping: > > grouping server-with-port { > uses server; > augment address { > leaf port { type inet:port-number; } > } > } > > This way extensions to groupings ("complex types":) can be defined. > >> That means while you are defining extra data to attach to /acme:foo >> you also define some extra data for /a:bar/b:baz? > > Yes. > >> I have only seen augment examples that appear at the top-level. >> Are there real examples of data models that actually need to >> nest the augment-stmt anywhere and everywhere in the data model, >> even inside the 'input' clause for an RPC method definition? >> >> What are the requirements for WG or vendor data model augmentation exactly? > > I'm not sure I understand this question either. > > > /martin > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 11 12:11:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J28dU-0002ZW-NE; Tue, 11 Dec 2007 12:11:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J28dT-0002Yg-Lc for yang-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 12:11:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J28dT-0002YM-4c for yang@ietf.org; Tue, 11 Dec 2007 12:11:11 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J28dS-0002Xx-E1 for yang@ietf.org; Tue, 11 Dec 2007 12:11:11 -0500 Received: (qmail 16978 invoked from network); 11 Dec 2007 17:11:09 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.122 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 11 Dec 2007 17:11:09 -0000 X-YMail-OSG: h_mVAeYVM1mf.gcYWDpsb_WSEzmwuQFjkACLb5quY7tis_TN Message-ID: <475EC4EA.30200@andybierman.com> Date: Tue, 11 Dec 2007 09:12:10 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] YANG augment-stmt References: <475D68D5.50400@andybierman.com> <20071210.224647.240363363.mbj@tail-f.com> In-Reply-To: <20071210.224647.240363363.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: yang@ietf.org, ngo@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Looking at the ABNF for the all-powerful augment statement, >> I notice it can appear inside a list or inside an another augment, >> anywhere a data-def-stmt can go in fact. >> >> Since this clause does not instantiate any data where it >> located, but rather at the target specified by the augment-arg-str, >> the containment for the augment seems pretty much irrelevant, >> except that the augment could be nested within N different 'when' >> statements, nested inside obsolete nodes, etc. >> >> The key in a list with an augment-stmt has no affect on the target data, >> does it? > > I'm not sure I understand this question. > It seems strange to me to define an augment of 'some' other data in a potentially different namespace, in the middle of the constructs that define named list entries. I'm not clear on the use-case, which is why I cc:ed the NGO list. We need to agree on the requirements for data model augmentation, just like every other part of standard NETCONF content. >> What does it mean to have an augment inside a grouping, so that >> it is copied everywhere a 'uses' for that grouping is specified? >> >> What is the use-case for augment inside augment? > > The use case for augment inside anything but on the top-level is to be > used in combination with 'uses'. The idea is that you can do 'uses > foo', and then in a following augment add new nodes to the foo > grouping: > > grouping server { > leaf name { type string; } > container address { > leaf ip { type inet:ip-address; } > } > } > > container foo { > uses server; > augment address { > leaf port { type inet:port-number; } > } > } Is this right? Don't you mean: container foo { uses server { augment address { leaf port { type inet:port-number; } } } } I understand this use-case, where the descendant-schema-nodeid is the target, instead of an absolute-schema-nodeid. I still don't see any use-case for augment-within-augment, or allowing nested augments to modify data structures outside their parent node. > > Or the same thing as a reusable grouping: > > grouping server-with-port { > uses server; > augment address { > leaf port { type inet:port-number; } > } > } > > This way extensions to groupings ("complex types":) can be defined. > >> That means while you are defining extra data to attach to /acme:foo >> you also define some extra data for /a:bar/b:baz? > > Yes. Why is this a feature, and what is it needed for? > >> I have only seen augment examples that appear at the top-level. >> Are there real examples of data models that actually need to >> nest the augment-stmt anywhere and everywhere in the data model, >> even inside the 'input' clause for an RPC method definition? >> >> What are the requirements for WG or vendor data model augmentation exactly? > > I'm not sure I understand this question either. > We should base the solution (DML) on the agreed-upon requirements. The requirements should be based upon real use-cases. IMO, there is a need for top-level augment clauses that name the target with an absolute path expression, as well as nested augment clauses that extend the data within their containment node (container, list, choice/case-foo, rpc/input, rpc/output, notification). It is the DM writers choice which form to use. You should use descendant form if 'when' clauses exist in any ancestor nodes, instead of replicating the effective Xpath 'when' expression for a top-level clause. It boils down to 1 simple CLR: A top-level augment-stmt must use the absolute form, and a nested augment-stmt must use the descendant form of the schema-nodeid target of the augmentation. (A top-level augment-stmt has no context for descendants.) The ABNF does not reflect this, or that only a choice augment can use the case-stmt, or only an RPC augment can use the input-stmt | output-stmt. > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 11 15:16:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BWj-0006yD-CH; Tue, 11 Dec 2007 15:16:25 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2BWi-0006y6-IV for yang-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 15:16:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BWi-0006xx-8g for yang@ietf.org; Tue, 11 Dec 2007 15:16:24 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J2BWh-0000rv-RT for yang@ietf.org; Tue, 11 Dec 2007 15:16:24 -0500 Received: (qmail 69503 invoked from network); 11 Dec 2007 20:16:23 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.122 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 11 Dec 2007 20:16:22 -0000 X-YMail-OSG: sNM7GAMVM1nSyDH9b3zDFrADslkDEZA7SvNGqo2h7KkegivDmE3Mrj3Sb6pBPq6xuFhDvIx197NMlawJC2IUCFevWWSSjA2t2Kg- Message-ID: <475EF015.9010301@andybierman.com> Date: Tue, 11 Dec 2007 12:16:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [YANG] sec 7.14.2 -- augment's when statement X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, The YANG draft does not really specify much about the sparse-augments mechanism. IMO, it has the same problem as the partial-lock Xpath expression, wrt/ different result-sets depending on the moment the Xpath expression is evaluated. As stupid as this decl is, it is legal: augment "/interfaces/interface[name='Ethernet0/1']" { when "/interfaces/interface/ifInOctets div 7"; leaf inTemp1 { type int32; } leaf inTemp2 { type float64; } } 1) Xpath does not force the DM writer to keep one Xpath expression free of instance information, and another specific to some instances. The augment target and when clauses do not treat the interface object the same way. Both are legal Xpath, but only one makes sense wrt/ the conceptual data model. 2) The 'when' expression is allowed to be dynamic. This definition adds a couple counters to interface 'Ethernet0/1', which exist when ifInOctets is divisible by seven. The counters appear and disappear as the counter ticks. IMO, it is okay to limit partial-lock and when expressions, such that they support real use cases, and are implementable and inter-operable. Full Xpath 1.0 has many more absurd corner-cases than this one. Study the spec for awhile to see what I mean: http://www.w3.org/TR/xpath Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 11 15:30:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Bk2-0004hn-6m; Tue, 11 Dec 2007 15:30:10 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2Bk0-0004hW-Hs for yang-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 15:30:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Bk0-0004h3-7W; Tue, 11 Dec 2007 15:30:08 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Bjz-00018c-FP; Tue, 11 Dec 2007 15:30:08 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 6A12C1B80CC; Tue, 11 Dec 2007 21:30:06 +0100 (CET) Date: Tue, 11 Dec 2007 21:26:16 +0100 (CET) Message-Id: <20071211.212616.122580787.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] YANG augment-stmt From: Martin Bjorklund In-Reply-To: <475EC4EA.30200@andybierman.com> References: <475D68D5.50400@andybierman.com> <20071210.224647.240363363.mbj@tail-f.com> <475EC4EA.30200@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: yang@ietf.org, ngo@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> Looking at the ABNF for the all-powerful augment statement, > >> I notice it can appear inside a list or inside an another augment, > >> anywhere a data-def-stmt can go in fact. > >> > >> Since this clause does not instantiate any data where it > >> located, but rather at the target specified by the augment-arg-str, > >> the containment for the augment seems pretty much irrelevant, > >> except that the augment could be nested within N different 'when' > >> statements, nested inside obsolete nodes, etc. > >> > >> The key in a list with an augment-stmt has no affect on the target data, > >> does it? > > > > I'm not sure I understand this question. > > > > > It seems strange to me to define an augment of 'some' other data > in a potentially different namespace, in the middle of the constructs > that define named list entries. But this isn't allowed. Only top-level augments can have absolute paths to augment. "Nested" augments MUST have descendant paths. > I'm not clear on the use-case, > which is why I cc:ed the NGO list. We need to agree on the requirements > for data model augmentation, just like every other part of > standard NETCONF content. Ok. > >> What does it mean to have an augment inside a grouping, so that > >> it is copied everywhere a 'uses' for that grouping is specified? > >> > >> What is the use-case for augment inside augment? > > > > The use case for augment inside anything but on the top-level is to be > > used in combination with 'uses'. The idea is that you can do 'uses > > foo', and then in a following augment add new nodes to the foo > > grouping: > > > > grouping server { > > leaf name { type string; } > > container address { > > leaf ip { type inet:ip-address; } > > } > > } > > > > container foo { > > uses server; > > augment address { > > leaf port { type inet:port-number; } > > } > > } > > Is this right? Don't you mean: > > container foo { > uses server { > augment address { > leaf port { type inet:port-number; } > } > } > } No, augment within a uses is not allowed. I do see your point though - if the use case is to allow augment of a 'uses', why not put the augment within the uses. The problem with this, as I see it, is that it might be confusing b/c all the other stmts with 'uses' are refinements of stmts found in the grouping. > I understand this use-case, where the descendant-schema-nodeid > is the target, instead of an absolute-schema-nodeid. > > I still don't see any use-case for augment-within-augment, augment /foo/bar { uses my-grouping; // defines a container 'baz' augment baz { leaf xxx { ... } } } > or allowing nested augments to modify data structures outside > their parent node. No, that is not allowed. > >> That means while you are defining extra data to attach to /acme:foo > >> you also define some extra data for /a:bar/b:baz? > > > > Yes. > > Why is this a feature, and what is it needed for? Sorry. My "Yes" should have been "No!!". > We should base the solution (DML) on the agreed-upon requirements. > The requirements should be based upon real use-cases. Absolutely. > IMO, there is a need for top-level augment clauses that name the target > with an absolute path expression, as well as nested augment clauses > that extend the data within their containment node (container, list, > choice/case-foo, rpc/input, rpc/output, notification). It is > the DM writers choice which form to use. > > You should use descendant form if 'when' clauses exist in any > ancestor nodes, instead of replicating the effective Xpath 'when' > expression for a top-level clause. I don't see how this has anything to do with 'when'...? > It boils down to 1 simple CLR: > > A top-level augment-stmt must use the absolute form, > and a nested augment-stmt must use the descendant form > of the schema-nodeid target of the augmentation. > (A top-level augment-stmt has no context for descendants.) This is already in the draft. > The ABNF does not reflect this, or that only a choice augment > can use the case-stmt, or only an RPC augment can use the > input-stmt | output-stmt. Yes you're right, we should make this change in the ABNF. Currently it's just in the text. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 11 15:35:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BpW-0004gT-4W; Tue, 11 Dec 2007 15:35:50 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2BpU-0004ag-Js for yang-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 15:35:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BpU-0004YV-9I for yang@ietf.org; Tue, 11 Dec 2007 15:35:48 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2BpT-0001GI-Tl for yang@ietf.org; Tue, 11 Dec 2007 15:35:48 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 630181B80CC; Tue, 11 Dec 2007 21:35:47 +0100 (CET) Date: Tue, 11 Dec 2007 21:31:57 +0100 (CET) Message-Id: <20071211.213157.100961521.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] sec 7.14.2 -- augment's when statement From: Martin Bjorklund In-Reply-To: <475EF015.9010301@andybierman.com> References: <475EF015.9010301@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Hi, > > The YANG draft does not really specify much about the sparse-augments > mechanism. [...] > As stupid as this decl is, it is legal: > > augment "/interfaces/interface[name='Ethernet0/1']" { > > when "/interfaces/interface/ifInOctets div 7"; Yes you're right. We couldn't think of a (yet another) restricted form of XPath that we could use. If you (or anybody else) has a suggestion that defines the when expression "such that they support real use cases" please let us know! /matin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 11 15:38:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BsR-0005wA-H5; Tue, 11 Dec 2007 15:38:51 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2BsP-0005w4-Rh for yang-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 15:38:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BsP-0005vv-Ff for yang@ietf.org; Tue, 11 Dec 2007 15:38:49 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2BsN-0001JG-6c for yang@ietf.org; Tue, 11 Dec 2007 15:38:49 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Tue, 11 Dec 2007 12:38:38 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 12:37:06 -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 lBBKb6E78848; Tue, 11 Dec 2007 12:37:06 -0800 (PST) (envelope-from phil@idle.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 lBBKXfOK050461; Tue, 11 Dec 2007 20:33:41 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712112033.lBBKXfOK050461@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] sec 7.14.2 -- augment's when statement In-reply-to: <475EF015.9010301@andybierman.com> Date: Tue, 11 Dec 2007 15:33:41 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2007 20:37:06.0553 (UTC) FILETIME=[98432690:01C83C35] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >The YANG draft does not really specify much about the sparse-augments >mechanism. IMO, it has the same problem as the partial-lock Xpath >expression, wrt/ different result-sets depending on the moment >the Xpath expression is evaluated. The big difference is that the YANG XPath is known at build time, so I can construct my model appropriately. Also key is that the "when" is defined by the data model, and is not a random string pitched at the server by an application. >As stupid as this decl is, it is legal: >augment "/interfaces/interface[name='Ethernet0/1']" { The argument to augment can't have predicates. > when "/interfaces/interface/ifInOctets div 7"; If I made a model like this, I could write C code to do this test, avoiding turning statistics into XML for my XPath code. >1) Xpath does not force the DM writer to keep one Xpath expression > free of instance information, and another specific to some instances. > The augment target and when clauses do not treat the interface object > the same way. Both are legal Xpath, but only one makes sense > wrt/ the conceptual data model. I'm not sure I follow you, but both are conceptual. >2) The 'when' expression is allowed to be dynamic. Dynamic, but not fully random. The "when" clause is not when the data model is defined, and can be implemented within the server as needed. The XPath is a way of expressing the restriction, but the server is free to code it by hand based on the model _or_ by XPath expression evaluation. No one is required to implement a data model that has silly "when"s. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Dec 11 15:52:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2C5L-00046p-Jt; Tue, 11 Dec 2007 15:52:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2C5K-00046k-F7 for yang-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 15:52:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2C5K-00046c-5M for yang@ietf.org; Tue, 11 Dec 2007 15:52:10 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2C5H-0001cO-Rs for yang@ietf.org; Tue, 11 Dec 2007 15:52:10 -0500 Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Tue, 11 Dec 2007 12:52:03 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 12:47:13 -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 lBBKlCE82021; Tue, 11 Dec 2007 12:47:12 -0800 (PST) (envelope-from phil@idle.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 lBBKhkl4050653; Tue, 11 Dec 2007 20:43:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712112043.lBBKhkl4050653@idle.juniper.net> To: Martin Bjorklund Subject: Re: [YANG] sec 7.14.2 -- augment's when statement In-reply-to: <20071211.213157.100961521.mbj@tail-f.com> Date: Tue, 11 Dec 2007 15:43:45 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2007 20:47:13.0284 (UTC) FILETIME=[01E6F440:01C83C37] X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund writes: >We couldn't think of a (yet another) restricted form of XPath that we >could use. If you (or anybody else) has a suggestion that defines the >when expression > "such that they support real use cases" >please let us know! It's hard to put "Don't be stupid" in a spec. But anyone making useless YANG modules will quickly notice that no one implements them. The SMI spec doesn't say "don't put a zillion layers of '.1.1.1.1.1.1' in your MIBs" but folks seem to get it. We need to add suitable words about "implementation considerations" in the "when" section, but I think that will suffice. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Dec 12 07:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2QlS-0001iV-FO; Wed, 12 Dec 2007 07:32:38 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2QlR-0001iM-MO for yang-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 07:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2QlR-0001i7-6r for yang@ietf.org; Wed, 12 Dec 2007 07:32:37 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J2QlQ-0000J8-Na for yang@ietf.org; Wed, 12 Dec 2007 07:32:37 -0500 Received: (qmail 11462 invoked from network); 12 Dec 2007 12:32:36 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.122 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 12 Dec 2007 12:32:35 -0000 X-YMail-OSG: _CjxUUMVM1mCNSd2KOHaDxPLUGse8ploAsofCQAmfOG5Kpsm Message-ID: <475FD4CC.4080303@andybierman.com> Date: Wed, 12 Dec 2007 04:32:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] sec 7.14.2 -- augment's when statement References: <475EF015.9010301@andybierman.com> <20071211.213157.100961521.mbj@tail-f.com> In-Reply-To: <20071211.213157.100961521.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The YANG draft does not really specify much about the sparse-augments >> mechanism. > > [...] > >> As stupid as this decl is, it is legal: >> >> augment "/interfaces/interface[name='Ethernet0/1']" { >> >> when "/interfaces/interface/ifInOctets div 7"; > > Yes you're right. > > We couldn't think of a (yet another) restricted form of XPath that we > could use. If you (or anybody else) has a suggestion that defines the > when expression > > "such that they support real use cases" Let's start with the requirements. The syntax is okay -- I figured out where augments-in-augments could be used (descendant form inside an absolute form). No WG bothered to separate config data from 'other' data before. We could separate 'other' into more categories: 0 - config 1 - key (naming) component 2 - read-only static property (e.g, ifType) 3 - read-only dynamic property (e.g., ifOperStatus) 4 - read-only statistic (e.g., ifInOctets) 5 - read-write dynamic property (e.g., ifMtu) IMO, only (1) and (2) are OK for 'when' clauses, but who knows. > > please let us know! > > > /matin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Dec 12 20:28:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2csb-0004uz-Ai; Wed, 12 Dec 2007 20:28:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2csa-0004uu-Ai for yang-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 20:28:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2csZ-0004um-Gy for yang@ietf.org; Wed, 12 Dec 2007 20:28:47 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J2csX-000285-P6 for yang@ietf.org; Wed, 12 Dec 2007 20:28:47 -0500 Received: (qmail 20042 invoked from network); 13 Dec 2007 01:28:45 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.165.67 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 13 Dec 2007 01:28:44 -0000 X-YMail-OSG: K9hB.FEVM1kI8zEV1Kz9SiEETE5XVudD8bBbk7O3cY3tLJZk Message-ID: <47608ACB.6040609@andybierman.com> Date: Wed, 12 Dec 2007 17:28:43 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] YANG augment-stmt References: <475D68D5.50400@andybierman.com> <20071210.224647.240363363.mbj@tail-f.com> <475EC4EA.30200@andybierman.com> <20071211.212616.122580787.mbj@tail-f.com> In-Reply-To: <20071211.212616.122580787.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> Looking at the ABNF for the all-powerful augment statement, >>>> I notice it can appear inside a list or inside an another augment, >>>> anywhere a data-def-stmt can go in fact. >>>> >>>> Since this clause does not instantiate any data where it >>>> located, but rather at the target specified by the augment-arg-str, >>>> the containment for the augment seems pretty much irrelevant, >>>> except that the augment could be nested within N different 'when' >>>> statements, nested inside obsolete nodes, etc. >>>> >>>> The key in a list with an augment-stmt has no affect on the target data, >>>> does it? >>> I'm not sure I understand this question. >>> >> >> It seems strange to me to define an augment of 'some' other data >> in a potentially different namespace, in the middle of the constructs >> that define named list entries. > > But this isn't allowed. Only top-level augments can have absolute > paths to augment. "Nested" augments MUST have descendant paths. > >> I'm not clear on the use-case, >> which is why I cc:ed the NGO list. We need to agree on the requirements >> for data model augmentation, just like every other part of >> standard NETCONF content. > > Ok. > > >>>> What does it mean to have an augment inside a grouping, so that >>>> it is copied everywhere a 'uses' for that grouping is specified? >>>> >>>> What is the use-case for augment inside augment? >>> The use case for augment inside anything but on the top-level is to be >>> used in combination with 'uses'. The idea is that you can do 'uses >>> foo', and then in a following augment add new nodes to the foo >>> grouping: >>> >>> grouping server { >>> leaf name { type string; } >>> container address { >>> leaf ip { type inet:ip-address; } >>> } >>> } >>> >>> container foo { >>> uses server; >>> augment address { >>> leaf port { type inet:port-number; } >>> } >>> } >> Is this right? Don't you mean: >> >> container foo { >> uses server { >> augment address { >> leaf port { type inet:port-number; } >> } >> } >> } > > No, augment within a uses is not allowed. I do see your point though > - if the use case is to allow augment of a 'uses', why not put the > augment within the uses. The problem with this, as I see it, is that > it might be confusing b/c all the other stmts with 'uses' are > refinements of stmts found in the grouping. The keyword 'augment' clearly is different than the refinement statements. The current way forces the DM reader to expand the 'server' grouping into the 'foo' container first (in their mind), and then there is an 'address' container to augment. IMO, the nested augment is more intuitive. It goes in with the refinement statements. It tells the reader and compiler not to go looking through the sibling nodes for 'address'. None of these nodes have to be together, or in bottom-up order. In a big DM module, this becomes a problem. The 'uses' braces {} should be used to contain the search. All of the 'changes' for 'server' should be contained within these braces. To go one step further, the other form should be an error. The nested augment target should be within one of its sibling nodes, defined directly in the containment node, not within a 'uses' statement. > >> I understand this use-case, where the descendant-schema-nodeid >> is the target, instead of an absolute-schema-nodeid. >> >> I still don't see any use-case for augment-within-augment, > > augment /foo/bar { > uses my-grouping; // defines a container 'baz' > augment baz { > leaf xxx { ... } > } > } > >> or allowing nested augments to modify data structures outside >> their parent node. > > No, that is not allowed. good > >>>> That means while you are defining extra data to attach to /acme:foo >>>> you also define some extra data for /a:bar/b:baz? >>> Yes. >> Why is this a feature, and what is it needed for? > > Sorry. My "Yes" should have been "No!!". > > >> We should base the solution (DML) on the agreed-upon requirements. >> The requirements should be based upon real use-cases. > > Absolutely. The 2 separate forms fit the bill quite nicely. > >> IMO, there is a need for top-level augment clauses that name the target >> with an absolute path expression, as well as nested augment clauses >> that extend the data within their containment node (container, list, >> choice/case-foo, rpc/input, rpc/output, notification). It is >> the DM writers choice which form to use. >> >> You should use descendant form if 'when' clauses exist in any >> ancestor nodes, instead of replicating the effective Xpath 'when' >> expression for a top-level clause. > > I don't see how this has anything to do with 'when'...? not much -- just my preferred DM design approach (not another CLR) > >> It boils down to 1 simple CLR: >> >> A top-level augment-stmt must use the absolute form, >> and a nested augment-stmt must use the descendant form >> of the schema-nodeid target of the augmentation. >> (A top-level augment-stmt has no context for descendants.) > > This is already in the draft. > good >> The ABNF does not reflect this, or that only a choice augment >> can use the case-stmt, or only an RPC augment can use the >> input-stmt | output-stmt. > > Yes you're right, we should make this change in the ABNF. Currently > it's just in the text. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Dec 13 11:59:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rP0-0002Sb-E5; Thu, 13 Dec 2007 11:59:14 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2rOz-0002SW-Vt for yang-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 11:59:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rOz-0002SO-IG for yang@ietf.org; Thu, 13 Dec 2007 11:59:13 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2rOz-0001zE-5E for yang@ietf.org; Thu, 13 Dec 2007 11:59:13 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1CD49214C8; Thu, 13 Dec 2007 17:58:37 +0100 (CET) X-AuditID: c1b4fb3c-af796bb0000030cf-5c-476164bddbda Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0B5D1214B8; Thu, 13 Dec 2007 17:58:37 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 17:58:36 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 17:58:36 +0100 Message-ID: <476164BB.9060307@ericsson.com> Date: Thu, 13 Dec 2007 17:58:35 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Chris Newman , yang@ietf.org References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E8CE9.10900@ericsson.com> <5FFDE49BC50705874BA846E3@446E7922C82D299DB29D899F> In-Reply-To: <5FFDE49BC50705874BA846E3@446E7922C82D299DB29D899F> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 16:58:36.0278 (UTC) FILETIME=[66C17160:01C83DA9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [YANG] Re: analysis of YANG vs. RELAX NG X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello Chris, Yang-Gang, I think this is an interesting idea. It could also be used for things that are so tricky that only vendor support personnel should use it. I will add it to the draft if no objections. Balazs Chris Newman wrote: > [off list since this is off topic] > > Balazs Lengyel wrote on 11/29/07 10:56 +0100: >> - a flag stating if a part of configuration is current, deprecated, >> obsolete > > For the XML configuration software I'm working on for Sun's mail server > software, we have an additional state -- "restricted" that means roughly > "setting this option without permission of product support renders the > device into an unsupported operation mode". Useful for those kludges > demanded by one big customer, for features that are present in the code > but are alpha quality, or for standards-violating features that > customers sometimes demand. You might want to think about the cost of > including such a feature now vs. adding it later if it's needed. > > - Chris > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Dec 13 12:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rYt-0005T0-Nk; Thu, 13 Dec 2007 12:09:27 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J2rYr-0005RK-RU for yang-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 12:09:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rYr-0005OC-1Z for yang@ietf.org; Thu, 13 Dec 2007 12:09:25 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2rYo-0001js-Op for yang@ietf.org; Thu, 13 Dec 2007 12:09:24 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B55318A20D; Thu, 13 Dec 2007 18:09:21 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11013-06; Thu, 13 Dec 2007 18:09:17 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 213BA8A20B; Thu, 13 Dec 2007 18:09:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7E1A0425704; Thu, 13 Dec 2007 18:09:17 +0100 (CET) Date: Thu, 13 Dec 2007 18:09:17 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Subject: Re: [YANG] Re: analysis of YANG vs. RELAX NG Message-ID: <20071213170917.GC9183@elstar.local> Mail-Followup-To: Balazs Lengyel , Chris Newman , yang@ietf.org References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E8CE9.10900@ericsson.com> <5FFDE49BC50705874BA846E3@446E7922C82D299DB29D899F> <476164BB.9060307@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476164BB.9060307@ericsson.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: yang@ietf.org, Chris Newman X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Dec 13, 2007 at 05:58:35PM +0100, Balazs Lengyel wrote: > I think this is an interesting idea. It could also be used for > things that are so tricky that only vendor support personnel should > use it. I will add it to the draft if no objections. I am confused. Usually, "current", "deprecated", "obsolete" refers to the status of a definition and that is not the same and in fact different from "harmful" or "pointless". Even a "harmful" definition can be "current", "deprecated", or "obsolete". Something that should not be touched by average users simply should be properly protected by access control rules, no? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Dec 14 10:29:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CTO-0004rN-45; Fri, 14 Dec 2007 10:29:10 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J3CTN-0004rH-CO for yang-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 10:29:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CTH-0004ma-7H for yang@ietf.org; Fri, 14 Dec 2007 10:29:03 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3CTG-0000OT-DW for yang@ietf.org; Fri, 14 Dec 2007 10:29:02 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 39BBB213B3 for ; Fri, 14 Dec 2007 16:26:46 +0100 (CET) X-AuditID: c1b4fb3e-aee9fbb00000459d-ee-4762a0b659ce Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2C3A7213AC for ; Fri, 14 Dec 2007 16:26:46 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 16:26:45 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 16:26:45 +0100 Message-ID: <4762A0B5.9010708@ericsson.com> Date: Fri, 14 Dec 2007 16:26:45 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , yang@ietf.org Subject: Re: [YANG] Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E8CE9.10900@ericsson.com> <5FFDE49BC50705874BA846E3@446E7922C82D299DB29D899F> <476164BB.9060307@ericsson.com> <20071213170917.GC9183@elstar.local> In-Reply-To: <20071213170917.GC9183@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 15:26:45.0866 (UTC) FILETIME=[BCB50CA0:01C83E65] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello Jurgen, You are right the "restricted" marking is a separate issue from the status, but still a valid use case. Access control is usually set by the customer, so I don't think it is a good way to restrict the customer itself from using specific features. If we would be looking for a restriction like: "Only expert operators are allowed to use this" I would agree with your proposal to use normal access control. However we are looking more for a "No employee of the customer is allowed to used this" restriction. (Only for vendor support, or only for specific customers). I think hidden data plays a somewhat similar role in the Tailf implementation. regards Balazs PS: In Ericsson we love having "harmful" features. It is called job security for customer support :-) Juergen Schoenwaelder wrote: > On Thu, Dec 13, 2007 at 05:58:35PM +0100, Balazs Lengyel wrote: > >> I think this is an interesting idea. It could also be used for >> things that are so tricky that only vendor support personnel should >> use it. I will add it to the draft if no objections. > > I am confused. Usually, "current", "deprecated", "obsolete" refers to > the status of a definition and that is not the same and in fact > different from "harmful" or "pointless". Even a "harmful" definition > can be "current", "deprecated", or "obsolete". > > Something that should not be touched by average users simply should be > properly protected by access control rules, no? > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Dec 14 10:52:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Cq4-0007HX-LD; Fri, 14 Dec 2007 10:52:36 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J3Cq2-0007ET-Hk for yang-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 10:52:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Cq2-0007Bc-4w for yang@ietf.org; Fri, 14 Dec 2007 10:52:34 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J3Cpz-0000Lu-Kc for yang@ietf.org; Fri, 14 Dec 2007 10:52:34 -0500 Received: (qmail 20484 invoked from network); 14 Dec 2007 15:52:31 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.7 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 14 Dec 2007 15:52:30 -0000 X-YMail-OSG: ShN6IJgVM1nkXZhqigwUFkh6onwx26Qyy7z6za_ehsEB8Xb. Message-ID: <4762A6BD.7000604@andybierman.com> Date: Fri, 14 Dec 2007 07:52:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Balazs Lengyel Subject: Re: [YANG] Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E8CE9.10900@ericsson.com> <5FFDE49BC50705874BA846E3@446E7922C82D299DB29D899F> <476164BB.9060307@ericsson.com> <20071213170917.GC9183@elstar.local> <4762A0B5.9010708@ericsson.com> In-Reply-To: <4762A0B5.9010708@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel wrote: > Hello Jurgen, > You are right the "restricted" marking is a separate issue from the > status, but still a valid use case. > I think Juergen means you are mixing apples and oranges by putting 'restricted' in with current/deprecated/obsolete. This is yet another proprietary data model property, such as 'hidden', 'help', 'sort-order', etc. If a property is common enough, then it should be included in the standard, instead of a vendor extension. In this case, the 'restricted' status has no impact whatsoever on the NETCONF protocol. IMO, NETCONF does not need any extensions to warn customers that on specific data will void their warranty, because the data is restricted. I prefer a coherent, comprehensive, standard access control model instead. Andy > Access control is usually set by the customer, so I don't think it is a > good way to restrict the customer itself from using specific features. > If we would be looking for a restriction like: "Only expert operators > are allowed to use this" I would agree with your proposal to use normal > access control. > > However we are looking more for a "No employee of the customer is > allowed to used this" restriction. (Only for vendor support, or only for > specific customers). > > I think hidden data plays a somewhat similar role in the Tailf > implementation. > regards Balazs > > PS: In Ericsson we love having "harmful" features. It is called job > security for customer support :-) > > Juergen Schoenwaelder wrote: >> On Thu, Dec 13, 2007 at 05:58:35PM +0100, Balazs Lengyel wrote: >> >>> I think this is an interesting idea. It could also be used for >>> things that are so tricky that only vendor support personnel should >>> use it. I will add it to the draft if no objections. >> >> I am confused. Usually, "current", "deprecated", "obsolete" refers to >> the status of a definition and that is not the same and in fact >> different from "harmful" or "pointless". Even a "harmful" definition >> can be "current", "deprecated", or "obsolete". >> >> Something that should not be touched by average users simply should be >> properly protected by access control rules, no? >> >> /js >> > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Dec 20 14:11:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QnZ-0008DJ-MB; Thu, 20 Dec 2007 14:11:13 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J5QnY-00089g-Em for yang-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 14:11:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QnQ-0007nY-6U for yang@ietf.org; Thu, 20 Dec 2007 14:11:04 -0500 Received: from smtp108.sbc.mail.mud.yahoo.com ([68.142.198.207]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5QnP-0005NY-P4 for yang@ietf.org; Thu, 20 Dec 2007 14:11:04 -0500 Received: (qmail 30298 invoked from network); 20 Dec 2007 19:11:02 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.7 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 20 Dec 2007 19:11:02 -0000 X-YMail-OSG: guUUp70VM1mYVXDwE2SBGrPM00S9VBMDyw9VRX._kc9Bl5oc Message-ID: <476ABE43.9050909@andybierman.com> Date: Thu, 20 Dec 2007 11:10:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [YANG] uses statement X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Section 7.11 para 2 says: The effect of a "uses" reference to a grouping is the same as if the "uses" statement was replaced with the contents of the "grouping" statement's content and updated according to the refinement statements. Thus, the identifiers defined the grouping are copied into the current module, even if the grouping is imported from some other module. This is not entirely true. The grouping that is being used may be in another module. The grouping statement is validated and 'resolved' within the context of the grouping-stmt, not the uses-stmt. ----------------- Module x: import foo { prefix foo; } typedef KnobType { type enumeration { enum zero; enum one; enum seven { value 7; } } } grouping group1 { leaf a { type int32; } leaf b { type KnobType; } leaf c { type foo:KnobType; } } Module y: import x { prefix x; } import z { prefix z; } container con1 { uses x:group1; leaf d { type z:KnobType; } } ---------------- 1) Both module x and y are valid YANG module fragments 2) The 'KnobType' data type is evaluated in the context of module 'x' so leaf 'b' and 'c' in 'group1' are always bound to the same data type no matter where the uses-stmt is located. 3) Although 'group1' is valid in module 'x', it would not be valid in module 'y', because 'KnobType' is not locally defined and would need a prefix (x:KnobType). 4) Since the 'type' field is not allowed to be refined, this 'type source' ambiguity is not a problem. 5) leaf 'c' is correctly bound to type foo:KnobType, and causes an implicit import of module foo into module y. 6) I'm not sure what the replacement text should be, so I thought I would ask this list Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Dec 26 22:48:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7jjF-0007bS-PX; Wed, 26 Dec 2007 22:48:17 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J7jjF-0007bN-0B for yang-confirm+ok@megatron.ietf.org; Wed, 26 Dec 2007 22:48:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7jj7-0007b5-TE for yang@ietf.org; Wed, 26 Dec 2007 22:48:10 -0500 Received: from smtp115.sbc.mail.sp1.yahoo.com ([69.147.64.88]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7jj7-0006I1-GA for yang@ietf.org; Wed, 26 Dec 2007 22:48:09 -0500 Received: (qmail 58171 invoked from network); 27 Dec 2007 03:48:08 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 27 Dec 2007 03:48:08 -0000 X-YMail-OSG: 1TPIwtYVM1n8XhBw.uCOk0EYqO.gke5VaftT0MjtkRaWhLym Message-ID: <4773207A.7020004@andybierman.com> Date: Wed, 26 Dec 2007 19:48:10 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [YANG] legal uses-stmt? X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Is this legal? grouping A { leaf x { type string; } } container foo { uses A { leaf x { description "blah"; } leaf x { default "blah-blah"; } } } Or is each leaf from 'grouping A' allowed to be specified 0 or 1 time within the 'uses A' statement? The ABNF allows the above, and sec 7.11.2 doesn't say (although there is a CLR about the clauses being in the same order as in the grouping). Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Dec 27 02:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7nKH-00062m-8l; Thu, 27 Dec 2007 02:38:45 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J7nKF-00062c-KJ for yang-confirm+ok@megatron.ietf.org; Thu, 27 Dec 2007 02:38:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7nKF-000608-7D for yang@ietf.org; Thu, 27 Dec 2007 02:38:43 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7nKC-00025s-Rk for yang@ietf.org; Thu, 27 Dec 2007 02:38:43 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id EFD081B80C9; Thu, 27 Dec 2007 08:38:37 +0100 (CET) Date: Thu, 27 Dec 2007 08:38:36 +0100 (CET) Message-Id: <20071227.083836.15618460.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] legal uses-stmt? From: Martin Bjorklund In-Reply-To: <4773207A.7020004@andybierman.com> References: <4773207A.7020004@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Hi, > > Is this legal? > > grouping A { > leaf x { type string; } > } > > container foo { > uses A { > leaf x { description "blah"; } > leaf x { default "blah-blah"; } > } > } > > > Or is each leaf from 'grouping A' allowed to be specified 0 or 1 time > within the 'uses A' statement? Yes, that was the idea. > The ABNF allows the above, The ABNF cannot make these kind of restrictions, since the identifier is dynamic. > and sec 7.11.2 doesn't say (although there is a CLR about the > clauses being in the same order as in the grouping). I'll update 7.11.2 /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Dec 27 02:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7nMk-0008Rr-RR; Thu, 27 Dec 2007 02:41:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J7nMk-0008ON-17 for yang-confirm+ok@megatron.ietf.org; Thu, 27 Dec 2007 02:41:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7nMj-0008OF-NE for yang@ietf.org; Thu, 27 Dec 2007 02:41:17 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7nMj-00029c-Bc for yang@ietf.org; Thu, 27 Dec 2007 02:41:17 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 62F201B80C9; Thu, 27 Dec 2007 08:41:16 +0100 (CET) Date: Thu, 27 Dec 2007 08:41:15 +0100 (CET) Message-Id: <20071227.084115.189158560.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] uses statement From: Martin Bjorklund In-Reply-To: <476ABE43.9050909@andybierman.com> References: <476ABE43.9050909@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Hi, > > Section 7.11 para 2 says: > > The effect of a "uses" reference to a grouping is the same as if the > "uses" statement was replaced with the contents of the "grouping" > statement's content and updated according to the refinement > statements. Thus, the identifiers defined the grouping are copied > into the current module, even if the grouping is imported from some > other module. > > > This is not entirely true. > The grouping that is being used may be in another module. > The grouping statement is validated and 'resolved' within > the context of the grouping-stmt, not the uses-stmt. Yes, you are right. > 6) I'm not sure what the replacement text should be, so I thought I would > ask this list We'll have to figure this one out... /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Dec 27 12:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7wHT-0000wM-1K; Thu, 27 Dec 2007 12:12:27 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1J7wHR-0000rr-Du for yang-confirm+ok@megatron.ietf.org; Thu, 27 Dec 2007 12:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7wHR-0000ri-22 for yang@ietf.org; Thu, 27 Dec 2007 12:12:25 -0500 Received: from smtp113.sbc.mail.mud.yahoo.com ([68.142.198.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J7wHO-0004OF-NZ for yang@ietf.org; Thu, 27 Dec 2007 12:12:25 -0500 Received: (qmail 40032 invoked from network); 27 Dec 2007 17:12:22 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 27 Dec 2007 17:12:21 -0000 X-YMail-OSG: RTxIltwVM1kNy4awWF7ybery13yuqrEaPXSKE3fhMsdA42RO Message-ID: <4773DCFF.2080206@andybierman.com> Date: Thu, 27 Dec 2007 09:12:31 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] legal uses-stmt? References: <4773207A.7020004@andybierman.com> <20071227.083836.15618460.mbj@tail-f.com> In-Reply-To: <20071227.083836.15618460.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Is this legal? >> >> grouping A { >> leaf x { type string; } >> } >> >> container foo { >> uses A { >> leaf x { description "blah"; } >> leaf x { default "blah-blah"; } >> } >> } >> >> >> Or is each leaf from 'grouping A' allowed to be specified 0 or 1 time >> within the 'uses A' statement? > > Yes, that was the idea. good -- then it works the same as the rules for container or list > >> The ABNF allows the above, > > The ABNF cannot make these kind of restrictions, since the identifier > is dynamic. > >> and sec 7.11.2 doesn't say (although there is a CLR about the >> clauses being in the same order as in the grouping). > > I'll update 7.11.2 > What about removing the CLR about the clauses in the 'uses' must match the exact order of clauses in the grouping? One of the things that makes YANG user-friendly (and a pain to implement ;-) is that forward references are allowed, and most sub-statements can appear in any order. Statement order is only forced when it really matters, like imports before the body statements. > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang