From netmod-bounces@ietf.org Thu May 1 17:23:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587D73A69BB; Thu, 1 May 2008 17:23:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8123A6B54 for ; Thu, 1 May 2008 17:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRYWN1HfrTZl for ; Thu, 1 May 2008 17:23:15 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 3F9AE3A69BB for ; Thu, 1 May 2008 17:23:15 -0700 (PDT) Received: (qmail 17000 invoked from network); 2 May 2008 00:23:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 00:23:15 -0000 X-YMail-OSG: hOOxo2QVM1kaJmTRUkB5ADAkeTTIwWaTy8G8jvna258iQOGWb5fN9EPqHVSbLpZkWZ4zkaCyFeU5k4xqJDKHFFcUJBTcyP8KAbcuNXNJjnQJRKs42NeZEMKl98mi.YdmE8I- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481A5EF1.7070507@andybierman.com> Date: Thu, 01 May 2008 17:23:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: netmod@ietf.org Subject: [netmod] yang-00 draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I propose that Martin publish the yang-02 draft (+ bugfixes) as draft-ietf-netmod-yang-00.txt. Not to rush anyone, but the current svn snapshot has some bugfixes not yet published. In case people want to start reading about YANG right away (it could happen!), no need to report bugs already fixed. thanks, Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 1 20:01:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3457A3A69CA; Thu, 1 May 2008 20:01:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797033A6A90 for ; Thu, 1 May 2008 20:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmzy+GUh0imj for ; Thu, 1 May 2008 20:01:52 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 8EF6E3A69CA for ; Thu, 1 May 2008 20:01:52 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA09.westchester.pa.mail.comcast.net with comcast id LRuT1Z0040QuhwU5905000; Fri, 02 May 2008 02:59:37 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.westchester.pa.mail.comcast.net with comcast id LT1u1Z0014HwxpC3N00000; Fri, 02 May 2008 03:01:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=8_f6gXrVaFAdN-xq7doA:9 a=MmkChepeFmEK-c3lhgTO6-8Tiz4A:4 a=lZB815dzVvQA:10 a=gi0PWCVxevcA:10 From: "David Harrington" To: "'Andy Bierman'" , References: <481A5EF1.7070507@andybierman.com> Date: Thu, 1 May 2008 23:01:53 -0400 Message-ID: <005b01c8ac00$e061ea70$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <481A5EF1.7070507@andybierman.com> Thread-Index: Acir6sLcPx9Ek6FuQ5WW1guHFZ6h9gAFgu2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [netmod] yang-00 draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I have already asked Martin to do this. There is a holiday in Sweden, so it will take a few days. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, May 01, 2008 8:23 PM > To: netmod@ietf.org > Subject: [netmod] yang-00 draft > > Hi, > > I propose that Martin publish the yang-02 draft (+ bugfixes) > as draft-ietf-netmod-yang-00.txt. Not to rush anyone, > but the current svn snapshot has some bugfixes not yet published. > > In case people want to start reading about YANG right away > (it could happen!), no need to report bugs already fixed. > > > thanks, > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 1 20:05:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5D23A684A; Thu, 1 May 2008 20:05:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE133A6785 for ; Thu, 1 May 2008 20:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdXfwRcqbL+h for ; Thu, 1 May 2008 20:05:29 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 4E6513A684A for ; Thu, 1 May 2008 20:05:29 -0700 (PDT) Received: (qmail 92858 invoked from network); 2 May 2008 03:05:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 03:05:29 -0000 X-YMail-OSG: DPgI8n4VM1mLs4z_AiG4DF2gtXdQJgnxSf5Pbcum9RUf7EKlevyq05soe953ppL1zDg0UXgMTB_GIuXVe8B2c7GknBbjHcYiUhnS3aYX0DS9VuuLqs1EKVhpAy05.4td6uZYTS.X3zwL3uW6GyJQsRIT X-Yahoo-Newman-Property: ymail-3 Message-ID: <481A84F7.6060109@andybierman.com> Date: Thu, 01 May 2008 20:05:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: David Harrington References: <481A5EF1.7070507@andybierman.com> <005b01c8ac00$e061ea70$0600a8c0@china.huawei.com> In-Reply-To: <005b01c8ac00$e061ea70$0600a8c0@china.huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] yang-00 draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Harrington wrote: > I have already asked Martin to do this. > There is a holiday in Sweden, so it will take a few days. > great! > dbh thanks, Andy > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Thursday, May 01, 2008 8:23 PM >> To: netmod@ietf.org >> Subject: [netmod] yang-00 draft >> >> Hi, >> >> I propose that Martin publish the yang-02 draft (+ bugfixes) >> as draft-ietf-netmod-yang-00.txt. Not to rush anyone, >> but the current svn snapshot has some bugfixes not yet published. >> >> In case people want to start reading about YANG right away >> (it could happen!), no need to report bugs already fixed. >> >> >> thanks, >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 1 21:45:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3843A67D4; Thu, 1 May 2008 21:45:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631783A687E for ; Thu, 1 May 2008 21:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df6gqgsC+DRo for ; Thu, 1 May 2008 21:45:40 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 18D153A67D4 for ; Thu, 1 May 2008 21:45:39 -0700 (PDT) Received: (qmail 31341 invoked from network); 2 May 2008 04:45:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 04:45:40 -0000 X-YMail-OSG: gtmCvK4VM1lcnODAJ3ErUTHxc3HuawJHn6FLogF9eDV_9wm8tIkeP5ZgEuoJnahSCt7iU7VkdgCs0nclHPnwuIz0eZcGEgozbceLgnqEoGUMYJcIml.bgpw1OOrnhqeoDhA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481A9C71.40600@andybierman.com> Date: Thu, 01 May 2008 21:45:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: netmod@ietf.org Subject: [netmod] YANG conformance-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Here is a first stab at a conformance example, even simpler than SMIv2 (which some people may or may not like). - only accessible objects can be listed in the conformance section. (This includes nodes, rpcs, and notifications) - only nodes in the module namespace can be listed in the conformance section. - there is no conformance info for a typedef or a grouping or augment (that I am suggesting). Instead the expanded target nodes are specified in the module with the uses. - top-level augment from module A to a subtree in module B must be documented in the conformance section for module A -------------------------- Phil's example: module A { revision 2008-01-01 { ... } grouping one { leaf foo { ... } leaf goo { ... } } // no conformance section needed } // revision 2008-04-01 left out for brevity module A { revision 2008-05-01 { ... } grouping one { leaf foo { ... } leaf goo { ... } leaf super-cool { ... } leaf way-super-cool { ... } } capability way-super-cool-stuff { description "Implements the Acme way super-cool features, if supported."; } // no conformance section needed } module B { import A { prefix A; } container zed { uses A:one; } conformance 2008-01-01 { requires "/zed/foo"; requires "/zed/goo"; requires "/zed/way-super-cool" { description "acme super cool stuff capability needed"; when-capability "A:way-super-cool-stuff"; } } } module C { import A { prefix A; } import B { ... } // do not see how this import is used container yancy { uses A:one; } conformance 2008-04-01 { requires "/yancy/foo"; requires "/yancy/goo"; requires "/yancy/super-cool"; } } ------------------------------- In this example, module B wants the newest way-super-cool leaf but not the super-cool leaf (could be deprecated by the time the implementation for B is updated). Module C was updated when super-cool was released, and has not yet been updated to way-super-cool (may never be updated). There should be a 1:1 correspondence between conformance-stmt and revision-stmt. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 1 22:02:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5880C3A69B3; Thu, 1 May 2008 22:02:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D093A680D for ; Thu, 1 May 2008 22:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE-sa8uQlsjD for ; Thu, 1 May 2008 22:02:37 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 761403A6A96 for ; Thu, 1 May 2008 22:02:37 -0700 (PDT) Received: (qmail 66546 invoked from network); 2 May 2008 05:02:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 05:02:37 -0000 X-YMail-OSG: 8.cBt7UVM1kyGLrUCCtxERgxU6UOaumGdZeluK9CmtC4XusuG9ZiD37q4toqa1mYzxHpLE1Z67yZEy.H63rBoXOxr7p9gQW2Uq98VkyB6nObtLEcuUHEhoHC5BaMi6GEMDg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481AA06B.5060504@andybierman.com> Date: Thu, 01 May 2008 22:02:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: netmod@ietf.org Subject: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Here is a first stab at a conformance example, even simpler than SMIv2 (which some people may or may not like). - only accessible objects can be listed in the conformance section. (This includes nodes, rpcs, and notifications) - only nodes in the module namespace can be listed in the conformance section. - there is no conformance info for a typedef or a grouping or augment (that I am suggesting). Instead the expanded target nodes are specified in the module with the uses. - top-level augment from module A to a subtree in module B must be documented in the conformance section for module A -------------------------- Phil's example: module A { revision 2008-01-01 { ... } grouping one { leaf foo { ... } leaf goo { ... } } // no conformance section needed } // revision 2008-04-01 left out for brevity module A { revision 2008-05-01 { ... } grouping one { leaf foo { ... } leaf goo { ... } leaf super-cool { ... } leaf way-super-cool { ... } } capability way-super-cool-stuff { description "Implements the Acme way super-cool features, if supported."; } // no conformance section needed } module B { import A { prefix A; } revision 2008-01-01 { description "Initial version."; } container zed { uses A:one; } conformance 2008-01-01 { requires "/zed/foo"; requires "/zed/goo"; } } module B { import A { prefix A; } revision 2008-05-01 { description "Added way-super-cool leaf to container zed."; } revision 2008-01-01 { description "Initial version."; } container zed { uses A:one; } conformance 2008-05-01 { requires "/zed/foo"; requires "/zed/goo"; requires "/zed/way-super-cool" { description "acme super cool stuff capability needed"; when-capability "A:way-super-cool-stuff"; } } conformance 2008-01-01 { requires "/zed/foo"; requires "/zed/goo"; } } module C { import A { prefix A; } import B { ... } // do not see how this import is used revision 2008-04-01 { description "Initial version."; } container yancy { uses A:one; } conformance 2008-04-01 { requires "/yancy/foo"; requires "/yancy/goo"; requires "/yancy/super-cool"; } } ------------------------------- In this example, module B wants the newest way-super-cool leaf but not the super-cool leaf (could be deprecated by the time the implementation for B is updated). Module C was updated when super-cool was released, and has not yet been updated to way-super-cool (may never be updated). There should be a 1:1 correspondence between conformance-stmt and revision-stmt. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 1 22:35:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD63C3A6845; Thu, 1 May 2008 22:35:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755413A6845 for ; Thu, 1 May 2008 22:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyqjgGnprnPX for ; Thu, 1 May 2008 22:35:57 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id B35FB3A6ACB for ; Thu, 1 May 2008 22:35:57 -0700 (PDT) Received: (qmail 8634 invoked from network); 2 May 2008 05:36:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 May 2008 05:35:58 -0000 X-YMail-OSG: nPUrQEkVM1n3W4jpVfHH8bFh0AuB7DTkaG9LasCbcOWhBaOg5en7elj1SbLLLy4spHIU4Uy_b01G8vyuFW1m4tK85vQeh7KomGkrFk9SuyFxWltv.htNoEdwU4BVoXMLhQM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481AA83C.3050200@andybierman.com> Date: Thu, 01 May 2008 22:35:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: netmod@ietf.org Subject: [netmod] conformance-stmt (netconf RPC example) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, A little more detail: - multiple when-capability statements are ANDed together From netconf.yang: rpc commit { description "Only available if 'candidate' capability is supported. When a candidate configuration's content is complete, the configuration data can be committed, publishing the data set to the rest of the device and requesting the device to conform to the behavior described in the new configuration. To commit the candidate configuration as the device's new current configuration, use the operation. The 'commit' operation instructs the device to implement the configuration data contained in the candidate configuration. If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration MUST remain unchanged. If the device does succeed in committing, the running configuration MUST be updated with the contents of the candidate configuration. If the system does not have the :candidate capability, the 'commit' operation is not available."; reference "RFC 4741, section 8.3.4.1"; ncx:rpc-type "config"; input { leaf confirmed { description "Request a confirmed commit. Only available if 'confirmed-commit' capability is supported."; reference "RFC 4741, section 8.4.5.1"; type empty; } leaf confirm-timeout { description "Request a specific timeout period for a confirmed commit if 'confirmed-commit' capability supported."; reference "RFC 4741, section 8.4.5.1"; type ConfirmTimeoutType; } } } conformance "2006-12-01" { ... requires "/commit" { // special-case: RPC allowed without any parameters when-capability "nc:candidate"; } requires "/commit/input/confirmed" { when-capability "nc:candidate"; when-capability "nc:confirmed-commit"; } requires "/commit/input/confirm-timeout" { when-capability "nc:candidate"; when-capability "nc:confirmed-commit"; } } Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 05:05:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F883A693E; Fri, 2 May 2008 05:05:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B97B3A6DDD for ; Fri, 2 May 2008 05:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5B5iC0b6oGZr for ; Fri, 2 May 2008 05:05:42 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 64C0F28C428 for ; Fri, 2 May 2008 05:05:18 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Fri, 02 May 2008 05:05:02 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 05:05:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m42C5Cx63759; Fri, 2 May 2008 05:05:12 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m42C3WeF014985; Fri, 2 May 2008 12:03:33 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805021203.m42C3WeF014985@idle.juniper.net> To: Andy Bierman In-reply-to: <481AA06B.5060504@andybierman.com> Date: Fri, 02 May 2008 08:03:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 12:05:13.0695 (UTC) FILETIME=[C70B2EF0:01C8AC4C] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: > conformance 2008-05-01 { > requires "/zed/foo"; > requires "/zed/goo"; > requires "/zed/way-super-cool" { > description "acme super cool stuff capability needed"; > when-capability "A:way-super-cool-stuff"; > } > } Doesn't this turn into a requirement that each module explicitly list the contents it's importing from another module? It's worse than SNMP, since I have to list complete hierarchies of stuff I want to import; if /zed/foo is a deep hiearchy, do I need to list every container, list, and leaf that it contains? if /zed/goo is an enumeration, do I need to list all current values so when one is added, I'm fine? IMHO anything that requires me to repeat the contents of another module is a non-starter. If the other module is published, any reader (human, device, application) should be able to know the contents of it without me repeating it when I import it. Revision- specific imports are a much cleaner, simpler way to handle this. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 05:50:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46EC23A6B68; Fri, 2 May 2008 05:50:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7660728C151 for ; Fri, 2 May 2008 05:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvYsvpq-xrMp for ; Fri, 2 May 2008 05:50:40 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 747CD3A6AF8 for ; Fri, 2 May 2008 05:50:40 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA09.westchester.pa.mail.comcast.net with comcast id LblU1Z00A0vyq2s590C200; Fri, 02 May 2008 12:48:24 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id Lcqh1Z00N4HwxpC3R00000; Fri, 02 May 2008 12:50:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=48vgC7mUAAAA:8 a=MGNvcS3udLTSy3mt25QA:9 a=0GQmSgQ69iyh0Jbf1cF972Tf16kA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Phil Shafer'" , "'Andy Bierman'" References: <481AA06B.5060504@andybierman.com> <200805021203.m42C3WeF014985@idle.juniper.net> Date: Fri, 2 May 2008 08:50:41 -0400 Message-ID: <007501c8ac53$213eb580$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200805021203.m42C3WeF014985@idle.juniper.net> Thread-Index: AcisTOpkYBCQlZ8bRImOazhns4iWJQABT0rg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Phil, I think the conformance statement allows the importing module to specify that conformance to it requires version-specific conformance to its dependencies, and all you need to list in the importing module is the named conformance statement from the exporting module. For example. using the snippet below, the conformance statement in the importing module would need to specify conformance 2008-09-01 { requires module A conformance 2008-05-01 } It would not need to list the contents of the module A conformance. This seems similar to installing a Linux application that has dependencies on, say, libxml v1.2. You don't need to list all the variables and APIs supported by v1.2. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Friday, May 02, 2008 8:04 AM > To: Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG conformance-stmt (corrected) > > Andy Bierman writes: > > conformance 2008-05-01 { > > requires "/zed/foo"; > > requires "/zed/goo"; > > requires "/zed/way-super-cool" { > > description "acme super cool stuff capability needed"; > > when-capability "A:way-super-cool-stuff"; > > } > > } > > Doesn't this turn into a requirement that each module explicitly > list the contents it's importing from another module? It's worse > than SNMP, since I have to list complete hierarchies of stuff I > want to import; if /zed/foo is a deep hiearchy, do I need to list > every container, list, and leaf that it contains? if /zed/goo is > an enumeration, do I need to list all current values so when one > is added, I'm fine? > > IMHO anything that requires me to repeat the contents of another > module is a non-starter. If the other module is published, any > reader (human, device, application) should be able to know the > contents of it without me repeating it when I import it. Revision- > specific imports are a much cleaner, simpler way to handle this. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 07:07:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6527228C1D7; Fri, 2 May 2008 07:07:04 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B97228C1D7 for ; Fri, 2 May 2008 07:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpKU5SgCL6C4 for ; Fri, 2 May 2008 07:07:02 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 6F1CF28C234 for ; Fri, 2 May 2008 07:07:02 -0700 (PDT) Received: (qmail 73635 invoked from network); 2 May 2008 14:07:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 14:07:02 -0000 X-YMail-OSG: RcNF8V0VM1nhir7DTYveaeWZcSmeFQpjAtjA8RtJjXNLiFHbrgme4aNoeIWTtwEKsz6aQ7s6XbkhkTtXVLyS6lWu6QdV32NcsgLIm2G0LQrFlDpA.ojzRnODn1TybEOTYRQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B2004.6090000@andybierman.com> Date: Fri, 02 May 2008 07:07:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805021203.m42C3WeF014985@idle.juniper.net> In-Reply-To: <200805021203.m42C3WeF014985@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> conformance 2008-05-01 { >> requires "/zed/foo"; >> requires "/zed/goo"; >> requires "/zed/way-super-cool" { >> description "acme super cool stuff capability needed"; >> when-capability "A:way-super-cool-stuff"; >> } >> } > > Doesn't this turn into a requirement that each module explicitly > list the contents it's importing from another module? It's worse > than SNMP, since I have to list complete hierarchies of stuff I > want to import; if /zed/foo is a deep hiearchy, do I need to list > every container, list, and leaf that it contains? if /zed/goo is > an enumeration, do I need to list all current values so when one > is added, I'm fine? > > IMHO anything that requires me to repeat the contents of another > module is a non-starter. If the other module is published, any > reader (human, device, application) should be able to know the > contents of it without me repeating it when I import it. Revision- > specific imports are a much cleaner, simpler way to handle this. > You are not repeating the contents of another module. The uses-stmt causes a foreign grouping to be expanded in your namespace, so it is in the current module. IMO any solution that does not allow a module to import *exactly* what it needs from another module is a non-starter. Your proposal requires that everything in the imported module at the time of the specified version be imported, which may include stuff added in the interim that is not desired. An explicit list of nodes is not that painful, especially to the readers, who count the most. It is way easier to deal with than figuring out by hand which exact nodes are part of the module (after uses and augments are expanded, it may look very different). How do I know what was added in rev 1, rev 2, rev 15? I just keep 'diffing' files by hand to figure out which objects are actually exported in each version? Or rely on the revision-stmt description, which is not even required to be present, let alone be accurate. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 07:17:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E645C3A6862; Fri, 2 May 2008 07:17:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9089A3A6862 for ; Fri, 2 May 2008 07:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ffc-m+VJilEt for ; Fri, 2 May 2008 07:17:31 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 367EA3A6A84 for ; Fri, 2 May 2008 07:17:31 -0700 (PDT) Received: (qmail 49265 invoked from network); 2 May 2008 14:17:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 14:17:28 -0000 X-YMail-OSG: 0dDcCVAVM1lAc7r2oZdzoAckab7DTgWql2Kh3rNigcGjF5FvdnTpg16p5RZ7QP7NcKlvXQcveiFyF2SaKBrVKR40c78F6RqDtHgJ87LEqwxk6kMA8Nz5F91GS2fhAO.Ug2owtQDT6YzntMEA8a2zzNhj X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B2275.6080401@andybierman.com> Date: Fri, 02 May 2008 07:17:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David Harrington References: <481AA06B.5060504@andybierman.com> <200805021203.m42C3WeF014985@idle.juniper.net> <007501c8ac53$213eb580$0600a8c0@china.huawei.com> In-Reply-To: <007501c8ac53$213eb580$0600a8c0@china.huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Harrington wrote: > Hi Phil, > > I think the conformance statement allows the importing module to > specify that conformance to it requires version-specific conformance > to its dependencies, and all you need to list in the importing module > is the named conformance statement from the exporting module. > > For example. using the snippet below, the conformance statement in the > importing module would need to specify > conformance 2008-09-01 { > requires module A conformance 2008-05-01 > } > > It would not need to list the contents of the module A conformance. > What if this module needed only some of the objects added to the 2008-05-01 version of module A? What if module A has 2 sets of 'features' (e.g, IPv4 or IPv6 version)? Are SMIv2-like GROUPs needed instead? conformance 2008-09-01 { requires "module A conformance 2008-05-01 group IPv6-objects"; } (A more condensed syntax might be better.) > This seems similar to installing a Linux application that has > dependencies on, say, libxml v1.2. You don't need to list all the > variables and APIs supported by v1.2. > > dbh Andy > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Phil Shafer >> Sent: Friday, May 02, 2008 8:04 AM >> To: Andy Bierman >> Cc: netmod@ietf.org >> Subject: Re: [netmod] YANG conformance-stmt (corrected) >> >> Andy Bierman writes: >>> conformance 2008-05-01 { >>> requires "/zed/foo"; >>> requires "/zed/goo"; >>> requires "/zed/way-super-cool" { >>> description "acme super cool stuff capability needed"; >>> when-capability "A:way-super-cool-stuff"; >>> } >>> } >> Doesn't this turn into a requirement that each module explicitly >> list the contents it's importing from another module? It's worse >> than SNMP, since I have to list complete hierarchies of stuff I >> want to import; if /zed/foo is a deep hiearchy, do I need to list >> every container, list, and leaf that it contains? if /zed/goo is >> an enumeration, do I need to list all current values so when one >> is added, I'm fine? >> >> IMHO anything that requires me to repeat the contents of another >> module is a non-starter. If the other module is published, any >> reader (human, device, application) should be able to know the >> contents of it without me repeating it when I import it. Revision- >> specific imports are a much cleaner, simpler way to handle this. >> >> Thanks, >> Phil >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 07:50:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173913A6862; Fri, 2 May 2008 07:50:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3517B28C22F for ; Fri, 2 May 2008 07:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlKIh2BypuuO for ; Fri, 2 May 2008 07:50:36 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 48F9428C435 for ; Fri, 2 May 2008 07:50:20 -0700 (PDT) Received: (qmail 54687 invoked from network); 2 May 2008 14:50:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 14:50:20 -0000 X-YMail-OSG: OgHrYnEVM1lY43BZpLIJB0QSj2apRRyQm_K8QFIgLTPVKcbiRu4Pm0iZOIVb5fMKm7qUSLfpenz3Hx5pIn106m_B4yn.JRDsOWyHYOVc.mAD7Mo5sGDBYk.by4FagWgpM4c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B2A2A.40306@andybierman.com> Date: Fri, 02 May 2008 07:50:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805021203.m42C3WeF014985@idle.juniper.net> In-Reply-To: <200805021203.m42C3WeF014985@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> conformance 2008-05-01 { >> requires "/zed/foo"; >> requires "/zed/goo"; >> requires "/zed/way-super-cool" { >> description "acme super cool stuff capability needed"; >> when-capability "A:way-super-cool-stuff"; >> } >> } > > Doesn't this turn into a requirement that each module explicitly > list the contents it's importing from another module? It's worse > than SNMP, since I have to list complete hierarchies of stuff I > want to import; if /zed/foo is a deep hiearchy, do I need to list > every container, list, and leaf that it contains? if /zed/goo is > an enumeration, do I need to list all current values so when one > is added, I'm fine? > > IMHO anything that requires me to repeat the contents of another > module is a non-starter. If the other module is published, any > reader (human, device, application) should be able to know the > contents of it without me repeating it when I import it. Revision- > specific imports are a much cleaner, simpler way to handle this. > Perhaps we need a precise and agreed-upon definition of a grouping. Does the module with the grouping or the module with the uses decide the conformance requirements? Don't the refinement statements in the uses module have the potential of changing the conformance, as well as the semantics of a node? How does a compiler know what was in version N of a module, if all it has is the latest version? Will all implementations need to maintain all versions of all modules somehow, and be forced to support multiple versions of a module at runtime? > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 07:57:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298FF3A6B71; Fri, 2 May 2008 07:57:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50EEE3A6B71 for ; Fri, 2 May 2008 07:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpAxccysm8vM for ; Fri, 2 May 2008 07:57:17 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id E4E1B3A6A4A for ; Fri, 2 May 2008 07:57:13 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Fri, 02 May 2008 07:57:06 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 07:48:35 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m42EmZx13368; Fri, 2 May 2008 07:48:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m42Ektxj016473; Fri, 2 May 2008 14:46:55 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805021446.m42Ektxj016473@idle.juniper.net> To: "David Harrington" In-reply-to: <007501c8ac53$213eb580$0600a8c0@china.huawei.com> Date: Fri, 02 May 2008 10:46:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 14:48:35.0726 (UTC) FILETIME=[99826AE0:01C8AC63] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "David Harrington" writes: >I think the conformance statement allows the importing module to >specify that conformance to it requires version-specific conformance >to its dependencies, and all you need to list in the importing module >is the named conformance statement from the exporting module. This sounds different than Andy's example, which listed required paths from module A in module B. >For example. using the snippet below, the conformance statement in the >importing module would need to specify >conformance 2008-09-01 { > requires module A conformance 2008-05-01 >} This approach seems similar to listing revisions in import statements. When I say: import A { revision 2008-05-01; } I'm saying that I want the contents of that specific revision of module A. Modules are monolithic constructs (in that we don't have a way of saying "I only implement x, y, and z from module A" (which I think is goodness)), so by saying I want that revision of module A, everyone is completely clear on what functionality I'm talking about. I guess there are two halves to the problem. First is defining the content which we are talking about (which revision-specific imports solves), and second is defining for any specific device/implementation, what portion of that content the device implements. If we allow SNMP-style implementation conformance statements, applications must perform the "well it implements x but not y so how do I tell it to do what I need it to do" logic. I'm happy to just say that modules are monoliths; implement it all. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 08:00:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7DC628C267; Fri, 2 May 2008 08:00:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D655428C240 for ; Fri, 2 May 2008 08:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJeb+5tjGW1M for ; Fri, 2 May 2008 08:00:39 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 228D828C435 for ; Fri, 2 May 2008 08:00:27 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Fri, 02 May 2008 08:00:26 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 08:00:06 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m42F05x16434; Fri, 2 May 2008 08:00:05 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m42EwP0g016569; Fri, 2 May 2008 14:58:25 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805021458.m42EwP0g016569@idle.juniper.net> To: Andy Bierman In-reply-to: <481B2A2A.40306@andybierman.com> Date: Fri, 02 May 2008 10:58:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 15:00:06.0007 (UTC) FILETIME=[34F2F070:01C8AC65] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >How does a compiler know what was in version N of a module, >if all it has is the latest version? Will all implementations >need to maintain all versions of all modules somehow, and >be forced to support multiple versions of a module at runtime? Your toolset need only know the contents of revisions of modules that are imported by other modules. If B imports 2008-01-01 of module A and C imports 2008-04-01 of module A, your toolset would need access to those two specific revisions of module A. Other revisions would not be needed. This information would be needed at build time, not runtime. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 08:07:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4D53A6DDD; Fri, 2 May 2008 08:07:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261333A6DD3 for ; Fri, 2 May 2008 08:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr2H1IYeB-Ac for ; Fri, 2 May 2008 08:07:18 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 3A73A3A6D4B for ; Fri, 2 May 2008 08:07:18 -0700 (PDT) Received: (qmail 81442 invoked from network); 2 May 2008 15:07:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 15:07:14 -0000 X-YMail-OSG: Vjc._KkVM1njkVY2mBHvjilWvwxsQymWu_t8R3uGjb80uczub3Bgzb_tHfmGFrCzMyNReaMa6ln7ASONZ9bhOm3yoxURYjrzI5VHHnCldNl1nrO93SFivWAVS52e37uyozI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B2E20.4070005@andybierman.com> Date: Fri, 02 May 2008 08:07:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805021446.m42Ektxj016473@idle.juniper.net> In-Reply-To: <200805021446.m42Ektxj016473@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: ... > do what I need it to do" logic. I'm happy to just say that modules > are monoliths; implement it all. > This has never been good enough for SNMP, and hasn't even been used in NETCONF. We have capabilities, which partition the functionality, sometimes down to separate parameters in an RPC operation, or even separate enum values within a single RPC paramater (e.g., rollback-on-error). I would be happy with an architecture where the entire module is the contract, except when conceptually partitioned with capabilities. Then a manager would use the module definition and the reply to figure out exactly what an agent had. This would align precisely with conformance definitions, given in terms of [module-name, capability-URI] pairs, without using any version date at all. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 08:10:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548AE3A6838; Fri, 2 May 2008 08:10:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78EA3A6B8F for ; Fri, 2 May 2008 08:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czCGL9A13U81 for ; Fri, 2 May 2008 08:10:32 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 21AF33A6838 for ; Fri, 2 May 2008 08:10:32 -0700 (PDT) Received: (qmail 33640 invoked from network); 2 May 2008 15:10:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 2 May 2008 15:10:32 -0000 X-YMail-OSG: EhcIu60VM1lppxnZL0lgdZqKlGzkZDgKLyAFdx.UArAr2a835iEuZu.QKVZfiprdiwLumgCAlrz_cSQm7Xg_wIChcWJvlbmwQwHkIr8rPH8v6fpUITtJfGC1i17q6G2kNhg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B2EE7.5040209@andybierman.com> Date: Fri, 02 May 2008 08:10:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805021458.m42EwP0g016569@idle.juniper.net> In-Reply-To: <200805021458.m42EwP0g016569@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> How does a compiler know what was in version N of a module, >> if all it has is the latest version? Will all implementations >> need to maintain all versions of all modules somehow, and >> be forced to support multiple versions of a module at runtime? > > Your toolset need only know the contents of revisions of modules > that are imported by other modules. If B imports 2008-01-01 of > module A and C imports 2008-04-01 of module A, your toolset would > need access to those two specific revisions of module A. Other > revisions would not be needed. > So, all implementers and even module readers need to maintain every version of every module ever used in the system. This is not a feature. > This information would be needed at build time, not runtime. OK - static at build-time, used at runtime. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 08:11:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077743A6AA1; Fri, 2 May 2008 08:11:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDFE28C12D for ; Fri, 2 May 2008 08:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBKcLId-H7sv for ; Fri, 2 May 2008 08:11:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E14853A6AA1 for ; Fri, 2 May 2008 08:11:55 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB988C001C; Fri, 2 May 2008 17:12:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WwBG1TK4yKrH; Fri, 2 May 2008 17:11:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB255C000C; Fri, 2 May 2008 17:11:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9E345550B75; Fri, 2 May 2008 17:11:45 +0200 (CEST) Date: Fri, 2 May 2008 17:11:45 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080502151145.GG836@elstar.local> Mail-Followup-To: Phil Shafer , David Harrington , netmod@ietf.org References: <007501c8ac53$213eb580$0600a8c0@china.huawei.com> <200805021446.m42Ektxj016473@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200805021446.m42Ektxj016473@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, May 02, 2008 at 10:46:55AM -0400, Phil Shafer wrote: > I'm saying that I want the contents of that specific revision of > module A. Modules are monolithic constructs (in that we don't have > a way of saying "I only implement x, y, and z from module A" (which > I think is goodness)), so by saying I want that revision of module > A, everyone is completely clear on what functionality I'm talking > about. In SMIv2 land, we do have reusable constructs that are often reduced when they are used. A good example is the InetAddress version of a union. And historically, we have produced several MIB modules where you might implement only certain subsets. I am not sure it would have been easy to break down all these MIBs in smaller functional units. Perhaps with YANG's augments this is easier to do but we clearly lack experience with that approach. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 08:27:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213543A6C3B; Fri, 2 May 2008 08:27:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A733A6C3B for ; Fri, 2 May 2008 08:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SBa9kDGtWiq for ; Fri, 2 May 2008 08:27:10 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 0367C3A699E for ; Fri, 2 May 2008 08:27:06 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 02 May 2008 08:27:06 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 08:19:40 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m42FJdx22594; Fri, 2 May 2008 08:19:39 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m42FHxAV016834; Fri, 2 May 2008 15:17:59 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805021517.m42FHxAV016834@idle.juniper.net> To: Andy Bierman In-reply-to: <481B2E20.4070005@andybierman.com> Date: Fri, 02 May 2008 11:17:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 15:19:40.0096 (UTC) FILETIME=[F0C2B400:01C8AC67] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >This has never been good enough for SNMP, >and hasn't even been used in NETCONF. We have capabilities, >which partition the functionality, sometimes down to separate >parameters in an RPC operation, or even separate enum values >within a single RPC paramater (e.g., rollback-on-error). With the current draft of YANG, the mapping between capabilities and modules is 1:1. We've deferred multiple capabilities to later work. >I would be happy with an architecture where the entire module >is the contract, except when conceptually partitioned with >capabilities. Then a manager would use the module definition >and the reply to figure out exactly what an agent had. >This would align precisely with conformance definitions, >given in terms of [module-name, capability-URI] pairs, >without using any version date at all. That's what we've got now, so we can both be happy, eh? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 08:27:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4865F3A6AA1; Fri, 2 May 2008 08:27:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6E43A6C3B for ; Fri, 2 May 2008 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGiyWMQmwXZ4 for ; Fri, 2 May 2008 08:27:23 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 325533A699E for ; Fri, 2 May 2008 08:27:20 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Fri, 02 May 2008 08:27:06 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 08:25:08 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m42FP7x24227; Fri, 2 May 2008 08:25:07 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m42FNRZd016901; Fri, 2 May 2008 15:23:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805021523.m42FNRZd016901@idle.juniper.net> To: Andy Bierman In-reply-to: <481B2004.6090000@andybierman.com> Date: Fri, 02 May 2008 11:23:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 15:25:08.0328 (UTC) FILETIME=[B466EE80:01C8AC68] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >An explicit list of nodes is not that painful, especially to >the readers, who count the most. Try this for a large, deep grouping. It's quite painful and completely uninteresting to the reader, who isn't seeing enough of the grouping to be useful and must go view the definition anyway. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 08:30:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF09F3A693D; Fri, 2 May 2008 08:30:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6242E3A6A28 for ; Fri, 2 May 2008 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLqOgjQpnTAO for ; Fri, 2 May 2008 08:30:31 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 4B0813A6C2D for ; Fri, 2 May 2008 08:27:06 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Fri, 02 May 2008 08:27:06 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 08:21:58 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m42FLvx23167; Fri, 2 May 2008 08:21:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m42FKHdh016860; Fri, 2 May 2008 15:20:18 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805021520.m42FKHdh016860@idle.juniper.net> To: Andy Bierman In-reply-to: <481B2EE7.5040209@andybierman.com> Date: Fri, 02 May 2008 11:20:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 15:21:58.0407 (UTC) FILETIME=[43334970:01C8AC68] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >So, all implementers and even module readers need to maintain >every version of every module ever used in the system. Nope, you only need the ones you import. If your new module imports an obscure old revision of another module, your readers will happily complain that they can't find it and that you should be using something more modern. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 08:49:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A5B3A6BD2; Fri, 2 May 2008 08:49:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036373A6A84 for ; Fri, 2 May 2008 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiyVyPA-JpmU for ; Fri, 2 May 2008 08:49:29 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id EE8CA28C23E for ; Fri, 2 May 2008 08:49:16 -0700 (PDT) Received: (qmail 94940 invoked from network); 2 May 2008 15:49:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 15:49:16 -0000 X-YMail-OSG: qHSCdAAVM1npM8VTj5w0KsO15fNX8zIzJSC_ot2IWKE7_QxY0w.3mDDhHOJJTz._3jjIFr87BsVyp8sTwpxxjUvMlRZoPjT.S8zgZmgBTcNPeS1znL4ciMODwWpGAiWWjJM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B37F9.7010003@andybierman.com> Date: Fri, 02 May 2008 08:49:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805021517.m42FHxAV016834@idle.juniper.net> In-Reply-To: <200805021517.m42FHxAV016834@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> This has never been good enough for SNMP, >> and hasn't even been used in NETCONF. We have capabilities, >> which partition the functionality, sometimes down to separate >> parameters in an RPC operation, or even separate enum values >> within a single RPC paramater (e.g., rollback-on-error). > > With the current draft of YANG, the mapping between capabilities > and modules is 1:1. We've deferred multiple capabilities to > later work. > >> I would be happy with an architecture where the entire module >> is the contract, except when conceptually partitioned with >> capabilities. Then a manager would use the module definition >> and the reply to figure out exactly what an agent had. >> This would align precisely with conformance definitions, >> given in terms of [module-name, capability-URI] pairs, >> without using any version date at all. > > That's what we've got now, so we can both be happy, eh? > We need the when-capability statement somewhere. BTW, this approach is how we extended the protocol with notifications. We actually used a new namespace, but partitioned it with capabilities. IMO, this isn't that different than just adding a new capability to an existing namespace. But it is not really good enough, because it could lead to an explosion of capabilities, which would be just as hard to manage as lots of module versions. Also, the module with the objects needs to define the 'when-capability' partitioning (in the affected objects), not the module importing the objects. This is backwards. (Using when-capability in the conformance section of the new module fixes that.) Another problem with the "import FOO-MIB, exact version X" approach is that every time I update FOO-MIB, such as fixing a typo or a bug in some construct, I have to update and release (perhaps) every version of FOO-MIB ever written. I would like the import-by-revision feature a lot better if the latest version of each module is all that is ever needed to implement it. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 11:05:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D27F3A6E2D; Fri, 2 May 2008 11:05:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFBA3A6E2D for ; Fri, 2 May 2008 11:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDshilEc6FHB for ; Fri, 2 May 2008 11:05:02 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id E976A3A6E56 for ; Fri, 2 May 2008 11:04:21 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id LZz31Z00216AWCUA60Z800; Fri, 02 May 2008 18:04:09 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id Li4N1Z0074HwxpC8S00000; Fri, 02 May 2008 18:04:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=bpfLyCms9caWpr2YoKIA:9 a=zDXmPejIvfZAQ51q7KAA:7 a=tw9Qy0LO-6c0xIE0oHV7_3aAR3AA:4 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <007501c8ac53$213eb580$0600a8c0@china.huawei.com> <200805021446.m42Ektxj016473@idle.juniper.net> Date: Fri, 2 May 2008 14:04:22 -0400 Message-ID: <00bc01c8ac7e$f3cfae70$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200805021446.m42Ektxj016473@idle.juniper.net> Thread-Index: AcisZNIA/NJKgOgLQ7ugglcpJk07WwAGADjQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Phil, For some technologies, the monolithic approach doesn't work that well. Andy uses an example in this thread of needing the IPv6 group but not the IPv4 group. For an IPv6-only router, it doesn't make sense to require that the IPv4 group be implemented. This could of course be handled by writing separate modules for IPv4 and IPv6, but if the functionality is identical except the group for IP versions, you aren't making it easier for the reader. We would also have to prescient to know how whether every vendor will implement future products with support for all the functionality mentioned in a module, so we knew whioch pieces neede to be broken out into separate emodules for configuration. Imagine RFC3805 (the Printer MIB) having to define a separate module for each optional type of functionality, or requiring that the only conformant implementations of the management data model support for all of the optional functionality, even if that functionality is not available in the device? (Juniper must be doing well if they can afford to pay engineers to implement management for non-existent functionality. good job security for management standards engineers if vendors agree to do this. ;-) dbh > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Friday, May 02, 2008 10:47 AM > To: David Harrington > Cc: 'Andy Bierman'; netmod@ietf.org > Subject: Re: [netmod] YANG conformance-stmt (corrected) > > "David Harrington" writes: > >I think the conformance statement allows the importing module to > >specify that conformance to it requires version-specific conformance > >to its dependencies, and all you need to list in the importing module > >is the named conformance statement from the exporting module. > > This sounds different than Andy's example, which listed required > paths from module A in module B. > > >For example. using the snippet below, the conformance > statement in the > >importing module would need to specify > >conformance 2008-09-01 { > > requires module A conformance 2008-05-01 > >} > > This approach seems similar to listing revisions in import > statements. When I say: > > import A { > revision 2008-05-01; > } > > I'm saying that I want the contents of that specific revision of > module A. Modules are monolithic constructs (in that we don't have > a way of saying "I only implement x, y, and z from module A" (which > I think is goodness)), so by saying I want that revision of module > A, everyone is completely clear on what functionality I'm talking > about. > > I guess there are two halves to the problem. First is defining the > content which we are talking about (which revision-specific imports > solves), and second is defining for any specific > device/implementation, > what portion of that content the device implements. If we allow > SNMP-style implementation conformance statements, applications must > perform the "well it implements x but not y so how do I tell it to > do what I need it to do" logic. I'm happy to just say that modules > are monoliths; implement it all. > > Thanks, > Phil > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 11:10:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3783A6A02; Fri, 2 May 2008 11:10:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7B13A6ABD for ; Fri, 2 May 2008 11:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QWpuWgLtgTP for ; Fri, 2 May 2008 11:10:42 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 02A273A6A02 for ; Fri, 2 May 2008 11:10:42 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id LdWC1Z0010FhH24A70d300; Fri, 02 May 2008 18:10:32 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id LiAi1Z0014HwxpC8U00000; Fri, 02 May 2008 18:10:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=Q8sJPc7KXBJTEKcMp7gA:9 a=N8mnQlOwgH-S2K_uefnSjMmBmeoA:4 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Andy Bierman'" , "'Phil Shafer'" References: <200805021446.m42Ektxj016473@idle.juniper.net> <481B2E20.4070005@andybierman.com> Date: Fri, 2 May 2008 14:10:41 -0400 Message-ID: <00c901c8ac7f$d647c170$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <481B2E20.4070005@andybierman.com> Thread-Index: AcisZjg5VVUNfxI9TiyCJuUUaHMA7wAGVDXw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, comments inline. > I would be happy with an architecture where the entire module > is the contract, except when conceptually partitioned with > capabilities. Then a manager would use the module definition > and the reply to figure out exactly what an agent had. s/had/claimed to have/ sadly, they are non necessarily the same. managers still need to work with those agents/servers. dbh _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 11:20:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F3A3A6906; Fri, 2 May 2008 11:20:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27FF3A6D35 for ; Fri, 2 May 2008 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKuIaI2tnjZr for ; Fri, 2 May 2008 11:20:34 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id CECC728C452 for ; Fri, 2 May 2008 11:20:07 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id LcT11Z00d0mlR8UA50Ue00; Fri, 02 May 2008 18:17:22 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id LiKe1Z0074HwxpC8X00000; Fri, 02 May 2008 18:19:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=trJ3h-l9lXUR3PFm48AA:9 a=XcohxtXNd7igwWN00Uh4ORfAot0A:4 a=gJcimI5xSWUA:10 From: "David Harrington" To: References: <200805021517.m42FHxAV016834@idle.juniper.net> <481B37F9.7010003@andybierman.com> Date: Fri, 2 May 2008 14:20:04 -0400 Message-ID: <00ca01c8ac81$25e60790$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <481B37F9.7010003@andybierman.com> Thread-Index: AcisbB4CDy0ypBRYSM2+YWHyPs7O/wAFLxHA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > But it is not really good enough, because it could lead to > an explosion of capabilities, which would be just as hard > to manage as lots of module versions. I bet operators will love configuring/troubleshooting access controls for this matrix of lots of module versions and lots of capabilities. ;-( dbh _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 11:36:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808A83A6A56; Fri, 2 May 2008 11:36:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34253A6A56 for ; Fri, 2 May 2008 11:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtRhAlfVKce6 for ; Fri, 2 May 2008 11:36:43 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 3FAF93A6826 for ; Fri, 2 May 2008 11:36:43 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id LcZ91Z01B17UAYkAA0MC00; Fri, 02 May 2008 18:35:47 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id Licg1Z00U4HwxpC8Z00000; Fri, 02 May 2008 18:36:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=Eay0XMiaHx_lcrZeEXgA:9 a=omtXq02P1kDkFeoOoz0Kxio-I2EA:4 a=gJcimI5xSWUA:10 From: "David Harrington" To: References: <481B2EE7.5040209@andybierman.com> <200805021520.m42FKHdh016860@idle.juniper.net> Date: Fri, 2 May 2008 14:36:40 -0400 Message-ID: <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200805021520.m42FKHdh016860@idle.juniper.net> Thread-Index: AcisaYacQ7AgciwETVOjx7kWLcV/bgAF6R5w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > >So, all implementers and even module readers need to maintain > >every version of every module ever used in the system. > > Nope, you only need the ones you import. I think agent implementers only need the ones they implement. Manager applications and operators (and other module readers) will need to keep a potentially-large database of versioned modules to support multiple devices that support different versions. This is not a lot different than MIB modules. I believe there are devices that support the RFC1643 Ether-MIB, and others that support the RFC3635 MIB module. A device usually supports one or the other, but an NMS needs to know about both versions if different devices support different versions. SMIv2 set rules about how modules can be updated to prevent incompatible differences, and we didn't have a whole tree of dependencies, we only had one layer of IMPORTs. dbh _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 11:46:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4F83A6A80; Fri, 2 May 2008 11:46:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1D93A6C6A for ; Fri, 2 May 2008 11:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzOZndA02I2r for ; Fri, 2 May 2008 11:46:05 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 779D33A67D0 for ; Fri, 2 May 2008 11:46:05 -0700 (PDT) Received: (qmail 32823 invoked from network); 2 May 2008 18:46:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 2 May 2008 18:46:05 -0000 X-YMail-OSG: 763ldHYVM1kpexlnAfM4ECSqiDnOFNWxGDm_TS.8Ouxk.IzqC1bIhffVGBUMX2gb_eWkVZAkHFuCcjvKtTc785PxJQqb0qjn21e6zEXI4LiRcGPCMp6VRRaVOo0LJ99UE1Y- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B616B.2040103@andybierman.com> Date: Fri, 02 May 2008 11:46:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David Harrington References: <200805021446.m42Ektxj016473@idle.juniper.net> <481B2E20.4070005@andybierman.com> <00c901c8ac7f$d647c170$0600a8c0@china.huawei.com> In-Reply-To: <00c901c8ac7f$d647c170$0600a8c0@china.huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Harrington wrote: > Hi, > comments inline. > > >> I would be happy with an architecture where the entire module >> is the contract, except when conceptually partitioned with >> capabilities. Then a manager would use the module definition >> and the reply to figure out exactly what an agent had. > > s/had/claimed to have/ > sadly, they are non necessarily the same. > managers still need to work with those agents/servers. > not a standards problem. You cannot write "an implementation MUST NOT contain any bugs or misrepresent the actual NETCONF capabilities in any way" in a standard. > dbh > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 11:51:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DFB3A6A80; Fri, 2 May 2008 11:51:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D213A6E27 for ; Fri, 2 May 2008 11:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxQzokaSkaEk for ; Fri, 2 May 2008 11:51:49 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id D50F23A6AE0 for ; Fri, 2 May 2008 11:51:49 -0700 (PDT) Received: (qmail 16106 invoked from network); 2 May 2008 18:51:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 2 May 2008 18:51:49 -0000 X-YMail-OSG: r54bveMVM1mzvpxv9gg1a2NdV9uxe3HNY.pLJT84LKf8FiwW30AijYmNie.evCpumZQ44dhXLuD9m4oiyKEmL8RD71Lq8GQZJsxOIx6XZOpxPbeRH1.xYj2IODyIsy3yoMI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B62C4.70000@andybierman.com> Date: Fri, 02 May 2008 11:51:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David Harrington References: <481B2EE7.5040209@andybierman.com> <200805021520.m42FKHdh016860@idle.juniper.net> <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> In-Reply-To: <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Harrington wrote: > >>> So, all implementers and even module readers need to maintain >>> every version of every module ever used in the system. >> Nope, you only need the ones you import. > > I think agent implementers only need the ones they implement. > > Manager applications and operators (and other module readers) will > need to keep a potentially-large database of versioned modules to > support multiple devices that support different versions. > > This is not a lot different than MIB modules. I believe there are > devices that support the RFC1643 Ether-MIB, and others that support > the RFC3635 MIB module. A device usually supports one or the other, > but an NMS needs to know about both versions if different devices > support different versions. > > SMIv2 set rules about how modules can be updated to prevent > incompatible differences, and we didn't have a whole tree of > dependencies, we only had one layer of IMPORTs. > This is a solved problem in SMIv2. I don't mind the restriction that the importing module must accept everything in the module for the revision specified. But SMIv2 has a way to specify multiple conformance levels for each version of a module, all contained within the latest version of the module. I think YANG needs to provide the same feature, even if it is not implemented anything like SMIv2 MODULE-CONFORMANCE. > dbh Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 12:37:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2F73A6C6A; Fri, 2 May 2008 12:37:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEB128C1CE for ; Fri, 2 May 2008 12:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWLsreQUocbN for ; Fri, 2 May 2008 12:37:46 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 808093A692E for ; Fri, 2 May 2008 12:37:46 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Fri, 02 May 2008 12:37:47 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 May 2008 12:27:45 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m42JRjx05602; Fri, 2 May 2008 12:27:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m42JQ5q1018551; Fri, 2 May 2008 19:26:05 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805021926.m42JQ5q1018551@idle.juniper.net> To: "David Harrington" In-reply-to: <00bc01c8ac7e$f3cfae70$0600a8c0@china.huawei.com> Date: Fri, 02 May 2008 15:26:04 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 19:27:45.0774 (UTC) FILETIME=[9950E8E0:01C8AC8A] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "David Harrington" writes: >For some technologies, the monolithic approach doesn't work that well. I completely agree. I like the idea of using "when-capability" to express conditional bits of modules. I think this is fairly slick and expressive. But the last time around this pond, we tabled working on "when-capability" as future work. Are we un-tabling it? Until we do, we have 1:1 and need to be happy about living with it. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 12:42:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E623A6918; Fri, 2 May 2008 12:42:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103753A6DBB for ; Fri, 2 May 2008 12:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNbPrTrOdjzz for ; Fri, 2 May 2008 12:42:13 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 130063A6C98 for ; Fri, 2 May 2008 12:42:12 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 02 May 2008 12:42:11 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 May 2008 12:41:58 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m42Jfwx10705; Fri, 2 May 2008 12:41:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m42JeHcj018635; Fri, 2 May 2008 19:40:18 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805021940.m42JeHcj018635@idle.juniper.net> To: Andy Bierman In-reply-to: <481B37F9.7010003@andybierman.com> Date: Fri, 02 May 2008 15:40:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 19:41:58.0567 (UTC) FILETIME=[959ECB70:01C8AC8C] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Also, the module >with the objects needs to define the 'when-capability' >partitioning (in the affected objects), >not the module importing the objects. This is backwards. But "when-capability" _does_ put the conditionality on the definer, not the importer: module A { capability foo; grouping goo { leaf one { ... } when-capability foo { leaf two { ... } } } } module B { import A; container bee { use goo; // gets bee/two iff :foo } } Or: module D { container dee { leaf d1 { ... } } } module E { capability eee; when-capability eee { augment D:dee { when "d1 > 1500"; leaf e2 { ... } } } } The point where the node is defined designates if it's conditional on a capability by using the when-capability statement. >Another problem with the "import FOO-MIB, exact version X" approach >is that every time I update FOO-MIB, such as fixing a typo or a bug >in some construct, I have to update and release (perhaps) every >version of FOO-MIB ever written. Yes, there's no mechanism to explicitly say "this updates isn't important enough to rev modules that import this one". It would be up to the module owners to make that call. Or we could add a mostly-never-used "functionally-equivalent-to" statement so you can say: revision 2008-04-01.1 { description "Fixed mispelled 'Juniper'"; functionally-equivalent-to 2008-04-01; } which will bring it's own boatload of issues. >I would like the import-by-revision feature a lot better if >the latest version of each module is all that is ever needed >to implement it. If you always used the latest, you wouldn't need to specific the version. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 12:59:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3454B3A6906; Fri, 2 May 2008 12:59:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B1E3A67A7 for ; Fri, 2 May 2008 12:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+SZtHkyMHRI for ; Fri, 2 May 2008 12:59:54 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 667093A6906 for ; Fri, 2 May 2008 12:59:54 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id LjXe1Z02F16AWCUA900z00; Fri, 02 May 2008 19:59:39 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id Ljzr1Z0054HwxpC8S00000; Fri, 02 May 2008 19:59:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=cOiDVhGRFo3jIeQEXEoA:9 a=vdWmqUXQd7BW4MKFFv91aj0hwlsA:4 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Andy Bierman'" References: <200805021446.m42Ektxj016473@idle.juniper.net> <481B2E20.4070005@andybierman.com> <00c901c8ac7f$d647c170$0600a8c0@china.huawei.com> <481B616B.2040103@andybierman.com> Date: Fri, 2 May 2008 15:59:51 -0400 Message-ID: <00df01c8ac8f$17d3b3b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <481B616B.2040103@andybierman.com> Thread-Index: AcishMiGn58ZdZHyR8SSw9R1xcnjAQACX1zg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > not a standards problem. > You cannot write "an implementation MUST NOT contain any bugs > or misrepresent the actual NETCONF capabilities in any way" > in a standard. But we also don't want to make it so expensive to be compliant that implementers will be motivated to lie about what they support, OR be motivated to say they do not support something which actually they do to a significant degree. Making compliance an all-or-nothing decision for the whole management data model, when it is not an all-or-nothing logical compliance decision for the technology being modeled is not really helpful. dbh _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 2 13:16:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363FB3A6ADA; Fri, 2 May 2008 13:16:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441543A6C20 for ; Fri, 2 May 2008 13:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.789 X-Spam-Level: X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWU0KAaZwvvH for ; Fri, 2 May 2008 13:16:49 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 6B46C28C14F for ; Fri, 2 May 2008 13:16:47 -0700 (PDT) Received: (qmail 33985 invoked from network); 2 May 2008 20:16:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 20:16:47 -0000 X-YMail-OSG: bTh3oGQVM1lYe7FWkPAsIFignGolVVCJpBwgI3u5JAoWMy82F.w4kJqCSiyQxd..dJRUHyBhEVT2XNbgVw990.tBLUtO0l.SEU3ltql20y9r_zxiR5Fn46ECRySvq9408ZE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481B76AD.4000006@andybierman.com> Date: Fri, 02 May 2008 13:16:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David Harrington References: <200805021446.m42Ektxj016473@idle.juniper.net> <481B2E20.4070005@andybierman.com> <00c901c8ac7f$d647c170$0600a8c0@china.huawei.com> <481B616B.2040103@andybierman.com> <00df01c8ac8f$17d3b3b0$0600a8c0@china.huawei.com> In-Reply-To: <00df01c8ac8f$17d3b3b0$0600a8c0@china.huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Harrington wrote: > > >> not a standards problem. >> You cannot write "an implementation MUST NOT contain any bugs >> or misrepresent the actual NETCONF capabilities in any way" >> in a standard. > > But we also don't want to make it so expensive to be compliant that > implementers will be motivated to lie about what they support, OR be > motivated to say they do not support something which actually they do > to a significant degree. > > Making compliance an all-or-nothing decision for the whole management > data model, when it is not an all-or-nothing logical compliance > decision for the technology being modeled is not really helpful. > Agreed -- worst case scenario is there is a capability URI for every knob (maybe more than 1), and there are all kinds of undocumented interactions in various permutations of capability-sets. The conformance-to-group (in SMIv2) has proven both tractable and politically necessary to get consensus on MIB objects. In a way, 'capability-stmt' is a replacement for SMIv2 GROUP. It is important to explicitly state what is in the capability for a given module version, which capability-stmt does not provide. We have no real experience with grouping/uses, multiple RFCs, and updates to the grouping over time. We need to really understand how this is supposed to work now, not 5 years from now, (when we will obviously know what to do ;-) > dbh > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 3 14:20:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971763A6D7C; Sat, 3 May 2008 14:20:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C8B3A6B31 for ; Sat, 3 May 2008 14:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2PjZShMoBLF for ; Sat, 3 May 2008 14:20:10 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 818F828C22A for ; Sat, 3 May 2008 14:19:35 -0700 (PDT) Received: (qmail 15177 invoked from network); 3 May 2008 21:19:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 3 May 2008 21:19:25 -0000 X-YMail-OSG: pQk_0QsVM1ndqIlXGzJc_CActYBI3fKuP.F2FtjOVnOpqd_c4JrseVNPdcWCDkPZ0Ksyy2re0I5JLAZxMXQ.LTfIEzfzTtOmX5EUv4280fjceJJgqPvDAacOuZ64.lSWXEk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481CD6DB.9040502@andybierman.com> Date: Sat, 03 May 2008 14:19:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: netmod@ietf.org Subject: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I'm not sure if I'm reading all the emails right, but it seems that sometimes we are mixing 2 very different concepts and language mechanisms. 1) module conformance For each revision, it must be clear what is mandatory-to-implement, what is conditional (e.g., when-capability) and what is simply optional-to-implement. Unless otherwise stated, this refers to the agent implementation, not the manager implementation. 2) agent-variance For each release of each agent implementation, there may be aspects which are not compliant to some part of the module conformance. In SNMP, an AGENT-CAPABILITIES document can be stored offline and used to figure out the differences between what the agent claims to support, and what it is willing to admit it does not support. There has never been any support for retrieving this data from the agent. Vendors want to keep this sort of info as hard to know as possible. Q1: What to do about module conformance in NETMOD? Q2: What to do about agent variance in NETMOD? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 3 14:38:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A623A6BF2; Sat, 3 May 2008 14:38:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5772C3A6C11 for ; Sat, 3 May 2008 14:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMT7Sl1rvAI6 for ; Sat, 3 May 2008 14:38:05 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 6F2E93A6BF2 for ; Sat, 3 May 2008 14:38:05 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id CC1EF1B80C7; Sat, 3 May 2008 23:37:58 +0200 (CEST) Date: Sat, 03 May 2008 23:37:50 +0200 (CEST) Message-Id: <20080503.233750.216615421.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805021940.m42JeHcj018635@idle.juniper.net> References: <481B37F9.7010003@andybierman.com> <200805021940.m42JeHcj018635@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Phil Shafer wrote: > Andy Bierman writes: > >Also, the module > >with the objects needs to define the 'when-capability' > >partitioning (in the affected objects), > >not the module importing the objects. This is backwards. > > But "when-capability" _does_ put the conditionality on > the definer, not the importer: I agree with Phil. I think that introducing the two constructs 'capability' and 'when-capability' might solve the conformance problem. No need for an additional 'conformance' statement. > module A { > capability foo; > > grouping goo { > leaf one { ... } > > when-capability foo { > leaf two { ... } > } > } > } > > module B { > import A; > > container bee { > use goo; // gets bee/two iff :foo > } > } > > Or: > > module D { > container dee { > leaf d1 { ... } > } > } > > module E { > capability eee; > > when-capability eee { > augment D:dee { > when "d1 > 1500"; > leaf e2 { ... } > } > } > } > > The point where the node is defined designates if it's conditional > on a capability by using the when-capability statement. I like this, except that wrapping parts of the statements with a 'with-capability' statement isn't perfect from a readbility pow. How about: module E { capability eee; augment D:dee { when-capability eee; when "d1 > 1500"; leaf e2 { ... } } } Then you could also do: container foo { when-capability aaa; when-capability bbb; ... } Instead of when-capability aaa { when-capability bbb { container foo { ... } } } And also: capability "...:confirmed-commit" { when-capability "...:candidate"; description "..."; } And maybe even: typedef ErrorOptionType { description "NETCONF 'error-option' Element Content"; type enumeration { enum stop-on-error; enum continue-on-error; enum rollback-on-error { when-capability "...:rollback-on-error"; } } default "stop-on-error"; } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 3 14:57:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910F13A6868; Sat, 3 May 2008 14:57:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442D83A6868 for ; Sat, 3 May 2008 14:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s766b8pNMPRb for ; Sat, 3 May 2008 14:57:23 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 5E3703A6865 for ; Sat, 3 May 2008 14:57:23 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 4B9C11B80D0; Sat, 3 May 2008 23:57:18 +0200 (CEST) Date: Sat, 03 May 2008 23:57:07 +0200 (CEST) Message-Id: <20080503.235707.162032006.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <481CD6DB.9040502@andybierman.com> References: <481CD6DB.9040502@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > 1) module conformance > > For each revision, it must be clear what is mandatory-to-implement, > what is conditional (e.g., when-capability) and what is simply > optional-to-implement. I'm not sure I understand the distinction between conditional-to-implement and optional-to-implement - couldn't capabilities be used to cover them both? I think that capabilities would be the NETMOD version of OBJECT-GROUP. > 2) agent-variance > > For each release of each agent implementation, there may be > aspects which are not compliant to some part > of the module conformance. In SNMP, an AGENT-CAPABILITIES > document can be stored offline and used to figure out the > differences between what the agent claims to support, > and what it is willing to admit it does not support. > > There has never been any support for retrieving > this data from the agent. Vendors want to keep this sort > of info as hard to know as possible. Currently in YANG we just have conformance to entire modules. With 'with-capability' we would have conformance to complete capabilities. Could this be good enough for now? Maybe we need some experience of these constructs before we do (if we do) more detailed agent-variance, esp. if the SMI experience is that AGENT-CAPABILITIES rarely is used. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 3 16:18:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839073A67D5; Sat, 3 May 2008 16:18:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390463A6835 for ; Sat, 3 May 2008 16:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAykr9fNeoOL for ; Sat, 3 May 2008 16:18:11 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 5ECB93A67D5 for ; Sat, 3 May 2008 16:18:11 -0700 (PDT) Received: (qmail 73246 invoked from network); 3 May 2008 23:18:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 3 May 2008 23:18:11 -0000 X-YMail-OSG: 4gtv4OoVM1mF3QWRtlvsMNQN6ype_yhhxY1mSXa1F81myCg_L9L2ZK8Mr3dvPUUhvgq0c.a2AOdxZQlifZgEJJG2Va8a61.mMXT90iYEazSbvdKRoLpHVOQa.PnllmGpAk4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481CF2B0.9000707@andybierman.com> Date: Sat, 03 May 2008 16:18:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <481CD6DB.9040502@andybierman.com> <20080503.235707.162032006.mbj@tail-f.com> In-Reply-To: <20080503.235707.162032006.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> 1) module conformance >> >> For each revision, it must be clear what is mandatory-to-implement, >> what is conditional (e.g., when-capability) and what is simply >> optional-to-implement. > > I'm not sure I understand the distinction between > conditional-to-implement and optional-to-implement - couldn't > capabilities be used to cover them both? > yes -- the derivative 'condition' is 'none'. Conditional means you MUST implement this object if the condition is met. Optional means there are no conditions under which the object is required to be implemented. > I think that capabilities would be the NETMOD version of > OBJECT-GROUP. > >> 2) agent-variance >> >> For each release of each agent implementation, there may be >> aspects which are not compliant to some part >> of the module conformance. In SNMP, an AGENT-CAPABILITIES >> document can be stored offline and used to figure out the >> differences between what the agent claims to support, >> and what it is willing to admit it does not support. >> >> There has never been any support for retrieving >> this data from the agent. Vendors want to keep this sort >> of info as hard to know as possible. > > Currently in YANG we just have conformance to entire modules. With > 'with-capability' we would have conformance to complete capabilities. > I don't really like the capability/with-capability form of conformance documentation (as much as it is defined at all). There can be arbitrarily nested clauses within the data structures in your example. This seems in the same vein as 'import-by-revision-date' to me. Something that seems like a rather minor feature takes on massive complexity, then more complexity to cover up some flaws, then a little more, then a little more. By the time these minor features are fully documented, inter-operable, and able to pass IESG inspection, half the language could be done. > Could this be good enough for now? Maybe we need some experience of > these constructs before we do (if we do) more detailed agent-variance, > esp. if the SMI experience is that AGENT-CAPABILITIES rarely is used. > I am not so willing to dismiss the 20 years experience we have in the IETF with MODULE-CONFORMANCE in SMIv2. I am not so willing to start the 'experience meter' over, just because we are using XML now, instead of ASN.1/BER encoding. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 3 16:40:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF413A6AEA; Sat, 3 May 2008 16:40:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179733A6AEA for ; Sat, 3 May 2008 16:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URB7vMCd4tVf for ; Sat, 3 May 2008 16:39:58 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 92F8F3A6D1D for ; Sat, 3 May 2008 16:39:00 -0700 (PDT) Received: (qmail 37559 invoked from network); 3 May 2008 23:39:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 3 May 2008 23:39:00 -0000 X-YMail-OSG: gSnsZbEVM1kQi_PW.S53AI8sYlZl9THKMaKL94s7M0WvHeN6SpSHHaxC1JKzCXhZh2UMGCV1UQ6jF8PN4fJqBwzV74Ztbid69fF9hWDiWglSkr80cwiW4F0JbknJnNh0T2k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481CF792.1070209@andybierman.com> Date: Sat, 03 May 2008 16:38:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <481CD6DB.9040502@andybierman.com> <20080503.235707.162032006.mbj@tail-f.com> <481CF2B0.9000707@andybierman.com> In-Reply-To: <481CF2B0.9000707@andybierman.com> Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: >.. > By the time these minor features are fully documented, > inter-operable, and able to pass IESG inspection, > half the language could be done. > IMO, it would be better to start off simple with minor features like import and conformance, rather than spend a long time designing something by committee. That would mean, for the current issues: -- you can only import the latest version of the module -- there is no concept of a partial conformance level. Capabilities can be defined outside the language. Conditions based on capabilities can be mentioned in description clauses. (This is what NETCONF has now.) -- there is no documentation of agent variance. To be fair, these features were not added on Day One of SMI either. We probably need to consider conformance to an XML namespace as well as module conformance. Is there a difference? We probably need to consider augments, groupings, choices, and deep tables when designing conformance and variance mechanisms for NETCONF/YANG. I think the design team got it right by leaving these items off the feature list in the first place. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun May 4 18:14:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838E03A6F5A; Sun, 4 May 2008 18:14:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740863A6F73 for ; Sun, 4 May 2008 18:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-bFiU4oGR5c for ; Sun, 4 May 2008 18:14:01 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id A3F213A6F5A for ; Sun, 4 May 2008 18:13:58 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Sun, 04 May 2008 18:13:29 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 May 2008 18:12:41 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m451Cex20540; Sun, 4 May 2008 18:12:40 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m451AwS7031968; Mon, 5 May 2008 01:10:58 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805050110.m451AwS7031968@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080503.233750.216615421.mbj@tail-f.com> Date: Sun, 04 May 2008 21:10:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2008 01:12:41.0152 (UTC) FILETIME=[1D8C7C00:01C8AE4D] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: > augment D:dee { > when-capability eee; > when "d1 > 1500"; > leaf e2 { ... } This is fine, and keeps us from having to sweat the context of the when-capability statement (and have differing sets of contents). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 06:35:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55803A68A8; Mon, 5 May 2008 06:35:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E701F3A6B65 for ; Mon, 5 May 2008 06:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4rZ4z6nJlEI for ; Mon, 5 May 2008 06:35:02 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D449B3A6C35 for ; Mon, 5 May 2008 06:35:02 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id C8F852F2FB9; Mon, 5 May 2008 06:33:04 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=0DJJLLkD5EXQk/gfA6arfqL5mx4=; b=n//gDWDQhItupC1kNUK1d84kccG8eiZ6NQtCm7GCoH2uZV6kD+x8k/1VGyruilRfyvlG7Th8TNmAKPamyhxWpShZfOMz5OKM4q1c9SaK1XzubNWos2iZKGEd2aGdbUlYNNLACqEUvbD6A48Cm1gLmNPNBtTgWJIE1IrpI9KNWv8= Received: by wes.hardakers.net (Postfix, from userid 274) id 496062F2FB6; Mon, 5 May 2008 06:33:04 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <481B2EE7.5040209@andybierman.com> <200805021520.m42FKHdh016860@idle.juniper.net> <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> Date: Mon, 05 May 2008 06:33:03 -0700 In-Reply-To: <481B62C4.70000@andybierman.com> (Andy Bierman's message of "Fri, 02 May 2008 11:51:48 -0700") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org >>>>> On Fri, 02 May 2008 11:51:48 -0700, Andy Bierman said: AB> I don't mind the restriction that the importing module AB> must accept everything in the module for the revision specified. I think the critical things (in my mind) are that: 1) Modules are backwards compatible. If this isn't the case then either we'd allow the tree structure to change in semantics without re-wording the leaf names which, IMHO, is a recipe for problems or we stop publishing tree components that are "obsolete" (like the IF-FORWARD-MIB continuing to contain the ipForwardTable even though it's obsolete). If modules are backwards compatible then you don't need to worry about specifying and exact version. 2) You probably do need a minimum conformance level though, especially if you want to blindly import a particular subtree within a module and not specify each leaf node. (specifying each leaf node was required in SMIv2 and the imports clause became potentially large if you needed a lot of pieces from the imported MIB). The solution to #2 is specifying a method to import portions from the other module that "is at least greater than or equal to version X". import A { at-least-revision 2008-05-01; } Would be a safe way, if modules must be backwards compatible, to reduce the number of loaded module As on this system to 1 (which had to be of a revision greater than the maximum specified). The downside, of course, to never allowing a subtree section to disappear from a module is module growth. You could solve that too by allowing a double import though (A imports something from B but B has outsourced it (now) to B-archive but the import from A to B will still work). -- Wes Hardaker Sparta, Inc. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 06:58:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD61E3A6C26; Mon, 5 May 2008 06:58:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51EF3A68D5 for ; Mon, 5 May 2008 06:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woIw9CGH8-KE for ; Mon, 5 May 2008 06:58:12 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 89CE33A6DA2 for ; Mon, 5 May 2008 06:56:26 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id CE60A1B80C7; Mon, 5 May 2008 15:56:24 +0200 (CEST) Date: Mon, 05 May 2008 15:56:35 +0200 (CEST) Message-Id: <20080505.155635.37289612.mbj@tail-f.com> To: wjhns1@hardakers.net From: Martin Bjorklund In-Reply-To: References: <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Wes Hardaker wrote: > I think the critical things (in my mind) are that: > > 1) Modules are backwards compatible. [...] > If modules are backwards compatible then you don't > need to worry about specifying and exact version. This has been our assumption as well. The problem is 'groupings', and what constitues a backwards compatible modification in a grouping. module a { revision 2008-05-01; grouping foo { leaf y { ... } } } module b { revision 2008-05-02; import a; container x { uses a:foo; } } Now, b has the structure ... If a new leaf 'z' is added to the grouping foo in an updated version of module a, the structure of b magically becomes: ... ... even though b hasn't been updated. So the conclusion is that adding structure to a (exported) grouping is not allowed. But this might be too restrictive, and would force people to encode a version number in the grouping name: module a { revision 2008-05-08; grouping foo { leaf y { ... } } grouping foo2 { uses foo; leaf z { ... } } } Although the versioning rules of YANG are not spelled out yet in the draft, this is the current situation. One solution is the versioned import. > 2) You probably do need a minimum conformance level though, especially > if you want to blindly import a particular subtree within a module > and not specify each leaf node. (specifying each leaf node was > required in SMIv2 and the imports clause became potentially large if > you needed a lot of pieces from the imported MIB). > > The solution to #2 is specifying a method to import portions from the > other module that "is at least greater than or equal to version X". > > import A { > at-least-revision 2008-05-01; > } Has this been a problem in SMI? If I IMPORT ifAlias from IF-MIB, and someone tries to use this togther with an old version of the IF-MIB it won't work. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 07:41:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6574B3A68BE; Mon, 5 May 2008 07:41:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5523A6989 for ; Mon, 5 May 2008 07:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9jKxznoAr0J for ; Mon, 5 May 2008 07:41:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D4FBA3A68BE for ; Mon, 5 May 2008 07:41:00 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA845C001F; Mon, 5 May 2008 16:41:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dVi+MWLOUGqh; Mon, 5 May 2008 16:40:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAD2CC0015; Mon, 5 May 2008 16:41:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3ABD05709DB; Mon, 5 May 2008 16:40:53 +0200 (CEST) Date: Mon, 5 May 2008 16:40:53 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080505144053.GD28170@elstar.local> Mail-Followup-To: Martin Bjorklund , wjhns1@hardakers.net, netmod@ietf.org References: <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> <20080505.155635.37289612.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080505.155635.37289612.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, May 05, 2008 at 03:56:35PM +0200, Martin Bjorklund wrote: > Wes Hardaker wrote: > > I think the critical things (in my mind) are that: > > > > 1) Modules are backwards compatible. > [...] > > If modules are backwards compatible then you don't > > need to worry about specifying and exact version. > > This has been our assumption as well. The problem is 'groupings', and > what constitues a backwards compatible modification in a grouping. > > module a { > revision 2008-05-01; > grouping foo { > leaf y { ... } > } > } > > module b { > revision 2008-05-02; > import a; > > container x { > uses a:foo; > } > } > > Now, b has the structure > > > ... > > > If a new leaf 'z' is added to the grouping foo in an updated version of > module a, the structure of b magically becomes: > > > ... > ... > > > even though b hasn't been updated. > > So the conclusion is that adding structure to a (exported) grouping is > not allowed. But this might be too restrictive, and would force > people to encode a version number in the grouping name: > > module a { > revision 2008-05-08; > grouping foo { > leaf y { ... } > } > grouping foo2 { > uses foo; > leaf z { ... } > } > } > > Although the versioning rules of YANG are not spelled out yet in the > draft, this is the current situation. One solution is the versioned > import. The alternative is to be explicit if you use a grouping what you use. This is what we ended up with when we did SMIng in the NMRG (I am not saying this is the solution but at least one solution to consider). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 08:19:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05583A695C; Mon, 5 May 2008 08:19:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9107A3A6DD9 for ; Mon, 5 May 2008 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qplydPR5voEU for ; Mon, 5 May 2008 08:19:35 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D94543A6989 for ; Mon, 5 May 2008 08:19:31 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id A9E2F2F2FB9; Mon, 5 May 2008 08:17:32 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=4rJWsDR4nvKqheT7dpSxXBhzwbU=; b=TVqWbq2X4rzOWWuHLZKGqSkZy8LICrRllOekv3cZFWvgdXAbAx6UjyXWOb+XpoHwgwyCh/x9RPgaiPLH1HeEYN8bXZrFHiY9oV5n5UF8vSazdZBMxwlqjyFexkrwpWfqZKc4ZFBDzk5HeXNFW3CbWUH+2js3pRrfFVHffVfzAoU= Received: by wes.hardakers.net (Postfix, from userid 274) id 6E21E2F2FB6; Mon, 5 May 2008 08:17:32 -0700 (PDT) From: Wes Hardaker To: Martin Bjorklund Organization: Sparta References: <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> <20080505.155635.37289612.mbj@tail-f.com> Date: Mon, 05 May 2008 08:17:32 -0700 In-Reply-To: <20080505.155635.37289612.mbj@tail-f.com> (Martin Bjorklund's message of "Mon, 05 May 2008 15:56:35 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org >>>>> On Mon, 05 May 2008 15:56:35 +0200 (CEST), Martin Bjorklund said: >> 2) You probably do need a minimum conformance level though, especially >> if you want to blindly import a particular subtree within a module >> and not specify each leaf node. (specifying each leaf node was >> required in SMIv2 and the imports clause became potentially large if >> you needed a lot of pieces from the imported MIB). >> >> The solution to #2 is specifying a method to import portions from the >> other module that "is at least greater than or equal to version X". >> >> import A { >> at-least-revision 2008-05-01; >> } MB> Has this been a problem in SMI? If I IMPORT ifAlias from IF-MIB, and MB> someone tries to use this togther with an old version of the IF-MIB it MB> won't work. No, but SMI doesn't let you import entire sections of a tree. There is no equivalent "import group". If you want all the columns of a table to be referenced in an SMI document you must manually import every single column. When importing a set (grouping) that may change in contents, it's equally important that you can specify a minimum compatible version. (If you're going to require exact version imports then it doesn't matter anyway. My point is you need either a >= operator or a = operator for an import statement) -- Wes Hardaker Sparta, Inc. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 08:20:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E223A6989; Mon, 5 May 2008 08:20:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC493A6CF1 for ; Mon, 5 May 2008 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncs1h-OHrQ3u for ; Mon, 5 May 2008 08:20:13 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id DAD343A695C for ; Mon, 5 May 2008 08:20:08 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 05 May 2008 08:19:43 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 08:19:39 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m45FINx66070; Mon, 5 May 2008 08:18:23 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m45FGeFE040764; Mon, 5 May 2008 15:16:40 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805051516.m45FGeFE040764@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080505144053.GD28170@elstar.local> Date: Mon, 05 May 2008 11:16:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2008 15:19:39.0283 (UTC) FILETIME=[6F83E630:01C8AEC3] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >The alternative is to be explicit if you use a grouping what you use. >This is what we ended up with when we did SMIng in the NMRG (I am not >saying this is the solution but at least one solution to consider). This is painful with hiearchies of nodes, since you'd need to list the complete hierarchy of nodes that you want to import, including containers, leafs, lists, leaf-lists, enumerations, etc. You'd end up with something like: use foo { container system { container services { container ssh { leaf version { type enumeration { enum v1; enum v2; } } leaf port; leaf rate-limit; leaf connection-limit; leaf-list allow-address; leaf-list deny-address; container trace-options { list flags { leaf name { type enumeration { enum listen; enum deny; enum auth; enum protocol-error; enum debug; } } } } } } } At this point, what's the grouping doing for you? It would be like doing a #include of a file, but having to list the contents of that file inline. It's the belt and suspenders approach. With big suspenders. ;^) Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 08:24:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF453A6E69; Mon, 5 May 2008 08:24:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DA128C2A9 for ; Mon, 5 May 2008 08:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cvqqyzKKIf1 for ; Mon, 5 May 2008 08:24:56 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 0FD0C3A6E6B for ; Mon, 5 May 2008 08:24:56 -0700 (PDT) Received: (qmail 69437 invoked from network); 5 May 2008 15:24:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 5 May 2008 15:24:53 -0000 X-YMail-OSG: WLwIo3wVM1n3T385tRLjISf05HLYnwY0rd3ZdVnla.3Ksu_8IkzancRzgcIXFdOte4fnRfJXco1L3bECq5qtEghHdLlvzVSQeJPccxCWxXrrJGvqsBS6RGUq65pd37TeAaw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481F26F4.7000102@andybierman.com> Date: Mon, 05 May 2008 08:25:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> <20080505.155635.37289612.mbj@tail-f.com> In-Reply-To: <20080505.155635.37289612.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Wes Hardaker wrote: >> I think the critical things (in my mind) are that: >> We are in new uncharted territory wrt/ backward compatibility. SMIv2 has strict rules (CLRs) for some important reasons. One of them is the need to control the interactions between modules. We never want the 'protocol contents' of a module to magically change because other modules have changed. In SMIv2, only data types and external columns used in INDEX clauses can be changed in this manner. TCs can only be changed in specific ways to maintain backward compatibility. In YANG, the uses-stmt can cause new nodes to show up. Augment doesn't matter. The new nodes are really in the original module's namespace, so this is not really a change to the augmented module. There MUST be some mechanism in YANG (either conformance or inline) to 'lock down' the contents of such a uses-stmt, so it is unambiguous which version of the grouping (from another module) is being used. Andy >> 1) Modules are backwards compatible. > [...] >> If modules are backwards compatible then you don't >> need to worry about specifying and exact version. > > This has been our assumption as well. The problem is 'groupings', and > what constitues a backwards compatible modification in a grouping. > > module a { > revision 2008-05-01; > grouping foo { > leaf y { ... } > } > } > > module b { > revision 2008-05-02; > import a; > > container x { > uses a:foo; > } > } > > Now, b has the structure > > > ... > > > If a new leaf 'z' is added to the grouping foo in an updated version of > module a, the structure of b magically becomes: > > > ... > ... > > > even though b hasn't been updated. > > So the conclusion is that adding structure to a (exported) grouping is > not allowed. But this might be too restrictive, and would force > people to encode a version number in the grouping name: > > module a { > revision 2008-05-08; > grouping foo { > leaf y { ... } > } > grouping foo2 { > uses foo; > leaf z { ... } > } > } > > Although the versioning rules of YANG are not spelled out yet in the > draft, this is the current situation. One solution is the versioned > import. > > >> 2) You probably do need a minimum conformance level though, especially >> if you want to blindly import a particular subtree within a module >> and not specify each leaf node. (specifying each leaf node was >> required in SMIv2 and the imports clause became potentially large if >> you needed a lot of pieces from the imported MIB). >> >> The solution to #2 is specifying a method to import portions from the >> other module that "is at least greater than or equal to version X". >> >> import A { >> at-least-revision 2008-05-01; >> } > > Has this been a problem in SMI? If I IMPORT ifAlias from IF-MIB, and > someone tries to use this togther with an old version of the IF-MIB it > won't work. > > > > > /martin > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 08:46:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C11A28C0ED; Mon, 5 May 2008 08:46:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F105228C0DC for ; Mon, 5 May 2008 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNzgrBS6gVwx for ; Mon, 5 May 2008 08:46:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 230D928C0FF for ; Mon, 5 May 2008 08:46:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71E64C0020; Mon, 5 May 2008 17:46:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KhZSa5ilhqVf; Mon, 5 May 2008 17:46:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31F52C001F; Mon, 5 May 2008 17:46:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D74A8570B30; Mon, 5 May 2008 17:46:04 +0200 (CEST) Date: Mon, 5 May 2008 17:46:04 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080505154604.GF28170@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20080505144053.GD28170@elstar.local> <200805051516.m45FGeFE040764@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200805051516.m45FGeFE040764@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, May 05, 2008 at 11:16:40AM -0400, Phil Shafer wrote: > This is painful with hiearchies of nodes, since you'd need to list > the complete hierarchy of nodes that you want to import, including > containers, leafs, lists, leaf-lists, enumerations, etc. You'd end up > with something like: [...] Yes, this is verbose. But this is actually spelling out what happens. Perhaps it is possible to improve the syntax but that is a secondary issue. Probably encoding a version number into the name of a grouping, that is introducing versioned identifiers, is actually not such a bad idea. This way, all versions of the grouping are easy to distinguish and accessible from a single place and if I want to use a new version of a grouping, I can be explicit. We just would need to figure out how to legalize such version updates under the versioning rules. I am concerned that having to deal with N version of the same module and being able to fully understand the impact of changing an import from one revision N to N+x is really tricky without having decent tool support (because the tool would have to compute the verbose stuff to allow comparisons). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 08:53:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CC83A684A; Mon, 5 May 2008 08:53:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9174F3A67B3 for ; Mon, 5 May 2008 08:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.789 X-Spam-Level: X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1Y8f369wtbM for ; Mon, 5 May 2008 08:53:29 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 008CB3A6CF1 for ; Mon, 5 May 2008 08:53:27 -0700 (PDT) Received: (qmail 70030 invoked from network); 5 May 2008 15:53:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 5 May 2008 15:53:25 -0000 X-YMail-OSG: IQNsHE4VM1mJjASgDu9_J8FJKFCjvtrlPkq1JsyFEynPYS341ZcW2aVYgh6BChCuWGiPb98xPTAMMp1H6ie.yyJJn_._HRt8KDEXwIZVj26l98LbT.KJSxIXraBecqTV92BMis3lRgoEMK2pIm0KLg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481F2DA7.7050505@andybierman.com> Date: Mon, 05 May 2008 08:54:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Wes Hardaker References: <481B2EE7.5040209@andybierman.com> <200805021520.m42FKHdh016860@idle.juniper.net> <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Wes Hardaker wrote: >>>>>> On Fri, 02 May 2008 11:51:48 -0700, Andy Bierman said: > > AB> I don't mind the restriction that the importing module > AB> must accept everything in the module for the revision specified. > > I think the critical things (in my mind) are that: > > 1) Modules are backwards compatible. If this isn't the case then either > we'd allow the tree structure to change in semantics without > re-wording the leaf names which, IMHO, is a recipe for problems or we > stop publishing tree components that are "obsolete" (like the > IF-FORWARD-MIB continuing to contain the ipForwardTable even though > it's obsolete). If modules are backwards compatible then you don't > need to worry about specifying and exact version. > > 2) You probably do need a minimum conformance level though, especially > if you want to blindly import a particular subtree within a module > and not specify each leaf node. (specifying each leaf node was > required in SMIv2 and the imports clause became potentially large if > you needed a lot of pieces from the imported MIB). > > The solution to #2 is specifying a method to import portions from the > other module that "is at least greater than or equal to version X". > > import A { > at-least-revision 2008-05-01; > } > This doesn't really help the 'changing uses-stmt' problem. If a grouping in module 'A' adds new columns each version, it is still not clear to a manager which version of the grouping is expected for a particular uses-stmt in the module importing 'A'. The problem with "import exact version" and "import version range" is that the upper bound on the version is artificial. Module 'A' will be updated for something that has nothing to do with the grouping, and modules that import A will 'break' according to the rules. Every one of these modules needs to be updated as well, reflecting the new version of 'A'. Worst of all, implementations will be forced to maintain several versions of each module. Implementers and operators accustomed to only referring to the most recent documentation might not appreciate this 'feature' of YANG. IMO, none of the proposed solutions actually works, except my conformance proposal (or any proposal which requires the leafs in the module namespace to be explicitly listed for each module version). I like the conformance approach better because it more precise. I want to say "Subtree /foo/bar/A" is from version 2008-05-05 of module A. That is a much finer-grained tool than saying "I want to import version 2008-0505 of module A". > Would be a safe way, if modules must be backwards compatible, to reduce > the number of loaded module As on this system to 1 (which had to be of a > revision greater than the maximum specified). > > The downside, of course, to never allowing a subtree section to > disappear from a module is module growth. You could solve that too by > allowing a double import though (A imports something from B but B has > outsourced it (now) to B-archive but the import from A to B will still work). > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 10:00:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1573A6B35; Mon, 5 May 2008 10:00:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0F93A6B5D for ; Mon, 5 May 2008 10:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt5a092mEqXR for ; Mon, 5 May 2008 10:00:44 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 3128E3A6B35 for ; Mon, 5 May 2008 10:00:39 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Mon, 05 May 2008 10:00:36 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 10:00:24 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m45H0Nx97517; Mon, 5 May 2008 10:00:23 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m45GwecZ041894; Mon, 5 May 2008 16:58:40 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805051658.m45GwecZ041894@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080505154604.GF28170@elstar.local> Date: Mon, 05 May 2008 12:58:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2008 17:00:24.0143 (UTC) FILETIME=[828855F0:01C8AED1] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >Yes, this is verbose. But this is actually spelling out what happens. Verbose, and a severe dilution of the functionality of groupings as a shorthand for writing complex hierarchies. >Probably encoding a version number into the name of a grouping, that >is introducing versioned identifiers, is actually not such a bad >idea. This requires the reader of "foo_v35" to thread their way back thru the 34 earlier versions. We trade benefits for "readers that want to understand the history of all revisions of this module" against "reader who want to understand the current revision of this module". The former can look at previous revisions, resorting to tools if needed to view the history. And the latter can use a tool to display the outcome of merging the various groupings together. But which reader do we want to optimize for? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 10:48:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAF03A68DE; Mon, 5 May 2008 10:48:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5393A6E09 for ; Mon, 5 May 2008 10:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoX09jle2Hue for ; Mon, 5 May 2008 10:48:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6EA4B3A6837 for ; Mon, 5 May 2008 10:48:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7B90C0023; Mon, 5 May 2008 19:48:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vVWv+7zjvmSB; Mon, 5 May 2008 19:48:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFAF6C000D; Mon, 5 May 2008 19:48:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 55A62570CFC; Mon, 5 May 2008 19:48:22 +0200 (CEST) Date: Mon, 5 May 2008 19:48:22 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080505174822.GA28813@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20080505154604.GF28170@elstar.local> <200805051658.m45GwecZ041894@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200805051658.m45GwecZ041894@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, May 05, 2008 at 12:58:40PM -0400, Phil Shafer wrote: > >Probably encoding a version number into the name of a grouping, that > >is introducing versioned identifiers, is actually not such a bad > >idea. > > This requires the reader of "foo_v35" to thread their way back thru > the 34 earlier versions. I don't get this; please explain. > We trade benefits for "readers that want to understand the history > of all revisions of this module" against "reader who want to > understand the current revision of this module". The former can > look at previous revisions, resorting to tools if needed to view the > history. And the latter can use a tool to display the outcome of > merging the various groupings together. But which reader do we want > to optimize for? The point is that "current revision" is pretty meaningless. If we do versioned imports, the user will have to find the right version of the module first to look at and only then the search becomes easier. The question boils down to whether it is a) easier to search for the right version of a definition in a single module or b) easier to find the right version of the module to find the right definition. Furthermore, if I cut'n'paste an example to an IETF mailing list, a vendor bug tracker, a news forum etc., I have the feeling that uses foo:foo_v35; or grouping foo_v35 { // ... } is actually easier for me to track since I do not need to maintain an implicit version context established by the import clauses (and which people likely leave out). That said, I am sure we will have to deal with groupings that implementors like to subset. I have some doubts that a standards body will get all the groupings right such that all details will work for every implementation equally well (which is a related subject). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:07:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3B53A6A11; Mon, 5 May 2008 11:07:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03753A6B35 for ; Mon, 5 May 2008 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei-lLzy+ZCT2 for ; Mon, 5 May 2008 11:07:06 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 6CFB43A6A9B for ; Mon, 5 May 2008 11:07:06 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA10.westchester.pa.mail.comcast.net with comcast id MqUG1Z00L0EZKEL5A0Dn00; Mon, 05 May 2008 18:05:41 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.westchester.pa.mail.comcast.net with comcast id Mu711Z00G4HwxpC3M00000; Mon, 05 May 2008 18:07:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=gVRd7z71awwA:10 a=FH951aLNgCQA:10 a=48vgC7mUAAAA:8 a=dCZzwo4Kvnw0MF0UT1oA:9 a=JqTEAC2HeSbWYL01lWzgYseWU8kA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Andy Bierman'" , "'Martin Bjorklund'" References: <481CD6DB.9040502@andybierman.com> <20080503.235707.162032006.mbj@tail-f.com><481CF2B0.9000707@andybierman.com> <481CF792.1070209@andybierman.com> Date: Mon, 5 May 2008 14:07:01 -0400 Message-ID: <020b01c8aeda$d1920390$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <481CF792.1070209@andybierman.com> Thread-Index: AcitdwSav2Sn7Xm1S9OWF36lsUezBABX+YsQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I never asked for agent-variance, nor has anybody else. My concern is that Netconf is adding support for schema discovery, and for imports of sub=schemas that could change, and it is unclear what rules must be followed in reporting what schemas are supported. If my agent says during schema discovery that it supports the FOO module, what does that mean? What if I actually implement one object froma a large module. My agent is obviously not compliant; does this mean I should not report this schema during discovery? The point came up when talking about versiuoning and the all-or-nothing compliance to a module. In many cases, as we know from SMI experience, a module definition may contain more objects than it makes sense to support by an implementation. This is known to be true for monitoring purposes, and likely to be common in the case of configuration data (I cannot help but think of the IPSec Policy MIBs). Often a WG will define a standard module that contains a bunch of tables, some of which model functionality that is optional in the underlying technology, or really cannot be used to model a vendor's actual implementation. Vendors often "cherry-pick" MIB modules to support the objects they consider important, and ignore those they consider unimportant. This raises two questions: 1) whether we should allow for some types of partial compliance to support underlying optional functionality, and 2) if an agent only partially supports a module standard, what should it report during schema discovery? Support for multiple compliace clauses in standard MIBs was added based on operational experience. If partial compliance is not allowed, then should we (try to) ensure that all modules are broken down into small enough chunks that full compliance is likely in the real world, or do we make compliance so hard to achieve in real world implementations that any "full compliance" edict effectively becomes meaningless? Schema discovery is in the process of being defined. Is there any implication for an agent reporting a module during discovery that the agent is fully compliant? If that is not the case, then I think the schema discovery capability needs to be very clear that no such assumption should be made by the querying application. This implies that using the reported schema to validate data might prove inaccurate. Are there any clearly defined rules about when a schema should or should not be reported in schema discovery, and does NETMOD need to provide anything to support those rules? dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Saturday, May 03, 2008 7:39 PM > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] module conformance vs. agent-variance > > Andy Bierman wrote: > > Martin Bjorklund wrote: > >.. > > By the time these minor features are fully documented, > > inter-operable, and able to pass IESG inspection, > > half the language could be done. > > > > IMO, it would be better to start off simple with > minor features like import and conformance, rather > than spend a long time designing something by committee. > > That would mean, for the current issues: > > -- you can only import the latest version of the module > > -- there is no concept of a partial conformance level. > Capabilities can be defined outside the language. > Conditions based on capabilities can be mentioned in description > clauses. (This is what NETCONF has now.) > > -- there is no documentation of agent variance. > > > To be fair, these features were not added on Day One of SMI either. > > We probably need to consider conformance to an XML namespace > as well as module conformance. Is there a difference? > We probably need to consider augments, groupings, choices, > and deep tables when designing conformance and variance > mechanisms for NETCONF/YANG. > > I think the design team got it right by leaving > these items off the feature list in the first place. > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:19:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAC928C295; Mon, 5 May 2008 11:19:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698B528C295 for ; Mon, 5 May 2008 11:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uePGYskYunP for ; Mon, 5 May 2008 11:19:15 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 0789528C2D9 for ; Mon, 5 May 2008 11:18:56 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 05 May 2008 11:18:51 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 11:18:48 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m45IIlx25529; Mon, 5 May 2008 11:18:47 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m45IH4qb042624; Mon, 5 May 2008 18:17:04 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805051817.m45IH4qb042624@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080505174822.GA28813@elstar.local> Date: Mon, 05 May 2008 14:17:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2008 18:18:48.0470 (UTC) FILETIME=[7687AB60:01C8AEDC] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >> This requires the reader of "foo_v35" to thread their way back thru >> the 34 earlier versions. >I don't get this; please explain. grouping foo { leaf f1; } grouping foo_v2 { uses foo; leaf f2; } grouping foo_v3 { uses foo_v2; leaf f3; } ... grouping foo_v35 { uses foo_v34; leaf f35; } So to understand what's in foo_v35 takes some legwork. You need to follow the path of uses and grouping and ferret out what's in the final foo_v35. Even this assumes a linear parentage, which isn't possible, if, say, foo_v20 wants to deprecate f2 from foo_v2. But more importantly, this view is giving you the history of the module, rather than what the current module contents are. The reviewer needs to see the current model, not the strung out "foo"s of ancient versions. They need to understand how the pieces fit together, not neccessarily how they got there. >The point is that "current revision" is pretty meaningless. If we do >versioned imports, the user will have to find the right version of the >module first to look at and only then the search becomes easier. My assumption is that the reviewer will only be reviewing modern stuff, which implies they are importing the modern revision of their imports. >That said, I am sure we will have to deal with groupings that >implementors like to subset. I have some doubts that a standards body >will get all the groupings right such that all details will work for >every implementation equally well (which is a related subject). Perhaps this should be done with refinements? The refinement can set the status to something that tells you I don't want that particular node. Imagine: grouping mine { uses some:standard-grouping { leaf yours { status unimplemented; // cast-off? uninteresting? gone? } } } For those the cast-iron stomachs, imagine using this in an augment to let the app know you have to break the contract of the original module. // I can't set the mtu on a logical unit on a sonet interface. // The hardware simply won't allow it. augment /if:interfaces/if:interface:/if:unit { when "if:type == 'sonet'"; leaf mtu { status ignored; } } Yeah, pretty gross.... Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:21:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27F03A6866; Mon, 5 May 2008 11:21:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CC83A6E6D for ; Mon, 5 May 2008 11:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfe9IBt3ln1O for ; Mon, 5 May 2008 11:21:35 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 22D4A3A6AB7 for ; Mon, 5 May 2008 11:21:35 -0700 (PDT) Received: (qmail 34365 invoked from network); 5 May 2008 18:21:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 5 May 2008 18:21:32 -0000 X-YMail-OSG: JOLDx2AVM1kOTWwFqN9iX3fFK249ZKT1QrE3q7o0Mr2f.bPvtawKEZIQ8jkcLfJnilm12y9KG.geTtsrnFZJNF.eJb8sVB6TXmyf6fAfC5Spoja4QDG7Ul2C3jGI1.LQlM4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481F5075.9010607@andybierman.com> Date: Mon, 05 May 2008 11:22:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20080505154604.GF28170@elstar.local> <200805051658.m45GwecZ041894@idle.juniper.net> <20080505174822.GA28813@elstar.local> In-Reply-To: <20080505174822.GA28813@elstar.local> Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, May 05, 2008 at 12:58:40PM -0400, Phil Shafer wrote: > >>> Probably encoding a version number into the name of a grouping, that >>> is introducing versioned identifiers, is actually not such a bad >>> idea. >> This requires the reader of "foo_v35" to thread their way back thru >> the 34 earlier versions. > > I don't get this; please explain. > >> We trade benefits for "readers that want to understand the history >> of all revisions of this module" against "reader who want to >> understand the current revision of this module". The former can >> look at previous revisions, resorting to tools if needed to view the >> history. And the latter can use a tool to display the outcome of >> merging the various groupings together. But which reader do we want >> to optimize for? > > The point is that "current revision" is pretty meaningless. If we do > versioned imports, the user will have to find the right version of the > module first to look at and only then the search becomes easier. The > question boils down to whether it is > > a) easier to search for the right version of a definition in a > single module or > > b) easier to find the right version of the module to find the > right definition. > > Furthermore, if I cut'n'paste an example to an IETF mailing list, a > vendor bug tracker, a news forum etc., I have the feeling that > > uses foo:foo_v35; > > or > > grouping foo_v35 { > // ... > } Thanks for pointing out that you can just create a new grouping, which has a different name. This seems like the right thing to do if any of the older versions are still in use. A strict rule, but it works: * Once a grouping is published, it can never be changed, except to change the status from current to deprecated, then to obsolete. grouping foo_v35 { uses foo_v34; container yet-another-cool-feature { ... } } I think that the module with the grouping needs to specify which versions are still current, deprecated, or obsolete. When a new module is created, it will normally use the latest version. Deployed modules which use 'foo' can be updated as needed, but the compiler must indicate if the version is not current. It would be better if every 'uses foo' in the same module was the exact same version of foo. Is this important or just nice-to-have? It would be better if there was a way to indicate the grouping was version-sensitive, or if it is okay to always use the latest\ version. It would be better if the YANG data constructs were simple, and the conformance gunk at the end was complicated, rather than making the data complicated. > > is actually easier for me to track since I do not need to maintain an > implicit version context established by the import clauses (and which > people likely leave out). > > That said, I am sure we will have to deal with groupings that > implementors like to subset. I have some doubts that a standards body > will get all the groupings right such that all details will work for > every implementation equally well (which is a related subject). > > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:33:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521E228C306; Mon, 5 May 2008 11:33:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A490428C0E2 for ; Mon, 5 May 2008 11:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1POUl1uF+mzj for ; Mon, 5 May 2008 11:33:31 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 3D4653A6935 for ; Mon, 5 May 2008 11:32:36 -0700 (PDT) Received: (qmail 84906 invoked from network); 5 May 2008 18:32:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 5 May 2008 18:32:33 -0000 X-YMail-OSG: _AfBG3oVM1kbtyYK8vml1vt.HCMCYWLzYcl_rs8yfK887id3l1ptDSGxKlD7gEohKh1OPd_tnJcPybMiHeUx4GXUje0z__frY8MzyC4xjx3NVoRh2gaWJWsEE7cuZAzZN8mfvx4.HBZ2SAgZGNn0S4G4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <481F530B.4050600@andybierman.com> Date: Mon, 05 May 2008 11:33:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David Harrington References: <481CD6DB.9040502@andybierman.com> <20080503.235707.162032006.mbj@tail-f.com><481CF2B0.9000707@andybierman.com> <481CF792.1070209@andybierman.com> <020b01c8aeda$d1920390$0600a8c0@china.huawei.com> In-Reply-To: <020b01c8aeda$d1920390$0600a8c0@china.huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Harrington wrote: > Hi, > > I never asked for agent-variance, nor has anybody else. > Scratch it off the list then ;-) > My concern is that Netconf is adding support for schema discovery, and > for imports of sub=schemas that could change, and it is unclear what > rules must be followed in reporting what schemas are supported. > The problem is that "uses foo:someGrouping;" is not static. We want module bar, version 2008-05-05 to have the same contents, no matter when it is compiled. That is not true in YANG. If 'someGrouping' changes in module foo over time, then each recompile of cast-in-stone "foo, version 2008-05-05" will be different. IMO, this is somewhat broken. What does it mean to advertise that your agent supports "foo, version 2008-05-05" if the actual contents of foo may depend on some arbitrary subset of all other module versions advertised? Andy > If my agent says during schema discovery that it supports the FOO > module, what does that mean? What if I actually implement one object > froma a large module. My agent is obviously not compliant; does this > mean I should not report this schema during discovery? > > The point came up when talking about versiuoning and the > all-or-nothing compliance to a module. In many cases, as we know from > SMI experience, a module definition may contain more objects than it > makes sense to support by an implementation. This is known to be true > for monitoring purposes, and likely to be common in the case of > configuration data (I cannot help but think of the IPSec Policy MIBs). > Often a WG will define a standard module that contains a bunch of > tables, some of which model functionality that is optional in the > underlying technology, or really cannot be used to model a vendor's > actual implementation. Vendors often "cherry-pick" MIB modules to > support the objects they consider important, and ignore those they > consider unimportant. > > This raises two questions: > 1) whether we should allow for some types of partial compliance to > support underlying optional functionality, and > 2) if an agent only partially supports a module standard, what should > it report during schema discovery? > > Support for multiple compliace clauses in standard MIBs was added > based on operational experience. If partial compliance is not allowed, > then should we (try to) ensure that all modules are broken down into > small enough chunks that full compliance is likely in the real world, > or do we make compliance so hard to achieve in real world > implementations that any "full compliance" edict effectively becomes > meaningless? > > Schema discovery is in the process of being defined. Is there any > implication for an agent reporting a module during discovery that the > agent is fully compliant? If that is not the case, then I think the > schema discovery capability needs to be very clear that no such > assumption should be made by the querying application. This implies > that using the reported schema to validate data might prove > inaccurate. Are there any clearly defined rules about when a schema > should or should not be reported in schema discovery, and does NETMOD > need to provide anything to support those rules? > > dbh > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Saturday, May 03, 2008 7:39 PM >> To: Martin Bjorklund >> Cc: netmod@ietf.org >> Subject: Re: [netmod] module conformance vs. agent-variance >> >> Andy Bierman wrote: >>> Martin Bjorklund wrote: >>> .. >>> By the time these minor features are fully documented, >>> inter-operable, and able to pass IESG inspection, >>> half the language could be done. >>> >> IMO, it would be better to start off simple with >> minor features like import and conformance, rather >> than spend a long time designing something by committee. >> >> That would mean, for the current issues: >> >> -- you can only import the latest version of the module >> >> -- there is no concept of a partial conformance level. >> Capabilities can be defined outside the language. >> Conditions based on capabilities can be mentioned in > description >> clauses. (This is what NETCONF has now.) >> >> -- there is no documentation of agent variance. >> >> >> To be fair, these features were not added on Day One of SMI either. >> >> We probably need to consider conformance to an XML namespace >> as well as module conformance. Is there a difference? >> We probably need to consider augments, groupings, choices, >> and deep tables when designing conformance and variance >> mechanisms for NETCONF/YANG. >> >> I think the design team got it right by leaving >> these items off the feature list in the first place. >> >> >> Andy >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:33:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8B33A68A9; Mon, 5 May 2008 11:33:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84F03A6EA1 for ; Mon, 5 May 2008 11:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOMqvuxBH5ki for ; Mon, 5 May 2008 11:33:31 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 16C4728C377 for ; Mon, 5 May 2008 11:32:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XNcyH5/UgVrqDDFL1qqi1wSpHXauTPxoFQLIUL5vQgpDdn5J+/qjduWMBl/8LArq; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.42] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jt5Tx-0005St-Nt for netmod@ietf.org; Mon, 05 May 2008 14:32:14 -0400 Message-ID: <009101c8aed5$fdf63fa0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080505154604.GF28170@elstar.local> <200805051658.m45GwecZ041894@idle.juniper.net><20080505174822.GA28813@elstar.local> <481F5075.9010607@andybierman.com> Date: Mon, 5 May 2008 11:32:27 -0600 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3781ab27c63504db8cb12b97d02d4eeb5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.42 Subject: [netmod] current, deprecated & obsolete X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Phil Shafer" ; "Martin Bjorklund" ; > Sent: Monday, May 05, 2008 12:22 PM > Subject: Re: [netmod] YANG conformance-stmt (corrected) ... > Thanks for pointing out that you can just create a new grouping, > which has a different name. This seems like the right thing to do > if any of the older versions are still in use. > > A strict rule, but it works: > > * Once a grouping is published, it can never be changed, except > to change the status from current to deprecated, then to obsolete. > > grouping foo_v35 { > uses foo_v34; > container yet-another-cool-feature { ... } > } > > I think that the module with the grouping needs to specify which > versions are still current, deprecated, or obsolete. ... It seems to me that the "current, deprecated, or obsolete" designation really belongs in the conformance material, rather than attached to the grouping. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:38:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1914E28C2B0; Mon, 5 May 2008 11:38:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D2C28C1E3 for ; Mon, 5 May 2008 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRMP7O6tcR05 for ; Mon, 5 May 2008 11:38:01 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id D2B0A28C127 for ; Mon, 5 May 2008 11:36:20 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA01.westchester.pa.mail.comcast.net with comcast id MqkU1Z0070xGWP8510Bs00; Mon, 05 May 2008 18:36:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.westchester.pa.mail.comcast.net with comcast id MucH1Z00M4HwxpC3Y00000; Mon, 05 May 2008 18:36:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=48vgC7mUAAAA:8 a=ochBs1NdiNJ1kpNZIXAA:9 a=7_JwJrJ-yUBMKXjx2YgA:7 a=kxd3NPDmmAHpTAtrVVZLRScJtJUA:4 a=lZB815dzVvQA:10 a=86L1PGDMzkIA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Andy Bierman'" , "'Martin Bjorklund'" References: <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> <20080505.155635.37289612.mbj@tail-f.com> <481F26F4.7000102@andybierman.com> Date: Mon, 5 May 2008 14:36:17 -0400 Message-ID: <020d01c8aede$e85bc440$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <481F26F4.7000102@andybierman.com> Thread-Index: AciuxDJAOGot7NK9R4KdpF768rxEGAAGmXCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, SNMP and SMI have lots of CLRs, but the change control rules in SMI are not "crappy little" ones; they are critical to interoperability. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, May 05, 2008 11:26 AM > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG conformance-stmt (corrected) > > Martin Bjorklund wrote: > > Hi, > > > > Wes Hardaker wrote: > >> I think the critical things (in my mind) are that: > >> > > > We are in new uncharted territory wrt/ backward compatibility. > SMIv2 has strict rules (CLRs) for some important reasons. > One of them is the need to control the interactions between > modules. We never want the 'protocol contents' of a module > to magically change because other modules have changed. > > In SMIv2, only data types and external columns used in > INDEX clauses can be changed in this manner. TCs can > only be changed in specific ways to maintain backward compatibility. > > In YANG, the uses-stmt can cause new nodes to show up. > Augment doesn't matter. The new nodes are really in the > original module's namespace, so this is not really a change > to the augmented module. > > There MUST be some mechanism in YANG (either conformance or inline) > to 'lock down' the contents of such a uses-stmt, so it is unambiguous > which version of the grouping (from another module) is being used. > > > Andy > > >> 1) Modules are backwards compatible. > > [...] > >> If modules are backwards compatible then you don't > >> need to worry about specifying and exact version. > > > > This has been our assumption as well. The problem is > 'groupings', and > > what constitues a backwards compatible modification in a grouping. > > > > module a { > > revision 2008-05-01; > > grouping foo { > > leaf y { ... } > > } > > } > > > > module b { > > revision 2008-05-02; > > import a; > > > > container x { > > uses a:foo; > > } > > } > > > > Now, b has the structure > > > > > > ... > > > > > > If a new leaf 'z' is added to the grouping foo in an > updated version of > > module a, the structure of b magically becomes: > > > > > > ... > > ... > > > > > > even though b hasn't been updated. > > > > So the conclusion is that adding structure to a (exported) > grouping is > > not allowed. But this might be too restrictive, and would force > > people to encode a version number in the grouping name: > > > > module a { > > revision 2008-05-08; > > grouping foo { > > leaf y { ... } > > } > > grouping foo2 { > > uses foo; > > leaf z { ... } > > } > > } > > > > Although the versioning rules of YANG are not spelled out yet in the > > draft, this is the current situation. One solution is the versioned > > import. > > > > > >> 2) You probably do need a minimum conformance level > though, especially > >> if you want to blindly import a particular subtree > within a module > >> and not specify each leaf node. (specifying each leaf node was > >> required in SMIv2 and the imports clause became > potentially large if > >> you needed a lot of pieces from the imported MIB). > >> > >> The solution to #2 is specifying a method to import > portions from the > >> other module that "is at least greater than or equal to version X". > >> > >> import A { > >> at-least-revision 2008-05-01; > >> } > > > > Has this been a problem in SMI? If I IMPORT ifAlias from > IF-MIB, and > > someone tries to use this togther with an old version of > the IF-MIB it > > won't work. > > > > > > > > > > /martin > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:38:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540D33A6952; Mon, 5 May 2008 11:38:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CC728C345 for ; Mon, 5 May 2008 11:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpoZXATlkfEX for ; Mon, 5 May 2008 11:38:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1432328C35A for ; Mon, 5 May 2008 11:36:29 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8653DC001F; Mon, 5 May 2008 20:36:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jRvsTRJoShd8; Mon, 5 May 2008 20:36:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E79A1C0020; Mon, 5 May 2008 20:36:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6355F570F74; Mon, 5 May 2008 20:36:19 +0200 (CEST) Date: Mon, 5 May 2008 20:36:19 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080505183619.GA28900@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20080505174822.GA28813@elstar.local> <200805051817.m45IH4qb042624@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200805051817.m45IH4qb042624@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, May 05, 2008 at 02:17:03PM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >> This requires the reader of "foo_v35" to thread their way back thru > >> the 34 earlier versions. > >I don't get this; please explain. > > grouping foo { > leaf f1; > } > > grouping foo_v2 { > uses foo; > leaf f2; > } > > grouping foo_v3 { > uses foo_v2; > leaf f3; > } > ... > grouping foo_v35 { > uses foo_v34; > leaf f35; > } > > So to understand what's in foo_v35 takes some legwork. You need > to follow the path of uses and grouping and ferret out what's in > the final foo_v35. > > Even this assumes a linear parentage, which isn't possible, if, say, > foo_v20 wants to deprecate f2 from foo_v2. > > But more importantly, this view is giving you the history of the > module, rather than what the current module contents are. The > reviewer needs to see the current model, not the strung out > "foo"s of ancient versions. They need to understand how the > pieces fit together, not neccessarily how they got there. Yes, if I decide to do things this way. But I might also decide to simply spell out foo_v35 in all its detail as a service to the reader. I can do as I see fit. I guess one of the problems we are facing here is that we do not really know (at least I don't) whether at the end 90% of our definitions will be just groupings or whether groupings will account for just some 10-20% of our definitions. And I don't know what I should expect to be the average size of groupings. So making trade off decisions is difficult; is there a way to phase this so that we do not have to decide now and defer a decision to a point where we are sure we better understand the trade-offs? > >The point is that "current revision" is pretty meaningless. If we do > >versioned imports, the user will have to find the right version of the > >module first to look at and only then the search becomes easier. > > My assumption is that the reviewer will only be reviewing modern > stuff, which implies they are importing the modern revision of > their imports. Perhaps true for a reviewer. For someone having to deal with concrete devices, you likely have to deal with all revisions that were ever produced of a popular module. While this might be OK for IETF modules since the IETF speed works as a natural barrier, it seems that having to deal with many different versions of vendor modules can become an interesting exercise for the reader. > Perhaps this should be done with refinements? The refinement > can set the status to something that tells you I don't want > that particular node. Imagine: > > grouping mine { > uses some:standard-grouping { > leaf yours { > status unimplemented; // cast-off? uninteresting? gone? > } > } > } > > For those the cast-iron stomachs, imagine using this in an augment > to let the app know you have to break the contract of the original > module. > > // I can't set the mtu on a logical unit on a sonet interface. > // The hardware simply won't allow it. > augment /if:interfaces/if:interface:/if:unit { > when "if:type == 'sonet'"; > leaf mtu { > status ignored; > } > } > > Yeah, pretty gross.... But we should not overload "status" with this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:38:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8FA28C254; Mon, 5 May 2008 11:38:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A884C3A6935 for ; Mon, 5 May 2008 11:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5n1B4S3WWsh for ; Mon, 5 May 2008 11:38:03 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 6D1FB28C0E2 for ; Mon, 5 May 2008 11:37:24 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 839B02F2FB9; Mon, 5 May 2008 11:35:22 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=dJM4tHGqa8zQFm3xLcYA6N9WJtE=; b=EXmAtj+vjRMwYbExRcY9Gsph+pShg0AkQep80+Z/zyLq85tLXAutBP+RUJc2tI1aCLtNvEkG4WyvFvzCsiDZvZJ9PMTSof6f/+oGeOEE0+t/0u4k8sSeT7bKqF5AGEJmYQOuD7tJ3fEBuldMo8nXHB84mNkwmsTsaKdKpn1zTmc= Received: by wes.hardakers.net (Postfix, from userid 274) id 59DC32F2FB6; Mon, 5 May 2008 11:35:22 -0700 (PDT) From: Wes Hardaker To: Phil Shafer Organization: Sparta References: <200805051817.m45IH4qb042624@idle.juniper.net> Date: Mon, 05 May 2008 11:35:22 -0700 In-Reply-To: <200805051817.m45IH4qb042624@idle.juniper.net> (Phil Shafer's message of "Mon, 05 May 2008 14:17:03 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org >>>>> On Mon, 05 May 2008 14:17:03 -0400, Phil Shafer said: PS> grouping foo { PS> leaf f1; PS> } PS> grouping foo_v2 { PS> uses foo; PS> leaf f2; PS> } If this type of thing is going to be common wouldn't it make more sense to make the language account for the need to do versioned groupings to make writing them (and reading them) easier? grouping foo 1 { leaf f1; leaf f2; } grouping foo 2 { leaf f3; obsolete f2; } ... Obviously 1 and 2 could use the date specification form of versioning that are already becoming standard for module revisions? Consistency in the spec would make sense. You could also move the versioning to inside the grouping, though I'm not sure I like it as much. I haven't decided: grouping foo { leaf 1: f1; # no obsolete point yet leaf 1:1 f2; # obsoletes after 1 leaf 2: f3; # created in version 2 } Or something like that. -- Wes Hardaker Sparta, Inc. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:41:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018893A6C86; Mon, 5 May 2008 11:41:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E953A6AD1 for ; Mon, 5 May 2008 11:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuCkfKGAJKDk for ; Mon, 5 May 2008 11:41:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1A8003A6952 for ; Mon, 5 May 2008 11:41:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E216C0024; Mon, 5 May 2008 20:41:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ULygtHqA8MHg; Mon, 5 May 2008 20:40:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76BD8C0014; Mon, 5 May 2008 20:41:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EB0BA570FE1; Mon, 5 May 2008 20:40:53 +0200 (CEST) Date: Mon, 5 May 2008 20:40:53 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080505184053.GB28900@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20080505154604.GF28170@elstar.local> <481F5075.9010607@andybierman.com> <009101c8aed5$fdf63fa0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <009101c8aed5$fdf63fa0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] current, deprecated & obsolete X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, May 05, 2008 at 11:32:27AM -0600, Randy Presuhn wrote: > > > > I think that the module with the grouping needs to specify which > > versions are still current, deprecated, or obsolete. > ... > > It seems to me that the "current, deprecated, or obsolete" designation > really belongs in the conformance material, rather than attached to > the grouping. Why? Status tells me something about the status of the definition, whether I can still safely use it or not. So it is a property of the definition itself. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:52:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EBC3A6866; Mon, 5 May 2008 11:52:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9823D3A69AE for ; Mon, 5 May 2008 11:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcHdrtR-sSsn for ; Mon, 5 May 2008 11:52:46 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 559943A6866 for ; Mon, 5 May 2008 11:52:46 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA03.westchester.pa.mail.comcast.net with comcast id MqUv1Z00F0Fqzac530Lt00; Mon, 05 May 2008 18:52:42 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id Musk1Z0014HwxpC3U00000; Mon, 05 May 2008 18:52:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=70xT8PM6QifmlMW9jl4A:9 a=CKRvYeQuZFz6L8QNI9cA:7 a=aYmesbxEfbmSA8yKXNNQROETJhEA:4 a=ucw2XimmUOMA:10 a=lZB815dzVvQA:10 a=gi0PWCVxevcA:10 From: "David Harrington" To: "'Andy Bierman'" , "'Wes Hardaker'" References: <481B2EE7.5040209@andybierman.com> <200805021520.m42FKHdh016860@idle.juniper.net> <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> <481F2DA7.7050505@andybierman.com> Date: Mon, 5 May 2008 14:52:44 -0400 Message-ID: <021401c8aee1$34356bd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <481F2DA7.7050505@andybierman.com> Thread-Index: AciuyCgg2HLbIHkqSouDFXRhxy+e0gAF0i0w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I think one thing we need to consdier is what tools ar egoing to use YAG modules. In large SNMP-based NMS systems like OpenView or Spectrum, the parsing of MIB modules is a tiny piece of the application. The MIB modules are parsed into application databases, and the assumptions of backwards compatibility of MIB modules that are found in SMI are embedded deep within the application code. I have very strong doubts that there will be a whole new generation of YANG-specific tools. If we make th etransition a reasonably cost-effective thing to do, then the existing tools will be updated to support YANG. If we change the basic assumptions of backwards compatibility, then we make it economically difficult to get vendors to update NMS applications. SNMPv3 proved that changing some of the fundamental concepts means NMS application vendors simply do not make the transition. We should try tio make sure we follow similar rules for backwards compatibility. I think this means we need to explicitly list the leaf nodes (etc.) that will be imported, either in IMPORT statements or in compliance clauses; I am not sure which will be more read-friendly; obviously only having to list them in one place makes it more write-friendly. dbh > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Monday, May 05, 2008 11:54 AM > To: Wes Hardaker > Cc: David Harrington; netmod@ietf.org > Subject: Re: [netmod] YANG conformance-stmt (corrected) > > Wes Hardaker wrote: > >>>>>> On Fri, 02 May 2008 11:51:48 -0700, Andy Bierman > said: > > > > AB> I don't mind the restriction that the importing module > > AB> must accept everything in the module for the revision specified. > > > > I think the critical things (in my mind) are that: > > > > 1) Modules are backwards compatible. If this isn't the > case then either > > we'd allow the tree structure to change in semantics without > > re-wording the leaf names which, IMHO, is a recipe for > problems or we > > stop publishing tree components that are "obsolete" (like the > > IF-FORWARD-MIB continuing to contain the ipForwardTable > even though > > it's obsolete). If modules are backwards compatible > then you don't > > need to worry about specifying and exact version. > > > > 2) You probably do need a minimum conformance level though, > especially > > if you want to blindly import a particular subtree > within a module > > and not specify each leaf node. (specifying each leaf node was > > required in SMIv2 and the imports clause became > potentially large if > > you needed a lot of pieces from the imported MIB). > > > > The solution to #2 is specifying a method to import > portions from the > > other module that "is at least greater than or equal to version X". > > > > import A { > > at-least-revision 2008-05-01; > > } > > > > This doesn't really help the 'changing uses-stmt' problem. > If a grouping in module 'A' adds new columns each version, > it is still not clear to a manager which version of the grouping > is expected for a particular uses-stmt in the module importing 'A'. > > The problem with "import exact version" and "import version range" > is that the upper bound on the version is artificial. Module 'A' > will be updated for something that has nothing to do with the > grouping, > and modules that import A will 'break' according to the rules. > Every one of these modules needs to be updated as well, reflecting > the new version of 'A'. Worst of all, implementations will be forced > to maintain several versions of each module. Implementers and > operators accustomed to only referring to the most recent > documentation > might not appreciate this 'feature' of YANG. > > IMO, none of the proposed solutions actually works, except my > conformance proposal (or any proposal which requires the leafs > in the module namespace to be explicitly listed for each > module version). > > I like the conformance approach better because it more precise. > I want to say "Subtree /foo/bar/A" is from version 2008-05-05 of > module A. That is a much finer-grained tool than saying "I want to > import version 2008-0505 of module A". > > > > > Would be a safe way, if modules must be backwards > compatible, to reduce > > the number of loaded module As on this system to 1 (which > had to be of a > > revision greater than the maximum specified). > > > > The downside, of course, to never allowing a subtree section to > > disappear from a module is module growth. You could solve > that too by > > allowing a double import though (A imports something from B > but B has > > outsourced it (now) to B-archive but the import from A to B > will still work). > > > > > > Andy > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:53:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395BE28C197; Mon, 5 May 2008 11:53:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF0D28C306 for ; Mon, 5 May 2008 11:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAIRepExYwax for ; Mon, 5 May 2008 11:53:11 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 9A6D328C1E3 for ; Mon, 5 May 2008 11:53:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UOjlj/9IzmqYwZViUJtPWIcAdwgflL36p9qqgbp3Y4XJXoAnYg0TtgOFu6Qxlf2y; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.42] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jt5oC-0003fT-A0 for netmod@ietf.org; Mon, 05 May 2008 14:53:08 -0400 Message-ID: <00c001c8aed8$e9cc2be0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080505154604.GF28170@elstar.local> <481F5075.9010607@andybierman.com> <009101c8aed5$fdf63fa0$6801a8c0@oemcomputer> <20080505184053.GB28900@elstar.local> Date: Mon, 5 May 2008 11:53:22 -0600 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3d1a3a2fe8eb56e64c8a4ed1bc15533f9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.42 Subject: Re: [netmod] current, deprecated & obsolete X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Monday, May 05, 2008 12:40 PM > Subject: Re: [netmod] current, deprecated & obsolete > > On Mon, May 05, 2008 at 11:32:27AM -0600, Randy Presuhn wrote: > > > > > > I think that the module with the grouping needs to specify which > > > versions are still current, deprecated, or obsolete. > > ... > > > > It seems to me that the "current, deprecated, or obsolete" designation > > really belongs in the conformance material, rather than attached to > > the grouping. > > Why? Status tells me something about the status of the definition, > whether I can still safely use it or not. So it is a property of > the definition itself. Only if by "use" you mean "implement in new software". For purposes of communicating with deployed gear, it's meaningless. If a box implements a particular knob, and not its more recent replacement, then managing that box means working with that knob, regardless of how obsolete it is. That's why I think it makes more sense to think about it in terms of conformance to a particular version of a specification, rather than as an intrinsic property of that particular bit of the data model. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:54:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B679A3A6B94; Mon, 5 May 2008 11:54:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5B73A6B94 for ; Mon, 5 May 2008 11:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7NF2P7OQLVo for ; Mon, 5 May 2008 11:54:11 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 9E9B628C268 for ; Mon, 5 May 2008 11:54:06 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 05 May 2008 11:54:05 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 11:53:33 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m45IrWx37935; Mon, 5 May 2008 11:53:32 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m45IpnWJ043142; Mon, 5 May 2008 18:51:49 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805051851.m45IpnWJ043142@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080505183619.GA28900@elstar.local> Date: Mon, 05 May 2008 14:51:48 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2008 18:53:33.0046 (UTC) FILETIME=[5108B960:01C8AEE1] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >So making trade off decisions is difficult; is there a way to phase >this so that we do not have to decide now and defer a decision to a >point where we are sure we better understand the trade-offs? Sure, we go with what YANG does now. The import statement imports the current revision and you are left to your own wits to make it work. >While this might be OK for IETF modules >since the IETF speed works as a natural barrier, it seems that having >to deal with many different versions of vendor modules can become an >interesting exercise for the reader. My guess is that vendors will choose between two strategies: - one revision per release (1r/r) - one module per release (1m/r) 1r/r gives you the ability to define one "JUNOS" module that you update each release. Since devices only run one version of software, the device announces "JUNOS?rev=2008-04-01", where the revision is the release date of the software version. This will work with one release train, but vendors need to support multiple trains, one for each release of software. 1m/r gives you a "JUNOS-9.1" module that you update only as "point" releases of 9.1 are published ("9.1R1", "9.1R2"). For us, these modules will be generated from our existing DDL, until we switch to using YANG internally. Trying to auto-generate "foo_v2"-style groupings will be a pain. Even when using YANG-based tools internally, I don't think I want developers too stare at this history-based threading. I just want them to see the current views of the current module. Adding a leaf to a grouping should be a one-line fix, not something that requires adding a grouping, using the old grouping, add the leaf, and then updating every user of that grouping. Also interesting is the ability of third-party on-device application writers using our SDK to import the modules that are specific to the release of JUNOS they are running. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 11:55:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA33A3A6866; Mon, 5 May 2008 11:55:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366253A6866 for ; Mon, 5 May 2008 11:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JdoTYM6SR5h for ; Mon, 5 May 2008 11:55:48 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5602A3A6E30 for ; Mon, 5 May 2008 11:55:48 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 75211D800C7 for ; Mon, 5 May 2008 20:55:46 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080505144053.GD28170@elstar.local> References: <00ce01c8ac83$77417190$0600a8c0@china.huawei.com> <481B62C4.70000@andybierman.com> <20080505.155635.37289612.mbj@tail-f.com> <20080505144053.GD28170@elstar.local> Organization: CESNET Date: Mon, 05 May 2008 20:55:47 +0200 Message-Id: <1210013747.6928.20.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFBvIDA1LiAwNS4gMjAwOCB2IDE2OjQwICsw MjAwOgoKPiBUaGUgYWx0ZXJuYXRpdmUgaXMgdG8gYmUgZXhwbGljaXQgaWYgeW91IHVzZSBhIGdy b3VwaW5nIHdoYXQgeW91IHVzZS4KPiBUaGlzIGlzIHdoYXQgd2UgZW5kZWQgdXAgd2l0aCB3aGVu IHdlIGRpZCBTTUluZyBpbiB0aGUgTk1SRyAoSSBhbSBub3QKPiBzYXlpbmcgdGhpcyBpcyB0aGUg c29sdXRpb24gYnV0IGF0IGxlYXN0IG9uZSBzb2x1dGlvbiB0byBjb25zaWRlcikuCgpSaWdodCwg SSB0aGluayBmb3IgdGhlIHB1cnBvc2Ugb2YgcmV1c2luZyBwcmUtYmFrZWQgZ3JvdXBpbmdzIGFu ZAp0eXBlZGVmcyBpdCBzaG91bGQgYmUgc3VmZmljaWVudCB0byBpbXBvcnQgYW4gZXhhY3QgdmVy c2lvbiBvZiBhIGZvcmVpZ24KbW9kdWxlIGFuZCBJIHdvdWxkIHN1Z2dlc3QKCmltcG9ydCBVUkk/ cmV2aXNpb247CgpJIGltYWdpbmUgYSBtb2R1bGUgYXV0aG9yIHByZXR0eSBtdWNoIGFsd2F5cyB3 YW50cyB0byBjb250cm9sIHdoYXQgaXMKaW1wb3J0ZWQgYW5kIHRoZXJlZm9yZSBjYW4gY2hvb3Nl IGFuIGV4YWN0IHZlcnNpb24gb2YgdGhlIGZvcmVpZ24KbW9kdWxlLgoKQ2hhbmdpbmcgdGhlIGlt cG9ydCBzdGF0ZW1lbnQgYXMgYWJvdmUgd291bGQgbm90IHdvcmsgc28gd2VsbCBmb3IgdGhlCm90 aGVyIGV4dGVuc2lvbiBtZWNoYW5pc20sIG5hbWVseSBhdWdtZW50aW5nIHRoZSBmb3JlaWduIG1v ZHVsZSB2aWEKYXVnbWVudC1zdG10IHdpdGggYWJzb2x1dGUgYXJndW1lbnQgc2luY2UgdGhpcyBp cyBwcm9iYWJseSBzdXBwb3NlZCB0bwp3b3JrIGFsc28gZm9yIGZ1dHVyZSB2ZXJzaW9ucyBvZiB0 aGUgZm9yZWlnbiBtb2R1bGUuCgpBIHNvbHV0aW9uIGNvdWxkIGJlIHRvIHNlcGFyYXRlIHRoZSB0 d28gZXh0ZW5zaW9uIG1lY2hhbmlzbXM6CgoxLiBVc2UgaW1wb3J0IHdpdGggYW4gVVJJIGFuZCBy ZXZpc2lvbiByZWFsbHkgZm9yIGltcG9ydGluZyB2ZXJ5CnNwZWNpZmljIGZvcmVpZ24gZ3JvdXBp bmdzIGFuZCB0eXBlZGVmcyBmb3IgcmV1c2UgaW4gdGhlIGxvY2FsIG1vZHVsZS4KCjIuIERldmlz ZSBhIG5ldyBzdGF0ZW1lbnQgZm9yIHRoZSBmdW5jdGlvbiBvZiBhdWdtZW50aW5nIHRoZSBmb3Jl aWduCm1vZHVsZSwgZm9yIGV4YW1wbGUKCiAgICBtb2RpZnkgPG1vZHVsZSBuYW1lPiB7CiAgICAg ICAgYXBwZW5kIDxhYnMtcGF0aD4gewogICAgICAgICAgICAuLi4KICAgICAgICB9CiAgICAgICAg Li4uCiAgICB9CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDog RTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon May 5 12:09:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A005D3A68CC; Mon, 5 May 2008 12:09:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D378E3A68DE for ; Mon, 5 May 2008 12:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF5KL35i1D8I for ; Mon, 5 May 2008 12:09:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A9AC73A68CC for ; Mon, 5 May 2008 12:09:39 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E80EC0019; Mon, 5 May 2008 21:09:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z0-24cJMzMTP; Mon, 5 May 2008 21:09:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0757C0014; Mon, 5 May 2008 21:09:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5122C571163; Mon, 5 May 2008 21:09:32 +0200 (CEST) Date: Mon, 5 May 2008 21:09:32 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080505190932.GA28983@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20080505154604.GF28170@elstar.local> <481F5075.9010607@andybierman.com> <009101c8aed5$fdf63fa0$6801a8c0@oemcomputer> <20080505184053.GB28900@elstar.local> <00c001c8aed8$e9cc2be0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <00c001c8aed8$e9cc2be0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] current, deprecated & obsolete X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, May 05, 2008 at 11:53:22AM -0600, Randy Presuhn wrote: > Only if by "use" you mean "implement in new software". It is about "implement in new software" and "use in new modules". > For purposes of communicating with deployed gear, it's meaningless. > If a box implements a particular knob, and not its more recent > replacement, then managing that box means working with that knob, > regardless of how obsolete it is. Sure, this is what we do anyway. And the market sometimes even forces new software to implement deprecated or obsolete things. > That's why I think it makes more sense to think about it in terms of > conformance to a particular version of a specification, rather than > as an intrinsic property of that particular bit of the data model. I believe having a status property of all YANG definitions itself is useful, in particular for the "use in new modules" scenario. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 12:13:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06C03A696A; Mon, 5 May 2008 12:12:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01EF3A68CC for ; Mon, 5 May 2008 12:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4jT6-jVNiaq for ; Mon, 5 May 2008 12:12:57 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 2E4333A696A for ; Mon, 5 May 2008 12:11:33 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA01.westchester.pa.mail.comcast.net with comcast id MrBY1Z01Z1GhbT85109w00; Mon, 05 May 2008 19:11:32 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id MvBY1Z00H4HwxpC3T00000; Mon, 05 May 2008 19:11:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZmK9YhMPMsUA:10 a=48vgC7mUAAAA:8 a=UWEtvj8zcDhMrVWRIrsA:9 a=xqFaGWrMGF2-94DbZlAA:7 a=byGwhZ6WMCXzTuhRPUkFS0mnljUA:4 a=lZB815dzVvQA:10 a=Vdgex2DK8hkA:10 From: "David Harrington" To: "'Phil Shafer'" , References: <20080505183619.GA28900@elstar.local> <200805051851.m45IpnWJ043142@idle.juniper.net> Date: Mon, 5 May 2008 15:11:32 -0400 Message-ID: <021501c8aee3$d4a261c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200805051851.m45IpnWJ043142@idle.juniper.net> Thread-Index: Aciu4W42f6beJvkzQzS/quQf9PTpowAAhOhw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org During the World Tour in 2002, operators complained that vendors kept changing the interface in a way that broke their scripts, and they were forced to update their scripts for (potentially) every release from every vendor. Which approach to "uses" and imports minimizes the script churn problem for operators? dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Monday, May 05, 2008 2:52 PM > To: j.schoenwaelder@jacobs-university.de > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG conformance-stmt (corrected) > > Juergen Schoenwaelder writes: > >So making trade off decisions is difficult; is there a way to phase > >this so that we do not have to decide now and defer a decision to a > >point where we are sure we better understand the trade-offs? > > Sure, we go with what YANG does now. The import statement imports > the current revision and you are left to your own wits to make > it work. > > >While this might be OK for IETF modules > >since the IETF speed works as a natural barrier, it seems that having > >to deal with many different versions of vendor modules can become an > >interesting exercise for the reader. > > My guess is that vendors will choose between two strategies: > - one revision per release (1r/r) > - one module per release (1m/r) > > 1r/r gives you the ability to define one "JUNOS" module that you > update each release. Since devices only run one version of software, > the device announces "JUNOS?rev=2008-04-01", where the revision is > the release date of the software version. This will work with one > release train, but vendors need to support multiple trains, one > for each release of software. > > 1m/r gives you a "JUNOS-9.1" module that you update only as "point" > releases of 9.1 are published ("9.1R1", "9.1R2"). > > For us, these modules will be generated from our existing DDL, until > we switch to using YANG internally. Trying to auto-generate > "foo_v2"-style groupings will be a pain. Even when using YANG-based > tools internally, I don't think I want developers too stare at this > history-based threading. I just want them to see the current views > of the current module. Adding a leaf to a grouping should be a > one-line fix, not something that requires adding a grouping, using > the old grouping, add the leaf, and then updating every user of > that grouping. > > Also interesting is the ability of third-party on-device application > writers using our SDK to import the modules that are specific to > the release of JUNOS they are running. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 12:22:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3D43A6A11; Mon, 5 May 2008 12:22:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560BB3A6A11 for ; Mon, 5 May 2008 12:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP-Fpmk7iUvb for ; Mon, 5 May 2008 12:22:30 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 337BB3A6E3D for ; Mon, 5 May 2008 12:22:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=g+gEGBP13YcVn3wdPzbsopCwg3x2+PEF+N4RUW0FUsnsU0ravWXXoNXkGIjKK/hz; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.42] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jt6Ga-0006Zt-PN for netmod@ietf.org; Mon, 05 May 2008 15:22:29 -0400 Message-ID: <00d401c8aedd$03402500$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200805051851.m45IpnWJ043142@idle.juniper.net> Date: Mon, 5 May 2008 12:22:43 -0600 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b352f013d84f57439a5cec9112d528dcd5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.42 Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Phil Shafer" > To: > Cc: > Sent: Monday, May 05, 2008 12:51 PM > Subject: Re: [netmod] YANG conformance-stmt (corrected) ... > Also interesting is the ability of third-party on-device application > writers using our SDK to import the modules that are specific to > the release of JUNOS they are running. ... Perhaps the authors of the "reuse" section in the presentation https://www3.ietf.org/proceedings/08mar/slides/canmod-3/canmod-3.htm could speak up. Their approach is quite different from traditional "inheritance" and the group "imports" that have been getting so much discussion here. My reading of their ideas: Key concepts: - Things that are reusable don't change in any substantive way. - A substantively changed version of any thing is a new thing. - The description of an implementation (version) is assembled largely from a bunch of reusable things, with the addition of whatever peculiar (non-reusable, vendor or implementation- specific) bits are needed Interesting properties: - the "inheritance" hierarchy is *very* shallow - the need for anything like "agent-capabilities" goes away - the need for machine-readable conformance material largely goes away From a modeling / re-use perspective it's rather like going to an "aspect-oriented" approach, allowing one to assemble a product's management interfaces from the various capabilities that the product needs to do its job. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 12:43:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A1B3A68D9; Mon, 5 May 2008 12:43:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3873F3A68D9 for ; Mon, 5 May 2008 12:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgbiE-+ev9zh for ; Mon, 5 May 2008 12:43:43 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 1950F3A6C2C for ; Mon, 5 May 2008 12:43:41 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 05 May 2008 12:43:29 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 12:35:32 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m45JZVx52597; Mon, 5 May 2008 12:35:31 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m45JXmr6043585; Mon, 5 May 2008 19:33:48 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805051933.m45JXmr6043585@idle.juniper.net> To: "David Harrington" In-reply-to: <021501c8aee3$d4a261c0$0600a8c0@china.huawei.com> Date: Mon, 05 May 2008 15:33:48 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2008 19:35:32.0468 (UTC) FILETIME=[2EBA0340:01C8AEE7] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance-stmt (corrected) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "David Harrington" writes: >During the World Tour in 2002, operators complained that vendors kept >changing the interface in a way that broke their scripts, and they >were forced to update their scripts for (potentially) every release >from every vendor. The operators were talking about screen scraping. We call it "Expect Hell". When the output of "show interfaces" changes, the regular expression used in an expect script may no longer match the appropriate information and you get more/less data than required. NETCONF's use of XML is meant to help build scripts that can survive over releases, since well-written XPath expressions don't care about unrelated content. (Yes, there are folks that feel well-written regular expressions can be created to survive over multiple releases, but they are relatively few (scripts and folks)). >Which approach to "uses" and imports minimizes the script churn >problem for operators? The content here is the same. It's a matter of how it's written down in the module. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 14:28:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2CB28C167; Mon, 5 May 2008 14:28:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0DCB28C125 for ; Mon, 5 May 2008 14:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5pw8hpq5xxU for ; Mon, 5 May 2008 14:28:11 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id DF2A43A6B70 for ; Mon, 5 May 2008 14:28:08 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 84BB71B80DC; Mon, 5 May 2008 23:28:06 +0200 (CEST) Date: Mon, 05 May 2008 23:27:56 +0200 (CEST) Message-Id: <20080505.232756.246934398.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <020b01c8aeda$d1920390$0600a8c0@china.huawei.com> References: <481CF2B0.9000707@andybierman.com> <481CF792.1070209@andybierman.com> <020b01c8aeda$d1920390$0600a8c0@china.huawei.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, "David Harrington" wrote: > Hi, > > I never asked for agent-variance, nor has anybody else. > > My concern is that Netconf is adding support for schema discovery, and > for imports of sub=schemas that could change, and it is unclear what > rules must be followed in reporting what schemas are supported. Agreed. > If my agent says during schema discovery that it supports the FOO > module, what does that mean? What if I actually implement one object > froma a large module. My agent is obviously not compliant; does this > mean I should not report this schema during discovery? Isn't what you're asking for here agent variance? > The point came up when talking about versiuoning and the > all-or-nothing compliance to a module. In many cases, as we know from > SMI experience, a module definition may contain more objects than it > makes sense to support by an implementation. This is known to be true > for monitoring purposes, and likely to be common in the case of > configuration data (I cannot help but think of the IPSec Policy MIBs). > Often a WG will define a standard module that contains a bunch of > tables, some of which model functionality that is optional in the > underlying technology, or really cannot be used to model a vendor's > actual implementation. Vendors often "cherry-pick" MIB modules to > support the objects they consider important, and ignore those they > consider unimportant. > > This raises two questions: > 1) whether we should allow for some types of partial compliance to > support underlying optional functionality, and > 2) if an agent only partially supports a module standard, what should > it report during schema discovery? There are two parts to the schema discovery process. One part is the capability list which is already supported in the base NETCONF protocol. The netconf monitoring draft adds a mechanism to find the actual schema files (or YANG module files). The schema list already supports multiple versions, and it might include "type libraries" which are not advertised as separate capabilities. Currently in YANG, w/o any MODULE-COMPLIANCE equivalent, the server advertises, for each module it supports, the capability ?, e.g. http://example.com/foo-module?2008-05-01 With a finer grained MODULE-COMPLIANCE equivalent, the same syntax could be extended: http://example.com/foo-module?revision=2008-05-01&compliance=full But the equivalent of AGENT-CAPABILITIES (if we want to do it) would probably be reported in some other way... > Schema discovery is in the process of being defined. Is there any > implication for an agent reporting a module during discovery that the > agent is fully compliant? If that is not the case, then I think the > schema discovery capability needs to be very clear that no such > assumption should be made by the querying application. This implies > that using the reported schema to validate data might prove > inaccurate. Are there any clearly defined rules about when a schema > should or should not be reported in schema discovery, and does NETMOD > need to provide anything to support those rules? I think NETMOD should provide rules for how YANG modules / capabilities are reported during schema discovery. As long as the schema discovery capability is DML-agnostic it cannot have too specific rules. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 5 15:30:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8894728C370; Mon, 5 May 2008 15:30:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780E128C373 for ; Mon, 5 May 2008 15:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sabk7yjtxHF for ; Mon, 5 May 2008 15:30:34 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 5D98128C371 for ; Mon, 5 May 2008 15:30:34 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA03.westchester.pa.mail.comcast.net with comcast id Ms0Y1Z0090bG4ec530HX00; Mon, 05 May 2008 22:30:29 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id MyWY1Z0044HwxpC3P00000; Mon, 05 May 2008 22:30:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=pD3PcbyhF38A:10 a=FH951aLNgCQA:10 a=A1X0JdhQAAAA:8 a=gOrLGUByTmlxCAPGg18A:9 a=SPbYpEPl0ODVhIX2dikA:7 a=_VfK5IHdnrwIWwgQY6uUhcy31NUA:4 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Martin Bjorklund'" References: <481CF2B0.9000707@andybierman.com><481CF792.1070209@andybierman.com><020b01c8aeda$d1920390$0600a8c0@china.huawei.com> <20080505.232756.246934398.mbj@tail-f.com> Date: Mon, 5 May 2008 18:30:32 -0400 Message-ID: <022101c8aeff$a1723890$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080505.232756.246934398.mbj@tail-f.com> Thread-Index: Aciu9vN4pw0zcSHcRkyQI7VOPYdhiAABZTbw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > > If my agent says during schema discovery that it supports the FOO > > module, what does that mean? What if I actually implement one object > > froma a large module. My agent is obviously not compliant; does this > > mean I should not report this schema during discovery? > > Isn't what you're asking for here agent variance? No. Agent variance in SNMPv3 is a external document (similar to release notes) that **details** all the little variances in your implementation: "The agent supports counter ABC, but the spec says it should have a range of 1..4B and we only support up to 2B. The agent does not support column X and Y in the WXYZ table. The agent does not support the QP4 interface elements, so therefore does not support the QP4 table." and so on. If you report a capability, and that capability is related to a specific data model, and you do not support every element in the data model, can you claim that you support the capability? How much can an NMS application actually rely upon the capability negotiation (or the schema provided) to imply that the whole data model has been implemented? Does the capability advertisement mean a) it absolutely supports everything in the data model, or b) it supports at least part of the data model? > Currently in YANG, w/o any MODULE-COMPLIANCE equivalent, the server > advertises, for each module it supports, the capability > ?, e.g. > > http://example.com/foo-module?2008-05-01 > > With a finer grained MODULE-COMPLIANCE equivalent, the same syntax > could be extended: > > http://example.com/foo-module?revision=2008-05-01&compliance=full > ... > I think NETMOD should provide rules for how YANG modules / > capabilities are reported during schema discovery. As long as the > schema discovery capability is DML-agnostic it cannot have too > specific rules. In SMI, we found it necessary to go to a finer-grained compliance clause than just "full". I don't think a binary "everything or you're not-compliant" rule makes sense given our previous experience. And a binary "everything or you're not-compliant" rule makes no sense if imported groups can change underneath the importing module. I think we need to lock down "uses" and we need to have "protcol-sense" granular compliance clauses. dbh _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 01:07:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10D93A6830; Tue, 6 May 2008 01:07:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4356D3A686D for ; Tue, 6 May 2008 01:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8JHjnsDDejF for ; Tue, 6 May 2008 01:07:29 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id BE1B63A687A for ; Tue, 6 May 2008 01:07:28 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 4626D1B80C4; Tue, 6 May 2008 10:07:26 +0200 (CEST) Date: Tue, 06 May 2008 10:07:38 +0200 (CEST) Message-Id: <20080506.100738.211949705.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <022101c8aeff$a1723890$0600a8c0@china.huawei.com> References: <020b01c8aeda$d1920390$0600a8c0@china.huawei.com> <20080505.232756.246934398.mbj@tail-f.com> <022101c8aeff$a1723890$0600a8c0@china.huawei.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, "David Harrington" wrote: > > > > If my agent says during schema discovery that it supports the FOO > > > module, what does that mean? What if I actually implement one > object > > > froma a large module. My agent is obviously not compliant; does > this > > > mean I should not report this schema during discovery? > > > > Isn't what you're asking for here agent variance? > > No. Agent variance in SNMPv3 is a external document (similar to > release notes) that **details** all the little variances in your > implementation: Yes I know. > "The agent supports counter ABC, but the spec says it should have a > range of 1..4B and we only support up to 2B. > The agent does not support column X and Y in the WXYZ table. > The agent does not support the QP4 interface elements, so therefore > does not support the QP4 table." > and so on. > > If you report a capability, and that capability is related to a > specific data model, and you do not support every element in the data > model, can you claim that you support the capability? > > How much can an NMS application actually rely upon the capability > negotiation (or the schema provided) to imply that the whole data > model has been implemented? Does the capability advertisement mean a) > it absolutely supports everything in the data model, or b) it supports > at least part of the data model? Unless we claim a), isn't some kind of agent variance needed? If we say b then w/o agent variance anyone can claim conformance to anything by implementing some small subset of each capability. That will not help interoperability. > > With a finer grained MODULE-COMPLIANCE equivalent, the same syntax > > could be extended: > > > > http://example.com/foo-module?revision=2008-05-01&compliance=full > > > ... > > I think NETMOD should provide rules for how YANG modules / > > capabilities are reported during schema discovery. As long as the > > schema discovery capability is DML-agnostic it cannot have too > > specific rules. > > In SMI, we found it necessary to go to a finer-grained compliance > clause than just "full". I don't think a binary "everything or you're > not-compliant" rule makes sense given our previous experience. Right. What I meant was something like this: module foo { namespace "http://example.com/foo-module"; revision 2008-05-01; ... compliance basic { ... } compliance feature-x { ... } compliance feature-y { ... } compliance full { ... } } Then a server that conforms to the 'full' compliance would advertise the capability above. > And a binary "everything or you're not-compliant" rule makes no sense > if imported groups can change underneath the importing module. > > I think we need to lock down "uses" Agreed. IMO this is a must (and we have 3-4 proposed solutions). > and we need to have > "protcol-sense" granular compliance clauses. Yes this would be useful. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 08:42:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F50E28C222; Tue, 6 May 2008 08:42:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32823A6DF0 for ; Tue, 6 May 2008 08:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ48I7RShp8q for ; Tue, 6 May 2008 08:42:09 -0700 (PDT) Received: from chip3og50.obsmtp.com (chip3og50.obsmtp.com [64.18.14.165]) by core3.amsl.com (Postfix) with ESMTP id 3364D3A69AF for ; Tue, 6 May 2008 08:42:07 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob50.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 08:42:01 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 08:41:01 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m46Ff0x61897; Tue, 6 May 2008 08:41:00 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m46FdG9T049987; Tue, 6 May 2008 15:39:16 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061539.m46FdG9T049987@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080506.100738.211949705.mbj@tail-f.com> Date: Tue, 06 May 2008 11:39:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 15:41:01.0382 (UTC) FILETIME=[961E6E60:01C8AF8F] Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: > module foo { > namespace "http://example.com/foo-module"; > revision 2008-05-01; > compliance basic { ... } > compliance feature-x { ... } > compliance feature-y { ... } > compliance full { ... } >Then a server that conforms to the 'full' compliance would advertise >the capability above. What about doing this with the when-capability mechanism? "basic" would be the base capability for the module, "x" and "y" would be additional capabilities, and "full" may or may not be needed, if it's just "x + y". Using the "when-capability" statement has the nice effect of keeping the condition with the node being defined, and not having to repeat nodes in a "compliance" statement. module foo { ... capability feature-x { ... } capability feature-y { ... } container ahh { container beh { container say { container day { when-capability feature-x; .... } container night { when-capability feature-y; ... } } } } } Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 10:06:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258C928C22D; Tue, 6 May 2008 10:06:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D053A6F24 for ; Tue, 6 May 2008 10:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKPcz0i20g60 for ; Tue, 6 May 2008 10:06:09 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id BBAC328C495 for ; Tue, 6 May 2008 10:04:20 -0700 (PDT) Received: (qmail 66505 invoked from network); 6 May 2008 17:04:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 6 May 2008 17:04:14 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48208F4D.90909@andybierman.com> Date: Tue, 06 May 2008 10:03:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805061539.m46FdG9T049987@idle.juniper.net> In-Reply-To: <200805061539.m46FdG9T049987@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: >> module foo { >> namespace "http://example.com/foo-module"; >> revision 2008-05-01; >> compliance basic { ... } >> compliance feature-x { ... } >> compliance feature-y { ... } >> compliance full { ... } >> Then a server that conforms to the 'full' compliance would advertise >> the capability above. > > What about doing this with the when-capability mechanism? "basic" > would be the base capability for the module, "x" and "y" would be > additional capabilities, and "full" may or may not be needed, if > it's just "x + y". > > Using the "when-capability" statement has the nice effect of keeping > the condition with the node being defined, and not having to repeat > nodes in a "compliance" statement. > > module foo { > ... > capability feature-x { ... } What goes in the { ... } (description, reference, status?) > capability feature-y { ... } > > container ahh { > container beh { > container say { > container day { > when-capability feature-x; > .... > } > container night { > when-capability feature-y; 1) Conformance I like 'when-capability' as a variant of the 'when-stmt'. This is better than adding a meta-containment layer. It seems 'all-or-nothing' conformance isn't winning the day. In that case, I strongly favor a conformance model based on capabilities, since the protocol already supports it. A separate conformance section requires data to be entered more than once, but may be easier to read, as it keeps the data definitions uncluttered with conformance meta-data. Entering data more than once can lead to human-introduced errors. Cluttered confusing data models can lead to human-introduced errors. IMO, the inline approach (Phil's proposal, also in netconf.yang) is best because: - it works for groupings and inline data - reproducing the object tree by hand can be nearly impossible for deep data models, almost ensuring human-introduced errors 2) Revisions Note that the 'grouping revision issues' are still unsolved by both approaches. IMO, the simplest approach is to mandate (outside the YANG language) that standard YANG groupings MUST NOT be changed in certain ways, just like SMIv2 does with TEXTUAL-CONVENTIONs. That way, import is simple, and conformance-by-capability (or by-anything) will be stable. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 13:44:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D2C3A6CF6; Tue, 6 May 2008 13:44:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C6A3A6A9F for ; Tue, 6 May 2008 13:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkflAbuqdHmG for ; Tue, 6 May 2008 13:44:13 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 2000F3A7044 for ; Tue, 6 May 2008 13:44:13 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id E17501B80CE; Tue, 6 May 2008 22:44:10 +0200 (CEST) Date: Tue, 06 May 2008 22:44:00 +0200 (CEST) Message-Id: <20080506.224400.04775157.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <48208F4D.90909@andybierman.com> References: <200805061539.m46FdG9T049987@idle.juniper.net> <48208F4D.90909@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Phil Shafer wrote: > > Martin Bjorklund writes: > >> module foo { > >> namespace "http://example.com/foo-module"; > >> revision 2008-05-01; > >> compliance basic { ... } > >> compliance feature-x { ... } > >> compliance feature-y { ... } > >> compliance full { ... } > >> Then a server that conforms to the 'full' compliance would advertise > >> the capability above. > > What about doing this with the when-capability mechanism? "basic" > > would be the base capability for the module, "x" and "y" would be > > additional capabilities, and "full" may or may not be needed, if > > it's just "x + y". > > > > Using the "when-capability" statement has the nice effect of keeping > > the condition with the node being defined, and not having to repeat > > nodes in a "compliance" statement. > > module foo { > > ... > > capability feature-x { ... } > > What goes in the { ... } (description, reference, status?) And uri and when-capability: capability confirmed-commit { uri urn:ietf:params:netconf:capability:confirmed-commit:1.0; when-capability nc:candidate; description "..."; } > 1) Conformance > > I like 'when-capability' as a variant of the 'when-stmt'. > This is better than adding a meta-containment layer. > > It seems 'all-or-nothing' conformance isn't winning the day. > In that case, I strongly favor a conformance model based > on capabilities, since the protocol already supports it. I agree. But the capability list reported in each hello message might get long... > A separate conformance section requires data to be entered > more than once, but may be easier to read, as it keeps the > data definitions uncluttered with conformance meta-data. Right. With when-capability, you have to scan the entire module to see if there are any more occurances of 'when-capability foo'. So for a reader it takes some work to figure out exactly what constitutes a capability. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 14:19:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62F23A6844; Tue, 6 May 2008 14:19:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2883A692E for ; Tue, 6 May 2008 14:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od3WqgzCsiGq for ; Tue, 6 May 2008 14:19:00 -0700 (PDT) Received: from chip3og58.obsmtp.com (chip3og58.obsmtp.com [64.18.14.181]) by core3.amsl.com (Postfix) with ESMTP id 246963A68E3 for ; Tue, 6 May 2008 14:18:16 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob58.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 14:17:39 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 14:17:35 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m46LHZx81731; Tue, 6 May 2008 14:17:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m46LFoLH053333; Tue, 6 May 2008 21:15:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805062115.m46LFoLH053333@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080506.224400.04775157.mbj@tail-f.com> Date: Tue, 06 May 2008 17:15:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 21:17:35.0726 (UTC) FILETIME=[9AE2C8E0:01C8AFBE] Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Right. With when-capability, you have to scan the entire module to >see if there are any more occurances of 'when-capability foo'. So for >a reader it takes some work to figure out exactly what constitutes a >capability. I see it the opposite. When I'm looking at a node, I want to see if that node is affected by capabilities. I don't want to go off and check a list (hierarchy?) of nodes in another section to see that this is conditional. We put things inline so the reader can see what's required directly, with the information as localized as possible. If you like the 'distinct section' approach, would you apply this approach to "status"? A distinct "status" section containing a list of nodes that are deprecated? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 14:27:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53AE23A68A8; Tue, 6 May 2008 14:27:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5C53A68A8 for ; Tue, 6 May 2008 14:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VJIknAuCN6i for ; Tue, 6 May 2008 14:27:57 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 5E2D43A6844 for ; Tue, 6 May 2008 14:27:57 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 946891B80CE; Tue, 6 May 2008 23:27:54 +0200 (CEST) Date: Tue, 06 May 2008 23:27:43 +0200 (CEST) Message-Id: <20080506.232743.15125951.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805062115.m46LFoLH053333@idle.juniper.net> References: <20080506.224400.04775157.mbj@tail-f.com> <200805062115.m46LFoLH053333@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: > >Right. With when-capability, you have to scan the entire module to > >see if there are any more occurances of 'when-capability foo'. So for > >a reader it takes some work to figure out exactly what constitutes a > >capability. > > I see it the opposite. When I'm looking at a node, I want to see > if that node is affected by capabilities. I don't want to go off > and check a list (hierarchy?) of nodes in another section to see > that this is conditional. We put things inline so the reader can > see what's required directly, with the information as localized as > possible. I agree with this. > If you like the 'distinct section' approach, would you apply this > approach to "status"? A distinct "status" section containing a > list of nodes that are deprecated? I didn't say I like it ;-) What I *would* like is a syntax w/o repetition which made it easy to see what is contained in a capability, and at the same time when looking at a node made it clear if the node was part of a capability or not. I don't think this is possible though, and of the alternatives we have now I think the when-capabiltiy is least bad. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 14:36:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3E128C3ED; Tue, 6 May 2008 14:36:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86AC528C3ED for ; Tue, 6 May 2008 14:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8jETIZCPRMW for ; Tue, 6 May 2008 14:36:48 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 947953A6873 for ; Tue, 6 May 2008 14:36:48 -0700 (PDT) Received: (qmail 90519 invoked from network); 6 May 2008 21:36:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 21:36:44 -0000 X-YMail-OSG: tqxcwZ8VM1mmONYZqD3Ikb5aPYn_nbab6sQ62AEp_4sEs4WW9qvBsFyCySdtlcmNZoTMK1fQhWWdsBbgJplrzKNXZik3.dlyT.tnwWcDEJHlTP1xeXqJhqFPK0OVS7yfSlY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820CF03.8020209@andybierman.com> Date: Tue, 06 May 2008 14:34:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062115.m46LFoLH053333@idle.juniper.net> In-Reply-To: <200805062115.m46LFoLH053333@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: >> Right. With when-capability, you have to scan the entire module to >> see if there are any more occurances of 'when-capability foo'. So for >> a reader it takes some work to figure out exactly what constitutes a >> capability. > > I see it the opposite. When I'm looking at a node, I want to see > if that node is affected by capabilities. I don't want to go off > and check a list (hierarchy?) of nodes in another section to see > that this is conditional. We put things inline so the reader can > see what's required directly, with the information as localized as > possible. > > If you like the 'distinct section' approach, would you apply this > approach to "status"? A distinct "status" section containing a > list of nodes that are deprecated? > I agree with Martin. An implementor or an operator is going to want to know what new data is going to be on the agent if this capability is supported. Tracking down this info in one or more modules would be quite a challenge, if when-capability clauses were scattered through the data model. Nested combinations are not that obvious either. It is also useful to know that 'when-capability' applies, when reading the data model inline. How are changes to the capability tracked over time? (Poorly.) One solution is 'external text', like in RFC 4741. There are sections that describe what the capability changes in the protocol, meant for humans. There are no machine-readable sections for this purpose, and maybe that's not a big deal. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 23:18:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEE43A68FF; Tue, 6 May 2008 23:18:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3BA28C4B9 for ; Tue, 6 May 2008 14:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZWFXDl07TKT for ; Tue, 6 May 2008 14:48:56 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 690DA28C499 for ; Tue, 6 May 2008 14:48:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:39567 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1JtV1o-0005Ma-BA; Tue, 06 May 2008 23:48:52 +0200 MIME-Version: 1.0 From: "netmod" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: dbharrington@comcast.net X-Trac-Project: netmod Date: Tue, 06 May 2008 21:48:52 -0000 X-URL: http://tools.ietf.org/netmod/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netmod/trac/ticket/1 Message-ID: <065.4f6dac043ac8f70f5c7397c7ad2fc770@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dbharrington@comcast.net, netmod@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 06 May 2008 23:18:09 -0700 Cc: netmod@ietf.org Subject: [netmod] #1: conformance in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: netmod@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ticket #1: conformance in YANG models see thread started at http://www.ietf.org/mail- archive/web/netmod/current/msg00010.html --------------------------------------+------------------------------------- Reporter: dbharrington@comcast.net | Owner: Type: enhancement | Status: new Priority: major | Milestone: YANG-00 Component: YANG | Version: Severity: Candidate WG Document | Keywords: --------------------------------------+------------------------------------- -- Ticket URL: netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 6 23:18:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCDCD28C54F; Tue, 6 May 2008 23:18:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B3428C4A6 for ; Tue, 6 May 2008 15:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usfFZcZFTX3W for ; Tue, 6 May 2008 15:11:15 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 6CEFE28C488 for ; Tue, 6 May 2008 15:11:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:43593 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1JtVNQ-0007WH-7q; Wed, 07 May 2008 00:11:12 +0200 MIME-Version: 1.0 From: "netmod" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: dbharrington@comcast.net X-Trac-Project: netmod Date: Tue, 06 May 2008 22:11:12 -0000 X-URL: http://tools.ietf.org/netmod/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netmod/trac/ticket/1#comment:1 Message-ID: <074.bae4c0d15a63e39b0cf882e69505d20f@tools.ietf.org> References: <065.4f6dac043ac8f70f5c7397c7ad2fc770@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <065.4f6dac043ac8f70f5c7397c7ad2fc770@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dbharrington@comcast.net, netmod@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 06 May 2008 23:18:12 -0700 Cc: netmod@ietf.org Subject: Re: [netmod] #1: conformance in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: netmod@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ticket #1: conformance in YANG models >From dbharrington@comcast.net): * milestone: YANG-00 => --------------------------------------+------------------------------------- Reporter: dbharrington@comcast.net | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: YANG | Version: Severity: Candidate WG Document | Resolution: Keywords: | --------------------------------------+------------------------------------- -- Ticket URL: netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 7 05:44:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4340A3A6C80; Wed, 7 May 2008 05:44:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EE928C639 for ; Wed, 7 May 2008 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lweVzXsso+Rg for ; Wed, 7 May 2008 05:43:51 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 85D4728C6A2 for ; Wed, 7 May 2008 05:43:21 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 05:42:58 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 05:43:11 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m47Ch5x91640; Wed, 7 May 2008 05:43:05 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m47CfKk2058198; Wed, 7 May 2008 12:41:20 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805071241.m47CfKk2058198@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080506.232743.15125951.mbj@tail-f.com> Date: Wed, 07 May 2008 08:41:20 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2008 12:43:11.0708 (UTC) FILETIME=[E8E921C0:01C8B03F] Cc: netmod@ietf.org Subject: Re: [netmod] module conformance vs. agent-variance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >What I *would* like is a syntax w/o repetition which made it easy to >see what is contained in a capability, and at the same time when >looking at a node made it clear if the node was part of a capability >or not. I don't think this is possible though, and of the >alternatives we have now I think the when-capabiltiy is least bad. Agree. Generating a list of capability-enabled nodes would be a simple xslt script that can be run on the YIN format of a YANG module. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 8 08:23:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B3228D76C; Thu, 8 May 2008 08:23:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9E13A6EBC for ; Thu, 8 May 2008 08:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR0V-FoMe8MJ for ; Thu, 8 May 2008 08:22:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7E18828D82C for ; Thu, 8 May 2008 07:25:19 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B1731D800BD for ; Thu, 8 May 2008 10:08:59 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Thu, 08 May 2008 10:08:58 +0200 Message-Id: <1210234139.14514.33.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Subject: [netmod] list keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, as an exercise, I converted manually the RELAX NG schema that we are using for our FlowMon probe to YANG. It went quite smoothly, the result is here: http://www.yang-central.org/twiki/pub/Main/YangExamples/flowmon.yang I encountered two problems related to list keys, one minor and one more serious: 1. In the following list list interface { key ifNumber; leaf ifNumber { type uint8 { range 0..3; } } choice monitoring-mirroring { case monitoring-interface { ... } case mirroring-interface { ... } } } I actually want to use the "monitoring-interface" case for ifNumber 0 or 1 and the other case for ifNumber 2 or 3. I could move ifNumber under the choice statement and make the distinction in each of the case statements - but is it possible with ifNumber serving as the list key? 2. In this list list filterCondition { ordered-by user; choice filter-conditions { leaf ipVersion { type inet:ip-version; } container addressRange { leaf startAddress { mandatory true; type inet:ip-address; } leaf endAddress { mandatory true; type inet:ip-address; } container matchAgainst { uses address-choice; } } } leaf ifNumber { type uint8 { range 0..1; } } } there is essentially no way how to define the mandatory key. With deep keys, it would be probably possible to use all contained leafs but IMO it makes little sense anyway. I propose to drop the requirement to define a key for lists ordered-by user. If the key is not defined (as it is here) the system should allocate internally ordinal numbers to list items that can be used for their addressing. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 8 09:37:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3673A725D; Thu, 8 May 2008 09:37:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D853A6BFA for ; Thu, 8 May 2008 09:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRoEshECsA+X for ; Thu, 8 May 2008 09:37:06 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id D495628C9C8 for ; Thu, 8 May 2008 09:35:09 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 08 May 2008 09:33:28 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 May 2008 09:34:52 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m48GYpx51770; Thu, 8 May 2008 09:34:51 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m48GX5kx068832; Thu, 8 May 2008 16:33:05 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805081633.m48GX5kx068832@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1210234139.14514.33.camel@missotis> Date: Thu, 08 May 2008 12:33:05 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 May 2008 16:34:52.0162 (UTC) FILETIME=[70A3D620:01C8B129] Cc: NETMOD Working Group Subject: Re: [netmod] list keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >http://www.yang-central.org/twiki/pub/Main/YangExamples/flowmon.yang Very cool. >I actually want to use the "monitoring-interface" case for ifNumber 0 or >1 and the other case for ifNumber 2 or 3. I could move ifNumber under >the choice statement and make the distinction in each of the case >statements - but is it possible with ifNumber serving as the list key? I'm confused about how the values relate to the content (and why interfaces 0 and 1 have inputSampling but not others), but aren't you really wanting a conditional augmentation? You want the common stuff always and the others if ifNum <= 1: list interface { key ifNumber; leaf ifNumber { type uint8 { range 0..3; } } uses common-interface-content; augment . { when "ifNumber <= 1"; container inputSampling { leaf samplingMethod { type enumeration { enum regular; enum statistical; } default statistical; } leaf samplingRate { type sampling-rate; } } leaf ifInPackets { config false; type uint32; } leaf ifInErrors { config false; type uint32; } leaf ifInDiscards { config false; type uint32; } } } } >there is essentially no way how to define the mandatory key. With deep >keys, it would be probably possible to use all contained leafs but IMO >it makes little sense anyway. I propose to drop the requirement to >define a key for lists ordered-by user. If the key is not defined (as it >is here) the system should allocate internally ordinal numbers to list >items that can be used for their addressing. I'd rather see explicit names, so both sides know which member you are talking about and there's no misunderstanding: list filterCondition { ordered-by user; key name; leaf name { // Explicit name type string; description "Name of this condition"; } ... } Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 8 13:28:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3603A67B5; Thu, 8 May 2008 13:28:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0133A6B83 for ; Thu, 8 May 2008 13:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXKJinDgEQPP for ; Thu, 8 May 2008 13:28:56 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id BDE653A6B19 for ; Thu, 8 May 2008 13:28:56 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 0ED881B80C5; Thu, 8 May 2008 22:28:54 +0200 (CEST) Date: Thu, 08 May 2008 22:28:40 +0200 (CEST) Message-Id: <20080508.222840.22424787.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805081633.m48GX5kx068832@idle.juniper.net> References: <1210234139.14514.33.camel@missotis> <200805081633.m48GX5kx068832@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] list keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Phil Shafer wrote: > Ladislav Lhotka writes: > >I actually want to use the "monitoring-interface" case for ifNumber 0 or > >1 and the other case for ifNumber 2 or 3. I could move ifNumber under > >the choice statement and make the distinction in each of the case > >statements - but is it possible with ifNumber serving as the list key? > > I'm confused about how the values relate to the content (and > why interfaces 0 and 1 have inputSampling but not others), but > aren't you really wanting a conditional augmentation? [...] Another alternative is to use a 'must' constraint: list interface { key ifNumber; leaf ifNumber { type uint8 { range 0..3; } } choice monitoring-mirroring { case monitoring-interface { must '../../../ifNumber <= 1'; ... } case mirroring-interface { must '../../../ifNumber > 1'; ... } } } (Note that YANG currently don't support "must" in a case; I think it should do that.) > >there is essentially no way how to define the mandatory key. With deep > >keys, it would be probably possible to use all contained leafs but IMO > >it makes little sense anyway. I propose to drop the requirement to > >define a key for lists ordered-by user. If the key is not defined (as it > >is here) the system should allocate internally ordinal numbers to list > >items that can be used for their addressing. > > I'd rather see explicit names, so both sides know which member > you are talking about and there's no misunderstanding: I agree. Using an explicit name as key also makes deletion via edit-config easier. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 8 13:41:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24FCE3A6824; Thu, 8 May 2008 13:41:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A8F3A6840 for ; Thu, 8 May 2008 13:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAbe9ShAuGl9 for ; Thu, 8 May 2008 13:40:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D91153A6824 for ; Thu, 8 May 2008 13:40:57 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 97326D800C0; Thu, 8 May 2008 22:40:55 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200805081633.m48GX5kx068832@idle.juniper.net> References: <200805081633.m48GX5kx068832@idle.juniper.net> Organization: CESNET Date: Thu, 08 May 2008 22:40:57 +0200 Message-Id: <1210279257.14514.60.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Cc: NETMOD Working Group Subject: Re: [netmod] list keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGkgUGhpbCwKClBoaWwgU2hhZmVyIHDDrcWhZSB2IMSMdCAwOC4gMDUuIDIwMDggdiAxMjozMyAt MDQwMDoKPiA+SSBhY3R1YWxseSB3YW50IHRvIHVzZSB0aGUgIm1vbml0b3JpbmctaW50ZXJmYWNl IiBjYXNlIGZvciBpZk51bWJlciAwIG9yCj4gPjEgYW5kIHRoZSBvdGhlciBjYXNlIGZvciBpZk51 bWJlciAyIG9yIDMuIEkgY291bGQgbW92ZSBpZk51bWJlciB1bmRlcgo+ID50aGUgY2hvaWNlIHN0 YXRlbWVudCBhbmQgbWFrZSB0aGUgZGlzdGluY3Rpb24gaW4gZWFjaCBvZiB0aGUgY2FzZQo+ID5z dGF0ZW1lbnRzIC0gYnV0IGlzIGl0IHBvc3NpYmxlIHdpdGggaWZOdW1iZXIgc2VydmluZyBhcyB0 aGUgbGlzdCBrZXk/Cj4gCj4gSSdtIGNvbmZ1c2VkIGFib3V0IGhvdyB0aGUgdmFsdWVzIHJlbGF0 ZSB0byB0aGUgY29udGVudCAoYW5kCj4gd2h5IGludGVyZmFjZXMgMCBhbmQgMSBoYXZlIGlucHV0 U2FtcGxpbmcgYnV0IG5vdCBvdGhlcnMpLCBidXQKCk9ubHkgaW50ZXJmYWNlcyAwIGFuZCAxIGNh biBkbyB0aGUgYWdncmVnYXRpb24gb2YgZmxvd3MgKHR5cGljYWxseSBmcm9tCmJvdGggZGlyZWN0 aW9ucyBvZiB0aGUgc2FtZSBsaW5rKSwgMiBhbmQgMyBjYW4gYmUgb3B0aW9uYWxseSB1c2VkIGp1 c3QKZm9yIGdldHRpbmcgYW5vdGhlciBjb3B5IG9mIHJhdyBkYXRhIGZyb20gMCBhbmQgMSwgcmVz cGVjdGl2ZWx5LiBUaGlzIGlzCmEgZmlybXdhcmUgbGltaXRhdGlvbi4KCj4gYXJlbid0IHlvdSBy ZWFsbHkgd2FudGluZyBhIGNvbmRpdGlvbmFsIGF1Z21lbnRhdGlvbj8gIFlvdSB3YW50Cj4gdGhl IGNvbW1vbiBzdHVmZiBhbHdheXMgYW5kIHRoZSBvdGhlcnMgaWYgaWZOdW0gPD0gMToKClllcywg dGhpcyBpcyBpdCwgdGhhbmtzLgoKPiA+dGhlcmUgaXMgZXNzZW50aWFsbHkgbm8gd2F5IGhvdyB0 byBkZWZpbmUgdGhlIG1hbmRhdG9yeSBrZXkuIFdpdGggZGVlcAo+ID5rZXlzLCBpdCB3b3VsZCBi ZSBwcm9iYWJseSBwb3NzaWJsZSB0byB1c2UgYWxsIGNvbnRhaW5lZCBsZWFmcyBidXQgSU1PCj4g Pml0IG1ha2VzIGxpdHRsZSBzZW5zZSBhbnl3YXkuIEkgcHJvcG9zZSB0byBkcm9wIHRoZSByZXF1 aXJlbWVudCB0bwo+ID5kZWZpbmUgYSBrZXkgZm9yIGxpc3RzIG9yZGVyZWQtYnkgdXNlci4gSWYg dGhlIGtleSBpcyBub3QgZGVmaW5lZCAoYXMgaXQKPiA+aXMgaGVyZSkgdGhlIHN5c3RlbSBzaG91 bGQgYWxsb2NhdGUgaW50ZXJuYWxseSBvcmRpbmFsIG51bWJlcnMgdG8gbGlzdAo+ID5pdGVtcyB0 aGF0IGNhbiBiZSB1c2VkIGZvciB0aGVpciBhZGRyZXNzaW5nLgo+IAo+IEknZCByYXRoZXIgc2Vl IGV4cGxpY2l0IG5hbWVzLCBzbyBib3RoIHNpZGVzIGtub3cgd2hpY2ggbWVtYmVyCj4geW91IGFy ZSB0YWxraW5nIGFib3V0IGFuZCB0aGVyZSdzIG5vIG1pc3VuZGVyc3RhbmRpbmc6Cj4gCj4gICAg ICAgICAgIGxpc3QgZmlsdGVyQ29uZGl0aW9uIHsKPiAgICAgICAgICAgICBvcmRlcmVkLWJ5IHVz ZXI7Cj4gICAgICAgICAgICAga2V5IG5hbWU7Cj4gICAgICAgICAgICAgbGVhZiBuYW1lIHsgIC8v IEV4cGxpY2l0IG5hbWUKPiAgICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7Cj4gICAgICAgICAg ICAgICAgIGRlc2NyaXB0aW9uICJOYW1lIG9mIHRoaXMgY29uZGl0aW9uIjsKPiAgICAgICAgICAg ICB9Cj4gICAgICAgICAgICAgLi4uCj4gICAgICAgICAgIH0KCldlbGwsIHdpdGggaHVuZHJlZHMg b2Ygc3VjaCBjb25kaXRpb25zIHRoaXMgbG9va3MgbGlrZSBhIGRydWRnZXJ5LiBObywKd2UgZG9u J3QgdXNlIHRoYXQgbWFueSBjb25kaXRpb25zLCBidXQgaW4gYSBnZW5lcmFsIHBhY2tldCBmaWx0 ZXIgaXQKY291bGQgZWFzaWx5IGJlIHRoZSBjYXNlLiBGb3IgbGlzdHMgb3JkZXJlZCBieSB1c2Vy IHRoZSBhdXRvbWF0aWMKb3JkaW5hbCBudW1iZXJzIGNvdWxkIGJlIGEgY29udmVuaWVudCBkZWZh dWx0LgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4 QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRt b2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu May 8 14:14:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA243A6B83; Thu, 8 May 2008 14:14:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65663A6EA2 for ; Thu, 8 May 2008 14:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YhberMNnIJa for ; Thu, 8 May 2008 14:14:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2914B3A6B83 for ; Thu, 8 May 2008 14:14:34 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AB5EFD800C0; Thu, 8 May 2008 23:14:32 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080508.222840.22424787.mbj@tail-f.com> References: <1210234139.14514.33.camel@missotis> <200805081633.m48GX5kx068832@idle.juniper.net> <20080508.222840.22424787.mbj@tail-f.com> Organization: CESNET Date: Thu, 08 May 2008 23:14:34 +0200 Message-Id: <1210281274.14514.68.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Cc: netmod@ietf.org Subject: Re: [netmod] list keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ck1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgxIx0IDA4LiAwNS4gMjAwOCB2IDIyOjI4ICswMjAw OgoKPiAKPiBBbm90aGVyIGFsdGVybmF0aXZlIGlzIHRvIHVzZSBhICdtdXN0JyBjb25zdHJhaW50 Ogo+IAo+ICAgICBsaXN0IGludGVyZmFjZSB7Cj4gICAgICAga2V5IGlmTnVtYmVyOwo+ICAgICAg IGxlYWYgaWZOdW1iZXIgewo+ICAgICAgICAgdHlwZSB1aW50OCB7Cj4gICAgICAgICAgIHJhbmdl IDAuLjM7Cj4gICAgICAgICB9Cj4gICAgICAgfQo+ICAgICAgIGNob2ljZSBtb25pdG9yaW5nLW1p cnJvcmluZyB7Cj4gICAgICAgICBjYXNlIG1vbml0b3JpbmctaW50ZXJmYWNlIHsKPiAgICAgICAg ICAgbXVzdCAnLi4vLi4vLi4vaWZOdW1iZXIgPD0gMSc7Cj4gICAgICAgICAgIC4uLiAgICAgICAg ICAgICAgICAKPiAgICAgICAgIH0KPiAgICAgICAgIGNhc2UgbWlycm9yaW5nLWludGVyZmFjZSB7 Cj4gICAgICAgICAgIG11c3QgJy4uLy4uLy4uL2lmTnVtYmVyID4gMSc7Cj4gICAgICAgICAgIC4u Lgo+ICAgICAgICAgfQo+ICAgICAgIH0KPiAgICAgfQo+IAo+IChOb3RlIHRoYXQgWUFORyBjdXJy ZW50bHkgZG9uJ3Qgc3VwcG9ydCAibXVzdCIgaW4gYSBjYXNlOyBJIHRoaW5rIGl0Cj4gc2hvdWxk IGRvIHRoYXQuKQoKWWVzLCBpdCB3YXMgbXkgZmlyc3QgaWRlYSwgYnV0IEkgZm91bmQgb3V0IGl0 IHdhcyBub3QgcG9zc2libGUuCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQ IEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri May 9 01:50:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726343A67A9; Fri, 9 May 2008 01:50:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EA93A67B0 for ; Fri, 9 May 2008 01:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLlR7KWlA8Ko for ; Fri, 9 May 2008 01:50:00 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5AF743A67A9 for ; Fri, 9 May 2008 01:49:57 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D15E0D800C0 for ; Fri, 9 May 2008 10:45:45 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Fri, 09 May 2008 10:45:45 +0200 Message-Id: <1210322745.16542.39.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Subject: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, since "augment" with a relative path seems to make sense only in connection with "uses", I am thinking about unifying refinements and augments, like this: uses "some-grouping" { refine foo/bar { ... } augment baz/mek { ... } } Any opinions? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 02:16:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17163A683E; Fri, 9 May 2008 02:16:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7BD3A683E for ; Fri, 9 May 2008 02:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.042 X-Spam-Level: X-Spam-Status: No, score=-5.042 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09EfZTu6Zrdx for ; Fri, 9 May 2008 02:16:46 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 7C0823A6923 for ; Fri, 9 May 2008 02:16:12 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m499Bp8R023967; Fri, 9 May 2008 11:11:52 +0200 Message-ID: <48241557.9080100@informatik.uni-tuebingen.de> Date: Fri, 09 May 2008 11:11:51 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: In-Reply-To: X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.14; VDF: 7.0.4.20; host: mx06) Cc: netmod@ietf.org Subject: Re: [netmod] list keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688988900==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0688988900== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070805070001000805090800" This is a cryptographically signed message in MIME format. --------------ms070805070001000805090800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ladislav, As your FlowMon probe is supporting Netflow, you might be interested in the IPFIX standardization activities. Do you know about the current IPFIX WG charter item concerning the configuration of IPFIX devices? As we are also using Netconf and YANG, you might be interested in following the discussion and bring in your ideas: http://tools.ietf.org/wg/ipfix/ http://tools.ietf.org/html/draft-muenz-ipfix-configuration-04 Regards, Gerhard netmod-request@ietf.org wrote: > Date: Thu, 08 May 2008 10:08:58 +0200 > From: Ladislav Lhotka > Subject: [netmod] list keys > To: NETMOD Working Group > Message-ID: <1210234139.14514.33.camel@missotis> > Content-Type: text/plain >=20 > Hi, >=20 > as an exercise, I converted manually the RELAX NG schema that we are > using for our FlowMon probe to YANG. It went quite smoothly, the result= > is here: > http://www.yang-central.org/twiki/pub/Main/YangExamples/flowmon.yang >=20 > I encountered two problems related to list keys, one minor and one more= > serious: >=20 > 1. In the following list >=20 > list interface { > key ifNumber; > leaf ifNumber { > type uint8 { > range 0..3; > } > } > choice monitoring-mirroring { > case monitoring-interface { > ... =20 > } > case mirroring-interface { > ... > } > } > } >=20 > I actually want to use the "monitoring-interface" case for ifNumber 0 o= r > 1 and the other case for ifNumber 2 or 3. I could move ifNumber under > the choice statement and make the distinction in each of the case > statements - but is it possible with ifNumber serving as the list key? >=20 > 2. In this list >=20 > list filterCondition { > ordered-by user; > choice filter-conditions { > leaf ipVersion { > type inet:ip-version; > } > container addressRange { > leaf startAddress { > mandatory true; > type inet:ip-address; > } > leaf endAddress { > mandatory true; > type inet:ip-address; > } > container matchAgainst { > uses address-choice; > } > } > } > leaf ifNumber { > type uint8 { > range 0..1; > } > } > } >=20 > there is essentially no way how to define the mandatory key. With deep > keys, it would be probably possible to use all contained leafs but IMO > it makes little sense anyway. I propose to drop the requirement to > define a key for lists ordered-by user. If the key is not defined (as i= t > is here) the system should allocate internally ordinal numbers to list > items that can be used for their addressing. >=20 > Lada >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070805070001000805090800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDUwOTA5MTE1MVowIwYJKoZIhvcNAQkEMRYEFPuTXeidppX3 e6tsoG7K61eg4NfpMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQC6v0QSzWxMZLUk27ps809Hel4LtTTmy9LWzbzIJZl6yF0Sc2ABV9TZx3Vm kMn5Zx1aGJm//izBVm/4+DO2goV25GlZjEPXBXwsxZvVAehEvclEv6w7KJiAi+bABbb+3Ubj 2lw3pvaa8ZWEZFjPMyNmeOzzMJQ+iCvx1wtmrGx4awsM3/Wc3zlBTun/29MhS1pzpUb3BXKg KjSjJNx3ptcVwEjQUAeC/WG4R9tvrj+aaZYpnwO7HN4PMiPq5Jc4Vqil2sO6YGUMfZEYZ7LM B7FqRRC7WLRy9FBZprXFBT/CG6KD10iNCRN7KPRkrkbf44HFLSaglhD4ZPn6Q129ZdpvAAAA AAAA --------------ms070805070001000805090800-- --===============0688988900== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============0688988900==-- From netmod-bounces@ietf.org Fri May 9 02:24:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231AA3A683F; Fri, 9 May 2008 02:24:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2E03A686C for ; Fri, 9 May 2008 02:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkwqjNKKIAZI for ; Fri, 9 May 2008 02:24:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D30F23A683F for ; Fri, 9 May 2008 02:24:07 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 16B76D800C0; Fri, 9 May 2008 11:22:50 +0200 (CEST) From: Ladislav Lhotka To: Gerhard Muenz In-Reply-To: <48241557.9080100@informatik.uni-tuebingen.de> References: <48241557.9080100@informatik.uni-tuebingen.de> Organization: CESNET Date: Fri, 09 May 2008 11:22:49 +0200 Message-Id: <1210324969.17587.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Cc: netmod@ietf.org Subject: Re: [netmod] list keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGkgR2VyaGFyZCwKCnllcywgSSBsb29rZWQgYXQgaXQgYnJpZWZseSwgYnV0IGhhdmVuJ3QgaGFk IHRpbWUgeWV0IHRvIGRvIGEgbW9yZQpkZXRhaWxlZCBjb21wYXJpc29uLgoKQ2hlZXJzLCBMYWRh CgpQUy4gRmxvd01vbiBub3cgYWxzbyBleHBvcnRzIElQRklYLiA6LSkKCkdlcmhhcmQgTXVlbnog cMOtxaFlIHYgUMOhIDA5LiAwNS4gMjAwOCB2IDExOjExICswMjAwOgo+IEhpIExhZGlzbGF2LAo+ IAo+IEFzIHlvdXIgRmxvd01vbiBwcm9iZSBpcyBzdXBwb3J0aW5nIE5ldGZsb3csIHlvdSBtaWdo dCBiZSBpbnRlcmVzdGVkIGluCj4gdGhlIElQRklYIHN0YW5kYXJkaXphdGlvbiBhY3Rpdml0aWVz Lgo+IERvIHlvdSBrbm93IGFib3V0IHRoZSBjdXJyZW50IElQRklYIFdHIGNoYXJ0ZXIgaXRlbSBj b25jZXJuaW5nIHRoZQo+IGNvbmZpZ3VyYXRpb24gb2YgSVBGSVggZGV2aWNlcz8KPiBBcyB3ZSBh cmUgYWxzbyB1c2luZyBOZXRjb25mIGFuZCBZQU5HLCB5b3UgbWlnaHQgYmUgaW50ZXJlc3RlZCBp bgo+IGZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBhbmQgYnJpbmcgaW4geW91ciBpZGVhczoKPiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvaXBmaXgvCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbXVlbnotaXBmaXgtY29uZmlndXJhdGlvbi0wNAo+IAo+IFJlZ2FyZHMsCj4gR2Vy aGFyZAo+IAo+IG5ldG1vZC1yZXF1ZXN0QGlldGYub3JnIHdyb3RlOgo+ID4gRGF0ZTogVGh1LCAw OCBNYXkgMjAwOCAxMDowODo1OCArMDIwMAo+ID4gRnJvbTogTGFkaXNsYXYgTGhvdGthIDxsaG90 a2FAY2VzbmV0LmN6Pgo+ID4gU3ViamVjdDogW25ldG1vZF0gbGlzdCBrZXlzCj4gPiBUbzogTkVU TU9EIFdvcmtpbmcgR3JvdXAgPG5ldG1vZEBpZXRmLm9yZz4KPiA+IE1lc3NhZ2UtSUQ6IDwxMjEw MjM0MTM5LjE0NTE0LjMzLmNhbWVsQG1pc3NvdGlzPgo+ID4gQ29udGVudC1UeXBlOiB0ZXh0L3Bs YWluCj4gPiAKPiA+IEhpLAo+ID4gCj4gPiBhcyBhbiBleGVyY2lzZSwgSSBjb252ZXJ0ZWQgbWFu dWFsbHkgdGhlIFJFTEFYIE5HIHNjaGVtYSB0aGF0IHdlIGFyZQo+ID4gdXNpbmcgZm9yIG91ciBG bG93TW9uIHByb2JlIHRvIFlBTkcuIEl0IHdlbnQgcXVpdGUgc21vb3RobHksIHRoZSByZXN1bHQK PiA+IGlzIGhlcmU6Cj4gPiBodHRwOi8vd3d3LnlhbmctY2VudHJhbC5vcmcvdHdpa2kvcHViL01h aW4vWWFuZ0V4YW1wbGVzL2Zsb3dtb24ueWFuZwo+ID4gCj4gPiBJIGVuY291bnRlcmVkIHR3byBw cm9ibGVtcyByZWxhdGVkIHRvIGxpc3Qga2V5cywgb25lIG1pbm9yIGFuZCBvbmUgbW9yZQo+ID4g c2VyaW91czoKPiA+IAo+ID4gMS4gSW4gdGhlIGZvbGxvd2luZyBsaXN0Cj4gPiAKPiA+IGxpc3Qg aW50ZXJmYWNlIHsKPiA+ICAga2V5IGlmTnVtYmVyOwo+ID4gICBsZWFmIGlmTnVtYmVyIHsKPiA+ ICAgICB0eXBlIHVpbnQ4IHsKPiA+ICAgICAgIHJhbmdlIDAuLjM7Cj4gPiAgICAgfQo+ID4gICB9 Cj4gPiAgIGNob2ljZSBtb25pdG9yaW5nLW1pcnJvcmluZyB7Cj4gPiAgICAgY2FzZSBtb25pdG9y aW5nLWludGVyZmFjZSB7Cj4gPiAgICAgICAuLi4gICAgICAgICAgICAgICAgCj4gPiAgICAgfQo+ ID4gICAgIGNhc2UgbWlycm9yaW5nLWludGVyZmFjZSB7Cj4gPiAgICAgICAuLi4KPiA+ICAgICB9 Cj4gPiAgIH0KPiA+IH0KPiA+IAo+ID4gSSBhY3R1YWxseSB3YW50IHRvIHVzZSB0aGUgIm1vbml0 b3JpbmctaW50ZXJmYWNlIiBjYXNlIGZvciBpZk51bWJlciAwIG9yCj4gPiAxIGFuZCB0aGUgb3Ro ZXIgY2FzZSBmb3IgaWZOdW1iZXIgMiBvciAzLiBJIGNvdWxkIG1vdmUgaWZOdW1iZXIgdW5kZXIK PiA+IHRoZSBjaG9pY2Ugc3RhdGVtZW50IGFuZCBtYWtlIHRoZSBkaXN0aW5jdGlvbiBpbiBlYWNo IG9mIHRoZSBjYXNlCj4gPiBzdGF0ZW1lbnRzIC0gYnV0IGlzIGl0IHBvc3NpYmxlIHdpdGggaWZO dW1iZXIgc2VydmluZyBhcyB0aGUgbGlzdCBrZXk/Cj4gPiAKPiA+IDIuIEluIHRoaXMgbGlzdAo+ ID4gCj4gPiBsaXN0IGZpbHRlckNvbmRpdGlvbiB7Cj4gPiAgIG9yZGVyZWQtYnkgdXNlcjsKPiA+ ICAgY2hvaWNlIGZpbHRlci1jb25kaXRpb25zIHsKPiA+ICAgICBsZWFmIGlwVmVyc2lvbiB7Cj4g PiAgICAgICB0eXBlIGluZXQ6aXAtdmVyc2lvbjsKPiA+ICAgICB9Cj4gPiAgICAgY29udGFpbmVy IGFkZHJlc3NSYW5nZSB7Cj4gPiAgICAgICBsZWFmIHN0YXJ0QWRkcmVzcyB7Cj4gPiAgICAgICAg IG1hbmRhdG9yeSB0cnVlOwo+ID4gICAgICAgICB0eXBlIGluZXQ6aXAtYWRkcmVzczsKPiA+ICAg ICAgIH0KPiA+ICAgICAgIGxlYWYgZW5kQWRkcmVzcyB7Cj4gPiAgICAgICAgIG1hbmRhdG9yeSB0 cnVlOwo+ID4gICAgICAgICB0eXBlIGluZXQ6aXAtYWRkcmVzczsKPiA+ICAgICAgIH0KPiA+ICAg ICAgIGNvbnRhaW5lciBtYXRjaEFnYWluc3Qgewo+ID4gICAgICAgICB1c2VzIGFkZHJlc3MtY2hv aWNlOwo+ID4gICAgICAgfQo+ID4gICAgIH0KPiA+ICAgfQo+ID4gICBsZWFmIGlmTnVtYmVyIHsK PiA+ICAgICB0eXBlIHVpbnQ4IHsKPiA+ICAgICAgIHJhbmdlIDAuLjE7Cj4gPiAgICAgfQo+ID4g ICB9Cj4gPiB9Cj4gPiAKPiA+IHRoZXJlIGlzIGVzc2VudGlhbGx5IG5vIHdheSBob3cgdG8gZGVm aW5lIHRoZSBtYW5kYXRvcnkga2V5LiBXaXRoIGRlZXAKPiA+IGtleXMsIGl0IHdvdWxkIGJlIHBy b2JhYmx5IHBvc3NpYmxlIHRvIHVzZSBhbGwgY29udGFpbmVkIGxlYWZzIGJ1dCBJTU8KPiA+IGl0 IG1ha2VzIGxpdHRsZSBzZW5zZSBhbnl3YXkuIEkgcHJvcG9zZSB0byBkcm9wIHRoZSByZXF1aXJl bWVudCB0bwo+ID4gZGVmaW5lIGEga2V5IGZvciBsaXN0cyBvcmRlcmVkLWJ5IHVzZXIuIElmIHRo ZSBrZXkgaXMgbm90IGRlZmluZWQgKGFzIGl0Cj4gPiBpcyBoZXJlKSB0aGUgc3lzdGVtIHNob3Vs ZCBhbGxvY2F0ZSBpbnRlcm5hbGx5IG9yZGluYWwgbnVtYmVycyB0byBsaXN0Cj4gPiBpdGVtcyB0 aGF0IGNhbiBiZSB1c2VkIGZvciB0aGVpciBhZGRyZXNzaW5nLgo+ID4gCj4gPiBMYWRhCj4gPiAK PiAKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGlu ZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZAo= From netmod-bounces@ietf.org Fri May 9 06:19:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA5E3A681C; Fri, 9 May 2008 06:19:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9575B3A6822 for ; Fri, 9 May 2008 06:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlAcjqEOLSt7 for ; Fri, 9 May 2008 06:19:39 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id AFDAC3A681C for ; Fri, 9 May 2008 06:19:36 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Fri, 09 May 2008 06:15:29 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 06:17:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m49DHDx28211; Fri, 9 May 2008 06:17:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m49DFPqX075864; Fri, 9 May 2008 13:15:26 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805091315.m49DFPqX075864@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1210322745.16542.39.camel@missotis> Date: Fri, 09 May 2008 09:15:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 May 2008 13:17:13.0842 (UTC) FILETIME=[FEF18D20:01C8B1D6] Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >since "augment" with a relative path seems to make sense only in >connection with "uses", I am thinking about unifying refinements and >augments, like this: > >uses "some-grouping" { > refine foo/bar { > ... > } > augment baz/mek { > ... > } >} I like that this allows you to move deeper into the hierarchy using a path instead of repeating nodes. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 07:55:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C249E3A67CE; Fri, 9 May 2008 07:55:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA1D3A681A for ; Fri, 9 May 2008 07:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5PdR9fxnprs for ; Fri, 9 May 2008 07:55:28 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id DD2DD3A67CE for ; Fri, 9 May 2008 07:55:27 -0700 (PDT) Received: (qmail 39646 invoked from network); 9 May 2008 14:53:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 9 May 2008 14:53:32 -0000 X-YMail-OSG: WFzgCIwVM1kNPtrMYhzdi5bg7tToPXvUm_YGRSEtShsXpRNVEEPG9cTNc.5o03EFQdrCyhQdcgMdj2Ul0K_wgRzN8BofnovW_fRy8jJYvlelICiZF.oXWF55tLGeGTwUqG8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4824656C.9040701@andybierman.com> Date: Fri, 09 May 2008 07:53:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805091315.m49DFPqX075864@idle.juniper.net> In-Reply-To: <200805091315.m49DFPqX075864@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: >> since "augment" with a relative path seems to make sense only in >> connection with "uses", I am thinking about unifying refinements and >> augments, like this: >> >> uses "some-grouping" { >> refine foo/bar { >> ... >> } >> augment baz/mek { >> ... >> } >> } > > I like that this allows you to move deeper into the hierarchy > using a path instead of repeating nodes. > I dislike it for the same reason. IMO, the weakest aspect of YANG is that it can be very difficult for a human to visualize or determine the actual nodes that will be present (in XML) for protocol operations. This is mostly due to the uses and augment statements, and making them more complex worsens the problem. IMO, the reader is #1 priority. Massive flexibility for the writer to be 'clever' is not nearly as important as the reader understanding everything in the data model well enough to use it in the protocol. Since this is a very subjective topic, there is no way to really pick the right balance, so we go by WG consensus instead. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 08:29:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D493A67CE; Fri, 9 May 2008 08:29:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8F43A67FA for ; Fri, 9 May 2008 08:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vchfImTHgxjj for ; Fri, 9 May 2008 08:29:47 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AFA003A67CE for ; Fri, 9 May 2008 08:29:47 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A1D34D800C1; Fri, 9 May 2008 13:57:25 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080509.125037.213868945.mbj@tail-f.com> References: <1210322745.16542.39.camel@missotis> <20080509.125037.213868945.mbj@tail-f.com> Organization: CESNET Date: Fri, 09 May 2008 13:57:25 +0200 Message-Id: <1210334245.18512.23.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ck1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgUMOhIDA5LiAwNS4gMjAwOCB2IDEyOjUwICswMjAw Ogo+IEhpLAo+IAo+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQGNlc25ldC5jej4gd3JvdGU6Cj4g PiBIaSwKPiA+IAo+ID4gc2luY2UgImF1Z21lbnQiIHdpdGggYSByZWxhdGl2ZSBwYXRoIHNlZW1z IHRvIG1ha2Ugc2Vuc2Ugb25seSBpbgo+ID4gY29ubmVjdGlvbiB3aXRoICJ1c2VzIiwKPiAKPiBJ IGRvbid0IHRoaW5rIHRoaXMgaXMgYSBnb29kIGlkZWEuICBXaHkgbWFrZSB0aGlzIHJlc3RyaWN0 aW9uPyAgQWxzbywKPiBzZWUgUGhpbCdzIGVtYWlsIGluIHRoZSAibGlzdCBrZXlzIiB0aHJlYWQK PiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21z ZzAwMDg0Lmh0bWwpCj4gZm9yIGFuIGV4YW1wbGUgb2YgYSB1c2UgY2FzZSB3aGVyZSBhdWdtZW50 IGlzIHVzZWQgb3V0c2lkZSBvZiBhCj4gZ3JvdXBpbmcuICAoT2sgaW4gdGhpcyBwYXJ0aWN1bGFy IGNhc2UgdGhlcmUgaXMgYSAndXNlcycganVzdCBiZWZvcmUKPiB0aGUgYXVnbWVudCwgYnV0IHRo ZSB1c2UgY2FzZSBpcyBlcXVhbGx5IHZhbGlkIHcvbyB0aGUgdGhpcyB1c2VzKQoKSXMgdGhlcmUg YW55IHJlYXNvbiBmb3IgcmVzdHJpY3RpbmcgIndoZW4iIG9ubHkgdG8gImF1Z21lbnQiPyBJTU8g IndoZW4iCmNvdWxkIGJlIGFsbG93ZWQgYXMgYSBnZW5lcmFsIG1ldGhvZCBmb3Igc3BlY2lmeWlu ZyBjb25kaXRpb25hbCBjb250ZW50LgpTbyBpbnN0ZWFkCgphdWdtZW50IC4gewogICAgd2hlbiA8 Y29uZGl0aW9uPiA7CiAgICAgIC4uLi4KfQoKb25lIGNvdWxkIHdyaXRlCgp3aGVuIDxjb25kaXRp b24+IHsKICAgIC4uLi4KfQoKSSB0aGluayBpbiB0aGlzIGNhc2UgImF1Z21lbnQiIHdvdWxkIGJl IHJlYWxseSBuZWVkZWQgb25seSBhcyBhIG1vZGlmaWVyCm9mICJ1c2VzIiBzaW5jZSBvdGhlcndp c2UgeW91IGNhbiB3cml0ZSB0aGUgbmV3IG5vZGVzIHN0cmFpZ2h0IHRvIHRoZQpwbGFjZSB3aGVy ZSB0aGV5IGJlbG9uZy4KCkxhZGEKCj4gCj4gCj4gL21hcnRpbgotLSAKTGFkaXNsYXYgTGhvdGth LCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri May 9 08:34:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424A73A67FA; Fri, 9 May 2008 08:34:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9B43A687E for ; Fri, 9 May 2008 08:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrQJuB3sDscu for ; Fri, 9 May 2008 08:34:27 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 6907B3A67FA for ; Fri, 9 May 2008 08:34:25 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Fri, 09 May 2008 08:33:28 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 08:14:44 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m49FEhx61396; Fri, 9 May 2008 08:14:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m49FCuVp076931; Fri, 9 May 2008 15:12:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805091512.m49FCuVp076931@idle.juniper.net> To: Andy Bierman In-reply-to: <4824656C.9040701@andybierman.com> Date: Fri, 09 May 2008 11:12:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 May 2008 15:14:44.0856 (UTC) FILETIME=[69ACE780:01C8B1E7] Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >IMO, the weakest aspect of YANG is that it can be very difficult >for a human to visualize or determine the actual nodes that will >be present (in XML) for protocol operations. This is mostly due to the >uses and augment statements, and making them more complex worsens >the problem. True, it's subjective, and one man's complexity is another's simplicity, but we're comparing: uses something { container eh { list be { leaf sea { some refinement; } } } } against: uses something { refine eh/be/sea { some refinement; } } IMHO this does three things: makes is more obvious that this is in fact a refinement, makes the point of the refinement more clear, and removes some depth between the uses and the actual refinement. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 08:38:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FC03A67E1; Fri, 9 May 2008 08:38:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557843A67FA for ; Fri, 9 May 2008 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U78-Gyu98U1 for ; Fri, 9 May 2008 08:38:25 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 9B9973A67E1 for ; Fri, 9 May 2008 08:38:25 -0700 (PDT) Received: (qmail 58642 invoked from network); 9 May 2008 15:34:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 9 May 2008 15:34:31 -0000 X-YMail-OSG: sXULf44VM1kXxGQ5IOBLAI6BbF078iwaziX2bzMl1.SmT44YPf2gP2dV7Y4iI_JI71eyqnlsl9F8e8f6cqz7K45caZmSK3cxRU2i4MA3q6gNh_mbI6DhH5wPfmthsRawDpg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48246F08.6010104@andybierman.com> Date: Fri, 09 May 2008 08:34:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805091512.m49FCuVp076931@idle.juniper.net> In-Reply-To: <200805091512.m49FCuVp076931@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> IMO, the weakest aspect of YANG is that it can be very difficult >> for a human to visualize or determine the actual nodes that will >> be present (in XML) for protocol operations. This is mostly due to the >> uses and augment statements, and making them more complex worsens >> the problem. > > True, it's subjective, and one man's complexity is another's > simplicity, but we're comparing: > > uses something { > container eh { > list be { > leaf sea { > some refinement; > } > } > } > } > > against: > > uses something { > refine eh/be/sea { > some refinement; > } > } > > IMHO this does three things: makes is more obvious that this > is in fact a refinement, makes the point of the refinement > more clear, and removes some depth between the uses and the > actual refinement. > I think the first version is easier to read, especially if you are not an Xpath expert. I also get to see the type of node-tree (container, list, leaf), which is just as interesting as the node names. Descendant-schema-nodeid does not provide this feature. What if there are lots of refine statements, that are allowed to be out of order, and maybe even duplicate target Xpaths? What if there are refinements to be made at multiple levels? Then the natural XML containment is lost and it gets way harder to read. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 09:37:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64093A67CE; Fri, 9 May 2008 09:37:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A384D3A67E1 for ; Fri, 9 May 2008 09:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x5WQFSfOfe9 for ; Fri, 9 May 2008 09:37:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 877803A67CE for ; Fri, 9 May 2008 09:37:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BBBEC0014; Fri, 9 May 2008 18:35:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3yycyjAncLqb; Fri, 9 May 2008 18:34:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B0ABC0003; Fri, 9 May 2008 18:34:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E624E57644B; Fri, 9 May 2008 18:34:55 +0200 (CEST) Date: Fri, 9 May 2008 18:34:55 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080509163455.GA5424@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <200805091512.m49FCuVp076931@idle.juniper.net> <48246F08.6010104@andybierman.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48246F08.6010104@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, May 09, 2008 at 08:34:32AM -0700, Andy Bierman wrote: > I think the first version is easier to read, especially > if you are not an Xpath expert. This somehow reminds to the discussion about the need for subtree filtering because (a subset of) Xpath is really too complicated for a non Xpath expert... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 10:05:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2505C3A67E1; Fri, 9 May 2008 10:05:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18673A67FA for ; Fri, 9 May 2008 10:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JPOAzF9xbpK for ; Fri, 9 May 2008 10:04:51 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 7ED1E3A67E1 for ; Fri, 9 May 2008 10:04:51 -0700 (PDT) Received: (qmail 17599 invoked from network); 9 May 2008 17:02:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 9 May 2008 17:02:04 -0000 X-YMail-OSG: Pqg0jvIVM1lm1Q5EJ.l_Ju3eBQT68ZN_mnm.PNaGFdV1cCrIzNAdBXwaW5GN8l_J4wmpWewZ4oV2B9ML7gC2lRKcsI7rirAOVzzc5Mt4pQ_1WQPKSdTXnU5Oq.u7awfRsHU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4824838E.5030607@andybierman.com> Date: Fri, 09 May 2008 10:02:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805091643.m49GhJhV077455@idle.juniper.net> In-Reply-To: <200805091643.m49GhJhV077455@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Juergen Schoenwaelder writes: >> On Fri, May 09, 2008 at 08:34:32AM -0700, Andy Bierman wrote: >>> I think the first version is easier to read, especially >>> if you are not an Xpath expert. >> This somehow reminds to the discussion about the need for subtree >> filtering because (a subset of) Xpath is really too complicated for a >> non Xpath expert... > > Sure, but this isn't an xpath, since it's got no axis, predicates, > functions, etc. It's a yang-path, which is pretty simple. > I'll repeat the paragraph, since it was quoted out of context: I think the first version is easier to read, especially if you are not an Xpath expert. I also get to see the type of node-tree (container, list, leaf), which is just as interesting as the node names. Descendant-schema-nodeid does not provide this feature. Note sentence 2: IMO, the type of node is very useful to see Note sentence 3: I understand this is not full Xpath > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 11:41:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9D53A67CE; Fri, 9 May 2008 11:41:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0733A67FA for ; Fri, 9 May 2008 11:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+Akf-8+JBgv for ; Fri, 9 May 2008 11:41:17 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id BC9D63A67CE for ; Fri, 9 May 2008 11:41:14 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 09 May 2008 11:36:43 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 09:45:07 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m49Gj6x89005; Fri, 9 May 2008 09:45:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m49GhJhV077455; Fri, 9 May 2008 16:43:19 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805091643.m49GhJhV077455@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080509163455.GA5424@elstar.local> Date: Fri, 09 May 2008 12:43:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 May 2008 16:45:07.0446 (UTC) FILETIME=[09CA7960:01C8B1F4] Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >On Fri, May 09, 2008 at 08:34:32AM -0700, Andy Bierman wrote: >> I think the first version is easier to read, especially >> if you are not an Xpath expert. >This somehow reminds to the discussion about the need for subtree >filtering because (a subset of) Xpath is really too complicated for a >non Xpath expert... Sure, but this isn't an xpath, since it's got no axis, predicates, functions, etc. It's a yang-path, which is pretty simple. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 12:43:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C483A67C0; Fri, 9 May 2008 12:43:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2A43A687E for ; Fri, 9 May 2008 12:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlXiYjfvtySP for ; Fri, 9 May 2008 12:43:13 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id E4A7E3A67A2 for ; Fri, 9 May 2008 12:41:05 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Fri, 09 May 2008 12:37:51 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 12:37:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m49JbSx44605; Fri, 9 May 2008 12:37:28 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m49JZfYO078612; Fri, 9 May 2008 19:35:41 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805091935.m49JZfYO078612@idle.juniper.net> To: Andy Bierman In-reply-to: <4824838E.5030607@andybierman.com> Date: Fri, 09 May 2008 15:35:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 May 2008 19:37:29.0181 (UTC) FILETIME=[1DF200D0:01C8B20C] Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I'll repeat the paragraph, since it was quoted out of context: I think Juergen was quoting the interesting part, which is that you think someone who isn't an XPath expert will be somehow confused by a sequence of tokens separated by slashes. Given that most operating systems have some directory-like mechanism, and that even computer illliterates are exposed to URLs, I find this a shocking claim. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 13:03:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B573A68DA; Fri, 9 May 2008 13:03:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBD53A68B8 for ; Fri, 9 May 2008 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d+rQy4AapNq for ; Fri, 9 May 2008 13:03:33 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 194C23A68EA for ; Fri, 9 May 2008 13:03:33 -0700 (PDT) Received: (qmail 80941 invoked from network); 9 May 2008 20:02:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 9 May 2008 20:02:38 -0000 X-YMail-OSG: xm9TUgYVM1kDWl_CpS0jMVQHQHNukUFb0zT16G_ANWHxdrGC2CsZr_f1F_8zrRSySdSNtLBcTxtg6JlVEzJ3Oku5vGXjUf6730ZRU0VvMA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4824ADE0.7040200@andybierman.com> Date: Fri, 09 May 2008 13:02:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805091935.m49JZfYO078612@idle.juniper.net> In-Reply-To: <200805091935.m49JZfYO078612@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I'll repeat the paragraph, since it was quoted out of context: > > I think Juergen was quoting the interesting part, which is that you > think someone who isn't an XPath expert will be somehow confused > by a sequence of tokens separated by slashes. Given that most > operating systems have some directory-like mechanism, and that even > computer illliterates are exposed to URLs, I find this a shocking > claim. > I don't think I said that. I think I said the current YANG syntax is more readable than the proposed changes. When there are multiple clauses of this sort, mixed together, at arbitrary points in the tree, pointing to arbitrary target nodes, this seems way less readable than the current syntax. In trivial examples, there is not much difference at all. Most importantly with the current syntax, the type of node is plain, the refinements are grouped together, and the extra burden of 1 redundant curly brace is not a concern to me. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 9 17:37:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4823A67A8; Fri, 9 May 2008 17:37:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78FD3A67E5 for ; Fri, 9 May 2008 17:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.003 X-Spam-Level: X-Spam-Status: No, score=-1.003 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDnEhR8km5PK for ; Fri, 9 May 2008 17:37:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D049D3A67A8 for ; Fri, 9 May 2008 17:37:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id CF6F6D800C1; Fri, 9 May 2008 23:51:03 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4824656C.9040701@andybierman.com> References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> Organization: CESNET Date: Fri, 09 May 2008 23:51:03 +0200 Message-Id: <1210369863.6133.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFDDoSAwOS4gMDUuIDIwMDggdiAwNzo1MyAtMDcwMDoKPiA+ IEkgbGlrZSB0aGF0IHRoaXMgYWxsb3dzIHlvdSB0byBtb3ZlIGRlZXBlciBpbnRvIHRoZSBoaWVy YXJjaHkKPiA+IHVzaW5nIGEgcGF0aCBpbnN0ZWFkIG9mIHJlcGVhdGluZyBub2Rlcy4KPiA+IAo+ IAo+IEkgZGlzbGlrZSBpdCBmb3IgdGhlIHNhbWUgcmVhc29uLgoKV2VsbCwgYW5vdGhlciBvcHRp b24gd291bGQgdG8gZm9sbG93IHRoZSByZWZpbmVtZW50IG1ldGhvZCBhbmQgd3JpdGUgdGhlCnRy ZWUgaGllcmFyY2h5IGV4cGxpY2l0bHkuCgpXaGF0IGlzIElNTyBtb3JlIGltcG9ydGFudCBpcyB0 aGF0IGF1Z21lbnQgaXMgbm93IGluIGZhY3QgdXNlZCBmb3IgdGhyZWUKZGlmZmVyZW50IGZ1bmN0 aW9uczoKCjEuIENvbmRpdGlvbmFsIGNvbnRlbnQ6CgogICBhdWdtZW50IC4gewogICAgIHdoZW4g Y29uZGl0aW9uOwogICAgIC4uLi4KICAgfQoKVGhpcyBjb3VsZCBiZSByZXBsYWNlZCBieSBhIHNp bXBsZXIgYW5kIGNsZWFyZXIgc3RhdGVtZW50CgogICAgd2hlbiBjb25kaXRpb24gewogICAgICAu Li4uCiAgICB9Cgp3aXRoIGV4YWN0bHkgdGhlIHNhbWUgc2VtYW50aWNzLiBJdCBjb3VsZCBiZSBh bGxvd2VkIGluIHRoZSBzYW1lIHBsYWNlcwphcyBhdWdtZW50IGlzIG5vdy4KCjIuIFVzZSBvZiBh IGdyb3VwaW5nIChpbnRlcm5hbCBvciBpbXBvcnRlZCkgd2l0aCBtb2RpZmljYXRpb25zLiBUaGlz CmNvdWxkIGJlIGRvbmUgdGhpcyB3YXk6CgogICB1c2VzIHNvbWUtZ3JvdXBpbmcgewogICAgIDxt b2RpZmllcnM+CiAgIH0KCndoZXJlIDxtb2RpZmllcnM+IGluY2x1ZGUgcmVmaW5lbWVudCBvZiB0 aGUgZXhpc3Rpbmcgbm9kZXMgYW5kL29yIGFkZGluZwpuZXcgbm9kZXMuIEZvciBhIHJlYWRlciBp dCBpcyBJTU8gYmV0dGVyIHRvIGV4cGxpY2l0bHkgc2VlIHdoYXQgZ3JvdXBpbmcKdGhlIG1vZGlm aWVycyBhcHBseSB0by4gV2hldGhlciB0aGUgbW9kaWZpZXJzIGFyZSBleHByZXNzZWQgdXNpbmcg YSBwYXRoCm9yIGFuIGV4cGxpY2l0IHRyZWUgaXMgc2Vjb25kYXJ5LgoKMy4gRXhwb3J0IG9mIG93 biBub2RlcyB0byBhIGZvcmVpZ24gZGF0YSBtb2RlbCAtIG5vdyBhdWdtZW50IHdpdGggYW4KYWJz b2x1dGUgcGF0aC4gSSB0aGluayBhIG5ldyBzdGF0ZW1lbnQgaXMgYXBwcm9wcmlhdGUgaGVyZSwg cGVyaGFwcwoKICAgZXhwb3J0IGZvcmVpZ24tbW9kdWxlIHsKICAgICAuLi4uCiAgIH0KCm9yIHNv bWV0aGluZyBzaW1pbGFyLgoKTGFkYQoKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1Ag S2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri May 9 23:01:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58EAE3A65A5; Fri, 9 May 2008 23:01:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB933A67A1 for ; Fri, 9 May 2008 23:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-s+MU6aDdXD for ; Fri, 9 May 2008 23:01:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 39B463A65A5 for ; Fri, 9 May 2008 23:01:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED318C000C; Sat, 10 May 2008 07:41:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id InPZOYbu-fXs; Sat, 10 May 2008 07:41:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0A25C0007; Sat, 10 May 2008 07:41:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ADCAC576C37; Sat, 10 May 2008 07:41:38 +0200 (CEST) Date: Sat, 10 May 2008 07:41:38 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080510054138.GA6218@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1210369863.6133.27.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, May 09, 2008 at 11:51:03PM +0200, Ladislav Lhotka wrote: > 3. Export of own nodes to a foreign data model - now augment with an > absolute path. I think a new statement is appropriate here, perhaps > > export foreign-module { > .... > } > > or something similar. This really is the core of an augment and should be called augment; export is a confusing name since we are not exporting anything. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 10 02:34:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C463A65A5; Sat, 10 May 2008 02:34:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9BE3A67AD for ; Sat, 10 May 2008 02:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQkH4W8U5Whw for ; Sat, 10 May 2008 02:33:59 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DD2303A65A5 for ; Sat, 10 May 2008 02:33:55 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 71ADCD800C1; Sat, 10 May 2008 11:32:08 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080510054138.GA6218@elstar.local> References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> Organization: CESNET Date: Sat, 10 May 2008 11:32:08 +0200 Message-Id: <1210411928.31834.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFNvIDEwLiAwNS4gMjAwOCB2IDA3OjQxICsw MjAwOgo+IE9uIEZyaSwgTWF5IDA5LCAyMDA4IGF0IDExOjUxOjAzUE0gKzAyMDAsIExhZGlzbGF2 IExob3RrYSB3cm90ZToKPiAgCj4gPiAzLiBFeHBvcnQgb2Ygb3duIG5vZGVzIHRvIGEgZm9yZWln biBkYXRhIG1vZGVsIC0gbm93IGF1Z21lbnQgd2l0aCBhbgo+ID4gYWJzb2x1dGUgcGF0aC4gSSB0 aGluayBhIG5ldyBzdGF0ZW1lbnQgaXMgYXBwcm9wcmlhdGUgaGVyZSwgcGVyaGFwcwo+ID4gCj4g PiAgICBleHBvcnQgZm9yZWlnbi1tb2R1bGUgewo+ID4gICAgICAuLi4uCj4gPiAgICB9Cj4gPiAK PiA+IG9yIHNvbWV0aGluZyBzaW1pbGFyLgo+IAo+IFRoaXMgcmVhbGx5IGlzIHRoZSBjb3JlIG9m IGFuIGF1Z21lbnQgYW5kIHNob3VsZCBiZSBjYWxsZWQgYXVnbWVudDsKPiBleHBvcnQgaXMgYSBj b25mdXNpbmcgbmFtZSBzaW5jZSB3ZSBhcmUgbm90IGV4cG9ydGluZyBhbnl0aGluZy4KClN1cmUs IGl0IGNvdWxkIGJlIGNhbGxlZCAiYXVnbWVudCIsIGlmIHRoaXMga2V5d29yZCBpcyBub3QgdXNl ZCBmb3IKc3BlY2lmeWluZyB0aGUgbW9kaWZpZXJzIGluICJ1c2VzIi4gT25lIHdheSBmb3IgZG9p bmcgaXQgKHdpdGhvdXQgInlhbmcKcGF0aCIpIGNvdWxkIGJlIHRoaXM6Cgp1c2VzIHNvbWUtZ3Jv dXBpbmcgewogIGNvbnRhaW5lciBmb28gewogICAgbGVhZiBiYXIgewogICAgICBkZWZhdWx0IDYz Nzg7CiAgICB9CiAgY29udGFpbmVyIGJheiB7CiAgICBsZWFmIG1layB7CiAgICAgIC4uLi4KICAg IH0KICB9Cn0KCndoZXJlIGZvby9iYXIgYnJhbmNoIGV4aXN0cyBpbiBzb21lLWdyb3VwaW5nIHdo aWxlIGJhei9tZWsgZG9lc24ndC4gU28sCmF1Z21lbnRpbmcgdGhlIGdyb3VwaW5nIGlzIGhhbmRs ZWQgaW4gdGhlIHNhbWUgd2F5IGFzIHJlZmluZW1lbnRzIGhlcmUgLQpub2RlcyB0aGF0IGRvbid0 IGV4aXN0IGluIHRoZSBncm91cGluZyBhcmUganVzdCBhZGRlZC4KCkkgd291bGQgc3RpbGwgcHJl ZmVyIHRvIHNwZWNpZnkgdGhlIG1vZGlmaWVycyB1c2luZyAieWFuZyBwYXRoIiBpbiBzb21lCndh eSB0aG91Z2guIElNTyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBjb250YWluZXJzIGFuZCBsZWFm cyBpc24ndCB0aGF0CmNydWNpYWwgLSBhZnRlciBhbGwsIGluIFhNTCBlbmNvZGluZyB0aGV5IGFy ZSBhbGwgZWxlbWVudHMuCgpMYWRhCgpMYWRhCgo+IAo+IC9qcwo+IAotLSAKTGFkaXNsYXYgTGhv dGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Sat May 10 04:46:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8AB3A65A5; Sat, 10 May 2008 04:46:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390F73A67AF for ; Sat, 10 May 2008 04:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwDGhyj3Jqg0 for ; Sat, 10 May 2008 04:46:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECB613A65A5 for ; Sat, 10 May 2008 04:46:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1C21C000D; Sat, 10 May 2008 11:54:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fyh+pDsAUe-i; Sat, 10 May 2008 11:54:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 852B3C0008; Sat, 10 May 2008 11:54:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 834E3576F22; Sat, 10 May 2008 11:54:33 +0200 (CEST) Date: Sat, 10 May 2008 11:54:33 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080510095433.GA6574@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> <1210411928.31834.18.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1210411928.31834.18.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sat, May 10, 2008 at 11:32:08AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v So 10. 05. 2008 v 07:41 +0200: > > On Fri, May 09, 2008 at 11:51:03PM +0200, Ladislav Lhotka wrote: > > > > > 3. Export of own nodes to a foreign data model - now augment with an > > > absolute path. I think a new statement is appropriate here, perhaps > > > > > > export foreign-module { > > > .... > > > } > > > > > > or something similar. > > > > This really is the core of an augment and should be called augment; > > export is a confusing name since we are not exporting anything. > > Sure, it could be called "augment", if this keyword is not used for > specifying the modifiers in "uses". One way for doing it (without "yang > path") could be this: > > uses some-grouping { > container foo { > leaf bar { > default 6378; > } > container baz { > leaf mek { > .... > } > } > } > > where foo/bar branch exists in some-grouping while baz/mek doesn't. So, > augmenting the grouping is handled in the same way as refinements here - > nodes that don't exist in the grouping are just added. > > I would still prefer to specify the modifiers using "yang path" in some > way though. IMO the distinction between containers and leafs isn't that > crucial - after all, in XML encoding they are all elements. So do I (just in case that was not clear). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 10 08:41:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF5C3A65A5; Sat, 10 May 2008 08:41:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D1C3A6825 for ; Sat, 10 May 2008 08:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQy4w-MegIY8 for ; Sat, 10 May 2008 08:41:26 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id C27663A65A5 for ; Sat, 10 May 2008 08:41:23 -0700 (PDT) Received: (qmail 40019 invoked from network); 10 May 2008 15:30:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 10 May 2008 15:30:34 -0000 X-YMail-OSG: RPnnhRIVM1m0cewE5bQJ7DS6w3LYeMkMWNAFYYqHZtLyo0ZhhKlQzAspKNu12bMFA875rgB_AdQXn4vurU4haa55B34y6y9kXYmjQILoghESnySbrCrmK3jY_s2XG5Plq6w- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4825BF98.3070407@andybierman.com> Date: Sat, 10 May 2008 08:30:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> <1210411928.31834.18.camel@missotis> In-Reply-To: <1210411928.31834.18.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: >.... > I would still prefer to specify the modifiers using "yang path" in some > way though. IMO the distinction between containers and leafs isn't that > crucial - after all, in XML encoding they are all elements. > I prefer to have YANG be a high-level DML, which has building blocks called 'container', 'list', leaf', etc. In the YANG module, I prefer not to reduce the DM to just more XML. There are already plenty of DMLs that do that, and we don't need another one. When the node type is always the same (e.g., directories or XML elements), then the 'foo/bar/baz' syntax is best. But when the node type is variable, then this syntax is not explicit enough. > Lada > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 10 09:07:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9840C3A65A5; Sat, 10 May 2008 09:07:04 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD1F3A68E3 for ; Sat, 10 May 2008 09:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tTTSY9E3m0x for ; Sat, 10 May 2008 09:07:00 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id AD66E3A65A5 for ; Sat, 10 May 2008 09:06:57 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id E13A21B80C5; Fri, 9 May 2008 12:50:50 +0200 (CEST) Date: Fri, 09 May 2008 12:50:37 +0200 (CEST) Message-Id: <20080509.125037.213868945.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1210322745.16542.39.camel@missotis> References: <1210322745.16542.39.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Ladislav Lhotka wrote: > Hi, > > since "augment" with a relative path seems to make sense only in > connection with "uses", I don't think this is a good idea. Why make this restriction? Also, see Phil's email in the "list keys" thread (http://www.ietf.org/mail-archive/web/netmod/current/msg00084.html) for an example of a use case where augment is used outside of a grouping. (Ok in this particular case there is a 'uses' just before the augment, but the use case is equally valid w/o the this uses) /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 10 09:52:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F022B3A6782; Sat, 10 May 2008 09:52:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35C73A67E9 for ; Sat, 10 May 2008 09:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atHbWjf2oHF2 for ; Sat, 10 May 2008 09:52:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1698D3A6782 for ; Sat, 10 May 2008 09:52:40 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 19E53D800C0; Sat, 10 May 2008 18:50:24 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4825BF98.3070407@andybierman.com> References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> <1210411928.31834.18.camel@missotis> <4825BF98.3070407@andybierman.com> Organization: CESNET Date: Sat, 10 May 2008 18:50:24 +0200 Message-Id: <1210438224.17865.28.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFNvIDEwLiAwNS4gMjAwOCB2IDA4OjMwIC0wNzAwOgo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+Li4uLgo+ID4gSSB3b3VsZCBzdGlsbCBwcmVmZXIgdG8g c3BlY2lmeSB0aGUgbW9kaWZpZXJzIHVzaW5nICJ5YW5nIHBhdGgiIGluIHNvbWUKPiA+IHdheSB0 aG91Z2guIElNTyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBjb250YWluZXJzIGFuZCBsZWFmcyBp c24ndCB0aGF0Cj4gPiBjcnVjaWFsIC0gYWZ0ZXIgYWxsLCBpbiBYTUwgZW5jb2RpbmcgdGhleSBh cmUgYWxsIGVsZW1lbnRzLgo+ID4gCj4gCj4gSSBwcmVmZXIgdG8gaGF2ZSBZQU5HIGJlIGEgaGln aC1sZXZlbCBETUwsIHdoaWNoIGhhcyBidWlsZGluZyBibG9ja3MKPiBjYWxsZWQgJ2NvbnRhaW5l cicsICdsaXN0JywgbGVhZicsIGV0Yy4gIEluIHRoZSBZQU5HIG1vZHVsZSwgSSBwcmVmZXIKPiBu b3QgdG8gcmVkdWNlIHRoZSBETSB0byBqdXN0IG1vcmUgWE1MLiAgVGhlcmUgYXJlIGFscmVhZHkg cGxlbnR5Cj4gb2YgRE1McyB0aGF0IGRvIHRoYXQsIGFuZCB3ZSBkb24ndCBuZWVkIGFub3RoZXIg b25lLgo+IAo+IFdoZW4gdGhlIG5vZGUgdHlwZSBpcyBhbHdheXMgdGhlIHNhbWUgKGUuZy4sIGRp cmVjdG9yaWVzIG9yCj4gWE1MIGVsZW1lbnRzKSwgdGhlbiB0aGUgJ2Zvby9iYXIvYmF6JyBzeW50 YXggaXMgYmVzdC4KPiBCdXQgd2hlbiB0aGUgbm9kZSB0eXBlIGlzIHZhcmlhYmxlLCB0aGVuIHRo aXMgc3ludGF4IGlzIG5vdCBleHBsaWNpdCBlbm91Z2guCgpJdCBpcyBleHBsaWNpdGx5IHJlY29y ZGVkIGluIHRoZSBncm91cGluZyB0aGF0IGlzIGJlaW5nIG1vZGlmaWVkIGFuZAp0aGlzIGdyb3Vw aW5nIG11c3QgYmUgY2hlY2tlZCBpbiBhbnkgY2FzZSBpbiBvcmRlciB0byBtYWtlIG9mIHRoZSB1 c2VzCnN0YXRlbWVudC4gQW5kIGZvciBhdWdtZW50cywgYWxsIHBhcnRzIG9mIHRoZSBwYXRoIG11 c3QgYmUgY29udGFpbmVycy4KQXMgUGhpbCBwb2ludGVkIG91dCwgdGhlIGFuYWxvZ3kgd2l0aCBm aWxlIHN5c3RlbSBwYXRocywgd2hlcmUgdGhlIHR5cGUKb2YgdGhlIGxhc3QgcGFydCBpcyBhbHNv IHZhcmlhYmxlLCBzaG91bGQgaGVscCB0aGUgdXNlcnMgdW5kZXJzdGFuZCB0aGUKbWVhbmluZy4K ClNvIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBpdCdzIGJldHRlciB0byBkaXN0aW5ndWlzaCByZWZp bmVtZW50cyBhbmQKYXVnbWVudHMgb2YgZ3JvdXBpbmdzIHN5bnRhY3RpY2FsbHksIGJ1dCBJIHdv dWxkIHVzZSB0aGUgcGF0aCBub3RhdGlvbgpmb3IgYm90aC4KCkxhZGEKCi0tIApMYWRpc2xhdiBM aG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Sat May 10 10:03:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF263A6782; Sat, 10 May 2008 10:03:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE3D3A67E9 for ; Sat, 10 May 2008 10:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-tIfzhPlGlz for ; Sat, 10 May 2008 10:03:44 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id A2D193A6782 for ; Sat, 10 May 2008 10:03:44 -0700 (PDT) Received: (qmail 41624 invoked from network); 10 May 2008 15:12:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 10 May 2008 15:12:39 -0000 X-YMail-OSG: RVGA1xgVM1le4Weygg0ilRhhRevgEzBaftqROaqrX6u3sHN7.kqym2D11PWq9JOzh4cYwGMGH3gnJysNCospC3m3VH3uBMWomFysrNTEuc8._B.PZ0lxBXf_dYpK6E3kI1I- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4825BB64.6070703@andybierman.com> Date: Sat, 10 May 2008 08:12:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> <1210411928.31834.18.camel@missotis> In-Reply-To: <1210411928.31834.18.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBww63FoWUgdiBT byAxMC4gMDUuIDIwMDggdiAwNzo0MSArMDIwMDoKPj4gT24gRnJpLCBNYXkgMDksIDIwMDggYXQg MTE6NTE6MDNQTSArMDIwMCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+PiAgCj4+PiAzLiBFeHBv cnQgb2Ygb3duIG5vZGVzIHRvIGEgZm9yZWlnbiBkYXRhIG1vZGVsIC0gbm93IGF1Z21lbnQgd2l0 aCBhbgo+Pj4gYWJzb2x1dGUgcGF0aC4gSSB0aGluayBhIG5ldyBzdGF0ZW1lbnQgaXMgYXBwcm9w cmlhdGUgaGVyZSwgcGVyaGFwcwo+Pj4KPj4+ICAgIGV4cG9ydCBmb3JlaWduLW1vZHVsZSB7Cj4+ PiAgICAgIC4uLi4KPj4+ICAgIH0KPj4+Cj4+PiBvciBzb21ldGhpbmcgc2ltaWxhci4KPj4gVGhp cyByZWFsbHkgaXMgdGhlIGNvcmUgb2YgYW4gYXVnbWVudCBhbmQgc2hvdWxkIGJlIGNhbGxlZCBh dWdtZW50Owo+PiBleHBvcnQgaXMgYSBjb25mdXNpbmcgbmFtZSBzaW5jZSB3ZSBhcmUgbm90IGV4 cG9ydGluZyBhbnl0aGluZy4KPiAKPiBTdXJlLCBpdCBjb3VsZCBiZSBjYWxsZWQgImF1Z21lbnQi LCBpZiB0aGlzIGtleXdvcmQgaXMgbm90IHVzZWQgZm9yCj4gc3BlY2lmeWluZyB0aGUgbW9kaWZp ZXJzIGluICJ1c2VzIi4gT25lIHdheSBmb3IgZG9pbmcgaXQgKHdpdGhvdXQgInlhbmcKPiBwYXRo IikgY291bGQgYmUgdGhpczoKPiAKPiB1c2VzIHNvbWUtZ3JvdXBpbmcgewo+ICAgY29udGFpbmVy IGZvbyB7Cj4gICAgIGxlYWYgYmFyIHsKPiAgICAgICBkZWZhdWx0IDYzNzg7Cj4gICAgIH0KPiAg IGNvbnRhaW5lciBiYXogewo+ICAgICBsZWFmIG1layB7Cj4gICAgICAgLi4uLgo+ICAgICB9Cj4g ICB9Cj4gfQo+IAo+IHdoZXJlIGZvby9iYXIgYnJhbmNoIGV4aXN0cyBpbiBzb21lLWdyb3VwaW5n IHdoaWxlIGJhei9tZWsgZG9lc24ndC4gU28sCj4gYXVnbWVudGluZyB0aGUgZ3JvdXBpbmcgaXMg aGFuZGxlZCBpbiB0aGUgc2FtZSB3YXkgYXMgcmVmaW5lbWVudHMgaGVyZSAtCj4gbm9kZXMgdGhh dCBkb24ndCBleGlzdCBpbiB0aGUgZ3JvdXBpbmcgYXJlIGp1c3QgYWRkZWQuCj4gCgoKTXkgIzEg Y29uY2VybiBpcyB0aGF0IHRoZSBETUwgYmUgcmVzaXN0YW50IHRvIGh1bWFuLWludHJvZHVjZWQK ZXJyb3JzLiAgVGhpcyBhcHByb2FjaCB3aWxsIHNpbGVudGx5IGdlbmVyYXRlIGEgbmV3IHN1Yi10 cmVlCmlmIHRoZSBpZGVudGlmaWVyIGlzIG1pcy1zcGVsbGVkLiAgSW5zdGVhZCBvZiBtb2RpZnlp bmcKY29udGFpbmVyICduYXonLCB0aGUgdXNlciBmYXQtZmluZ2VycyAnYmF6JywgYW5kIHRoZQpj b21waWxlciBkb2Vzbid0IGNvbXBsYWluIGF0IGFsbC4KCkkgcHJlZmVyIHRvIGtlZXAgdXNlcyBy ZWZpbmVtZW50cyBhbmQgbG9jYWwgYXVnbWVudHMgc2VwYXJhdGUuClRoZXkgYXJlIG5vdCB0aGUg c2FtZSB0aGluZyBpbiBjb25jZXB0IG9yIHN5bnRheC4KCkkgcHJlZmVyIHRvIG1ha2UgdGhlIHdy aXRlciAoYW5kIHJlYWRlcikgdmVyaWZ5CnRoYXQgdGhleSBhcmUgbW9kaWZ5aW5nIHRoZSBjb3Jy ZWN0IG5vZGUsIGFuZCBhbHNvIHByZWZlcgp0byBsZXQgdGhlIHJlYWRlciBzZWUgdGhlIHR5cGUg b2Ygbm9kZXMgdGhhdCBhcmUgYmVpbmcgbW9kaWZpZWQuClRoaXMgaXMgZWFzaWVyIHRvIHJlYWQg YW5kIGVhc2llciB0byB0cmFjayBkb3duIHRoZXNlIG5vZGVzCmVsc2V3aGVyZSAoaW4gd2hhdGV2 ZXIgbW9kdWxlIGhhcyB0aGUgZ3JvdXBpbmcpLgoKSXQgaXMgbm90IGltcG9ydGFudCB0aGF0IHRo ZSBjbGV2ZXIgRE0gd3JpdGVyIGtub3dzIHdoYXQKICAgJ3JlZmluZSBmb28vYmFyL2Jhei90YXov cGl6YXp6JyBtZWFucy4KClRoZSAxMDAwcyBvZiByZWFkZXJzIG1heSBub3QgYmUgc28gZmFtaWxp YXIgd2l0aCB0aGUgZGF0YSBtb2RlbAppcyB0aGlzIGNsZXZlciB3cml0ZXIuICBGb3IgdGhlbSwg c2VlaW5nIHRoZSBub2RlIHR5cGUgbWF5IG9mZmVyCm1vcmUgY29udGV4dCBhcyB0byB3aGF0IHRo ZSBjbGV2ZXIgd3JpdGVyIGlzIGRvaW5nLCBvciBhdCBsZWFzdApzb21lIG1vcmUgaGludHMgd2hh dCBrZXl3b3JkcyB0byB1c2UgaW4gdGhlIHNlYXJjaC4KCiAgIGNvbnRhaW5lciBmb28gewogICAg IGNob2ljZSBiYXIgewogICAgICAgY2FzZSBiYXogewogICAgICAgICBjb250YWluZXIgdGF6IHsK ICAgICAgICAgICBsZWFmIHBpemF6eiB7ICAuLi4uIH0KICAgICAgICAgfQogICAgICAgfQogICAg IH0KICAgfQoKT2YgY291cnNlIHRoaXMgaXMgbW9yZSB2ZXJib3NlIHRoYW4gJ2Zvby9iYXIvYmF6 L3Rhei9waXphenonLApidXQgaXQgaXMgbW9yZSB1c2VmdWwgdG8gdGhlIHJlYWRlci4KCgo+IEkg d291bGQgc3RpbGwgcHJlZmVyIHRvIHNwZWNpZnkgdGhlIG1vZGlmaWVycyB1c2luZyAieWFuZyBw YXRoIiBpbiBzb21lCj4gd2F5IHRob3VnaC4gSU1PIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGNv bnRhaW5lcnMgYW5kIGxlYWZzIGlzbid0IHRoYXQKPiBjcnVjaWFsIC0gYWZ0ZXIgYWxsLCBpbiBY TUwgZW5jb2RpbmcgdGhleSBhcmUgYWxsIGVsZW1lbnRzLgo+IAo+IExhZGEKPiAKPiBMYWRhCj4g Cj4+IC9qcwo+PgoKQW5keQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Sat May 10 10:19:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE613A6782; Sat, 10 May 2008 10:19:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5903A6785 for ; Sat, 10 May 2008 10:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogwob1wOB6IV for ; Sat, 10 May 2008 10:19:25 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id A53993A6782 for ; Sat, 10 May 2008 10:19:25 -0700 (PDT) Received: (qmail 33353 invoked from network); 10 May 2008 17:17:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 10 May 2008 17:17:30 -0000 X-YMail-OSG: hR_MSgsVM1lhtEEjeKWVfHzGwFI8gzBOEq7ADC4qaWT.R7Yci7xaxUUXV002UsZTM_jCMubtUS4ldmu97uD03tEXj.NAiY_Iq6G9c7qOM1YjeZajE2VbhX6_kfxYapuEEg4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4825D8A7.4060102@andybierman.com> Date: Sat, 10 May 2008 10:17:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> <1210411928.31834.18.camel@missotis> <4825BF98.3070407@andybierman.com> <1210438224.17865.28.camel@missotis> In-Reply-To: <1210438224.17865.28.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTbyAxMC4gMDUu IDIwMDggdiAwODozMCAtMDcwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+Pj4gLi4uLgo+ Pj4gSSB3b3VsZCBzdGlsbCBwcmVmZXIgdG8gc3BlY2lmeSB0aGUgbW9kaWZpZXJzIHVzaW5nICJ5 YW5nIHBhdGgiIGluIHNvbWUKPj4+IHdheSB0aG91Z2guIElNTyB0aGUgZGlzdGluY3Rpb24gYmV0 d2VlbiBjb250YWluZXJzIGFuZCBsZWFmcyBpc24ndCB0aGF0Cj4+PiBjcnVjaWFsIC0gYWZ0ZXIg YWxsLCBpbiBYTUwgZW5jb2RpbmcgdGhleSBhcmUgYWxsIGVsZW1lbnRzLgo+Pj4KPj4gSSBwcmVm ZXIgdG8gaGF2ZSBZQU5HIGJlIGEgaGlnaC1sZXZlbCBETUwsIHdoaWNoIGhhcyBidWlsZGluZyBi bG9ja3MKPj4gY2FsbGVkICdjb250YWluZXInLCAnbGlzdCcsIGxlYWYnLCBldGMuICBJbiB0aGUg WUFORyBtb2R1bGUsIEkgcHJlZmVyCj4+IG5vdCB0byByZWR1Y2UgdGhlIERNIHRvIGp1c3QgbW9y ZSBYTUwuICBUaGVyZSBhcmUgYWxyZWFkeSBwbGVudHkKPj4gb2YgRE1McyB0aGF0IGRvIHRoYXQs IGFuZCB3ZSBkb24ndCBuZWVkIGFub3RoZXIgb25lLgo+Pgo+PiBXaGVuIHRoZSBub2RlIHR5cGUg aXMgYWx3YXlzIHRoZSBzYW1lIChlLmcuLCBkaXJlY3RvcmllcyBvcgo+PiBYTUwgZWxlbWVudHMp LCB0aGVuIHRoZSAnZm9vL2Jhci9iYXonIHN5bnRheCBpcyBiZXN0Lgo+PiBCdXQgd2hlbiB0aGUg bm9kZSB0eXBlIGlzIHZhcmlhYmxlLCB0aGVuIHRoaXMgc3ludGF4IGlzIG5vdCBleHBsaWNpdCBl bm91Z2guCj4gCj4gSXQgaXMgZXhwbGljaXRseSByZWNvcmRlZCBpbiB0aGUgZ3JvdXBpbmcgdGhh dCBpcyBiZWluZyBtb2RpZmllZCBhbmQKPiB0aGlzIGdyb3VwaW5nIG11c3QgYmUgY2hlY2tlZCBp biBhbnkgY2FzZSBpbiBvcmRlciB0byBtYWtlIG9mIHRoZSB1c2VzCj4gc3RhdGVtZW50LgoKClRo ZSBncm91cGluZyBpcyBub3QgcHJlc2VudC4gIEp1c3QgdGhlIHVzZXMtc3RtdC4KCgo+IEFuZCBm b3IgYXVnbWVudHMsIGFsbCBwYXJ0cyBvZiB0aGUgcGF0aCBtdXN0IGJlIGNvbnRhaW5lcnMuCgpO b3QgdHJ1ZSAtLSB0aGlzIGlzIHdoZXJlIFlBTkcgZ2V0cyByZWFsbHkgbWVzc3kuCgpUaGUgY29u dGFpbm1lbnQgdHJlZSBjYW4gaGF2ZSAyIHR5cGVzIG9mIHNwZWNpYWwgdG9wLWxldmVsIG9ubHkg bm9kZXM6CiAgIC0gcnBjCiAgIC0gbm90aWZpY2F0aW9uCgpUaGUgY29udGFpbm1lbnQgdHJlZSBj YW4gaGF2ZSAyIHR5cGVzIG9mIHJlYWwgJ25vbi1sZWFmJyBub2RlczoKICAgLSBjb250YWluZXIK ICAgLSBsaXN0CgpUaGUgY29udGFpbm1lbnQgdHJlZSBjYW4gaGF2ZSAzIHR5cGVzIG9mIHJlYWwg bGVhZnM6CiAgIC0gbGVhZgogICAtIGxlYWYtbGlzdAogICAtIGFueXhtbAoKVGhlIGNvbnRhaW5t ZW50IHRyZWUgY2FuIGhhdmUgNCB0eXBlcyBvZiBtZXRhLW5vZGVzCnRoYXQgZG8gbm90IGdlbmVy YXRlIGFueSBYTUw6CiAgIC0gY2hvaWNlCiAgIC0gY2FzZQogICAtIGlucHV0CiAgIC0gb3V0cHV0 CgpUaGUgY29udGFpbm1lbnQgdHJlZSBjYW4gaGF2ZSAyIHR5cGVzIG9mIHVubmFtZWQgbm9kZXM6 CiAgIC0gdXNlcwogICAtIGF1Z21lbnQKCgoKCj4gQXMgUGhpbCBwb2ludGVkIG91dCwgdGhlIGFu YWxvZ3kgd2l0aCBmaWxlIHN5c3RlbSBwYXRocywgd2hlcmUgdGhlIHR5cGUKPiBvZiB0aGUgbGFz dCBwYXJ0IGlzIGFsc28gdmFyaWFibGUsIHNob3VsZCBoZWxwIHRoZSB1c2VycyB1bmRlcnN0YW5k IHRoZQo+IG1lYW5pbmcuCj4gCj4gU28gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGl0J3MgYmV0dGVy IHRvIGRpc3Rpbmd1aXNoIHJlZmluZW1lbnRzIGFuZAo+IGF1Z21lbnRzIG9mIGdyb3VwaW5ncyBz eW50YWN0aWNhbGx5LCBidXQgSSB3b3VsZCB1c2UgdGhlIHBhdGggbm90YXRpb24KPiBmb3IgYm90 aC4KPiAKPiBMYWRhCj4gCgoKQW5keQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Sat May 10 10:48:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B873A67E2; Sat, 10 May 2008 10:48:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34003A683B for ; Sat, 10 May 2008 10:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAwupINk9bJE for ; Sat, 10 May 2008 10:48:24 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id D6F913A67E2 for ; Sat, 10 May 2008 10:48:20 -0700 (PDT) Received: (qmail 24421 invoked from network); 10 May 2008 17:47:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 10 May 2008 17:47:18 -0000 X-YMail-OSG: Kf0MNgAVM1kN7xOiyBoA44oK6zMT6b4ctJzSRYH7gKu3SkRFwwdbpTOej1sXeeJsXvXJfN67A.651KFNntyTACJT64xm80sDbYy7roQaeLkvGSNO8jplU_j5tPI5KItvuq8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4825DFA2.8080403@andybierman.com> Date: Sat, 10 May 2008 10:47:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> <1210411928.31834.18.camel@missotis> <4825BF98.3070407@andybierman.com> <1210438224.17865.28.camel@missotis> In-Reply-To: <1210438224.17865.28.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: >... > So I agree with you that it's better to distinguish refinements and > augments of groupings syntactically, but I would use the path notation > for both. > Don't forget to leave out the prefixes for the special case nodes called 'input' and 'output', since they are in the YANG meta-space, not any XML namespace. augment /nc:edit-config/input { leaf my-param { ... } } E.g: 17 Of course, the other meta-nodes 'choice' and 'case' have names, so they must have prefixes specified, to clarify which module the name is from. Case names and real node names can collide, but it should be obvious if you see the same node name twice that it's probably a single-node case-arm within a choice. augment foo/bar/baz/taz/pizazz/name Once you hunt down all the node definitions (nobody would ever make you hunt down a generic node name like 'name' or 'type', right?), it it clear what the model looks like after the augment. I would rather make the writer hunt down the node types once, than make every reader do this every time they read the module. > Lada > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun May 11 14:24:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DD03A6857; Sun, 11 May 2008 14:24:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361D73A6886 for ; Sun, 11 May 2008 14:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVOdD0a+bAkX for ; Sun, 11 May 2008 14:24:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BB7D03A6857 for ; Sun, 11 May 2008 14:24:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24E7AC000E; Sun, 11 May 2008 23:24:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mqL3CcEg0xjt; Sun, 11 May 2008 23:24:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9EEBC000D; Sun, 11 May 2008 23:24:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F395D577841; Sun, 11 May 2008 23:24:03 +0200 (CEST) Date: Sun, 11 May 2008 23:24:03 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080511212403.GA7476@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , NETMOD Working Group References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> <1210411928.31834.18.camel@missotis> <4825BB64.6070703@andybierman.com> MIME-Version: 1.0 In-Reply-To: <4825BB64.6070703@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0090556762==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org --===============0090556762== Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sat, May 10, 2008 at 08:12:36AM -0700, Andy Bierman wrote: > The 1000s of readers may not be so familiar with the data model > is this clever writer. For them, seeing the node type may offer > more context as to what the clever writer is doing, or at least > some more hints what keywords to use in the search. > > container foo { > choice bar { > case baz { > container taz { > leaf pizazz { .... } > } > } > } > } > > Of course this is more verbose than 'foo/bar/baz/taz/pizazz', > but it is more useful to the reader. I guess this is subjective. For me, the noise kind of hides what is being refinedÂat the end. Perhaps I belong to the other 1000s of readers of this definition. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --===============0090556762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============0090556762==-- From netmod-bounces@ietf.org Sun May 11 15:13:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB583A698A; Sun, 11 May 2008 15:13:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2783A6B36 for ; Sun, 11 May 2008 15:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI67KRg1NIBF for ; Sun, 11 May 2008 15:13:34 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 6FBE13A6B2E for ; Sun, 11 May 2008 15:13:30 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Sun, 11 May 2008 15:13:27 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 May 2008 15:08:38 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4BM8bx19415; Sun, 11 May 2008 15:08:37 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4BM6lT1088608; Sun, 11 May 2008 22:06:48 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805112206.m4BM6lT1088608@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1210411928.31834.18.camel@missotis> Date: Sun, 11 May 2008 18:06:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2008 22:08:38.0221 (UTC) FILETIME=[90572FD0:01C8B3B3] Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >where foo/bar branch exists in some-grouping while baz/mek doesn't. So, >augmenting the grouping is handled in the same way as refinements here - >nodes that don't exist in the grouping are just added. This would mean the reader doesn't know what's a refinement and what's an augmentation, so this would be very confusing. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun May 11 15:13:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A82D3A6B2E; Sun, 11 May 2008 15:13:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8653A6B2E for ; Sun, 11 May 2008 15:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdzEQAqq6z4M for ; Sun, 11 May 2008 15:13:36 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 6FC0D3A6B34 for ; Sun, 11 May 2008 15:13:30 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Sun, 11 May 2008 15:13:27 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 May 2008 15:07:47 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4BM7kx19307; Sun, 11 May 2008 15:07:46 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4BM5vj8088592; Sun, 11 May 2008 22:05:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805112205.m4BM5vj8088592@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080511212403.GA7476@elstar.local> Date: Sun, 11 May 2008 18:05:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2008 22:07:47.0517 (UTC) FILETIME=[721E5ED0:01C8B3B3] Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1732346934==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org --===============1732346934== Juergen Schoenwaelder writes: >I guess this is subjective. For me, the noise kind of hides what is >being refinedÂat the end. Perhaps I belong to the other 1000s of >readers of this definition. ;-) I concur. The first question the contents of the "uses" statement must answer is "what's being refined?". The noise words mask this. Thanks, Phil --===============1732346934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============1732346934==-- From netmod-bounces@ietf.org Mon May 12 02:12:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5148B3A680F; Mon, 12 May 2008 02:12:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF663A680F for ; Mon, 12 May 2008 02:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg80VtYab10R for ; Mon, 12 May 2008 02:12:06 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id B219A3A6782 for ; Mon, 12 May 2008 02:12:02 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 89B4C1B80C5; Mon, 12 May 2008 10:12:03 +0200 (CEST) Date: Mon, 12 May 2008 10:12:26 +0200 (CEST) Message-Id: <20080512.101226.18726538.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805112206.m4BM6lT1088608@idle.juniper.net> References: <1210411928.31834.18.camel@missotis> <200805112206.m4BM6lT1088608@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Phil Shafer wrote: > Ladislav Lhotka writes: > >where foo/bar branch exists in some-grouping while baz/mek doesn't. So, > >augmenting the grouping is handled in the same way as refinements here - > >nodes that don't exist in the grouping are just added. > > This would mean the reader doesn't know what's a refinement and > what's an augmentation, so this would be very confusing. Not with the new proposed syntax: uses something { refine eh/be/sea { } augment eh/be { leaf my-new-leaf { ... } } } I think this syntax makes it very clear what the intention is. I was going to say that based on experience I didn't like the new syntax. In our proprietary DML we use this proposed syntax to add implementation-specific annotations to data models - things like hints to the code generator etc. The idea is that the data model can be clean and additional annotation files can be used to guide the code generation. This syntax is fine when there are just a few modifications. But if you have to list every node in the tree as a separate path, it gets messy - more verbose and error-prone. Compare: uses something { refine eh { } refine eh/be/sea { } refine eh/be/seb { } refine eh/be/seb { } } vs. uses something { container eh { container be { leaf sea { } leaf seb { } leaf sec { } } } } If we anticipate large, deep groupings where people often make many refinements, then the original syntax is better. If groupings are smaller and/or people don't refine eveything, then the proposed syntax is more clear. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 02:13:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD043A6782; Mon, 12 May 2008 02:13:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE2D3A684A for ; Mon, 12 May 2008 02:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woGceU5BY7Qc for ; Mon, 12 May 2008 02:13:08 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 665873A6782 for ; Mon, 12 May 2008 02:13:08 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 813F91B80CE; Mon, 12 May 2008 10:14:42 +0200 (CEST) Date: Mon, 12 May 2008 10:15:05 +0200 (CEST) Message-Id: <20080512.101505.07904375.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4825DFA2.8080403@andybierman.com> References: <4825BF98.3070407@andybierman.com> <1210438224.17865.28.camel@missotis> <4825DFA2.8080403@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Ladislav Lhotka wrote: > >... > > So I agree with you that it's better to distinguish refinements and > > augments of groupings syntactically, but I would use the path notation > > for both. > > > > Don't forget to leave out the prefixes for the special case nodes > called 'input' and 'output', since they are in the YANG meta-space, > not any XML namespace. > > augment /nc:edit-config/input { > leaf my-param { ... } > } No, the spec currently says: The "input" statement defines an input node in the schema tree, with the name "input". So the 'input' node *is* in the same schema tree just like the other nodes. Thus the correct syntax is: augment /nc:edit-config/nc:input { leaf my-param { ... } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 04:33:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2FC3A67F9; Mon, 12 May 2008 04:33:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C78A3A6910 for ; Mon, 12 May 2008 04:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYplmjw0RNAX for ; Mon, 12 May 2008 04:33:08 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 7BCC73A6906 for ; Mon, 12 May 2008 04:33:08 -0700 (PDT) Received: (qmail 53002 invoked from network); 12 May 2008 11:26:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 12 May 2008 11:26:04 -0000 X-YMail-OSG: Jje5F_8VM1mo6tYa6ono_KTmdypxxzTdTNY8f_3PAUI.btg3gZOuUDUJlwH5xs588DRejqzoYpoYYfPcfVirzxIf9w36PQ7xNH9O9RhrIb906v2n.oBBAuxxrTaBPhYgrRg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4828294A.5000609@andybierman.com> Date: Mon, 12 May 2008 04:26:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <4825BF98.3070407@andybierman.com> <1210438224.17865.28.camel@missotis> <4825DFA2.8080403@andybierman.com> <20080512.101505.07904375.mbj@tail-f.com> In-Reply-To: <20080512.101505.07904375.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Ladislav Lhotka wrote: >>> ... >>> So I agree with you that it's better to distinguish refinements and >>> augments of groupings syntactically, but I would use the path notation >>> for both. >>> >> Don't forget to leave out the prefixes for the special case nodes >> called 'input' and 'output', since they are in the YANG meta-space, >> not any XML namespace. >> >> augment /nc:edit-config/input { >> leaf my-param { ... } >> } > > No, the spec currently says: > > The "input" statement defines an input node in the schema tree, with > the name "input". > > So the 'input' node *is* in the same schema tree just like the other > nodes. Thus the correct syntax is: > > augment /nc:edit-config/nc:input { > leaf my-param { ... } > } > I don't see how the current text says one way or another that there are N instances of the 'input' keyword, each in its own namespace (nc:input, foo:input, bar:input). IMO, 'input' is a YANG keyword, and YANG keywords MUST NOT have prefixes. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 06:12:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DE73A68D9; Mon, 12 May 2008 06:12:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A07A28C22B for ; Mon, 12 May 2008 06:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeR6oAZC7sYg for ; Mon, 12 May 2008 06:12:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 26F4728C21C for ; Mon, 12 May 2008 06:12:01 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 6CB73D800C4; Mon, 12 May 2008 15:11:45 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4825D8A7.4060102@andybierman.com> References: <200805091315.m49DFPqX075864@idle.juniper.net> <4824656C.9040701@andybierman.com> <1210369863.6133.27.camel@missotis> <20080510054138.GA6218@elstar.local> <1210411928.31834.18.camel@missotis> <4825BF98.3070407@andybierman.com> <1210438224.17865.28.camel@missotis> <4825D8A7.4060102@andybierman.com> Organization: CESNET Date: Mon, 12 May 2008 15:11:45 +0200 Message-Id: <1210597905.17370.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: NETMOD Working Group Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFNvIDEwLiAwNS4gMjAwOCB2IDEwOjE3IC0wNzAwOgo+ID4g Cj4gPiBJdCBpcyBleHBsaWNpdGx5IHJlY29yZGVkIGluIHRoZSBncm91cGluZyB0aGF0IGlzIGJl aW5nIG1vZGlmaWVkIGFuZAo+ID4gdGhpcyBncm91cGluZyBtdXN0IGJlIGNoZWNrZWQgaW4gYW55 IGNhc2UgaW4gb3JkZXIgdG8gbWFrZSBvZiB0aGUgdXNlcwo+ID4gc3RhdGVtZW50Lgo+IAo+IAo+ IFRoZSBncm91cGluZyBpcyBub3QgcHJlc2VudC4gIEp1c3QgdGhlIHVzZXMtc3RtdC4KPiAKCklm IHRoZSBncm91cGluZyBpcyBub3QgcHJlc2VudCwgdGhlIHBlcnNvbiB3YW50aW5nIHRvIGdldCBz ZW5zZSBvZiB0aGUKZGF0YSBtb2RlbCBzaG91bGQgZmluZCB0aGUgbW9kdWxlIHdoZXJlIGl0IGlz IGRlZmluZWQgLSBhbmQgaXQgY2FuIGJlCmVhc2lseSBzZWVuIHRoZXJlIHdoYXQgdGhlIHJlZmlu ZW1lbnQgYW5kL29yIGF1Z21lbnQgbWVhbi4KCkxhZGEgCgotLSAKTGFkaXNsYXYgTGhvdGthLCBD RVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon May 12 06:32:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B463A681C; Mon, 12 May 2008 06:32:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0F03A681C for ; Mon, 12 May 2008 06:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrK2mgYTwRiX for ; Mon, 12 May 2008 06:32:31 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 3B7BA3A6885 for ; Mon, 12 May 2008 06:32:29 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Mon, 12 May 2008 06:32:26 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 06:31:28 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4CDVRx38917; Mon, 12 May 2008 06:31:27 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4CDTbm7096671; Mon, 12 May 2008 13:29:37 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805121329.m4CDTbm7096671@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080512.101505.07904375.mbj@tail-f.com> Date: Mon, 12 May 2008 09:29:37 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2008 13:31:28.0345 (UTC) FILETIME=[7B819C90:01C8B434] Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >So the 'input' node *is* in the same schema tree just like the other >nodes. Thus the correct syntax is: > augment /nc:edit-config/nc:input { > leaf my-param { ... } > } I agree that "input" is there, but don't see it having a namespace/prefix. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 07:13:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631603A6885; Mon, 12 May 2008 07:13:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A133A6B8D for ; Mon, 12 May 2008 07:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIQr9TNOP7-r for ; Mon, 12 May 2008 07:13:27 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 180A13A6884 for ; Mon, 12 May 2008 07:11:41 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id D6B901B80C5; Mon, 12 May 2008 15:43:19 +0200 (CEST) Date: Mon, 12 May 2008 15:43:43 +0200 (CEST) Message-Id: <20080512.154343.144630761.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4828294A.5000609@andybierman.com> References: <4825DFA2.8080403@andybierman.com> <20080512.101505.07904375.mbj@tail-f.com> <4828294A.5000609@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > Andy Bierman wrote: > >> Ladislav Lhotka wrote: > >>> ... > >>> So I agree with you that it's better to distinguish refinements and > >>> augments of groupings syntactically, but I would use the path notation > >>> for both. > >>> > >> Don't forget to leave out the prefixes for the special case nodes > >> called 'input' and 'output', since they are in the YANG meta-space, > >> not any XML namespace. > >> > >> augment /nc:edit-config/input { > >> leaf my-param { ... } > >> } > > > > No, the spec currently says: > > > > The "input" statement defines an input node in the schema tree, with > > the name "input". > > > > So the 'input' node *is* in the same schema tree just like the other > > nodes. Thus the correct syntax is: > > > > augment /nc:edit-config/nc:input { > > leaf my-param { ... } > > } > > > > > I don't see how the current text says one way or another > that there are N instances of the 'input' keyword, > each in its own namespace (nc:input, foo:input, bar:input). > > IMO, 'input' is a YANG keyword, and YANG keywords MUST NOT have prefixes. The text says that the 'input' keyword defines a node in the schema tree. Compare with the 'container' keyword - it also defines a node in the schema tree. The difference is that 'input' defines a node with a static name ("input"), where 'container' takes the name as argument. So this construct: rpc foo { input { container bar { ... } } } defines three nodes in the schema tree: foo |__ input |___ bar By saying that "input" is just another node in the schema tree, the explanation of 'augment' is easier and consistent. If we say that the nodes "input" and "output" are special and not really part of the schema tree, we have to treat them different when we describe how augment works. I think the current solution is simpler. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 07:38:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9313A67AC; Mon, 12 May 2008 07:38:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21EB3A6849 for ; Mon, 12 May 2008 07:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbfuoqX7WYfJ for ; Mon, 12 May 2008 07:38:11 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 223EB3A67AC for ; Mon, 12 May 2008 07:38:11 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 6068F1B80C5; Mon, 12 May 2008 16:37:20 +0200 (CEST) Date: Mon, 12 May 2008 16:37:44 +0200 (CEST) Message-Id: <20080512.163744.232560997.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: [netmod] Conditional content [was: refinements and augments] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Ladislav Lhotka wrote: > What is IMO more important is that augment is now in fact used for three > different functions: > > 1. Conditional content: > > augment . { > when condition; > .... > } > > This could be replaced by a simpler and clearer statement > > when condition { > .... > } > > with exactly the same semantics. It could be allowed in the same places > as augment is now. So instead of: augment /foo/bar { when ""; ... } I would write: when "" { augment /foo/bar { ... } } I suppose I also can write: when "" { leaf foo { ... } } and also: when "" { leaf bar { mandatory "true"; ... } container baz { presence "..."; ... } } Which means that if "" is true, then "bar" MUST exist in a valid configuration and "foo" MAY exist. If "" is false, both "foo" and "bar" MUST NOT exist in a valid configuration. Can I do: when "a > b" { must "b < 42"; } On the plus side it has a similar synatx as the proposed when-capability: when-capability foo { leaf bar { mandatory true; ... } } This says that if the capability "foo" is advertised, then the leaf bar MUST exist in a valid configuration. I have to think some more about the similarities / differences with 'must'... /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 08:13:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08243A6889; Mon, 12 May 2008 08:13:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27F33A68FF for ; Mon, 12 May 2008 08:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOnPka9PnU+s for ; Mon, 12 May 2008 08:13:12 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 5EECE3A67B6 for ; Mon, 12 May 2008 08:13:04 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Mon, 12 May 2008 08:12:45 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 08:13:01 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4CFD0x91726; Mon, 12 May 2008 08:13:00 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4CFBAZ1097289; Mon, 12 May 2008 15:11:10 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805121511.m4CFBAZ1097289@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080512.163744.232560997.mbj@tail-f.com> Date: Mon, 12 May 2008 11:11:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2008 15:13:01.0028 (UTC) FILETIME=[AB074240:01C8B442] Cc: netmod@ietf.org Subject: Re: [netmod] Conditional content [was: refinements and augments] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: > augment /foo/bar { > when ""; > ... > } Having the "when" inside the node has two advantages. First we can define other conditional mechanisms, like "when-capability". Second, the contents of the "when" statement are fixed, not dependent on the location of the statement in the module. If the when is the parent, the contents may vary. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 08:35:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3F03A69A7; Mon, 12 May 2008 08:35:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DB03A69A7 for ; Mon, 12 May 2008 08:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpTy-tE8Ned8 for ; Mon, 12 May 2008 08:35:13 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id D5A193A6AF1 for ; Mon, 12 May 2008 08:35:12 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id B3DE01B80C5; Mon, 12 May 2008 17:35:09 +0200 (CEST) Date: Mon, 12 May 2008 17:34:51 +0200 (CEST) Message-Id: <20080512.173451.91952772.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <20080512.163744.232560997.mbj@tail-f.com> References: <20080512.163744.232560997.mbj@tail-f.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Conditional content X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Martin Bjorklund wrote: > On the plus side it has a similar synatx as the proposed > when-capability: > > when-capability foo { > leaf bar { > mandatory true; > ... > } > } Sorry, my mistake. The proposed 'when-capability' has the same syntax as the current 'when'. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 09:01:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D36D3A6867; Mon, 12 May 2008 09:01:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AC63A68B4 for ; Mon, 12 May 2008 09:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RXQvOFDQpLB for ; Mon, 12 May 2008 09:01:26 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 5AB9B3A676A for ; Mon, 12 May 2008 09:01:26 -0700 (PDT) Received: (qmail 88508 invoked from network); 12 May 2008 16:01:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 12 May 2008 16:01:20 -0000 X-YMail-OSG: bYxqdj8VM1mjPt2pXwmO9HRiVhGf5rY3jCdeeH.NrCm8.1koXFce7w7yDosxHQN3B8B_NWDEGHoZieVlIQfmIXyjJwGcsYk7uKkM9RQ8jCroxPTmf82FaAOTpbPxFTeRyLQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <482869CF.5080304@andybierman.com> Date: Mon, 12 May 2008 09:01:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <4825DFA2.8080403@andybierman.com> <20080512.101505.07904375.mbj@tail-f.com> <4828294A.5000609@andybierman.com> <20080512.154343.144630761.mbj@tail-f.com> In-Reply-To: <20080512.154343.144630761.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> >>> Andy Bierman wrote: >>>> Ladislav Lhotka wrote: >>>>> ... >>>>> So I agree with you that it's better to distinguish refinements and >>>>> augments of groupings syntactically, but I would use the path notation >>>>> for both. >>>>> >>>> Don't forget to leave out the prefixes for the special case nodes >>>> called 'input' and 'output', since they are in the YANG meta-space, >>>> not any XML namespace. >>>> >>>> augment /nc:edit-config/input { >>>> leaf my-param { ... } >>>> } >>> No, the spec currently says: >>> >>> The "input" statement defines an input node in the schema tree, with >>> the name "input". >>> >>> So the 'input' node *is* in the same schema tree just like the other >>> nodes. Thus the correct syntax is: >>> >>> augment /nc:edit-config/nc:input { >>> leaf my-param { ... } >>> } >>> >> >> I don't see how the current text says one way or another >> that there are N instances of the 'input' keyword, >> each in its own namespace (nc:input, foo:input, bar:input). >> >> IMO, 'input' is a YANG keyword, and YANG keywords MUST NOT have prefixes. > > The text says that the 'input' keyword defines a node in the schema > tree. Compare with the 'container' keyword - it also defines a node > in the schema tree. The difference is that 'input' defines a node > with a static name ("input"), where 'container' takes the name as > argument. So this construct: > > rpc foo { > input { > container bar { ... } > } > } > > defines three nodes in the schema tree: > > foo > |__ input > |___ bar > > > By saying that "input" is just another node in the schema tree, the > explanation of 'augment' is easier and consistent. If we say that the > nodes "input" and "output" are special and not really part of the > schema tree, we have to treat them different when we describe how > augment works. I think the current solution is simpler. > Except that this is valid too: augment nc:close-session { input { leaf close-log-message { type string; } } } This is where it gets confusing. The node 'input' is a meta-node that does not produce any XML. It is special because there can only be one of them. There is no 'nc:input' and separate 'foo:input' nodes. If the 'input' node already exists, then the augment cannot add it again, or it is an error. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 15:02:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77DB3A6767; Mon, 12 May 2008 15:02:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A9C3A6B88 for ; Mon, 12 May 2008 15:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mavZ2Ee+XOj for ; Mon, 12 May 2008 15:02:53 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 6F0F53A6767 for ; Mon, 12 May 2008 15:02:52 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id A148C1B80C5; Tue, 13 May 2008 00:02:48 +0200 (CEST) Date: Tue, 13 May 2008 00:02:29 +0200 (CEST) Message-Id: <20080513.000229.193340456.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <482869CF.5080304@andybierman.com> References: <4828294A.5000609@andybierman.com> <20080512.154343.144630761.mbj@tail-f.com> <482869CF.5080304@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Martin Bjorklund wrote: > > By saying that "input" is just another node in the schema tree, the > > explanation of 'augment' is easier and consistent. If we say that the > > nodes "input" and "output" are special and not really part of the > > schema tree, we have to treat them different when we describe how > > augment works. I think the current solution is simpler. > > > > Except that this is valid too: > > augment nc:close-session { > input { > leaf close-log-message { type string; } > } > } > > > This is where it gets confusing. > The node 'input' is a meta-node that does not produce any XML. > It is special because there can only be one of them. > There is no 'nc:input' and separate 'foo:input' nodes. > If the 'input' node already exists, then the augment cannot > add it again, or it is an error. You're right, but this makes the augment above broken. Consider the following: module a { ... augment nc:close-session { input { leaf close-log-message { type string; } } } } and module b { ... augment nc:close-session { input { leaf close-log-reason { type string; } } } } The problem is that once the input node exists, it cannot be created in another augment. But 'a' and 'b' might not know of each other. There are a couple of solutions: 1. don't allow augment to add the input and output nodes 2. specify that when input/output is used in an augment, the node is added if it doesn't exist, and just merged if it does exist. this makes it really different from normal augmentation... 3. say that the input and output nodes _always_ exist when an rpc is created. if input doesn't have any children then the rpc doesn't expect any parameters in the XML encoding, and similar for output. Any other alternatives? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon May 12 16:16:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED1328C2B8; Mon, 12 May 2008 16:16:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46F528C2B3 for ; Mon, 12 May 2008 16:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV6zxZfMTSRG for ; Mon, 12 May 2008 16:16:27 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 28EC628C2AB for ; Mon, 12 May 2008 16:16:26 -0700 (PDT) Received: (qmail 96976 invoked from network); 12 May 2008 23:16:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 12 May 2008 23:16:23 -0000 X-YMail-OSG: jiGT_CUVM1kd_rG3tjMxtcDmiso4lheJofT1H9y2.N3whKaPiFMBBUy2vEBiXZy6zn51IH33FXrB7XLKyjBLTHtb9OQoQeUNPHEiQBMADUnl4I5fES_2NN_W31gO9xjMVW8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4828CFC6.2020109@andybierman.com> Date: Mon, 12 May 2008 16:16:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <4828294A.5000609@andybierman.com> <20080512.154343.144630761.mbj@tail-f.com> <482869CF.5080304@andybierman.com> <20080513.000229.193340456.mbj@tail-f.com> In-Reply-To: <20080513.000229.193340456.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> By saying that "input" is just another node in the schema tree, the >>> explanation of 'augment' is easier and consistent. If we say that the >>> nodes "input" and "output" are special and not really part of the >>> schema tree, we have to treat them different when we describe how >>> augment works. I think the current solution is simpler. >>> >> Except that this is valid too: >> >> augment nc:close-session { >> input { >> leaf close-log-message { type string; } >> } >> } >> >> >> This is where it gets confusing. >> The node 'input' is a meta-node that does not produce any XML. >> It is special because there can only be one of them. >> There is no 'nc:input' and separate 'foo:input' nodes. >> If the 'input' node already exists, then the augment cannot >> add it again, or it is an error. > > You're right, but this makes the augment above broken. Consider the > following: > > module a { > ... > augment nc:close-session { > input { > leaf close-log-message { type string; } > } > } > } > > and > > module b { > ... > augment nc:close-session { > input { > leaf close-log-reason { type string; } > } > } > } > > The 'input' and 'output' nodes are special this way ;-) The different namespaces keep all other Descendant-schema-nodeid components distinct. This is good, because we have no way of knowing if modules A and B will be used together, and therefore clash. This design problem does not exist for any other nodes. > The problem is that once the input node exists, it cannot be created > in another augment. But 'a' and 'b' might not know of each other. > > There are a couple of solutions: > > 1. don't allow augment to add the input and output nodes > > 2. specify that when input/output is used in an augment, the node > is added if it doesn't exist, and just merged if it does > exist. this makes it really different from normal > augmentation... > > 3. say that the input and output nodes _always_ exist when an rpc > is created. if input doesn't have any children then the rpc > doesn't expect any parameters in the XML encoding, and similar > for output. > does (3) mean that the input/output forms of augment go away completely? I kind of like that approach. > Any other alternatives? > > > > /martin > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue May 13 00:17:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DC23A6803; Tue, 13 May 2008 00:17:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F993A6835 for ; Tue, 13 May 2008 00:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPKsWJSkdHeU for ; Tue, 13 May 2008 00:17:05 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 636C83A6803 for ; Tue, 13 May 2008 00:17:05 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id D7AF91B80C5; Tue, 13 May 2008 09:15:03 +0200 (CEST) Date: Tue, 13 May 2008 09:15:28 +0200 (CEST) Message-Id: <20080513.091528.228088491.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4828CFC6.2020109@andybierman.com> References: <482869CF.5080304@andybierman.com> <20080513.000229.193340456.mbj@tail-f.com> <4828CFC6.2020109@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinements and augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Martin Bjorklund wrote: > > The problem is that once the input node exists, it cannot be created > > in another augment. But 'a' and 'b' might not know of each other. > > > > There are a couple of solutions: > > > > 1. don't allow augment to add the input and output nodes > > > > 2. specify that when input/output is used in an augment, the node > > is added if it doesn't exist, and just merged if it does > > exist. this makes it really different from normal > > augmentation... > > > > 3. say that the input and output nodes _always_ exist when an rpc > > is created. if input doesn't have any children then the rpc > > doesn't expect any parameters in the XML encoding, and similar > > for output. > > > > does (3) mean that the input/output forms of augment go away > completely? I kind of like that approach. Yes. Something like: The "rpc" statement defines three nodes in the schema tree. One top-level node with same name as the RPC method, and two child nodes "input" and "output", which are used to hold input parameters and response data to the RPC method respectively. The text about "input" must be modified to say that the "input" statement adds nodes to the "input" schema node. Since the input schema node always exist, the follwoing would be legal: augment /nc:close-session/nc:input { leaf close-log-message { type string; } } even though the input statement is not used in the defintion of close-session. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 14 06:26:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3829A3A6985; Wed, 14 May 2008 06:26:37 -0700 (PDT) X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 698C53A6954; Wed, 14 May 2008 06:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080514130001.698C53A6954@core3.amsl.com> Date: Wed, 14 May 2008 06:00:01 -0700 (PDT) X-Mailman-Approved-At: Wed, 14 May 2008 06:26:36 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-00.txt Pages : 153 Date : 2008-05-05 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-14055143.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --NextPart-- From netmod-bounces@ietf.org Wed May 14 10:46:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E743A69DD; Wed, 14 May 2008 10:46:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E7E28C106 for ; Wed, 14 May 2008 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e04XzbXyHlIp for ; Wed, 14 May 2008 10:45:57 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 63AAF3A6A12 for ; Wed, 14 May 2008 10:45:57 -0700 (PDT) Received: (qmail 53200 invoked from network); 14 May 2008 17:45:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 14 May 2008 17:45:07 -0000 X-YMail-OSG: sI2TevAVM1luDRxWekVx1ybTk1LlGMKSvx639x33zh32a_lCiNkt1w3f9U_4TKO4GkUQuX0RIaC5L6k8YFtCwcMSr9gWNMbtfdN.fF.fEAyuLbmZlTpzEyvBbg6JjxI93Y4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <482B2520.1060400@andybierman.com> Date: Wed, 14 May 2008 10:45:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I think the application of the 'mandatory-stmt' should be more consistent throughout the language. It is allowed within: - leaf - choice - anyxml It is not allowed within: - container - leaf-list - list - case I realize that container has 'presence' and leaf-list/list have the 'min-elements' clauses instead. IMO, a case-stmt should allow mandatory-stmt to be present. This is just an omission. The use case is simply to reduce the duplication. choice foo { mandatory false; case A { mandatory true; // same as if 'mandatory true;' was present in // every node in the A case-arm } } A container should also allow the mandatory-stmt. This is different than the presence-stmt, which only provides a description of what it means *if* the container is present. For consistency, the mandatory-stmt should be allowed in leaf-list and list, but must be consistent with 'min-elements' if also present: mandatory true; --> min-elements 1; mandatory false; --> min-elements 0; // default Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 14 12:22:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE863A6781; Wed, 14 May 2008 12:22:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C093A6811 for ; Wed, 14 May 2008 12:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbXgtP2u7Q7Y for ; Wed, 14 May 2008 12:22:10 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 044F23A6781 for ; Wed, 14 May 2008 12:22:10 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id E98BC1B80D4; Wed, 14 May 2008 21:21:08 +0200 (CEST) Date: Wed, 14 May 2008 21:20:48 +0200 (CEST) Message-Id: <20080514.212048.175582205.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <482B2520.1060400@andybierman.com> References: <482B2520.1060400@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Hi, > > I think the application of the 'mandatory-stmt' should > be more consistent throughout the language. [...] > IMO, a case-stmt should allow mandatory-stmt to be present. > This is just an omission. The use case is simply to > reduce the duplication. > > choice foo { > mandatory false; > case A { > mandatory true; > // same as if 'mandatory true;' was present in > // every node in the A case-arm > } > } I would argue that the meaning of 'mandatory true' in your proposal above is inconsistent with the other applications of 'mandatory' we have. In your proposal it affects not the current node but child nodes. Can I override this in individual nodes in the case branch: case A { mandatory true; leaf foo { mandatory false; } } > A container should also allow the mandatory-stmt. > This is different than the presence-stmt, which only provides > a description of what it means *if* the container is present. We had long discussions in the design team about this. What does it mean that a container is mandatory? That it MUST be present in the config? If the container is always there it does not carry any semantic meaning. We do this with "non-presence" containers today. Do you suggest that if mandatory is true on a container, then the presence statement MUST NOT be there, and vice versa? Or do you suggest that mandatory true works like in the case statement above? > For consistency, the mandatory-stmt should be allowed in leaf-list > and list, but must be consistent with 'min-elements' if also present: > > mandatory true; --> min-elements 1; > mandatory false; --> min-elements 0; // default I don't agree that it's more consistent to use a statement in places where it doesn't add any value. Or do you think it adds value? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 14 14:22:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832123A63D2; Wed, 14 May 2008 14:22:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A969C3A63D3 for ; Wed, 14 May 2008 14:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNMh6+MZkJR9 for ; Wed, 14 May 2008 14:22:14 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id E1FC83A63D2 for ; Wed, 14 May 2008 14:22:14 -0700 (PDT) Received: (qmail 62946 invoked from network); 14 May 2008 21:21:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 14 May 2008 21:21:25 -0000 X-YMail-OSG: nsIaBAsVM1madNU3CZ.RbcTuRs4_AdXdTFEElnuTtP6kWK7ZJZGjdfbf2wEhAoL2gSXcKiZ1VoAshBJIM9TU4MEKdxskEGhuE_duS1UgIAqiZI7E.fcgGsUhd2slZ97AgiE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <482B57D2.5050201@andybierman.com> Date: Wed, 14 May 2008 14:21:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <482B2520.1060400@andybierman.com> <20080514.212048.175582205.mbj@tail-f.com> In-Reply-To: <20080514.212048.175582205.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> I think the application of the 'mandatory-stmt' should >> be more consistent throughout the language. > > [...] > >> IMO, a case-stmt should allow mandatory-stmt to be present. >> This is just an omission. The use case is simply to >> reduce the duplication. >> >> choice foo { >> mandatory false; >> case A { >> mandatory true; >> // same as if 'mandatory true;' was present in >> // every node in the A case-arm >> } >> } > > I would argue that the meaning of 'mandatory true' in your proposal > above is inconsistent with the other applications of 'mandatory' we > have. In your proposal it affects not the current node but child > nodes. > you are right. I realized that after I sent the mail. It should not be allowed for case-stmt. > Can I override this in individual nodes in the case branch: > > case A { > mandatory true; > leaf foo { > mandatory false; > } > } > > >> A container should also allow the mandatory-stmt. >> This is different than the presence-stmt, which only provides >> a description of what it means *if* the container is present. > > We had long discussions in the design team about this. What does it > mean that a container is mandatory? That it MUST be present in the > config? If the container is always there it does not carry any > semantic meaning. We do this with "non-presence" containers today. > It makes more sense for RPC , , and . Mandatory true means the node must be present (in these cases), even if it is an empty container. > Do you suggest that if mandatory is true on a container, then the > presence statement MUST NOT be there, and vice versa? > > Or do you suggest that mandatory true works like in the case statement > above? > >> For consistency, the mandatory-stmt should be allowed in leaf-list >> and list, but must be consistent with 'min-elements' if also present: >> >> mandatory true; --> min-elements 1; >> mandatory false; --> min-elements 0; // default > > I don't agree that it's more consistent to use a statement in places > where it doesn't add any value. Or do you think it adds value? > I think it is better to be lenient in what is entered by the user. To me, 'mandatory true' or 'min-elements 1' are both equally valid, and make sense. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 14 14:35:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D21B3A6780; Wed, 14 May 2008 14:35:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2803A67AE for ; Wed, 14 May 2008 14:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LujHVxPIj5MM for ; Wed, 14 May 2008 14:35:12 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id B4DB53A6780 for ; Wed, 14 May 2008 14:35:08 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 14 May 2008 14:33:28 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 14:34:40 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4ELYdx03218; Wed, 14 May 2008 14:34:39 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4ELWl4t017372; Wed, 14 May 2008 21:32:47 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805142132.m4ELWl4t017372@idle.juniper.net> To: Andy Bierman In-reply-to: <482B57D2.5050201@andybierman.com> Date: Wed, 14 May 2008 17:32:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 May 2008 21:34:40.0381 (UTC) FILETIME=[50EEBAD0:01C8B60A] Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Mandatory true means the node must be present (in these cases), >even if it is an empty container. If it's empty and not a presense container, then it carries no useful information. Why would it be mandatory? >I think it is better to be lenient in what is entered by the user. >To me, 'mandatory true' or 'min-elements 1' are both equally valid, >and make sense. Having both is an expense we don't need. As a reader, I don't want to have to look for both. As a developer, I don't want to have to check for both. Why make an optimization for sloppy YANG writers? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 14 15:44:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8BD3A63D3; Wed, 14 May 2008 15:44:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623043A6780 for ; Wed, 14 May 2008 15:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VUTMDD2EKWD for ; Wed, 14 May 2008 15:44:02 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 8F76D3A63D3 for ; Wed, 14 May 2008 15:44:02 -0700 (PDT) Received: (qmail 83205 invoked from network); 14 May 2008 22:42:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 14 May 2008 22:42:12 -0000 X-YMail-OSG: ABUdz9YVM1m8dJ17D9Zn8zn2e0IV1O0OUp6vH2Ydn31I3LlYLRufkw05vGSxNxv0zj8w0aVhs5vEdv8pjkjdPODA.H6AjCgnOIgr1bmyoQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <482B6AC1.90700@andybierman.com> Date: Wed, 14 May 2008 15:42:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805142132.m4ELWl4t017372@idle.juniper.net> In-Reply-To: <200805142132.m4ELWl4t017372@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Mandatory true means the node must be present (in these cases), >> even if it is an empty container. > > If it's empty and not a presense container, then it carries > no useful information. Why would it be mandatory? > IMO, that is up to the data model write. Maybe there is a choice within the container or other constructs that end up with no instances, so the the data model can convey an empty set in an extensible manner. rpc do-search { input { leaf search-type { type string; mandatory true; } leaf search-string { type string; mandatory true; } } output { container search-matches { mandatory true; choice search-type { ... } } } It is just as valid to give the manager a stable 'search-matches' node in the reply as to leave it out. >> I think it is better to be lenient in what is entered by the user. >> To me, 'mandatory true' or 'min-elements 1' are both equally valid, >> and make sense. > > Having both is an expense we don't need. As a reader, I don't want > to have to look for both. As a developer, I don't want to have to > check for both. Why make an optimization for sloppy YANG writers? > One could consider the special-case nature of all the various YANG object types to be an expense we don't need. Most DML features are very subjective in nature. It doesn't really help to characterize mechanisms you don't like as 'noise' or 'sloppy'. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 15 10:17:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5333A68DE; Thu, 15 May 2008 10:17:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBAE73A68DE for ; Thu, 15 May 2008 10:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Oefpl6Of4oH for ; Thu, 15 May 2008 10:17:28 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 013753A68E8 for ; Thu, 15 May 2008 10:17:24 -0700 (PDT) Received: (qmail 46534 invoked from network); 15 May 2008 17:17:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 15 May 2008 17:16:58 -0000 X-YMail-OSG: NJMjf9gVM1mMJfa9d5EiwLMLzYnPjIPi2IPnA4yrYcwbBZ95Ky0TfmJsXB6rmULbWOLRjvRW.X2oqYc8xaE3SEumZEhdxPIwjCEqBmY6SOAbGmnJzc_CqXBYEpiS0IC.91DwxYoQQ3Cr5Vxb.Ol0iFgi X-Yahoo-Newman-Property: ymail-3 Message-ID: <482C7008.8050106@andybierman.com> Date: Thu, 15 May 2008 10:16:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805151657.m4FGvp7A024148@idle.juniper.net> In-Reply-To: <200805151657.m4FGvp7A024148@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >>> If it's empty and not a presense container, then it carries >>> no useful information. Why would it be mandatory? >> IMO, that is up to the data model write. > > No, if it doesn't make sense, it's up to us to forbid it > and avoid the confusion of meaningless YANG (and content). > IMO, the concept of mandatory true/false is useful and simple to understand. I do not agree it is meaningless. I prefer this simple clause to 'must' and 'presence' and 'min-elements'. I don't really care that much, though. (I already have a YANG cheat sheet to remind of of all the little quirks and details -- it's almost as bad as XSD in that regard ;-) >> It is just as valid to give the manager a stable 'search-matches' >> node in the reply as to leave it out. > > If it's just as valid to leave it out, why would you want to make > it mandatory? > >> Most DML features are very subjective in nature. > > Sorry, but you are trying to give the writer two choices, one > that context sensitive and one that's not so meaningful but > less context dependent. I don't see why we'd allow the writer > this choice, given that readers and clarity are more important > that a writer that wants to be context insensitive. Why would > the writer need or want this choice? > > Yes, design work is subjective and there are many right answers, > but there are also many wrong ones. Consider: > > http://www.8sharp.com/inspired/images/norman_book.jpg > http://snarfd.com/wp-content/uploads/2007/11/sorapot_white.jpg > > Language design is subjective, but every feature needs a semi-objective > cost/benefit analysis to see if it's worth inclusion in the language. > Here I see the cost but don't see the benefit. I have a hard time > with The idea of helping writers that want to say "mandatory true" > instead of "min-elements 1" because they don't want to think about > if they are inside a list or not. I think it matters more to the readers than the writer of the module. I will let this thread go. I think some other WG members (besides the YANG co-authors) should get involved and express their opinions. (If not, then why didn't we just publish YANG as Experimental a year ago?) > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 15 10:27:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556423A67D6; Thu, 15 May 2008 10:27:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5B13A6833 for ; Thu, 15 May 2008 10:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGIZLB-5bY3W for ; Thu, 15 May 2008 10:27:56 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 5099C3A67D6 for ; Thu, 15 May 2008 10:27:52 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 15 May 2008 10:25:55 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 10:27:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4FHRQx78327; Thu, 15 May 2008 10:27:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4FHPX5D024628; Thu, 15 May 2008 17:25:33 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805151725.m4FHPX5D024628@idle.juniper.net> To: Andy Bierman In-reply-to: <482C7008.8050106@andybierman.com> Date: Thu, 15 May 2008 13:25:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 May 2008 17:27:27.0058 (UTC) FILETIME=[F1FF0320:01C8B6B0] Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >IMO, the concept of mandatory true/false is useful and >simple to understand. I do not agree it is meaningless. My point was that an empty XML element that doesn't have a meaning is meaningless, making it mandatory would be unnecessary. If it doesn't mean anything, I shouldn't have to emit it. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 15 10:29:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713353A67D6; Thu, 15 May 2008 10:29:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A423A6806 for ; Thu, 15 May 2008 10:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqM6GGlW7SDM for ; Thu, 15 May 2008 10:29:25 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id D32373A68F3 for ; Thu, 15 May 2008 10:29:25 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 15 May 2008 10:28:07 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 09:59:44 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4FGxix67119; Thu, 15 May 2008 09:59:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4FGvp7A024148; Thu, 15 May 2008 16:57:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805151657.m4FGvp7A024148@idle.juniper.net> To: Andy Bierman In-reply-to: <482B6AC1.90700@andybierman.com> Date: Thu, 15 May 2008 12:57:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 May 2008 16:59:44.0859 (UTC) FILETIME=[133F92B0:01C8B6AD] Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >> If it's empty and not a presense container, then it carries >> no useful information. Why would it be mandatory? >IMO, that is up to the data model write. No, if it doesn't make sense, it's up to us to forbid it and avoid the confusion of meaningless YANG (and content). >It is just as valid to give the manager a stable 'search-matches' >node in the reply as to leave it out. If it's just as valid to leave it out, why would you want to make it mandatory? >Most DML features are very subjective in nature. Sorry, but you are trying to give the writer two choices, one that context sensitive and one that's not so meaningful but less context dependent. I don't see why we'd allow the writer this choice, given that readers and clarity are more important that a writer that wants to be context insensitive. Why would the writer need or want this choice? Yes, design work is subjective and there are many right answers, but there are also many wrong ones. Consider: http://www.8sharp.com/inspired/images/norman_book.jpg http://snarfd.com/wp-content/uploads/2007/11/sorapot_white.jpg Language design is subjective, but every feature needs a semi-objective cost/benefit analysis to see if it's worth inclusion in the language. Here I see the cost but don't see the benefit. I have a hard time with The idea of helping writers that want to say "mandatory true" instead of "min-elements 1" because they don't want to think about if they are inside a list or not. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 15 11:35:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960FE3A6895; Thu, 15 May 2008 11:35:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15C83A689F for ; Thu, 15 May 2008 11:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsfudfvMz72C for ; Thu, 15 May 2008 11:35:27 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id D61F83A67A2 for ; Thu, 15 May 2008 11:35:26 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id CB97E1B80D4; Thu, 15 May 2008 20:34:31 +0200 (CEST) Date: Thu, 15 May 2008 20:34:10 +0200 (CEST) Message-Id: <20080515.203410.198502947.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <482B6AC1.90700@andybierman.com> References: <200805142132.m4ELWl4t017372@idle.juniper.net> <482B6AC1.90700@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> Mandatory true means the node must be present (in these cases), > >> even if it is an empty container. > > If it's empty and not a presense container, then it carries > > no useful information. Why would it be mandatory? > > > > IMO, that is up to the data model write. > Maybe there is a choice within the container or other > constructs that end up with no instances, so the > the data model can convey an empty set in an extensible manner. > > rpc do-search { > input { > leaf search-type { > type string; > mandatory true; > } > leaf search-string { > type string; > mandatory true; > } > } > output { > container search-matches { > mandatory true; > choice search-type { > ... > } > } > } This usage of mandatory true on a container seems quite arbitrary to me. I think you agreed that it doesn't add any extra information to the data model. So when a data model designer is writing his container, how will he determine whether to use 'mandatory true' or not? It is also different from our other constructs b/c it controls the XML encoding only. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 15 12:05:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5656F28C0E3; Thu, 15 May 2008 12:05:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7993A6957 for ; Thu, 15 May 2008 12:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJBj3xle3iLI for ; Thu, 15 May 2008 12:05:14 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 1E79B3A6807 for ; Thu, 15 May 2008 12:05:14 -0700 (PDT) Received: (qmail 5751 invoked from network); 15 May 2008 19:05:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 15 May 2008 19:05:03 -0000 X-YMail-OSG: FwlGJVwVM1m.s7rxlIi2eSq.9YQjEyYcCScP4wrCwXk9cHngcw3hbDVsYBpai4b7KpNsSTvDPkgPMYWh3gfeOuDEMbwmsnwrFnJwDvIDYUZHqnN42eZVOaLL99f18Cuu96Q- X-Yahoo-Newman-Property: ymail-3 Message-ID: <482C895D.1000800@andybierman.com> Date: Thu, 15 May 2008 12:05:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <200805142132.m4ELWl4t017372@idle.juniper.net> <482B6AC1.90700@andybierman.com> <20080515.203410.198502947.mbj@tail-f.com> In-Reply-To: <20080515.203410.198502947.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> Mandatory true means the node must be present (in these cases), >>>> even if it is an empty container. >>> If it's empty and not a presense container, then it carries >>> no useful information. Why would it be mandatory? >>> >> IMO, that is up to the data model write. >> Maybe there is a choice within the container or other >> constructs that end up with no instances, so the >> the data model can convey an empty set in an extensible manner. >> >> rpc do-search { >> input { >> leaf search-type { >> type string; >> mandatory true; >> } >> leaf search-string { >> type string; >> mandatory true; >> } >> } >> output { >> container search-matches { >> mandatory true; >> choice search-type { >> ... >> } >> } >> } > > This usage of mandatory true on a container seems quite arbitrary to > me. I think you agreed that it doesn't add any extra information to > the data model. So when a data model designer is writing his > container, how will he determine whether to use 'mandatory true' or > not? It is also different from our other constructs b/c it controls > the XML encoding only. > It is not XML encoding only. It should be up to the DM writer if they want a placeholder node or not. E.g: container interfaces { mandatory true; must "."; presence "Root of all interface information. Presence indicates the device has some interface information."; leaf ifNumber { type uint32; mandatory true; config false; } leaf ifLastChangeTime { type yang:date-and-time; config false; } list interface { key name; min-elements 0; mandatory false; ... } } Why bother creating an /interfaces root for the interface info? IMO, it is useful for creating a stable API. I can configure access control for /interfaces and not worry if new child nodes were added underneath. Same applies for applications or operators hard-wiring or hand-coding filters. What if I want all implementations to have an interfaces root, to make sure filters or ACEs for '/interfaces' are clear and unambiguous and static? What if an agent MUST at least return 'ifNumber==0' to be compliant to the Acme Interface module? Is that meaningless? Just leaving out nodes instead can be masked by access control. IMO, 'mandatory true' is more intuitive than 'must "."'. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 15 12:35:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EEB3A67B6; Thu, 15 May 2008 12:35:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3783A67FB for ; Thu, 15 May 2008 12:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1OGLvAQHnO4 for ; Thu, 15 May 2008 12:35:24 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 43E3A3A67B6 for ; Thu, 15 May 2008 12:35:24 -0700 (PDT) Received: from u-173-c251.cs.uni-tuebingen.de (u-173-c251.cs.uni-tuebingen.de [134.2.173.251]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m4FJZHNc029938 for ; Thu, 15 May 2008 21:35:17 +0200 Received: from localhost ([127.0.0.1] helo=www.ri.uni-tuebingen.de ident=www-data) by u-173-c251.cs.uni-tuebingen.de with esmtp (Exim 4.50) id 1JwjFN-00089j-3W for netmod@ietf.org; Thu, 15 May 2008 21:36:13 +0200 Received: from 195.4.204.204 (SquirrelMail authenticated user muenz) by www.ri.uni-tuebingen.de with HTTP; Thu, 15 May 2008 21:36:13 +0200 (CEST) Message-ID: <61546.195.4.204.204.1210880173.squirrel@www.ri.uni-tuebingen.de> In-Reply-To: References: Date: Thu, 15 May 2008 21:36:13 +0200 (CEST) From: "Gerhard Muenz" To: netmod@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.19; VDF: 7.0.4.46; host: mx06) Subject: Re: [netmod] netmod Digest, Vol 2, Issue 23 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, My 5 cents: Honestly, I was a little bit shocked when I read that YANG should allow alternatives for specifying exactly the same thing, such as "mandatory true" and "min-elements 1". This is one of the most terrible properties of XSD. I would opt for keeping YANG concise and neat. If I write a YANG document, I can very quickly find the valid attributes for each keyword in the language specification. Being offered alternatives here would confuse me. Concerning containers: It's a simple rule that containers cannot be mandatory. After I understood this rule, it was not a problem at all when I designed my model. Maybe, it even made me writing a better model than I would have done otherwise. However, if you explicitly want to enforce an empty in your example, you can specify this with YANG: output { choice search-type { case no-result { leaf search-matches { type empty; } } case a-result { container search-matches { choice search-type { ... } } } } } Hopefully, there is no error in my YANG code ;) I'm a little bit out of practice. Regards, Gerhard Andy Bierman wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>>> If it's empty and not a presense container, then it carries >>>> no useful information. Why would it be mandatory? >>> IMO, that is up to the data model write. >> >> No, if it doesn't make sense, it's up to us to forbid it >> and avoid the confusion of meaningless YANG (and content). >> > > IMO, the concept of mandatory true/false is useful and > simple to understand. I do not agree it is meaningless. > I prefer this simple clause to 'must' and 'presence' and 'min-elements'. > I don't really care that much, though. (I already have a YANG cheat sheet > to remind of of all the little quirks and details -- it's almost > as bad as XSD in that regard ;-) > >>> It is just as valid to give the manager a stable 'search-matches' >>> node in the reply as to leave it out. >> >> If it's just as valid to leave it out, why would you want to make >> it mandatory? >> >>> Most DML features are very subjective in nature. >> >> Sorry, but you are trying to give the writer two choices, one >> that context sensitive and one that's not so meaningful but >> less context dependent. I don't see why we'd allow the writer >> this choice, given that readers and clarity are more important >> that a writer that wants to be context insensitive. Why would >> the writer need or want this choice? >> >> Yes, design work is subjective and there are many right answers, >> but there are also many wrong ones. Consider: >> >> http://www.8sharp.com/inspired/images/norman_book.jpg >> http://snarfd.com/wp-content/uploads/2007/11/sorapot_white.jpg >> >> Language design is subjective, but every feature needs a semi-objective >> cost/benefit analysis to see if it's worth inclusion in the language. >> Here I see the cost but don't see the benefit. I have a hard time >> with The idea of helping writers that want to say "mandatory true" >> instead of "min-elements 1" because they don't want to think about >> if they are inside a list or not. > > > I think it matters more to the readers than the writer of the module. > > I will let this thread go. I think some other WG members > (besides the YANG co-authors) should get involved and express > their opinions. (If not, then why didn't we just publish YANG > as Experimental a year ago?) > > >> >> Thanks, >> Phil >> >> >> > > Andy -- = Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 15 12:35:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9793A69FD; Thu, 15 May 2008 12:35:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1ECB3A69FD for ; Thu, 15 May 2008 12:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtvqqLuetY45 for ; Thu, 15 May 2008 12:35:51 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 7D1ED3A6955 for ; Thu, 15 May 2008 12:35:51 -0700 (PDT) Received: from u-173-c251.cs.uni-tuebingen.de (u-173-c251.cs.uni-tuebingen.de [134.2.173.251]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m4FJZj2D029996 for ; Thu, 15 May 2008 21:35:45 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=www.ri.uni-tuebingen.de ident=www-data) by u-173-c251.cs.uni-tuebingen.de with esmtp (Exim 4.50) id 1JwjFp-00089x-5f for netmod@ietf.org; Thu, 15 May 2008 21:36:41 +0200 Received: from 195.4.204.204 (SquirrelMail authenticated user muenz) by www.ri.uni-tuebingen.de with HTTP; Thu, 15 May 2008 21:36:41 +0200 (CEST) Message-ID: <61549.195.4.204.204.1210880201.squirrel@www.ri.uni-tuebingen.de> In-Reply-To: References: Date: Thu, 15 May 2008 21:36:41 +0200 (CEST) From: "Gerhard Muenz" To: netmod@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.19; VDF: 7.0.4.46; host: mx06) Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, My 5 cents: Honestly, I was a little bit shocked when I read that YANG should allow alternatives for specifying exactly the same thing, such as "mandatory true" and "min-elements 1". This is one of the most terrible properties of XSD. I would opt for keeping YANG concise and neat. If I write a YANG document, I can very quickly find the valid attributes for each keyword in the language specification. Being offered alternatives here would confuse me. Concerning containers: It's a simple rule that containers cannot be mandatory. After I understood this rule, it was not a problem at all when I designed my model. Maybe, it even made me writing a better model than I would have done otherwise. However, if you explicitly want to enforce an empty in your example, you can specify this with YANG: output { choice search-type { case no-result { leaf search-matches { type empty; } } case a-result { container search-matches { choice search-type { ... } } } } } Hopefully, there is no error in my YANG code ;) I'm a little bit out of practice. Regards, Gerhard Andy Bierman wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>>> If it's empty and not a presense container, then it carries >>>> no useful information. Why would it be mandatory? >>> IMO, that is up to the data model write. >> >> No, if it doesn't make sense, it's up to us to forbid it >> and avoid the confusion of meaningless YANG (and content). >> > > IMO, the concept of mandatory true/false is useful and > simple to understand. I do not agree it is meaningless. > I prefer this simple clause to 'must' and 'presence' and 'min-elements'. > I don't really care that much, though. (I already have a YANG cheat sheet > to remind of of all the little quirks and details -- it's almost > as bad as XSD in that regard ;-) > >>> It is just as valid to give the manager a stable 'search-matches' >>> node in the reply as to leave it out. >> >> If it's just as valid to leave it out, why would you want to make >> it mandatory? >> >>> Most DML features are very subjective in nature. >> >> Sorry, but you are trying to give the writer two choices, one >> that context sensitive and one that's not so meaningful but >> less context dependent. I don't see why we'd allow the writer >> this choice, given that readers and clarity are more important >> that a writer that wants to be context insensitive. Why would >> the writer need or want this choice? >> >> Yes, design work is subjective and there are many right answers, >> but there are also many wrong ones. Consider: >> >> http://www.8sharp.com/inspired/images/norman_book.jpg >> http://snarfd.com/wp-content/uploads/2007/11/sorapot_white.jpg >> >> Language design is subjective, but every feature needs a semi-objective >> cost/benefit analysis to see if it's worth inclusion in the language. >> Here I see the cost but don't see the benefit. I have a hard time >> with The idea of helping writers that want to say "mandatory true" >> instead of "min-elements 1" because they don't want to think about >> if they are inside a list or not. > > > I think it matters more to the readers than the writer of the module. > > I will let this thread go. I think some other WG members > (besides the YANG co-authors) should get involved and express > their opinions. (If not, then why didn't we just publish YANG > as Experimental a year ago?) > > >> >> Thanks, >> Phil >> >> >> > > Andy -- = Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 15 12:38:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E263A67B6; Thu, 15 May 2008 12:38:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5B53A67B6 for ; Thu, 15 May 2008 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN1YXXgWbyGL for ; Thu, 15 May 2008 12:38:49 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 4A4943A67FB for ; Thu, 15 May 2008 12:38:49 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id EC1ED1B80D0; Thu, 15 May 2008 21:38:43 +0200 (CEST) Date: Thu, 15 May 2008 21:38:21 +0200 (CEST) Message-Id: <20080515.213821.130122998.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <482C895D.1000800@andybierman.com> References: <482B6AC1.90700@andybierman.com> <20080515.203410.198502947.mbj@tail-f.com> <482C895D.1000800@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > It is not XML encoding only. > It should be up to the DM writer if they want > a placeholder node or not. E.g: Absolutely. These kind of placeholder nodes are very useful. But there's no need for 'mandatory true' on them. Just use an ordinary ("non-presence") container. > container interfaces { > mandatory true; > must "."; > presence > "Root of all interface information. > Presence indicates the device has some interface information."; So this says that if the node is present, then the device has some interface information. But it is also mandatory, so it has to be present! This does not make much sense to me. Also, the 'must "."' expression doesn't make any sense. must expressions are evaluated for data nodes that exist in the tree. So this expression says "if /interfaces exists, then it must exist". > Why bother creating an /interfaces root for the interface info? > IMO, it is useful for creating a stable API. I can configure > access control for /interfaces and not worry if new child nodes > were added underneath. Same applies for applications or operators > hard-wiring or hand-coding filters. Sure. > What if I want all implementations to have an interfaces root, Make it an ordinary container. > to make sure filters or ACEs for '/interfaces' are clear and > unambiguous and static? What if an agent MUST at least > return 'ifNumber==0' to be compliant to the Acme Interface module? In this case you have nothing to worry about at all - if there's a mandatory leaf under an ordinary container, then you know that the container will always be sent in the XML. > IMO, 'mandatory true' is more intuitive than 'must "."'. They are different things, as explained above. Another thing: > leaf ifNumber { > type uint32; > mandatory true; > config false; > } mandatory true in combination with config false doesn't make sense. mandatory means that the node must exist in a valid configuration. Thus it does not apply to non-config nodes. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 21 08:09:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7657B3A6AB2; Wed, 21 May 2008 08:09:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD713A6877 for ; Wed, 21 May 2008 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVIIwhUmg6ey for ; Wed, 21 May 2008 08:09:21 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 2401B3A6AF5 for ; Wed, 21 May 2008 08:09:21 -0700 (PDT) Received: (qmail 64554 invoked from network); 21 May 2008 15:09:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 21 May 2008 15:09:18 -0000 X-YMail-OSG: RCxvRP0VM1llxZU_CY8z2dj0ljhS7JfYOhr5ANlJVoGdobg1OOa3r2yExbqA1ofqNB.ypA1VVIwB5gU12.V6SPqGB8m5Hs0Zn0wCHSAgUFnxuaIovnRm4oWw8Er7xSrAJdA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48343B1C.9000408@andybierman.com> Date: Wed, 21 May 2008 08:09:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <482B6AC1.90700@andybierman.com> <20080515.203410.198502947.mbj@tail-f.com> <482C895D.1000800@andybierman.com> <20080515.213821.130122998.mbj@tail-f.com> In-Reply-To: <20080515.213821.130122998.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > .... > Another thing: > >> leaf ifNumber { >> type uint32; >> mandatory true; >> config false; >> } > > mandatory true in combination with config false doesn't make sense. > mandatory means that the node must exist in a valid configuration. > Thus it does not apply to non-config nodes. > Then the draft needs to be clarified or corrected, because the mandatory-stmt is allowed for leafs within notifications and RPC input/output. If it has no meaning in these cases, then the draft needs to specify what happens if they are present. (Same applies for config-stmt.) > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 21 09:15:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F3A28C118; Wed, 21 May 2008 09:15:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26B128C1C3 for ; Wed, 21 May 2008 09:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXhoYJsL0hn3 for ; Wed, 21 May 2008 09:15:17 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 5672F3A69B0 for ; Wed, 21 May 2008 09:15:16 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id U9tt1Z0051HpZEsA40V600; Wed, 21 May 2008 16:15:20 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id UGFJ1Z00D4HwxpC8a00000; Wed, 21 May 2008 16:15:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=MwYSnzdu7qGfHyhRvrsA:9 a=0I7T1lMsy1fu945pViuuEv29mkkA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Wed, 21 May 2008 12:15:18 -0400 Message-ID: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci7XduEEZj/afTqTuyC9czD1zDjbg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Our first milestone: Jun 2008 All _individual_ drafts available that will be used as input into the WG documents (draft-bjorklund-yang, architecture draft, YIN draft, YANG standard library draft, DSDL mapping rules draft) The Yang draft has been published. We need to get the other drafts published as individual drafts. Deadlines are starting to creep closer. June is only 10 days away. If you plan to contribute an individual draft toward these deliverables, please do so soon. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 21 11:25:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23003A67F9; Wed, 21 May 2008 11:25:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC15C3A68AB for ; Wed, 21 May 2008 11:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5tszZbtP+wW for ; Wed, 21 May 2008 11:25:05 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 147883A67F9 for ; Wed, 21 May 2008 11:25:05 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 932851B80CD; Wed, 21 May 2008 20:25:08 +0200 (CEST) Date: Wed, 21 May 2008 20:24:39 +0200 (CEST) Message-Id: <20080521.202439.160249518.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <48343B1C.9000408@andybierman.com> References: <482C895D.1000800@andybierman.com> <20080515.213821.130122998.mbj@tail-f.com> <48343B1C.9000408@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > .... > > > Another thing: > > > >> leaf ifNumber { > >> type uint32; > >> mandatory true; > >> config false; > >> } > > mandatory true in combination with config false doesn't make sense. > > mandatory means that the node must exist in a valid configuration. > > Thus it does not apply to non-config nodes. > > > > Then the draft needs to be clarified or corrected, because > the mandatory-stmt is allowed for leafs within notifications > and RPC input/output. If it has no meaning in these cases, > then the draft needs to specify what happens if they are present. > (Same applies for config-stmt.) The idea was that mandatory does make sense in e.g. RPC input parameters. The draft currently says this for input (and similar for output and notifications): If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC invocation. I think we need some clarifications to this. As it stands right now, the only case that is not covered is non-config nodes. If we don't want to allow mandatory on non-config nodes, this should be spelled out explicitly. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 21 11:30:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009F33A63D3; Wed, 21 May 2008 11:30:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD943A63D3 for ; Wed, 21 May 2008 11:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cnf7kLMyHZfU for ; Wed, 21 May 2008 11:30:54 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 13C463A6A4E for ; Wed, 21 May 2008 11:30:54 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 1021B1B80CD; Wed, 21 May 2008 20:30:58 +0200 (CEST) Date: Wed, 21 May 2008 20:30:28 +0200 (CEST) Message-Id: <20080521.203028.238829365.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, "David Harrington" wrote: > Hi, > > Our first milestone: > Jun 2008 All _individual_ drafts available that will be used as > input into the WG documents (draft-bjorklund-yang, architecture draft, > YIN draft, YANG standard library draft, DSDL mapping rules draft) > > The Yang draft has been published. This draft currently contains YANG, YIN and the standard library part. I have split the standard library part out into a separate draft (not yet published), but for the YIN part I would like to know what the WG thinks. I have heard some opinions that it should be a separate document, and some that it should be in kept in the YANG document. As for the DSDL mapping, I believe there is a bug in the charter - the initial version of this draft is scheduled for Jun _and_ Sep. I think Sep is the correct date. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 21 11:38:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08EF63A68AB; Wed, 21 May 2008 11:38:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953FD3A69C6 for ; Wed, 21 May 2008 11:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.789 X-Spam-Level: X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cbnloZhq2Gc for ; Wed, 21 May 2008 11:38:25 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id B0A9F3A68B8 for ; Wed, 21 May 2008 11:38:25 -0700 (PDT) Received: (qmail 73700 invoked from network); 21 May 2008 18:38:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 21 May 2008 18:38:25 -0000 X-YMail-OSG: SH68aaoVM1lAV5FDX9dxP1WeHmRcS_f9ih90R1kJaSIfXPmwXnfJcBy4rcKEXiKGIw29QiOPn4JU2nrnY5xK4cnMV7ukgr331saDZ08qmMQ7OkiR.f3.n9axEwgl8a9JIgQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48346C1E.9090802@andybierman.com> Date: Wed, 21 May 2008 11:38:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <482C895D.1000800@andybierman.com> <20080515.213821.130122998.mbj@tail-f.com> <48343B1C.9000408@andybierman.com> <20080521.202439.160249518.mbj@tail-f.com> In-Reply-To: <20080521.202439.160249518.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] mandatory-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> .... >>> Another thing: >>> >>>> leaf ifNumber { >>>> type uint32; >>>> mandatory true; >>>> config false; >>>> } >>> mandatory true in combination with config false doesn't make sense. >>> mandatory means that the node must exist in a valid configuration. >>> Thus it does not apply to non-config nodes. >>> >> Then the draft needs to be clarified or corrected, because >> the mandatory-stmt is allowed for leafs within notifications >> and RPC input/output. If it has no meaning in these cases, >> then the draft needs to specify what happens if they are present. >> (Same applies for config-stmt.) > > The idea was that mandatory does make sense in e.g. RPC input > parameters. The draft currently says this for input (and similar for > output and notifications): > > If a leaf in the input tree has a "mandatory" statement with the > value "true", the leaf MUST be present in a NETCONF RPC invocation. > > I think we need some clarifications to this. As it stands right now, > the only case that is not covered is non-config nodes. If we don't > want to allow mandatory on non-config nodes, this should be spelled > out explicitly. > Yes -- you spelled it out at the last IETF I think: config-stmt has no meaning (ignored or compiler warning): - /some-rpc/input/* - /some-rpc/output/* - /some-notification/* for mandatory-stmt: - /some-rpc/input/* : must be present in the input parameters - /some-rpc/output/* : must be present in the output if no errors - /some-notification/* : must be present in the notification > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 21 12:49:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D63E28C255; Wed, 21 May 2008 12:49:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E958528C258 for ; Wed, 21 May 2008 12:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh6sWtM+Teuv for ; Wed, 21 May 2008 12:49:20 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 17D3A28C255 for ; Wed, 21 May 2008 12:49:20 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id UKWs1Z0011HpZEsA602P00; Wed, 21 May 2008 19:49:24 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id UKpN1Z00A4HwxpC8a00000; Wed, 21 May 2008 19:49:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=_Y5QBs2iGHYA:10 a=tXWDgJ4S68k2ITBB7DYA:9 a=NRjSIElOh2wLfmngMtvVocukOU0A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=XqebBV1NYWwA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Martin Bjorklund'" References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> Date: Wed, 21 May 2008 15:49:22 -0400 Message-ID: <0a5601c8bb7b$c556a2e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080521.203028.238829365.mbj@tail-f.com> Thread-Index: Aci7cNjpycRfwSMUSr6gXCYJfntLyQAAJsIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, speaking as co-chair ... Our charter calls for all drafts to be first published as individual, and then discussed in Dublin, before being published as WG -00- drafts. The Jun deadline is for individual drafts. The Aug date refers to the -00- WG drafts, after the WG has agreed the individual drafts should be adopted as WG drafts. The chairs approved the YANG-00 draft already because the charter states that the WG will use YANG (draft-bjorklund-yang) as its starting point for the human friendly language. The other drafts should be first published as individual drafts. It is unclear what the Sep 2008 deadline refers to, since DSDL is also listed as having Jun and Aug deadlines. I think we should use the Jun and Aug deadlines. Rohan expressed an interest in writing the first DSDL draft. He expects to become unavailable later in the year, so we should try to have the individual draft ready by June so we have plenty of time to discuss it while he is still available. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, May 21, 2008 2:30 PM > To: ietfdbh@comcast.net > Cc: netmod@ietf.org > Subject: Re: [netmod] individiual drafts deadline > > Hi, > > "David Harrington" wrote: > > Hi, > > > > Our first milestone: > > Jun 2008 All _individual_ drafts available that will be used as > > input into the WG documents (draft-bjorklund-yang, > architecture draft, > > YIN draft, YANG standard library draft, DSDL mapping rules draft) > > > > The Yang draft has been published. > > This draft currently contains YANG, YIN and the standard library > part. I have split the standard library part out into a separate > draft (not yet published), but for the YIN part I would like to know > what the WG thinks. I have heard some opinions that it should be a > separate document, and some that it should be in kept in the YANG > document. > > As for the DSDL mapping, I believe there is a bug in the charter - the > initial version of this draft is scheduled for Jun _and_ Sep. I think > Sep is the correct date. > > > /martin > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 21 13:04:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0C73A6B9D; Wed, 21 May 2008 13:04:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9832D3A6958 for ; Wed, 21 May 2008 13:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzEe3b6yHWUe for ; Wed, 21 May 2008 13:04:48 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 2758C3A67A8 for ; Wed, 21 May 2008 13:04:48 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id UL2C1Z00L1GXsucA200P00; Wed, 21 May 2008 20:04:52 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id UL4q1Z0044HwxpC8T00000; Wed, 21 May 2008 20:04:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=g65Jc2-v_0zTv5eMc28A:9 a=UjFCwK9X1KRx_-B5qMntUV9cUUsA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Martin Bjorklund'" References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> Date: Wed, 21 May 2008 16:04:50 -0400 Message-ID: <0a5a01c8bb7d$ee7acaf0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080521.203028.238829365.mbj@tail-f.com> Thread-Index: Aci7cNjpycRfwSMUSr6gXCYJfntLyQACvkHQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: [netmod] YIN as separate document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, speaking as co-chair ... > > This draft currently contains YANG, YIN and the standard library > part. I have split the standard library part out into a separate > draft (not yet published), but for the YIN part I would like to know > what the WG thinks. I have heard some opinions that it should be a > separate document, and some that it should be in kept in the YANG > document. The charter calls for a separate docuemnt, and we have consensus on the charter. I checked the netmod, NGO, rcdml, and ietf archives looking for consensus that YIN should be kept in the YANG draft. I did not see enough discussion of this to justify claiming a concensus to override the charter. I saw lots of consensus that it should be listed as a separate charter item. Anybody that has an opinon about keeping YIN in the YANG document versus separating it, please speak up. The chairs will consider the WG input and make a decision. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed May 21 22:03:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43EA3A6B71; Wed, 21 May 2008 22:03:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240AE3A6A11 for ; Wed, 21 May 2008 22:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i38GSmc68u-o for ; Wed, 21 May 2008 22:03:35 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 2751D3A6AAB for ; Wed, 21 May 2008 22:03:30 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Wed, 21 May 2008 22:03:24 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 May 2008 21:55:45 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4M4tjx35770; Wed, 21 May 2008 21:55:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4M4rh1q073925; Thu, 22 May 2008 04:53:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805220453.m4M4rh1q073925@idle.juniper.net> To: "David Harrington" In-reply-to: <0a5a01c8bb7d$ee7acaf0$0600a8c0@china.huawei.com> Date: Thu, 22 May 2008 00:53:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 May 2008 04:55:45.0862 (UTC) FILETIME=[187AE660:01C8BBC8] Cc: netmod@ietf.org Subject: Re: [netmod] YIN as separate document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "David Harrington" writes: >The charter calls for a separate docuemnt, and we have consensus on >the charter. I thought the charter gave us freedom to control this: The working group may choose to combine multiple deliverables into a single document where deemed appropriate. >Anybody that has an opinon about keeping YIN in the YANG document >versus separating it, please speak up. The chairs will consider the WG >input and make a decision. +1 to keep it in a single document. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 22 01:28:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E3F3A6AD4; Thu, 22 May 2008 01:28:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D9B3A6B06 for ; Thu, 22 May 2008 01:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8wwSiNC85id for ; Thu, 22 May 2008 01:28:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CECA23A6AD4 for ; Thu, 22 May 2008 01:28:08 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C1F4FD800C7 for ; Thu, 22 May 2008 10:04:49 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080521.203028.238829365.mbj@tail-f.com> References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> Organization: CESNET Date: Thu, 22 May 2008 10:04:49 +0200 Message-Id: <1211443489.6295.26.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyMS4gMDUuIDIwMDggdiAyMDozMCArMDIwMDoK PiAKPiBBcyBmb3IgdGhlIERTREwgbWFwcGluZywgSSBiZWxpZXZlIHRoZXJlIGlzIGEgYnVnIGlu IHRoZSBjaGFydGVyIC0gdGhlCj4gaW5pdGlhbCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgaXMgc2No ZWR1bGVkIGZvciBKdW4gX2FuZF8gU2VwLiAgSSB0aGluawo+IFNlcCBpcyB0aGUgY29ycmVjdCBk YXRlLgoKV291bGQgaXQgYmUgdXNlZnVsIHRvIHB1Ymxpc2ggbm93IGRyYWZ0LW1haHktY2FubW9k LWRzZGwtMDEgYXMgYSBXRwpkcmFmdCBub3csIG1vcmUgb3IgbGVzcyBhcyBpdCBpcz8gT3RoZXJ3 aXNlLCBJIGFsc28gdGhpbmsgU2VwdGVtYmVyIGlzCnRoZSBjb3JyZWN0IGRlYWRsaW5lLgoKTGFk YQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGlu ZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu May 22 02:01:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42353A682F; Thu, 22 May 2008 02:01:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D5528C270 for ; Thu, 22 May 2008 02:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtAe+Konp7-f for ; Thu, 22 May 2008 02:01:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6D79628C0DD for ; Thu, 22 May 2008 02:01:28 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B85F0D800C1 for ; Thu, 22 May 2008 09:55:35 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <0a5a01c8bb7d$ee7acaf0$0600a8c0@china.huawei.com> References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> <0a5a01c8bb7d$ee7acaf0$0600a8c0@china.huawei.com> Organization: CESNET Date: Thu, 22 May 2008 09:55:34 +0200 Message-Id: <1211442935.6295.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [netmod] YIN as separate document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org RGF2aWQgSGFycmluZ3RvbiBww63FoWUgdiBTdCAyMS4gMDUuIDIwMDggdiAxNjowNCAtMDQwMDoK PiAKPiBBbnlib2R5IHRoYXQgaGFzIGFuIG9waW5vbiBhYm91dCBrZWVwaW5nIFlJTiBpbiB0aGUg WUFORyBkb2N1bWVudAo+IHZlcnN1cyBzZXBhcmF0aW5nIGl0LCBwbGVhc2Ugc3BlYWsgdXAuIFRo ZSBjaGFpcnMgd2lsbCBjb25zaWRlciB0aGUgV0cKPiBpbnB1dCBhbmQgbWFrZSBhIGRlY2lzaW9u LgoKSU1PIFlBTkcgYW5kIFlJTiBzaG91bGQgYmUgdHJlYXRlZCBhcyB0d28gZmFjZXRzIG9mIHRo ZSBzYW1lIHRoaW5nLCBzbworMSBmb3Iga2VlcGluZyB0aGVtIGluIHRoZSBzYW1lIGRvY3VtZW50 LgoKTGFkYQoKPiAKPiBEYXZpZCBIYXJyaW5ndG9uCj4gZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0 Cj4gaWV0ZmRiaEBjb21jYXN0Lm5ldAo+IGRoYXJyaW5ndG9uQGh1YXdlaS5jb20KPiAKPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWls aW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDog RTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu May 22 04:01:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E27D28C279; Thu, 22 May 2008 04:01:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FD628C278 for ; Thu, 22 May 2008 04:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK2YQPQEhLr0 for ; Thu, 22 May 2008 04:01:35 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 50C6428C281 for ; Thu, 22 May 2008 04:01:09 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 34F7E1B80C4; Thu, 22 May 2008 13:01:15 +0200 (CEST) Date: Thu, 22 May 2008 13:01:56 +0200 (CEST) Message-Id: <20080522.130156.187113218.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1211442935.6295.18.camel@missotis> References: <20080521.203028.238829365.mbj@tail-f.com> <0a5a01c8bb7d$ee7acaf0$0600a8c0@china.huawei.com> <1211442935.6295.18.camel@missotis> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YIN as separate document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gRGF2aWQgSGFycmlu Z3RvbiBww63FoWUgdiBTdCAyMS4gMDUuIDIwMDggdiAxNjowNCAtMDQwMDoNCj4gPiANCj4gPiBB bnlib2R5IHRoYXQgaGFzIGFuIG9waW5vbiBhYm91dCBrZWVwaW5nIFlJTiBpbiB0aGUgWUFORyBk b2N1bWVudA0KPiA+IHZlcnN1cyBzZXBhcmF0aW5nIGl0LCBwbGVhc2Ugc3BlYWsgdXAuIFRoZSBj aGFpcnMgd2lsbCBjb25zaWRlciB0aGUgV0cNCj4gPiBpbnB1dCBhbmQgbWFrZSBhIGRlY2lzaW9u Lg0KPiANCj4gSU1PIFlBTkcgYW5kIFlJTiBzaG91bGQgYmUgdHJlYXRlZCBhcyB0d28gZmFjZXRz IG9mIHRoZSBzYW1lIHRoaW5nLCBzbw0KPiArMSBmb3Iga2VlcGluZyB0aGVtIGluIHRoZSBzYW1l IGRvY3VtZW50Lg0KDQorMS4gIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgWUlOIG1hcHBpbmcgZG9j dW1lbnQgd2lsbCBldm9sdmUNCnNlcGFyYXRlbHkgZnJvbSB0aGUgbWFpbiBkb2N1bWVudCAobGlr ZSB0aGUgRFNETC1tYXBwaW5nIGRvY3VtZW50IG1heQ0KZG8pLCBhbmQgaXQncyBub3QgYSBsb3Qg b2YgdGV4dCB0aGF0IGNsdXR0ZXJzIHRoZSBtYWluIGRvY3VtZW50Lg0KDQpJZiB3ZSBkbyBrZWVw IGl0IGluIHRoZSBzYW1lIGRvY3VtZW50LCBJIHRoaW5rIGl0IHNob3VsZCBiZSBtb3ZlZCBmcm9t DQphbiBhcHBlbmRpeCBpbnRvIGl0cyBvd24gc2VjdGlvbi4gIEkgZG9uJ3Qga25vdyB3aHkgaXQg aXMgaW4gYW4NCmFwcGVuZGl4IHRvZGF5Li4uDQoNCg0KL21hcnRpbg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRt b2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu May 22 04:04:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2753A6AE0; Thu, 22 May 2008 04:04:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED143A6BC6 for ; Thu, 22 May 2008 04:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8n9tC8I6m35 for ; Thu, 22 May 2008 04:04:26 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id D458B3A6B00 for ; Thu, 22 May 2008 04:04:24 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 4E46F1B80C4; Thu, 22 May 2008 13:04:31 +0200 (CEST) Date: Thu, 22 May 2008 13:05:12 +0200 (CEST) Message-Id: <20080522.130512.141013979.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1211443489.6295.26.camel@missotis> References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> <1211443489.6295.26.camel@missotis> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAyMS4gMDUuIDIwMDggdiAyMDozMCArMDIwMDoNCj4gPiANCj4gPiBB cyBmb3IgdGhlIERTREwgbWFwcGluZywgSSBiZWxpZXZlIHRoZXJlIGlzIGEgYnVnIGluIHRoZSBj aGFydGVyIC0gdGhlDQo+ID4gaW5pdGlhbCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgaXMgc2NoZWR1 bGVkIGZvciBKdW4gX2FuZF8gU2VwLiAgSSB0aGluaw0KPiA+IFNlcCBpcyB0aGUgY29ycmVjdCBk YXRlLg0KPiANCj4gV291bGQgaXQgYmUgdXNlZnVsIHRvIHB1Ymxpc2ggbm93IGRyYWZ0LW1haHkt Y2FubW9kLWRzZGwtMDEgYXMgYSBXRw0KPiBkcmFmdCBub3csIG1vcmUgb3IgbGVzcyBhcyBpdCBp cz8gDQoNCkkgZG9uJ3QgdGhpbmsgc28sIHNpbXBseSBiZWNhdXNlIHRoaXMgZHJhZnQgZG9lcyBu b3QgZGVmaW5lIGEgbWFwcGluZw0Kb2YgWUFORyB0byBEU0RMLiAgKFRoZSBtYXBwaW5nIGRvY3Vt ZW50IHdpbGwgcHJvYmFibHkgcmUtdXNlIGxhcmdlDQpwYXJ0cyBvZiB0aGlzIGRvY3VtZW50IHRo b3VnaCkuDQoNCg0KL21hcnRpbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu May 22 04:56:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939E828C11E; Thu, 22 May 2008 04:56:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6501828C0E9 for ; Thu, 22 May 2008 04:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0tc1Uo-KriW for ; Thu, 22 May 2008 04:56:27 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 09FE028C166 for ; Thu, 22 May 2008 04:56:26 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA01.westchester.pa.mail.comcast.net with comcast id UbWr1Z0070cZkys5101c00; Thu, 22 May 2008 11:56:33 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id UbwT1Z00N4HwxpC3W00000; Thu, 22 May 2008 11:56:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=3XAv8hL7axYlzsx5Ka4A:9 a=JZ2Gx-G55jup7q122m1FN8PXOiYA:4 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Phil Shafer'" References: <0a5a01c8bb7d$ee7acaf0$0600a8c0@china.huawei.com> <200805220453.m4M4rh1q073925@idle.juniper.net> Date: Thu, 22 May 2008 07:56:28 -0400 Message-ID: <006b01c8bc02$df25c4d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200805220453.m4M4rh1q073925@idle.juniper.net> thread-index: Aci7yTOv1NUDYRt+QkysJhSPrq9L/wAOXn2A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] YIN as separate document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Phil, if we didn't have the freedom to control this, I wouldn't be asking for input. So far, we have not seen enough discussion of this to determine what the WG wants to do. dbh > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Thursday, May 22, 2008 12:54 AM > To: David Harrington > Cc: 'Martin Bjorklund'; netmod@ietf.org > Subject: Re: [netmod] YIN as separate document > > "David Harrington" writes: > >The charter calls for a separate docuemnt, and we have consensus on > >the charter. > > I thought the charter gave us freedom to control this: > > The working group may choose to combine multiple deliverables > into a single document where deemed appropriate. > > >Anybody that has an opinon about keeping YIN in the YANG document > >versus separating it, please speak up. The chairs will > consider the WG > >input and make a decision. > > +1 to keep it in a single document. > > Thanks, > Phil > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 22 05:02:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B9A28C0E9; Thu, 22 May 2008 05:02:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC80D3A6ADA for ; Thu, 22 May 2008 05:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-iZ-jR+RQEU for ; Thu, 22 May 2008 05:02:19 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 517A228C1EC for ; Thu, 22 May 2008 05:02:17 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 3D8B41B80C4; Thu, 22 May 2008 14:02:16 +0200 (CEST) Date: Thu, 22 May 2008 14:02:57 +0200 (CEST) Message-Id: <20080522.140257.40940954.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <0a5601c8bb7b$c556a2e0$0600a8c0@china.huawei.com> References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> <0a5601c8bb7b$c556a2e0$0600a8c0@china.huawei.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, "David Harrington" wrote: > Hi, > > speaking as co-chair ... > > Our charter calls for all drafts to be first published as individual, > and then discussed in Dublin, before being published as WG -00- > drafts. The Jun deadline is for individual drafts. The Aug date refers > to the -00- WG drafts, after the WG has agreed the individual drafts > should be adopted as WG drafts. > > The chairs approved the YANG-00 draft already because the charter > states that the WG will use YANG (draft-bjorklund-yang) as its > starting point for the human friendly language. The other drafts > should be first published as individual drafts. Does this mean that the standard derived types draft should be published as an individual draft first, or did you refer to dsdl and arch. when you said 'other'? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 22 05:27:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070ED28C0E9; Thu, 22 May 2008 05:27:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFC628C0E9 for ; Thu, 22 May 2008 05:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0b9YFk59A1b for ; Thu, 22 May 2008 05:27:53 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 6D3473A6BCC for ; Thu, 22 May 2008 05:27:53 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA05.westchester.pa.mail.comcast.net with comcast id UbkN1Z0050bG4ec5503a00; Thu, 22 May 2008 12:28:00 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id UcTz1Z0034HwxpC3P00000; Thu, 22 May 2008 12:28:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=_Y5QBs2iGHYA:10 a=7DlyBAa3s1Ix9wlXTzoA:9 a=WcQPEYDfbkFZN6z8p2urI2DMvEQA:4 a=XqebBV1NYWwA:10 a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Martin Bjorklund'" References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com><20080521.203028.238829365.mbj@tail-f.com><0a5601c8bb7b$c556a2e0$0600a8c0@china.huawei.com> <20080522.140257.40940954.mbj@tail-f.com> Date: Thu, 22 May 2008 08:27:59 -0400 Message-ID: <006c01c8bc07$45fcaf80$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20080522.140257.40940954.mbj@tail-f.com> thread-index: Aci8A7eGV8G5RTDRRpaO9uKR/x6VAQAAlTVg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, yes. The standard types draft should also be published as an individual draft first. It's an administrative thing, to ensure an open and fair process. dbh > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, May 22, 2008 8:03 AM > To: ietfdbh@comcast.net > Cc: netmod@ietf.org > Subject: Re: [netmod] individiual drafts deadline > > Hi, > > "David Harrington" wrote: > > Hi, > > > > speaking as co-chair ... > > > > Our charter calls for all drafts to be first published as > individual, > > and then discussed in Dublin, before being published as WG -00- > > drafts. The Jun deadline is for individual drafts. The Aug > date refers > > to the -00- WG drafts, after the WG has agreed the individual drafts > > should be adopted as WG drafts. > > > > The chairs approved the YANG-00 draft already because the charter > > states that the WG will use YANG (draft-bjorklund-yang) as its > > starting point for the human friendly language. The other drafts > > should be first published as individual drafts. > > Does this mean that the standard derived types draft should be > published as an individual draft first, or did you refer to dsdl and > arch. when you said 'other'? > > > /martin > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 22 05:39:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552E128C1F0; Thu, 22 May 2008 05:39:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC69228C276 for ; Thu, 22 May 2008 05:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djxy6vmkLuCK for ; Thu, 22 May 2008 05:38:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 94AD828C1F0 for ; Thu, 22 May 2008 05:38:59 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4E76C0041; Thu, 22 May 2008 14:39:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aZlyyDKPble7; Thu, 22 May 2008 14:39:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE3D0C003C; Thu, 22 May 2008 14:38:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B6FFE59BEED; Thu, 22 May 2008 14:38:56 +0200 (CEST) Date: Thu, 22 May 2008 14:38:56 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080522123856.GB4604@elstar.local> Mail-Followup-To: Phil Shafer , David Harrington , netmod@ietf.org References: <0a5a01c8bb7d$ee7acaf0$0600a8c0@china.huawei.com> <200805220453.m4M4rh1q073925@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200805220453.m4M4rh1q073925@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] YIN as separate document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, May 22, 2008 at 12:53:43AM -0400, Phil Shafer wrote: > >Anybody that has an opinon about keeping YIN in the YANG document > >versus separating it, please speak up. The chairs will consider the WG > >input and make a decision. > > +1 to keep it in a single document. +1 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 22 06:09:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C2C3A6AB1; Thu, 22 May 2008 06:09:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64CA3A6AB1 for ; Thu, 22 May 2008 06:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP0NpQ04ik4c for ; Thu, 22 May 2008 06:09:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8C7EA28C178 for ; Thu, 22 May 2008 06:09:13 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6961C001A; Thu, 22 May 2008 15:09:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Wc0NTDhQ5J8d; Thu, 22 May 2008 15:09:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A5D7C003F; Thu, 22 May 2008 15:09:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AC45359C03D; Thu, 22 May 2008 15:09:13 +0200 (CEST) Date: Thu, 22 May 2008 15:09:13 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080522130913.GA5241@elstar.local> Mail-Followup-To: David Harrington , 'Martin Bjorklund' , netmod@ietf.org References: <20080522.140257.40940954.mbj@tail-f.com> <006c01c8bc07$45fcaf80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <006c01c8bc07$45fcaf80$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, May 22, 2008 at 08:27:59AM -0400, David Harrington wrote: > yes. The standard types draft should also be published as an > individual draft first. I have submitted for (re-)consideration by the working group. Despite a few bug fixes and some editorial changes, the content of the document is identical with the data type definitions contained in . /js PS: It might take a while until the document pops up since the ID submission tool has stopped to work for me and so the document must be processed manually. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 22 07:47:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67E028C11C; Thu, 22 May 2008 07:47:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FDA28C1E8 for ; Thu, 22 May 2008 07:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mQ5W4LyT8WB for ; Thu, 22 May 2008 07:47:15 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id E0C4F28C11C for ; Thu, 22 May 2008 07:47:14 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id Uef41Z00E0vyq2s5A01H00; Thu, 22 May 2008 14:47:21 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id UenE1Z0084HwxpC3R00000; Thu, 22 May 2008 14:47:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=_Y5QBs2iGHYA:10 a=j3Z76cjpAAAA:8 a=EL0stz6LLz_5ggXGpSQA:9 a=Tp9SYz_HbO00cBqLd_wA:7 a=Q-CqpXOFMPnZQSNnawSxC3kntnQA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=XF7b4UCPwd8A:10 From: "David Harrington" To: References: <20080522.140257.40940954.mbj@tail-f.com> <006c01c8bc07$45fcaf80$0600a8c0@china.huawei.com> <20080522130913.GA5241@elstar.local> Date: Thu, 22 May 2008 10:47:15 -0400 Message-ID: <00a701c8bc1a$bd9b6af0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20080522130913.GA5241@elstar.local> thread-index: Aci8DRJwHnfSInAnT7CC4Ho03QihAAADY1+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Thank you, dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, May 22, 2008 9:09 AM > To: David Harrington > Cc: 'Martin Bjorklund'; netmod@ietf.org > Subject: Re: [netmod] individiual drafts deadline > > On Thu, May 22, 2008 at 08:27:59AM -0400, David Harrington wrote: > > > yes. The standard types draft should also be published as an > > individual draft first. > > I have submitted for > (re-)consideration by the working group. Despite a few bug fixes and > some editorial changes, the content of the document is identical with > the data type definitions contained in . > > /js > > PS: It might take a while until the document pops up since the ID > submission tool has stopped to work for me and so the document > must be processed manually. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu May 22 13:58:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F159C3A68FF; Thu, 22 May 2008 13:58:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810F23A68FF for ; Thu, 22 May 2008 13:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5xJ8fz-HB82 for ; Thu, 22 May 2008 13:57:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8C74F3A6969 for ; Thu, 22 May 2008 13:57:41 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EEDC5C0002 for ; Thu, 22 May 2008 22:57:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8qBCfQ+MsiD6 for ; Thu, 22 May 2008 22:57:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55FA3C0015 for ; Thu, 22 May 2008 22:57:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 62BE359CCF6; Thu, 22 May 2008 22:57:32 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Thu, 22 May 2008 22:57:32 +0200 Resent-Message-ID: <20080522205732.GA7082@elstar.local> Resent-To: netmod@ietf.org Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.2.13) with LMTPA; Thu, 22 May 2008 22:02:22 +0200 X-Sieve: CMU Sieve 2.2 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by merkur.jacobs-university.de (Postfix) with ESMTP id 83032472E7 for ; Thu, 22 May 2008 22:02:22 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85C39C0027 for ; Thu, 22 May 2008 22:02:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qdBU54qsDsHi for ; Thu, 22 May 2008 22:02:17 +0200 (CEST) X-JacobsISPWhiteListed: med ietf.org DNSWLId 1703 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7BF7C001B for ; Thu, 22 May 2008 22:02:16 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5706B28C12D; Thu, 22 May 2008 13:01:00 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 458143A6801; Thu, 22 May 2008 13:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080522200001.458143A6801@core3.amsl.com> Date: Thu, 22 May 2008 13:00:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Subject: [netmod] I-D ACTION:draft-schoenw-netmod-yang-types-00.txt X-BeenThere: netmod@ietf.org Reply-To: internet-drafts@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Common YANG Data Types Author(s) : J. Schoenwaelder Filename : draft-schoenw-netmod-yang-types-00.txt Pages : 24 Date : 2008-5-22 This document introduces a collection of common data types to be used with the YANG data modeling language. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-netmod-yang-types-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-schoenw-netmod-yang-types-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-22124555.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --NextPart-- From netmod-bounces@ietf.org Thu May 22 16:45:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FAE3A6B77; Thu, 22 May 2008 16:45:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC373A6B77 for ; Thu, 22 May 2008 16:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kltkvnRZ+R3u for ; Thu, 22 May 2008 16:45:10 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id B50EB3A6B7D for ; Thu, 22 May 2008 16:45:08 -0700 (PDT) Received: (qmail 46354 invoked from network); 22 May 2008 23:38:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 22 May 2008 23:38:25 -0000 X-YMail-OSG: QZ5hdbwVM1kCpxwqLGyA_htA4.MFlSF.Cb7ew_N4ATRBTh.oHfYtdplVldnfSrAbR4nTXyYYrSjA3tDmJ0lFQXrsUS.cPIcJW5vzqbIQ_qDRot5GVhKY9fvhP5hrx3Xeapj_pOnDBp0EaoPM7c65FY0C X-Yahoo-Newman-Property: ymail-3 Message-ID: <483603F0.5090201@andybierman.com> Date: Thu, 22 May 2008 16:38:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Subject: [netmod] Online YANG module checker X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I am starting a new WEB site called Netconf Central, which has some free YANG tools. The 'yangto' program has been renamed 'yangdump' and is freely available in binary form: http://www.netconfcentral.com/download YANG modules can also be validated online: http://www.netconfcentral.com/run_yangdump (The WEB pages are still kind of rough, and most of the tools are not done yet, but maybe 'yangdump' can help people learn/use YANG a little better.) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 23 05:34:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555BB3A69D4; Fri, 23 May 2008 05:34:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0083A69D4 for ; Fri, 23 May 2008 05:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IceE22hgAFpS for ; Fri, 23 May 2008 05:34:39 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id CFDFB3A69D1 for ; Fri, 23 May 2008 05:34:38 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Uzf71Z0040ldTLk5504U00; Fri, 23 May 2008 12:34:37 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.westchester.pa.mail.comcast.net with comcast id V0ab1Z0064HwxpC3Q00000; Fri, 23 May 2008 12:34:37 +0000 X-Authority-Analysis: v=1.0 c=1 a=_Y5QBs2iGHYA:10 a=48vgC7mUAAAA:8 a=iJvCStY_JYk8PjQLZzIA:9 a=OhZR119pO33JEzxWIjaWPhn2Yd4A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Ladislav Lhotka'" , References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com><20080521.203028.238829365.mbj@tail-f.com> <1211443489.6295.26.camel@missotis> Date: Fri, 23 May 2008 08:34:35 -0400 Message-ID: <016a01c8bcd1$5ce61b30$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <1211443489.6295.26.camel@missotis> thread-index: Aci75demzn8/tTOzRZOFMr/aFJnM5wAHUE7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I don't think the current draft provides a mapping from YANG to DSDL. We need a mapping document. I think we need it soon so the WG, not just the editor, can see the scope of the problem, and start to work on proposing the mappings. We have a WG to contribute to the effort, so we should not expect just the editor to do all the work on this. The initial version does not not need to map everything that YANG can do now, just start the process. I would like to see an individual draft published by the June deadline. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netmod-bounces@ietf.org = > [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Thursday, May 22, 2008 4:05 AM > To: netmod@ietf.org > Subject: Re: [netmod] individiual drafts deadline > = > Martin Bjorklund p=ED=B9e v St 21. 05. 2008 v 20:30 +0200: > > = > > As for the DSDL mapping, I believe there is a bug in the = > charter - the > > initial version of this draft is scheduled for Jun _and_ = > Sep. I think > > Sep is the correct date. > = > Would it be useful to publish now draft-mahy-canmod-dsdl-01 as a WG > draft now, more or less as it is? Otherwise, I also think September is > the correct deadline. > = > Lada > = > -- = > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > = _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 23 07:11:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A613A6CB2; Fri, 23 May 2008 07:11:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D71A3A6CB5 for ; Fri, 23 May 2008 07:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAi4Y6G6yWCa for ; Fri, 23 May 2008 07:11:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9A5E63A6CB2 for ; Fri, 23 May 2008 07:11:35 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7C291D800C1; Fri, 23 May 2008 15:53:39 +0200 (CEST) From: Ladislav Lhotka To: David Harrington In-Reply-To: <016a01c8bcd1$5ce61b30$0600a8c0@china.huawei.com> References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> <1211443489.6295.26.camel@missotis> <016a01c8bcd1$5ce61b30$0600a8c0@china.huawei.com> Organization: CESNET Date: Fri, 23 May 2008 15:53:38 +0200 Message-Id: <1211550818.8247.14.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGkgRGF2ZSwKCmR1cmluZyB0aGUgbGFzdCB0d28gbW9udGhzIG9yIHNvIEkndmUgYmVlbiB3b3Jr aW5nIG9uIGEgcHJvZ3JhbSB0aGF0CmRvZXMgdGhlIHRyYW5zbGF0aW9uLiBJdCBjYW4gbm93IGhh bmRsZSBtb3N0IG9mIHRoZSBzdHVmZiB0aGF0IGNhbiBiZQpyZXByZXNlbnRlZCBpbiBSRUxBWCBO RyBidXQgbm8gU2NoZW1hdHJvbiBvciBhbnl0aGluZyBlbHNlIHlldC4gSSBjb3VsZApkZXNjcmli ZSB0aGUgYWxnb3JpdGhtIGluIGEgZHJhZnQsIGlmIHlvdSB0aGluayBpdCB3b3VsZCBiZSB1c2Vm dWwuCgpMYWRhCgpEYXZpZCBIYXJyaW5ndG9uIHDDrcWhZSB2IFDDoSAyMy4gMDUuIDIwMDggdiAw ODozNCAtMDQwMDoKPiBIaSwKPiAKPiBJIGRvbid0IHRoaW5rIHRoZSBjdXJyZW50IGRyYWZ0IHBy b3ZpZGVzIGEgbWFwcGluZyBmcm9tIFlBTkcgdG8gRFNETC4KPiBXZSBuZWVkIGEgbWFwcGluZyBk b2N1bWVudC4KPiAKPiBJIHRoaW5rIHdlIG5lZWQgaXQgc29vbiBzbyB0aGUgV0csIG5vdCBqdXN0 IHRoZSBlZGl0b3IsIGNhbiBzZWUgdGhlCj4gc2NvcGUgb2YgdGhlIHByb2JsZW0sIGFuZCBzdGFy dCB0byB3b3JrIG9uIHByb3Bvc2luZyB0aGUgbWFwcGluZ3MuIFdlCj4gaGF2ZSBhIFdHIHRvIGNv bnRyaWJ1dGUgdG8gdGhlIGVmZm9ydCwgc28gd2Ugc2hvdWxkIG5vdCBleHBlY3QganVzdAo+IHRo ZSBlZGl0b3IgdG8gZG8gYWxsIHRoZSB3b3JrIG9uIHRoaXMuIFRoZSBpbml0aWFsIHZlcnNpb24g ZG9lcyBub3QKPiBub3QgbmVlZCB0byBtYXAgZXZlcnl0aGluZyB0aGF0IFlBTkcgY2FuIGRvIG5v dywganVzdCBzdGFydCB0aGUKPiBwcm9jZXNzLgo+IAo+IEkgd291bGQgbGlrZSB0byBzZWUgYW4g aW5kaXZpZHVhbCBkcmFmdCBwdWJsaXNoZWQgYnkgdGhlIEp1bmUKPiBkZWFkbGluZS4KPiAKPiBE YXZpZCBIYXJyaW5ndG9uCj4gZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0Cj4gaWV0ZmRiaEBjb21j YXN0Lm5ldAo+IGRoYXJyaW5ndG9uQGh1YXdlaS5jb20KPiAKPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tCj4gPiBGcm9tOiBuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyAKPiA+IFttYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMYWRpc2xhdiBMaG90a2EKPiA+ IFNlbnQ6IFRodXJzZGF5LCBNYXkgMjIsIDIwMDggNDowNSBBTQo+ID4gVG86IG5ldG1vZEBpZXRm Lm9yZwo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGluZGl2aWRpdWFsIGRyYWZ0cyBkZWFkbGlu ZQo+ID4gCj4gPiBNYXJ0aW4gQmpvcmtsdW5kIHDDrcWhZSB2IFN0IDIxLiAwNS4gMjAwOCB2IDIw OjMwICswMjAwOgo+ID4gPiAKPiA+ID4gQXMgZm9yIHRoZSBEU0RMIG1hcHBpbmcsIEkgYmVsaWV2 ZSB0aGVyZSBpcyBhIGJ1ZyBpbiB0aGUgCj4gPiBjaGFydGVyIC0gdGhlCj4gPiA+IGluaXRpYWwg dmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGlzIHNjaGVkdWxlZCBmb3IgSnVuIF9hbmRfIAo+ID4gU2Vw LiAgSSB0aGluawo+ID4gPiBTZXAgaXMgdGhlIGNvcnJlY3QgZGF0ZS4KPiA+IAo+ID4gV291bGQg aXQgYmUgdXNlZnVsIHRvIHB1Ymxpc2ggbm93IGRyYWZ0LW1haHktY2FubW9kLWRzZGwtMDEgYXMg YSBXRwo+ID4gZHJhZnQgbm93LCBtb3JlIG9yIGxlc3MgYXMgaXQgaXM/IE90aGVyd2lzZSwgSSBh bHNvIHRoaW5rIFNlcHRlbWJlcgo+IGlzCj4gPiB0aGUgY29ycmVjdCBkZWFkbGluZS4KPiA+IAo+ ID4gTGFkYQo+ID4gCj4gPiAtLSAKPiA+IExhZGlzbGF2IExob3RrYSwgQ0VTTkVUCj4gPiBQR1Ag S2V5IElEOiBFNzRFOEMwQwo+ID4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdAo+ID4gbmV0bW9kQGlldGYu b3JnCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+ID4g Cj4gCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxp bmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri May 23 08:37:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96623A6942; Fri, 23 May 2008 08:37:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88953A6942 for ; Fri, 23 May 2008 08:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+BWCnv0MFp4 for ; Fri, 23 May 2008 08:36:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 95EF63A6B6A for ; Fri, 23 May 2008 08:36:59 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FA89C0006; Fri, 23 May 2008 17:36:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pCVU9coVLXIk; Fri, 23 May 2008 17:36:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AF18C000A; Fri, 23 May 2008 17:36:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4BB0959E1E0; Fri, 23 May 2008 17:36:51 +0200 (CEST) Date: Fri, 23 May 2008 17:36:51 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080523153651.GA9276@elstar.local> Mail-Followup-To: Ladislav Lhotka , David Harrington , netmod@ietf.org References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> <1211443489.6295.26.camel@missotis> <016a01c8bcd1$5ce61b30$0600a8c0@china.huawei.com> <1211550818.8247.14.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1211550818.8247.14.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, May 23, 2008 at 03:53:38PM +0200, Ladislav Lhotka wrote: > Hi Dave, > > during the last two months or so I've been working on a program that > does the translation. It can now handle most of the stuff that can be > represented in RELAX NG but no Schematron or anything else yet. I could > describe the algorithm in a draft, if you think it would be useful. Your program translates from YANG to Relax NG or from Relax NG to YANG or both? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 23 09:00:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9618A3A6CAE; Fri, 23 May 2008 09:00:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE1F3A6A33 for ; Fri, 23 May 2008 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIwmN3WVzsNZ for ; Fri, 23 May 2008 08:59:59 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 61CEA3A6CEC for ; Fri, 23 May 2008 08:59:40 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA06.westchester.pa.mail.comcast.net with comcast id V1Ge1Z0400bG4ec5608300; Fri, 23 May 2008 15:59:39 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id V3zf1Z0034HwxpC3P00000; Fri, 23 May 2008 15:59:39 +0000 X-Authority-Analysis: v=1.0 c=1 a=_Y5QBs2iGHYA:10 a=48vgC7mUAAAA:8 a=tniBeTz_l5s1dCyKHoMA:9 a=bUh6Bysvrurpyw5aDN_ZVTHITb4A:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Ladislav Lhotka'" References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> <1211443489.6295.26.camel@missotis> <016a01c8bcd1$5ce61b30$0600a8c0@china.huawei.com> <1211550818.8247.14.camel@missotis> Date: Fri, 23 May 2008 11:59:39 -0400 Message-ID: <019101c8bcee$01b55b00$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <1211550818.8247.14.camel@missotis> thread-index: Aci83GmREswCZ3avSfCez566kIHYOwAEOEKw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I think that would be useful. I also welcome other YANG-RelaxNG drafts, (and other individual drafts toward the chartered deliverables) and the WG might decide multiple individual drafts should be combined to create the chartered WG drafts. Don't worry about creating a perfect draft; focus on documenting the ideas, and we'll worry about perfecting a WG draft later. Thanks, dbh = > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@cesnet.cz] = > Sent: Friday, May 23, 2008 9:54 AM > To: David Harrington > Cc: netmod@ietf.org > Subject: RE: [netmod] individiual drafts deadline > = > Hi Dave, > = > during the last two months or so I've been working on a program that > does the translation. It can now handle most of the stuff that can be > represented in RELAX NG but no Schematron or anything else = > yet. I could > describe the algorithm in a draft, if you think it would be useful. > = > Lada > = > David Harrington p=ED=B9e v P=E1 23. 05. 2008 v 08:34 -0400: > > Hi, > > = > > I don't think the current draft provides a mapping from = > YANG to DSDL. > > We need a mapping document. > > = > > I think we need it soon so the WG, not just the editor, can see the > > scope of the problem, and start to work on proposing the = > mappings. We > > have a WG to contribute to the effort, so we should not expect just > > the editor to do all the work on this. The initial version does not > > not need to map everything that YANG can do now, just start the > > process. > > = > > I would like to see an individual draft published by the June > > deadline. > > = > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > = > > > -----Original Message----- > > > From: netmod-bounces@ietf.org = > > > [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka > > > Sent: Thursday, May 22, 2008 4:05 AM > > > To: netmod@ietf.org > > > Subject: Re: [netmod] individiual drafts deadline > > > = > > > Martin Bjorklund p=ED=B9e v St 21. 05. 2008 v 20:30 +0200: > > > > = > > > > As for the DSDL mapping, I believe there is a bug in the = > > > charter - the > > > > initial version of this draft is scheduled for Jun _and_ = > > > Sep. I think > > > > Sep is the correct date. > > > = > > > Would it be useful to publish now = > draft-mahy-canmod-dsdl-01 as a WG > > > draft now, more or less as it is? Otherwise, I also think = > September > > is > > > the correct deadline. > > > = > > > Lada > > > = > > > -- = > > > Ladislav Lhotka, CESNET > > > PGP Key ID: E74E8C0C > > > = > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > = > > = > -- = > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > = > = _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 23 09:10:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6351C3A6B95; Fri, 23 May 2008 09:10:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E213A6B95 for ; Fri, 23 May 2008 09:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFv4G4dEPNYj for ; Fri, 23 May 2008 09:10:33 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 942A73A6CE8 for ; Fri, 23 May 2008 09:10:33 -0700 (PDT) Received: (qmail 28615 invoked from network); 23 May 2008 16:10:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 23 May 2008 16:10:31 -0000 X-YMail-OSG: oi8QQnoVM1l5NX9TxvP4wwoicAHCOJzW.dzYh6df7KYTPUMS6vM6aO6Ue8hnos5LUEiLAUvIcTfG2VkQcJqQz4M2Syc5wbbe5PkNEOwr5fD6eVFwKpPTWjWkUYMCnsTR_OiIzTilMj7FcC2hHsJHA7B2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4836EC73.8030304@andybierman.com> Date: Fri, 23 May 2008 09:10:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] DSDL questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I looked over the specs at the DSDL WEB site: http://dsdl.org/ Q1) Of the 10 documents listed there, which subset is the NETMOD WG selecting? Q2) Where can I find free tools which do useful things with the DSDL framework? Q3) Where can I find data models which have already been written in DSDL+Schematron, so I can understand it better? (I mean other than the examples generated for the benefit of the CANMOD BoF) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri May 23 10:39:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CBFE3A6C6E; Fri, 23 May 2008 10:39:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A083A6C97 for ; Fri, 23 May 2008 10:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd1uxFN8DRI2 for ; Fri, 23 May 2008 10:39:30 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 05D1C3A6BD1 for ; Fri, 23 May 2008 10:39:30 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D5F48D800BD; Fri, 23 May 2008 19:39:28 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080523153651.GA9276@elstar.local> References: <0a2a01c8bb5d$dd555990$0600a8c0@china.huawei.com> <20080521.203028.238829365.mbj@tail-f.com> <1211443489.6295.26.camel@missotis> <016a01c8bcd1$5ce61b30$0600a8c0@china.huawei.com> <1211550818.8247.14.camel@missotis> <20080523153651.GA9276@elstar.local> Organization: CESNET Date: Fri, 23 May 2008 19:39:29 +0200 Message-Id: <1211564369.8247.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: netmod@ietf.org Subject: Re: [netmod] individiual drafts deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFDDoSAyMy4gMDUuIDIwMDggdiAxNzozNiAr MDIwMDoKPiBPbiBGcmksIE1heSAyMywgMjAwOCBhdCAwMzo1MzozOFBNICswMjAwLCBMYWRpc2xh diBMaG90a2Egd3JvdGU6Cj4gPiBIaSBEYXZlLAo+ID4gCj4gPiBkdXJpbmcgdGhlIGxhc3QgdHdv IG1vbnRocyBvciBzbyBJJ3ZlIGJlZW4gd29ya2luZyBvbiBhIHByb2dyYW0gdGhhdAo+ID4gZG9l cyB0aGUgdHJhbnNsYXRpb24uIEl0IGNhbiBub3cgaGFuZGxlIG1vc3Qgb2YgdGhlIHN0dWZmIHRo YXQgY2FuIGJlCj4gPiByZXByZXNlbnRlZCBpbiBSRUxBWCBORyBidXQgbm8gU2NoZW1hdHJvbiBv ciBhbnl0aGluZyBlbHNlIHlldC4gSSBjb3VsZAo+ID4gZGVzY3JpYmUgdGhlIGFsZ29yaXRobSBp biBhIGRyYWZ0LCBpZiB5b3UgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsLgo+IAo+IFlvdXIgcHJv Z3JhbSB0cmFuc2xhdGVzIGZyb20gWUFORyB0byBSZWxheCBORyBvciBmcm9tIFJlbGF4IE5HIHRv IFlBTkcKPiBvciBib3RoPwoKWUFORyB0byBSRUxBWCBORy4KCkxhZGEKCj4gCj4gL2pzCj4gCi0t IApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlz dApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QK From netmod-bounces@ietf.org Fri May 23 15:17:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4FB3A69AC; Fri, 23 May 2008 15:17:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D57C3A6D00 for ; Fri, 23 May 2008 15:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBheXmLBz+-G for ; Fri, 23 May 2008 15:17:50 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 736713A69AC for ; Fri, 23 May 2008 15:17:50 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 3E766D800BD for ; Sat, 24 May 2008 00:17:46 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4836EC73.8030304@andybierman.com> References: <4836EC73.8030304@andybierman.com> Organization: CESNET Date: Sat, 24 May 2008 00:17:47 +0200 Message-Id: <1211581067.8247.41.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [netmod] DSDL questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFDDoSAyMy4gMDUuIDIwMDggdiAwOToxMCAtMDcwMDoKPiBI aSwKPiAKPiBJIGxvb2tlZCBvdmVyIHRoZSBzcGVjcyBhdCB0aGUgRFNETCBXRUIgc2l0ZToKPiBo dHRwOi8vZHNkbC5vcmcvCj4gCj4gUTEpIE9mIHRoZSAxMCBkb2N1bWVudHMgbGlzdGVkIHRoZXJl LCB3aGljaCBzdWJzZXQgaXMKPiAgICAgIHRoZSBORVRNT0QgV0cgc2VsZWN0aW5nPwoKSW4gdGhl IGZpcnN0IHBoYXNlIG1haW5seSBwYXJ0cyAyIChSRUxBWCBORykgYW5kIDMgKFNjaGVtYXRyb24p Lgo+IAo+IFEyKSBXaGVyZSBjYW4gSSBmaW5kIGZyZWUgdG9vbHMgd2hpY2ggZG8gdXNlZnVsIHRo aW5ncyB3aXRoCj4gICAgICB0aGUgRFNETCBmcmFtZXdvcms/CgpUaGUgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIGZvciBJU08gU2NoZW1hdHJvbiAoWFNMVCBzdHlsZXNoZWV0KSBpcwpoZXJlOiBo dHRwOi8vd3d3LnNjaGVtYXRyb24uY29tL2ltcGxlbWVudGF0aW9uLmh0bWwKT3RoZXIgaW1wbGVt ZW50YXRpb25zIGFyZSBsaXN0ZWQgaW4gdGhlICJSZXNvdXJjZXMiIGFuZCAiTGlua3MiIHNlY3Rp b25zCmF0IHRoZSBzYW1lIHNpdGUuCgo+IAo+IFEzKSBXaGVyZSBjYW4gSSBmaW5kIGRhdGEgbW9k ZWxzIHdoaWNoIGhhdmUgYWxyZWFkeSBiZWVuIHdyaXR0ZW4KPiAgICAgIGluIERTREwrU2NoZW1h dHJvbiwgc28gSSBjYW4gdW5kZXJzdGFuZCBpdCBiZXR0ZXI/ICAoSSBtZWFuCj4gICAgICBvdGhl ciB0aGFuIHRoZSBleGFtcGxlcyBnZW5lcmF0ZWQgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBDQU5N T0QgQm9GKQoKQUZBSUssIHRoZSBtb3N0IGNvbXByZWhlbnNpdmUgZXhhbXBsZSBzbyBmYXIgaXMg Um9oYW4ncyBESENQIHNjaGVtYSBpbgpBcHBlbmRpeCBEIG9mIGRyYWZ0LW1haHktY2FubW9kLWRz ZGwtMDEudHh0LiBTb21lIGdlbmVyaWMgZXhhbXBsZXMgY2FuCmJlIGZvdW5kIGluIHRoaXMgdHV0 b3JpYWw6Cmh0dHA6Ly93d3cuenZvbi5vcmcveHhsL1NjaGVtYXRyb25UdXRvcmlhbC9HZW5lcmFs L3RvYy5odG1sCgpMYWRhCgo+IAo+IAo+IEFuZHkKPiAKPiAKPiAKPiAKPiAKPiAKPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5n IGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0 RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5l dG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri May 23 18:14:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2213A6CA9; Fri, 23 May 2008 18:14:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29493A6D1E for ; Fri, 23 May 2008 18:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk8mo0w9j4JQ for ; Fri, 23 May 2008 18:14:12 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id C9B113A6CA9 for ; Fri, 23 May 2008 18:14:12 -0700 (PDT) Received: (qmail 94858 invoked from network); 24 May 2008 01:14:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 24 May 2008 01:14:06 -0000 X-YMail-OSG: ZLOoJVUVM1lYUIuk067iak5g8t4f8WWOyGBGNqnF8pBwTULU3WlACa8kZO9VWGm2cXJWqsKbz.8Cdx0G6fM3lKt4NQrxiPF3zrW5c2RzhZsrc7R6DR0ew4b4OTVxhJ__QB58sCvr87igrnmH1sVUYC2C X-Yahoo-Newman-Property: ymail-3 Message-ID: <48376BDD.2060709@andybierman.com> Date: Fri, 23 May 2008 18:14:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <4836EC73.8030304@andybierman.com> <1211581067.8247.41.camel@missotis> In-Reply-To: <1211581067.8247.41.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] DSDL questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQw6EgMjMuIDA1 LiAyMDA4IHYgMDk6MTAgLTA3MDA6Cj4+IEhpLAo+Pgo+PiBJIGxvb2tlZCBvdmVyIHRoZSBzcGVj cyBhdCB0aGUgRFNETCBXRUIgc2l0ZToKPj4gaHR0cDovL2RzZGwub3JnLwo+Pgo+PiBRMSkgT2Yg dGhlIDEwIGRvY3VtZW50cyBsaXN0ZWQgdGhlcmUsIHdoaWNoIHN1YnNldCBpcwo+PiAgICAgIHRo ZSBORVRNT0QgV0cgc2VsZWN0aW5nPwo+IAoKVGhlIGRzZGwub3JnIFdFQiBzaXRlIGhhcyBub3Qg YmVlbiB1cGRhdGVkIHNpbmNlIE5vdmVtYmVyIDIwMDYuCjIgb2YgdGhlIDEwIGRvY3VtZW50cyB3 ZXJlIG5ldmVyIHdyaXR0ZW4uICBNb3N0IG9mIHRoZW0gZG8gbm90Cmxvb2sgbGlrZSB0aGV5IGhh dmUgbXVjaCBkZXBsb3ltZW50LgoKCj4gSW4gdGhlIGZpcnN0IHBoYXNlIG1haW5seSBwYXJ0cyAy IChSRUxBWCBORykgYW5kIDMgKFNjaGVtYXRyb24pLgo+PiBRMikgV2hlcmUgY2FuIEkgZmluZCBm cmVlIHRvb2xzIHdoaWNoIGRvIHVzZWZ1bCB0aGluZ3Mgd2l0aAo+PiAgICAgIHRoZSBEU0RMIGZy YW1ld29yaz8KPiAKPiBUaGUgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIGZvciBJU08gU2NoZW1h dHJvbiAoWFNMVCBzdHlsZXNoZWV0KSBpcwo+IGhlcmU6IGh0dHA6Ly93d3cuc2NoZW1hdHJvbi5j b20vaW1wbGVtZW50YXRpb24uaHRtbAo+IE90aGVyIGltcGxlbWVudGF0aW9ucyBhcmUgbGlzdGVk IGluIHRoZSAiUmVzb3VyY2VzIiBhbmQgIkxpbmtzIiBzZWN0aW9ucwo+IGF0IHRoZSBzYW1lIHNp dGUuCj4gCgpUaGUgcHJlbWlzZSBmb3IgdGhpcyBEU0RMK1NjaGVtYXRyb24gY2hhcnRlciByZXF1 aXJlbWVudCBpcwpjbGVhcmx5IHN0YXRlZCBpbiB0aGUgZmlyc3Qgc2VudGVuY2U6CgogICAgSW4g b3JkZXIgdG8gbGV2ZXJhZ2UgZXhpc3RpbmcgWE1MIHRvb2xzIGZvciB2YWxpZGF0aW5nIE5FVENP TkYKICAgIGRhdGEgaW4gdmFyaW91cyBjb250ZXh0cyBhbmQgYWxzbyBmYWNpbGl0YXRlIGV4Y2hh bmdlIG9mIGRhdGEKICAgIG1vZGVscyBhbmQgc2NoZW1hcyB3aXRoIG90aGVyIElFVEYgd29ya2lu ZyBncm91cHMsIHRoZSBXRyB3aWxsCiAgICBkZWZpbmUgc3RhbmRhcmQgbWFwcGluZyBydWxlcyBm cm9tIFlBTkcgdG8gdGhlIERTREwgZGF0YSBtb2RlbGluZwogICAgZnJhbWV3b3JrIChJU08vSUVD IDE5NzU3KSB3aXRoIGFkZGl0aW9uYWwgYW5ub3RhdGlvbnMgdG8gcHJlc2VydmUKICAgIHNlbWFu dGljcy4KCkl0IGlzIHJlYXNvbmFibGUgdG8gZXhwZWN0IG1vcmUgZGVwbG95bWVudCBvZiB0aGlz IFJORytTY2hlbWF0cm9uCnRlY2hub2xvZ3kgdGhhbiBhIGJldGEtbGV2ZWwgcmVmZXJlbmNlIGlt cGxlbWVudGF0aW9uIGZvciBTY2hlbWF0cm9uLgoKCj4+IFEzKSBXaGVyZSBjYW4gSSBmaW5kIGRh dGEgbW9kZWxzIHdoaWNoIGhhdmUgYWxyZWFkeSBiZWVuIHdyaXR0ZW4KPj4gICAgICBpbiBEU0RM K1NjaGVtYXRyb24sIHNvIEkgY2FuIHVuZGVyc3RhbmQgaXQgYmV0dGVyPyAgKEkgbWVhbgo+PiAg ICAgIG90aGVyIHRoYW4gdGhlIGV4YW1wbGVzIGdlbmVyYXRlZCBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlIENBTk1PRCBCb0YpCj4gCj4gQUZBSUssIHRoZSBtb3N0IGNvbXByZWhlbnNpdmUgZXhhbXBs ZSBzbyBmYXIgaXMgUm9oYW4ncyBESENQIHNjaGVtYSBpbgo+IEFwcGVuZGl4IEQgb2YgZHJhZnQt bWFoeS1jYW5tb2QtZHNkbC0wMS50eHQuIFNvbWUgZ2VuZXJpYyBleGFtcGxlcyBjYW4KPiBiZSBm b3VuZCBpbiB0aGlzIHR1dG9yaWFsOgo+IGh0dHA6Ly93d3cuenZvbi5vcmcveHhsL1NjaGVtYXRy b25UdXRvcmlhbC9HZW5lcmFsL3RvYy5odG1sCj4gCgpUaGVzZSBhcmUgJ0hlbGxvIHdvcmxkJyBr aW5kIG9mIG1vZGVscy4KV2UgbmVlZCB0byBtb2RlbCBodWdlLCBjb21wbGV4IHN0dWZmIGxpa2Ug RElGRlNFUlYtTUlCLgoKPGNoYXJ0ZXItcmFudD4KSSBhc3N1bWVkIHRoYXQgdGhlIGNsb3NlZCBk ZXNpZ24gdGVhbSB3b3JrZWQgb3V0IGRldGFpbHMKc3VjaCBhcyB0aGUgc2tpbGxlZCBwZW9wbGUg bmVlZGVkIHRvIGNvbXBsZXRlIGVhY2ggZG9jdW1lbnQKZGVsaXZlcmFibGUuICBJdCBkb2Vzbid0 IGxvb2sgdGhhdCB3YXkgZm9yIHRoZSBJU08gMTk3NTcgbWFwcGluZy4KTmV2ZXIgbWluZCB0aGUg b2J2aW91cyBxdWVzdGlvbiBvZiB3aHkgdGhlIE5FVENPTkYgV0cgc2hvdWxkCmJlIGZvcmNlZCB0 byB1c2VkIHRoaXMgc3RhbmRhcmQgd2hlbiB0aGUgYXBwbGljYXRpb25zIHdvcmxkCmRvZXMgbm90 IGV2ZW4gdXNlIGl0IC0tIGhvdyBhYm91dCB0aGUgcHJhY3RpY2FsIHF1ZXN0aW9uIG9mCmhvdyB3 aWxsIHRoZSBXRyBhZGVxdWF0ZWx5IHNwZWNpZnkgYW5kIHJldmlldyB0aGlzIG1hcHBpbmcgZG9j dW1lbnQ/CgpJdCBpcyBvbmUgdGhpbmcgaWYgdGhlIElFU0cgd2FudHMgdG8gbWFuZGF0ZSB0aGF0 IGFsbCBXR3Mgc3dpdGNoCmZyb20gWFNEIHRvIFJlbGF4TkcgKG9yIGlzIGl0IGp1c3QgdGhlIE5F VENPTkYgV0cgYWdhaW4/KS4KSSBjYW4gZGVhbCB3aXRoIHRoYXQuICBUaGVyZSBhcmUgbG90cyBv ZiB0b29scyBmb3IgUmVsYXhORy4KKEkgYW0gd29ya2luZyBvbiBhIE5FVENPTkYgY2xpZW50IGxp YiBmb3IgbGlieG1sMiwgZXZlbiwKd2hpY2ggaGFzIGdyZWF0IFJlbGF4Tkcgc3VwcG9ydC4gOy0p CgpJIHRoaW5rIGEgWUFORyB0byBSZWxheE5HIG1hcHBpbmcgbWFrZXMgcHJhY3RpY2FsIHNlbnNl LApzdGFuZGFyZHMgc2Vuc2UsIGFuZCB3ZSBoYXZlIHRoZSByZXNvdXJjZXMgdG8gZG8gYSBjb21w ZXRlbnQKam9iIG9uIHRoZSBtYXBwaW5nIGRvY3VtZW50LiAgSU1PLCBhbnkgbW9yZSB0aGFuIHRo YXQgaXMgcmVhbGx5IGRvdWJ0ZnVsLgo8L2NoYXJ0ZXItcmFudD4KCgo+IExhZGEKPiAKCkFuZHkK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBt YWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Sat May 24 04:51:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBC73A67EB; Sat, 24 May 2008 04:51:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9863A6866 for ; Sat, 24 May 2008 04:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su-hDV+nED2M for ; Sat, 24 May 2008 04:51:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AC1923A6812 for ; Sat, 24 May 2008 04:51:26 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6390DD800BD; Sat, 24 May 2008 13:51:24 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48376BDD.2060709@andybierman.com> References: <4836EC73.8030304@andybierman.com> <1211581067.8247.41.camel@missotis> <48376BDD.2060709@andybierman.com> Organization: CESNET Date: Sat, 24 May 2008 13:51:24 +0200 Message-Id: <1211629884.16762.24.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: netmod@ietf.org Subject: Re: [netmod] DSDL questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFDDoSAyMy4gMDUuIDIwMDggdiAxODoxNCAtMDcwMDoKPiBJ IHRoaW5rIGEgWUFORyB0byBSZWxheE5HIG1hcHBpbmcgbWFrZXMgcHJhY3RpY2FsIHNlbnNlLAo+ IHN0YW5kYXJkcyBzZW5zZSwgYW5kIHdlIGhhdmUgdGhlIHJlc291cmNlcyB0byBkbyBhIGNvbXBl dGVudAo+IGpvYiBvbiB0aGUgbWFwcGluZyBkb2N1bWVudC4gIElNTywgYW55IG1vcmUgdGhhbiB0 aGF0IGlzIHJlYWxseQo+IGRvdWJ0ZnVsLgoKUkVMQVggTkcgd2lsbCBjZXJ0YWlubHkgYmUgdGhl IG1vc3QgZnVuZGFtZW50YWwgcGFydCBpbiBhbnkgY2FzZS4gSXQKd2lsbCBtYWtlIG5vIGhhcm0g dGhvdWdoIHRvIGV4cHJlc3Mgc29tZSBjb25zdHJhaW50cywgZS5nLiwgdGhvc2UKc3BlY2lmaWVk IGluICJtdXN0IiBvciAidW5pcXVlIiBzdGF0ZW1lbnRzLCB3aXRoIFNjaGVtYXRyb24gcnVsZXMK ZW1iZWRkZWQgaW4gdGhlIFJFTEFYIE5HIHNjaGVtYSwgYW5kIO+7v21ldGFpbmZvcm1hdGlvbiBp biBEdWJsaW4gQ29yZS4KVGhpcyB3aWxsIGJlIGFscmVhZHkgcXVpdGUgdXNlZnVsLgoKWW91IGFy ZSByaWdodCB0aGF0IHRoZSBvdGhlciBwYXJ0cyBvZiBEU0RMIGFyZSBzdGlsbApyZXNlYXJjaHkv dmFwb3J3YXJlLiBIb3dldmVyLCBzb21lIG9mIHRoZXNlIGNvbmNlcHRzIGFyZSBJTU8gb2YgaW50 ZXJlc3QKZXZlbiBmb3IgWUFORyBpdHNlbGYuIFRoaXMgaXMgZXNwZWNpYWxseSB0aGUgY2FzZSBv ZiB0aGUgRGF0YXR5cGluZwpMaWJyYXJ5IExhbmd1YWdlLiBUaGlzIHBhcGVyIGJ5IEplbmkgVGVu bmlzb24gZ2l2ZXMgYSBuaWNlIG92ZXJ2aWV3IG9mCnRoZSBwcm9ibGVtcyBvZiB0aGUgZXhpc3Rp bmcgbGlicmFyaWVzIGZvciBYU0QsIFJORywgYW5kIFlBTkcgYXMgd2VsbDoKCmh0dHA6Ly93d3cu aWRlYWxsaWFuY2Uub3JnL3BhcGVycy9leHRyZW1lL3Byb2NlZWRpbmdzL2h0bWwvMjAwNi9UZW5u aXNvbjAxL0VNTDIwMDZUZW5uaXNvbjAxLmh0bWwKCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2Es IENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Sat May 24 09:12:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485343A6841; Sat, 24 May 2008 09:12:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A293A6949 for ; Sat, 24 May 2008 09:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.482 X-Spam-Level: X-Spam-Status: No, score=0.482 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jNECZHhYst8 for ; Sat, 24 May 2008 09:12:32 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id A5A483A69DE for ; Sat, 24 May 2008 09:12:30 -0700 (PDT) Received: (qmail 12949 invoked from network); 24 May 2008 16:12:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 24 May 2008 16:12:27 -0000 X-YMail-OSG: 8nF1EUcVM1kn14VtlWIEo1DzSIFVVsnhlEPwjnRLwAFGfd2H77z4gQpMmafQIYmCYFdWBwfO2I5GhDBMtMjNZbpH4XPeKRoLUyCI0MIGOuImr2lLBkmZOPtHUnmlyBkCeJCKyqp6mhMWlx8oR0f3u3r7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48383E6A.5010000@andybierman.com> Date: Sat, 24 May 2008 09:12:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <4836EC73.8030304@andybierman.com> <1211581067.8247.41.camel@missotis> <48376BDD.2060709@andybierman.com> <1211629884.16762.24.camel@missotis> In-Reply-To: <1211629884.16762.24.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] DSDL questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQw6EgMjMuIDA1 LiAyMDA4IHYgMTg6MTQgLTA3MDA6Cj4+IEkgdGhpbmsgYSBZQU5HIHRvIFJlbGF4TkcgbWFwcGlu ZyBtYWtlcyBwcmFjdGljYWwgc2Vuc2UsCj4+IHN0YW5kYXJkcyBzZW5zZSwgYW5kIHdlIGhhdmUg dGhlIHJlc291cmNlcyB0byBkbyBhIGNvbXBldGVudAo+PiBqb2Igb24gdGhlIG1hcHBpbmcgZG9j dW1lbnQuICBJTU8sIGFueSBtb3JlIHRoYW4gdGhhdCBpcyByZWFsbHkKPj4gZG91YnRmdWwuCj4g Cj4gUkVMQVggTkcgd2lsbCBjZXJ0YWlubHkgYmUgdGhlIG1vc3QgZnVuZGFtZW50YWwgcGFydCBp biBhbnkgY2FzZS4gSXQKPiB3aWxsIG1ha2Ugbm8gaGFybSB0aG91Z2ggdG8gZXhwcmVzcyBzb21l IGNvbnN0cmFpbnRzLCBlLmcuLCB0aG9zZQo+IHNwZWNpZmllZCBpbiAibXVzdCIgb3IgInVuaXF1 ZSIgc3RhdGVtZW50cywgd2l0aCBTY2hlbWF0cm9uIHJ1bGVzCj4gZW1iZWRkZWQgaW4gdGhlIFJF TEFYIE5HIHNjaGVtYSwgYW5kIO+7v21ldGFpbmZvcm1hdGlvbiBpbiBEdWJsaW4gQ29yZS4KPiBU aGlzIHdpbGwgYmUgYWxyZWFkeSBxdWl0ZSB1c2VmdWwuCj4gCj4gWW91IGFyZSByaWdodCB0aGF0 IHRoZSBvdGhlciBwYXJ0cyBvZiBEU0RMIGFyZSBzdGlsbAo+IHJlc2VhcmNoeS92YXBvcndhcmUu IEhvd2V2ZXIsIHNvbWUgb2YgdGhlc2UgY29uY2VwdHMgYXJlIElNTyBvZiBpbnRlcmVzdAo+IGV2 ZW4gZm9yIFlBTkcgaXRzZWxmLiBUaGlzIGlzIGVzcGVjaWFsbHkgdGhlIGNhc2Ugb2YgdGhlIERh dGF0eXBpbmcKPiBMaWJyYXJ5IExhbmd1YWdlLiBUaGlzIHBhcGVyIGJ5IEplbmkgVGVubmlzb24g Z2l2ZXMgYSBuaWNlIG92ZXJ2aWV3IG9mCj4gdGhlIHByb2JsZW1zIG9mIHRoZSBleGlzdGluZyBs aWJyYXJpZXMgZm9yIFhTRCwgUk5HLCBhbmQgWUFORyBhcyB3ZWxsOgo+IAo+IGh0dHA6Ly93d3cu aWRlYWxsaWFuY2Uub3JnL3BhcGVycy9leHRyZW1lL3Byb2NlZWRpbmdzL2h0bWwvMjAwNi9UZW5u aXNvbjAxL0VNTDIwMDZUZW5uaXNvbjAxLmh0bWwKPiAKClRoZSBjaGFydGVyIHNheXM6CgogICAg IEluIG9yZGVyIHRvIGxldmVyYWdlIGV4aXN0aW5nIFhNTCB0b29scwoKSXQgZG9lcyBub3Qgc2F5 OgoKICAgICBJbiBvcmRlciB0byBsZXZlcmFnZSBleGlzdGluZyBYTUwgcmVzZWFyY2gKCkkgdmll dyB0aGUgWFNEIG9yIFJORyB0eXBlIG9mIG1hcHBpbmcgYXMgdGhlIGh1bWFuLXRvLW1hY2hpbmUK dHJhbnNsYXRpb24sIG5lZWRlZCB0byBzdXBwb3J0IGV4aXN0aW5nIFhNTCB0b29scy4gIElNTywK WFNEIGlzIGdvb2QgZW5vdWdoLCBidXQgUk5HIGlzIGJldHRlciB0aGFuIFhTRCwgc28gaXQncyBo YXJkCnRvIGFyZ3VlIGFnYWluc3QgYSBZQU5HIHRvIFJORyBtYXBwaW5nLgoKV2l0aG91dCB0b29s cywgYW5kIHNvbWUgcmVhbCBleGFtcGxlcyBmcm9tIFhNTCBhcHBsaWNhdGlvbgpleHBlcnRzLCBJ IGRvbid0IHNlZSBob3cgdGhlIFdHIChhbmQgSUVURikgY2FuIG1ha2UgcHJhY3RpY2FsCnVzZSBv ZiB0aGUgRFNETCBmcmFtZXdvcmsuICBJIGhhdmUgY29uY2VybnMgYWJvdXQgYSByZXF1aXJlbWVu dAp0byBpbmNsdWRlIGNyeXB0aWMgc3ludGF4IGluIGV2ZXJ5IE5FVENPTkYgZGF0YSBtb2RlbCBS RkMsCndoaWNoIHJlbGllcyBvbiBvbmUgYWxwaGEtbGV2ZWwgdHJhbnNsYXRvciBpbXBsZW1lbnRh dGlvbgphbmQgb25lIGJldGEtbGV2ZWwgdmFsaWRhdG9yIGltcGxlbWVudGF0aW9uLiAgVGhhdCBt aWdodApiZSBmaW5lIGZvciByZXNlYXJjaCwgYnV0IG5vdCBmb3IgdGhlIElFVEYgc3RhbmRhcmRz IHRyYWNrLgoKCj4gTGFkYQo+IAoKQW5keQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon May 26 04:27:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C493A6B7A; Mon, 26 May 2008 04:27:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E2C3A6B7A for ; Mon, 26 May 2008 04:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avcWN4szIVih for ; Mon, 26 May 2008 04:27:20 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0FBF23A6B78 for ; Mon, 26 May 2008 04:27:20 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 0C83AD800BD; Mon, 26 May 2008 13:27:19 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48383E6A.5010000@andybierman.com> References: <4836EC73.8030304@andybierman.com> <1211581067.8247.41.camel@missotis> <48376BDD.2060709@andybierman.com> <1211629884.16762.24.camel@missotis> <48383E6A.5010000@andybierman.com> Organization: CESNET Date: Mon, 26 May 2008 13:27:18 +0200 Message-Id: <1211801239.6920.26.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: netmod@ietf.org Subject: Re: [netmod] DSDL questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFNvIDI0LiAwNS4gMjAwOCB2IDA5OjEyIC0wNzAwOgoKPiBU aGUgY2hhcnRlciBzYXlzOgo+IAo+ICAgICAgSW4gb3JkZXIgdG8gbGV2ZXJhZ2UgZXhpc3Rpbmcg WE1MIHRvb2xzCj4gCj4gSXQgZG9lcyBub3Qgc2F5Ogo+IAo+ICAgICAgSW4gb3JkZXIgdG8gbGV2 ZXJhZ2UgZXhpc3RpbmcgWE1MIHJlc2VhcmNoCj4gCgpSaWdodCwgYnV0IHRoZSBjaGFydGVyIGFs c28gc2F5czogIi4uLiwgdGhlIFdHIHdpbGwKZGVmaW5lIHN0YW5kYXJkIG1hcHBpbmcgcnVsZXMg ZnJvbSBZQU5HIHRvIHRoZSBEU0RMIGRhdGEgbW9kZWxpbmcKZnJhbWV3b3JrIChJU08vSUVDIDE5 NzU3KSB3aXRoIGFkZGl0aW9uYWwgYW5ub3RhdGlvbnMgdG8gcHJlc2VydmUKc2VtYW50aWNzLiIK ClNvIHRoZSBmaXJzdCBnb2FsIGlzIHRvIGNyZWF0ZSAxOjEgbWFwcGluZyBmcm9tIFlBTkcgdG8g UkVMQVggTkcgd2l0aAphbm5vdGF0aW9ucy4gVGhlc2UgYW5ub3RhdGlvbnMgbWF5IGJlIFNjaGVt YXRyb24sIGNvbXBhdGliaWxpdHkKYW5ub3RhdGlvbnMgZGVmaW5lZCBhcyBwYXJ0IG9mIFJFTEFY IE5HLCBvdGhlciBwYXJ0cyBvZiBEU0RMIG9yIG90aGVycwp0aGF0IHdlIHdpbGwgaGF2ZSB0byBp bnZlbnQuIEhvd2V2ZXIsIGZhY2VkIHdpdGggdGhlIGRpbGVtbWEgb2YgY2hvb3NpbmcKZWl0aGVy IHRoZSBEU0RMIGZvcm1hbGlzbSAoZXZlbiBpZiBubyB0b29scyBmb3IgaXQgZXhpc3QgeWV0KSBv cgppbnZlbnRpbmcgbmV3IGFubm90YXRpb25zLCBJIHdvdWxkIG1vc3RseSBwcmVmZXIgdGhlIGZv cm1lci4KClRoaXMgZnVsbCBzY2hlbWEgd2lsbCB0aGVuIHNlcnZlIGFzIGEgc291cmNlIGZvciB2 YXJpb3VzIHRyYW5zZm9ybWF0aW9ucwpwcm92aW5nIHJlbGF0ZWQgc2NoZW1hdGEgZm9yIGNvbmNy ZXRlIHRhc2tzIGxpa2UgdmFsaWRhdGlvbiBvZiBkYXRhCnN0b3JlcyBvciBORVRDT05GIFBEVXMg KHZpYSBYU0xUIGFuZCBvdGhlciBleGlzdGluZyBtZXRob2RzKS4gSXQgaXMgdGhpcwoiYXBwbGlj YXRpb24gcGFydCIgd2hlcmUgdGhlIGV4aXN0aW5nIFhNTCB0b29scyB3aWxsIGJlIGxldmVyYWdl ZC4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMw QwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9k IG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Sat May 31 09:22:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153783A6A52; Sat, 31 May 2008 09:22:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FF23A69F4 for ; Sat, 31 May 2008 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q0dW1Te5f1e for ; Sat, 31 May 2008 09:22:29 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id C925C3A6A70 for ; Sat, 31 May 2008 09:22:28 -0700 (PDT) Received: (qmail 13678 invoked from network); 31 May 2008 16:22:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 31 May 2008 16:22:26 -0000 X-YMail-OSG: n7zcNx8VM1l4Gj66xGN5.bY861CpEdtKL6KONR2k8EMYG4Z8PeP3ikoyJ0TlyyC6fFyMI9sQzarVJ8ZYLcAD9FfCpqwykVKjBqC46Xg9CyRUC0AxepRhWBn0rk.3klKCFZ4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48417B41.4030409@netconfcentral.com> Date: Sat, 31 May 2008 09:22:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] yang-00, ordered-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Another partially documented YANG feature is the 'ordered-by' statement. As with many other features, the draft needs to specify what happens outside the narrow scope of the intended usage (e.g., 'key' and 'insert' attributes are only discussed appearing in ). Does the operation need to support these in filters? (No.) These attributes need to be removed from the data model and turned into verbs, similar to the NETCONF 'operation' attribute. In non-YANG data models, 'key' and 'insert' would be part of the data being edited, not encoded verbs to change the operation. This should be documented. What does 'ordered-by user;' mean for read-only data or RPC input or notification content? Can the manager create user-ordered data unsorted, or is the PDU order always the sorted order for 'create'? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 31 16:42:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAF83A6A56; Sat, 31 May 2008 16:42:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040AB3A6AA1 for ; Sat, 31 May 2008 16:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L72NklBIT7+f for ; Sat, 31 May 2008 16:42:45 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 0F6473A6A56 for ; Sat, 31 May 2008 16:42:45 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Sat, 31 May 2008 16:42:40 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 May 2008 16:42:31 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m4VNgUx37428; Sat, 31 May 2008 16:42:30 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4VNeKRV051590; Sat, 31 May 2008 23:40:20 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805312340.m4VNeKRV051590@idle.juniper.net> To: Andy Bierman In-reply-to: <48417B41.4030409@netconfcentral.com> Date: Sat, 31 May 2008 19:40:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 31 May 2008 23:42:31.0519 (UTC) FILETIME=[FE4F3EF0:01C8C377] Cc: NETMOD Working Group Subject: Re: [netmod] yang-00, ordered-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Another partially documented YANG feature is the 'ordered-by' statement. >As with many other features, the draft needs to specify what happens >outside the narrow scope of the intended usage (e.g., 'key' and 'insert' >attributes are only discussed appearing in ). Are you saying just that we need to say "these attributes are only meaningful in the following contexts", or is something more needed? By saying what they mean in certain contexts, we didn't see a need to list all the contexts in which they were meaningless, nor did we say "these are illegal everywhere else" since that makes issues with future features that want to use them in other contexts. >Does the operation need to support these in filters? (No.) Are you wanting an exhaustive list of "thou shalt not"s? >These attributes need to be removed from the data model and >turned into verbs, similar to the NETCONF 'operation' attribute. "turned into verbs" like "insert"? Or you're saying you'd rather see "op='insert' insert='before' key='whatever'"? >In non-YANG data models, 'key' and 'insert' would be part >of the data being edited, not encoded verbs to change the > operation. This should be documented. YANG doesn't have much to say about non-YANG models. >What does 'ordered-by user;' mean for read-only data or >RPC input or notification content? Can the manager create user-ordered >data unsorted, or is the PDU order always the sorted order for 'create'? These are great questions and these are definitely the sorts of details we need to document in the YANG spec. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat May 31 16:53:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346453A67F4; Sat, 31 May 2008 16:53:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB0E3A6835 for ; Sat, 31 May 2008 16:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuC7EHeAc8tb for ; Sat, 31 May 2008 16:53:54 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 265013A67F4 for ; Sat, 31 May 2008 16:53:53 -0700 (PDT) Received: (qmail 97918 invoked from network); 31 May 2008 23:53:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 31 May 2008 23:53:52 -0000 X-YMail-OSG: BII4v6EVM1lp0QaMyACDpOsK8g_hXhHJo0JKQlT2Wn_bgMzexomm7RhQ19gMrKbJsW2CqvVWcSQM4fwBIEYnF50z_6ql0k5tUPHs08dAC5y5kI7jKojP0DtGPMxChxm2DaI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4841E50F.5070807@netconfcentral.com> Date: Sat, 31 May 2008 16:53:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805312340.m4VNeKRV051590@idle.juniper.net> In-Reply-To: <200805312340.m4VNeKRV051590@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] yang-00, ordered-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Another partially documented YANG feature is the 'ordered-by' statement. >> As with many other features, the draft needs to specify what happens >> outside the narrow scope of the intended usage (e.g., 'key' and 'insert' >> attributes are only discussed appearing in ). > > Are you saying just that we need to say "these attributes are only > meaningful in the following contexts", or is something more needed? That could work. I agree with you that we should not over-specify YANG. We need more reviews from non-authors to determine if all the text is clear enough to write code from. > By saying what they mean in certain contexts, we didn't see a need > to list all the contexts in which they were meaningless, nor did > we say "these are illegal everywhere else" since that makes issues > with future features that want to use them in other contexts. > >> Does the operation need to support these in filters? (No.) > > Are you wanting an exhaustive list of "thou shalt not"s? > No -- just point out the way it is supposed to work. Maybe an implementor will think (because RFC 4741 says so) that these XML attributes included in the content are actually part of the content. That would be wrong of course. The operation attribute and these new attributes do not get saved in the config database at all. IMO, that is not obvious. >> These attributes need to be removed from the data model and >> turned into verbs, similar to the NETCONF 'operation' attribute. > > "turned into verbs" like "insert"? Or you're saying you'd > rather see "op='insert' insert='before' key='whatever'"? > >> In non-YANG data models, 'key' and 'insert' would be part >> of the data being edited, not encoded verbs to change the >> operation. This should be documented. > > YANG doesn't have much to say about non-YANG models. > >> What does 'ordered-by user;' mean for read-only data or >> RPC input or notification content? Can the manager create user-ordered >> data unsorted, or is the PDU order always the sorted order for 'create'? > > These are great questions and these are definitely the sorts of > details we need to document in the YANG spec. > > Thanks, > Phil > > > Andy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod