From jernej.tuljak@mg-soft.si Wed Aug 1 00:22:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA89711E8087 for ; Wed, 1 Aug 2012 00:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74qma3GyVsOJ for ; Wed, 1 Aug 2012 00:22:11 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFFD11E80A2 for ; Wed, 1 Aug 2012 00:22:09 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q717M5hk014211; Wed, 1 Aug 2012 09:22:06 +0200 Message-ID: <5018D91A.20609@mg-soft.com> Date: Wed, 01 Aug 2012 09:22:02 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> In-Reply-To: <20120731.072142.385816835.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 07:22:11 -0000 Dne 31.7.2012 16:21, piše Martin Bjorklund: > Hi, > > Jernej Tuljak wrote: >> Dne 29.7.2012 1:34, piše Andy Bierman: >>> Hi, >>> >>> I am getting lots of XPath errors reported from yangdump: >>> >>> >>> >>> *** Generated by yangdump 5.0.da08cd7 >>> *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. >>> >>> Warning: no child nodes found in XPath expr '../type = read or ../type = write' >>> ietf-snmp-proxy.yang:114.24: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr '../type = read or ../type = write' >>> ietf-snmp-proxy.yang:114.42: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr '../type = trap or ../type = inform' >>> ietf-snmp-proxy.yang:123.24: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr '../type = trap or ../type = inform' >>> ietf-snmp-proxy.yang:123.42: warning(432): no child node available >>> >>> These errors in ietf-snmp-proxy.yang are because the strings need to >>> be quoted. When unquoted, they are XPath node names, not strings. >>> >>> e.g.: >>> >>> ../type = 'trap' or ../type = 'inform' >> I agree. These should be quoted. > Fixed. > >>> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or >>> snmp:params/snmp:v2c' >>> ietf-snmp-community.yang:196.12: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or >>> snmp:params/snmp:v2c' >>> ietf-snmp-community.yang:196.35: warning(432): no child node available >>> >>> >>> There is a missing '/' so XPath this is supposed to be a child node >>> >>> e.g. >>> /snmp:params/snmp:v1 >> No. There is no toplevel params node in this module. These should probably be >> "../snmp:v1 or ../snmp:v2c". They appear to be refering to nodes of >>> the params choice inside /snmp:snmp/snmp:target. > Yes. I fixed this by moving the when stmt up one level: > > augment /snmp:snmp/snmp:target { > when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; > leaf mms { > ... Hmm.. I don't think you can refer to snmp:params in an XPath expression. It's a YANG choice statement and will never exist in an instance document when the expression is evaluated. This will always result to "false". The context node of the above when statement is /snmp:snmp/snmp:target, which will either have snmp:v1 or snmp:v2c as a child element but no snmp:params. Unless I'm missing something. This is my first time seeing a conditional augment in action. Does this mean that such augmentations should be done dynamically based on the current instance document (from a YANG implementation's perspective)? This is bad. I've been under the impression that a YANG data model is "static" where the entire schema is known before hand, even conditional leaves and branches. But this means that the model may not be known until and actual instance is present - the schema may change under certain conditions. Or does a conditional augment mean that the augmentation will always be done but all of the augmented nodes "inherit" the augment's when conditions making all of them conditional? This would make much more sense to me. Would this be legal as a potential workaround to dynamically changing a module's schema? What was the group's intention regarding this matter? Jernej >>> Warning: no child nodes found in XPath expr >>> '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' >>> ietf-snmp-usm.yang:194.13: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr >>> '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' >>> ietf-snmp-usm.yang:194.29: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr >>> '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' >>> ietf-snmp-usm.yang:194.55: warning(432): no child node available >>> >>> >>> Not sure if the 3 errors above are yangdump problems or due to >>> restrictions on what can be >>> referenced within an augment-stmt. The XPath and combination of uses >>> and augments >>> is complicated to follow, so not sure if it is correct yet. >> I don't think these are errors. > Neither do I. > >>> Warning: no child nodes found in XPath expr '../map-type = snmp:specified' >>> ietf-snmp-tls.yang:174.30: warning(432): no child node available >>> >>> Not sure what snmp:specified is -- XPath thinks it is a node name because this >>> is an unquoted string. There is no child 'specified' under this leaf. >> snmp:specified appears to be an identity in ietf-snmp-tls (base >>> cert-to-tm-security-name). This should also be quoted, it's a >>> QName value. > Fixed. > > > > /martin From andy@yumaworks.com Wed Aug 1 00:54:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EB421F8634 for ; Wed, 1 Aug 2012 00:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13M1onfXEQFo for ; Wed, 1 Aug 2012 00:54:13 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7124421F8567 for ; Wed, 1 Aug 2012 00:54:13 -0700 (PDT) Received: by qaea16 with SMTP id a16so207369qae.10 for ; Wed, 01 Aug 2012 00:54:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=YqLIgUsy+4l/XJAbP17wtIDvQ2Hs+uQhOSXpzYPoxc4=; b=DrgguBtuMf7OwWvjpg1AnUh8SCxbLQJbsV2sUwoVRyDn+VAVjdUtwfmhY2YVek1Ayg CACobktmvb/UqNa8cX6CNq9N/MKAAG5dWkxAFapsDxaHtt1M3O/oCXW9l1bEuLTU6CnX vTFr8uz91HrZRexBFeGrmVfH933dh+VWlOZsoZ8XugnwEp3RyoV2PwFr9erzgKYY9k9U xyL/aXjUY5/hHPV2UVkpnrvVt5KWOdkBv932IxL0OqEGPKXb1lvrSs0Dc8xfTaHuvSUy qX6L1XE0fG1rPkeVaBsUHR31dAB//Xu7O6YTJmbzAjVI6lKd1Q7jBOR/gsr4woPcvthT b8sg== MIME-Version: 1.0 Received: by 10.224.35.130 with SMTP id p2mr34009432qad.21.1343807652609; Wed, 01 Aug 2012 00:54:12 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Wed, 1 Aug 2012 00:54:12 -0700 (PDT) X-Originating-IP: [130.129.65.206] In-Reply-To: <5018D91A.20609@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> Date: Wed, 1 Aug 2012 00:54:12 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm3e6XoZN8jkzuOMW0P3rg053tCDsgXtIQxDqU61IMti8ABgLW8tZhdXnV7r/etPKZzVYXM Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 07:54:14 -0000 On Wed, Aug 1, 2012 at 12:22 AM, Jernej Tuljak w= rote: > Dne 31.7.2012 16:21, pi=C5=A1e Martin Bjorklund: >> >> Hi, >> >> Jernej Tuljak wrote: >>> >>... >> augment /snmp:snmp/snmp:target { >> when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; >> leaf mms { >> ... > > > Hmm.. I don't think you can refer to snmp:params in an XPath expression. > It's a YANG choice statement and will never exist in an instance documen= t > when the expression is evaluated. This will always result to "false". The > context node of the above when statement is /snmp:snmp/snmp:target, which > will either have snmp:v1 or snmp:v2c as a child element but no snmp:param= s. > Unless I'm missing something. You are right. Good catch -- it isn't obvious but the syntax for the augment target path is not the same as an XPath expression. Choice and case nodes cannot ever appear in an XPath path-expr. These nodes do not exist in the data tree. The ABNF is clear: uses-augment-arg-str =3D < a string that matches the rule uses-augment-arg > uses-augment-arg =3D descendant-schema-nodeid augment-arg-str =3D < a string that matches the rule augment-arg > augment-arg =3D absolute-schema-nodeid when-stmt =3D when-keyword sep string optsep ... > > This is my first time seeing a conditional augment in action. Does this m= ean > that such augmentations should be done dynamically based on the current > instance document (from a YANG implementation's perspective)? This is bad= . > I've been under the impression that a YANG data model is "static" where t= he > entire schema is known before hand, even conditional leaves and branches. > But this means that the model may not be known until and actual instance = is > present - the schema may change under certain conditions. The complexity involved in implementing when-stmt in an automated fashion is probably an order of magnitude more complicated than any other YANG statement. There are many ways they can be inherited, and the context node is not always straight-forward. Sometimes the context node doesn't even exist, so evaluating the when-stmt actually requires that the data tree be modified in order to test it. Since no value is provided, the server needs to pick an arbitrary value, which is completely broken. This often needs to be done to decide whether a min-elements of mandatory-stmt is really true (because when=3Dfalse overrides mandatory=3Dtrue). Since when-stmts interact, they may need to be reevaluated (A depends on B, B depends on C, and C depends on A). Delete 1 and they maybe they all get deleted. The order the when-stmts are evaluated can change the result. > > Or does a conditional augment mean that the augmentation will always be d= one > but all of the augmented nodes "inherit" the augment's when conditions > making all of them conditional? This would make much more sense to me. Wo= uld > this be legal as a potential workaround to dynamically changing a module'= s > schema? What was the group's intention regarding this matter? > The schema is not static. When-stmt causes nodes to magically appear or disappear instantly --- it is applied right away, not at validation time= . The intent was to support conditional nodes. The result is complicated. Since features are not required to be static either, if-feature-stmt can also cause nodes to appear or disappear. > Jernej Andy From jernej.tuljak@mg-soft.si Wed Aug 1 01:47:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6361E21F8668 for ; Wed, 1 Aug 2012 01:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnYGvd6HKNDA for ; Wed, 1 Aug 2012 01:46:59 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6C62D21F8625 for ; Wed, 1 Aug 2012 01:46:58 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q718ktsd015264; Wed, 1 Aug 2012 10:46:56 +0200 Message-ID: <5018ECFC.8050508@mg-soft.com> Date: Wed, 01 Aug 2012 10:46:52 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:47:00 -0000 Dne 1.8.2012 9:54, piĆĄe Andy Bierman: > On Wed, Aug 1, 2012 at 12:22 AM, Jernej Tuljak wrote: >> Dne 31.7.2012 16:21, piĆĄe Martin Bjorklund: >>> Hi, >>> >>> Jernej Tuljak wrote: >>> ... >>> augment /snmp:snmp/snmp:target { >>> when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; >>> leaf mms { >>> ... >> >> Hmm.. I don't think you can refer to snmp:params in an XPath expression. >> It's a YANG choice statement and will never exist in an instance document >> when the expression is evaluated. This will always result to "false". The >> context node of the above when statement is /snmp:snmp/snmp:target, which >> will either have snmp:v1 or snmp:v2c as a child element but no snmp:params. >> Unless I'm missing something. > You are right. > Good catch -- it isn't obvious but the syntax for the augment target path > is not the same as an XPath expression. Choice and case nodes cannot > ever appear in an XPath path-expr. These nodes do not exist in the > data tree. > > The ABNF is clear: > > > uses-augment-arg-str =< a string that matches the rule > uses-augment-arg> > > uses-augment-arg = descendant-schema-nodeid > > > augment-arg-str =< a string that matches the rule > augment-arg> > > augment-arg = absolute-schema-nodeid > > > when-stmt = when-keyword sep string optsep ... > > >> This is my first time seeing a conditional augment in action. Does this mean >> that such augmentations should be done dynamically based on the current >> instance document (from a YANG implementation's perspective)? This is bad. >> I've been under the impression that a YANG data model is "static" where the >> entire schema is known before hand, even conditional leaves and branches. >> But this means that the model may not be known until and actual instance is >> present - the schema may change under certain conditions. > The complexity involved in implementing when-stmt in an automated fashion > is probably an order of magnitude more complicated than any other YANG > statement. There are many ways they can be inherited, and the context node > is not always straight-forward. Sometimes the context node doesn't > even exist, so evaluating the when-stmt actually requires that the > data tree be modified in order to test it. Since no value is provided, > the server needs to pick an arbitrary value, which is completely broken. > > This often needs to be done to decide whether a > min-elements of mandatory-stmt is really true (because when=false > overrides mandatory=true). Since when-stmts interact, they may need to > be reevaluated (A depends on B, B depends on C, and C depends on A). > Delete 1 and they maybe they all get deleted. The order the when-stmts > are evaluated can change the result. > >> Or does a conditional augment mean that the augmentation will always be done >> but all of the augmented nodes "inherit" the augment's when conditions >> making all of them conditional? This would make much more sense to me. Would >> this be legal as a potential workaround to dynamically changing a module's >> schema? What was the group's intention regarding this matter? >> > The schema is not static. When-stmt causes nodes to magically appear > or disappear instantly --- it is applied right away, not at validation time. > The intent was to support conditional nodes. The result is complicated. > > Since features are not required to be static either, if-feature-stmt can > also cause nodes to appear or disappear. I know about if-feature statements since I implemented them for our XML editor. Selecting a set of enabled features may truncate entire subtrees of the schema. But this is not the same as how I described conditional augmentation. For if-features the user decides before hand (before writing an instance document) what the schema should be. This is a one time only thing as features of a server do not change that often. When the user chooses another set of features, she is willingly changing the schema. But conditional augments may cue in at any time during the creation of an instance document, since it decides what the schema shall be. This is not what I expected. Am I the only one? I mean, this would probably lead to chicken or the egg dilemmas, would it not? These are also the only cases where schema nodes may appear and disappear at runtime that I know of as of today. In all other cases the schema is static. All the schema nodes are there, but there may be constraints specified on them which later constrain nodes in an instance document such as a datastore. I think you are mixing constraints for the schema and constrains for instance nodes. So I disagree that schema nodes may appear at disappear just like that. They should not. That's why when-stmt exists - so that data based on these schema nodes may be constrained without changing the schema itself (the structure of leafs, lists, etc.). What I'm trying to say is that when-stmts are part of a static schema. May I have an example of how when-stmt may magically remove/add schema nodes (which is not a conditional augment)? Jernej > >> Jernej > Andy From mbj@tail-f.com Wed Aug 1 06:36:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8823F11E80EE for ; Wed, 1 Aug 2012 06:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22wBT4sFgHbG for ; Wed, 1 Aug 2012 06:36:55 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 96BBF11E80D5 for ; Wed, 1 Aug 2012 06:36:55 -0700 (PDT) Received: from localhost (dhcp-410a.meeting.ietf.org [130.129.65.10]) by mail.tail-f.com (Postfix) with ESMTPSA id E26551200048; Wed, 1 Aug 2012 15:36:52 +0200 (CEST) Date: Wed, 01 Aug 2012 06:36:49 -0700 (PDT) Message-Id: <20120801.063649.317187839.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <5018D91A.20609@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:36:56 -0000 Jernej Tuljak wrote: > Dne 31.7.2012 16:21, pi=A8e Martin Bjorklund: > > Hi, > > > > Jernej Tuljak wrote: > >> Dne 29.7.2012 1:34, pi=A8e Andy Bierman: > >>> Hi, > >>> > >>> I am getting lots of XPath errors reported from yangdump: > >>> > >>> > >>> > >>> *** Generated by yangdump 5.0.da08cd7 > >>> *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. > >>> > >>> Warning: no child nodes found in XPath expr '../type =3D read or = ../type =3D > >>> write' > >>> ietf-snmp-proxy.yang:114.24: warning(432): no child node availabl= e > >>> > >>> Warning: no child nodes found in XPath expr '../type =3D read or = ../type =3D > >>> write' > >>> ietf-snmp-proxy.yang:114.42: warning(432): no child node availabl= e > >>> > >>> Warning: no child nodes found in XPath expr '../type =3D trap or = ../type =3D > >>> inform' > >>> ietf-snmp-proxy.yang:123.24: warning(432): no child node availabl= e > >>> > >>> Warning: no child nodes found in XPath expr '../type =3D trap or = ../type =3D > >>> inform' > >>> ietf-snmp-proxy.yang:123.42: warning(432): no child node availabl= e > >>> > >>> These errors in ietf-snmp-proxy.yang are because the strings need= to > >>> be quoted. When unquoted, they are XPath node names, not strings= .= > >>> > >>> e.g.: > >>> > >>> ../type =3D 'trap' or ../type =3D 'inform' > >> I agree. These should be quoted. > > Fixed. > > > >>> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 = or > >>> snmp:params/snmp:v2c' > >>> ietf-snmp-community.yang:196.12: warning(432): no child node avai= lable > >>> > >>> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 = or > >>> snmp:params/snmp:v2c' > >>> ietf-snmp-community.yang:196.35: warning(432): no child node avai= lable > >>> > >>> > >>> There is a missing '/' so XPath this is supposed to be a child no= de > >>> > >>> e.g. > >>> /snmp:params/snmp:v1 > >> No. There is no toplevel params node in this module. These should = probably > >> be > >> "../snmp:v1 or ../snmp:v2c". They appear to be refering to nodes o= f > >>> the params choice inside /snmp:snmp/snmp:target. > > Yes. I fixed this by moving the when stmt up one level: > > > > augment /snmp:snmp/snmp:target { > > when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; > > leaf mms { > > ... > = > Hmm.. I don't think you can refer to snmp:params in an XPath expressi= on. It's > a YANG choice statement and will never exist in an instance document = when the > expression is evaluated. This will always result to "false". The cont= ext node > of the above when statement is /snmp:snmp/snmp:target, which will eit= her have > snmp:v1 or snmp:v2c as a child element but no snmp:params. Unless I'm= missing > something. Right, this should be = augment /snmp:snmp/snmp:target { when "snmp:v1 or snmp:v2c"; Sorry about that. > This is my first time seeing a conditional augment in action. Does th= is mean > that such augmentations should be done dynamically based on the curre= nt > instance document (from a YANG implementation's perspective)? This is= > bad. I've been under the impression that a YANG data model is "static= " where > the entire schema is known before hand, even conditional leaves and > branches. But this means that the model may not be known until and ac= tual > instance is present - the schema may change under certain conditions.= > = > Or does a conditional augment mean that the augmentation will always = be done > but all of the augmented nodes "inherit" the augment's when condition= s making > all of them conditional? This would make much more sense to me. I am not sure I understand the distinction. Let's try an example: Given: container a { leaf b { ... } } Then augment a { when "b =3D 1"; leaf c { ... } } and augment a { leaf c { when "../b =3D 1"; ... } } produces the same end result. So I guess you can say that the when is inherited in the augment. /martin From andy@yumaworks.com Wed Aug 1 06:48:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE76811E813A for ; Wed, 1 Aug 2012 06:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1F9OmIW47pY for ; Wed, 1 Aug 2012 06:48:02 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF00811E8136 for ; Wed, 1 Aug 2012 06:48:01 -0700 (PDT) Received: by qcac10 with SMTP id c10so4901053qca.31 for ; Wed, 01 Aug 2012 06:48:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=u0ATl/CD2tslupGmIr0p7Ihw3lnLQJBIFmuDAvfCYTM=; b=E56OfYAgBC9KdBDYxRfOd1QFCSJscRgOuyA+kdcaPlQNkfTNh7Du83KTrJqw36JSO5 EKtPE2d5YxBYSo2CLSqY7map5H4M8n27pu1t/pFM4RKmdVsKKEdiZFIzdKHrZVauo9Vp xc+ylPaOc+fCJO+AQ2GfrXkpKS9RiHxVwwR0+Xo12zfu/5U8Y74mxLApnVbJZamcNtPr ruJIePIW+kJeQraSv3iIrXi86qmjaMM6Mwp5p1qalg9javNEm9aedCINU8Ei/3AFloQ6 NWb6XZhlLzI08Gq+9YSVCZnXq34BZQWF/q8xb7N0DJJuITXsQ2RcqsVf+egfR9klSaNt b5PQ== MIME-Version: 1.0 Received: by 10.224.180.146 with SMTP id bu18mr36209707qab.10.1343828881250; Wed, 01 Aug 2012 06:48:01 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Wed, 1 Aug 2012 06:48:01 -0700 (PDT) X-Originating-IP: [130.129.65.206] In-Reply-To: <5018ECFC.8050508@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <5018ECFC.8050508@mg-soft.com> Date: Wed, 1 Aug 2012 06:48:01 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmcMJemubOKus5XsCFs8q9ZiTXStJI+v7Nod7oA42Tv0Xw8oy8mF7vciuZ5X+QdAsVJ7Y86 Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:48:03 -0000 On Wed, Aug 1, 2012 at 1:46 AM, Jernej Tuljak wr= ote: > Dne 1.8.2012 9:54, pi=C5=A1e Andy Bierman: >> >> On Wed, Aug 1, 2012 at 12:22 AM, Jernej Tuljak >> wrote: >>> >>> Dne 31.7.2012 16:21, pi=C5=A1e Martin Bjorklund: >>>> >>>> Hi, >>>> >>>> Jernej Tuljak wrote: >>>> ... >>>> augment /snmp:snmp/snmp:target { >>>> when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; >>>> leaf mms { >>>> ... >>> >>> >>> Hmm.. I don't think you can refer to snmp:params in an XPath expression= . >>> It's a YANG choice statement and will never exist in an instance >>> document >>> when the expression is evaluated. This will always result to "false". T= he >>> context node of the above when statement is /snmp:snmp/snmp:target, whi= ch >>> will either have snmp:v1 or snmp:v2c as a child element but no >>> snmp:params. >>> Unless I'm missing something. >> >> You are right. >> Good catch -- it isn't obvious but the syntax for the augment target pat= h >> is not the same as an XPath expression. Choice and case nodes cannot >> ever appear in an XPath path-expr. These nodes do not exist in the >> data tree. >> >> The ABNF is clear: >> >> >> uses-augment-arg-str =3D< a string that matches the rule >> uses-augment-arg> >> >> uses-augment-arg =3D descendant-schema-nodeid >> >> >> augment-arg-str =3D< a string that matches the rule >> augment-arg> >> >> augment-arg =3D absolute-schema-nodeid >> >> >> when-stmt =3D when-keyword sep string optsep ... >> >> >>> This is my first time seeing a conditional augment in action. Does this >>> mean >>> that such augmentations should be done dynamically based on the current >>> instance document (from a YANG implementation's perspective)? This is >>> bad. >>> I've been under the impression that a YANG data model is "static" where >>> the >>> entire schema is known before hand, even conditional leaves and branche= s. >>> But this means that the model may not be known until and actual instanc= e >>> is >>> present - the schema may change under certain conditions. >> >> The complexity involved in implementing when-stmt in an automated fashio= n >> is probably an order of magnitude more complicated than any other YANG >> statement. There are many ways they can be inherited, and the context >> node >> is not always straight-forward. Sometimes the context node doesn't >> even exist, so evaluating the when-stmt actually requires that the >> data tree be modified in order to test it. Since no value is provided, >> the server needs to pick an arbitrary value, which is completely broken. >> >> This often needs to be done to decide whether a >> min-elements of mandatory-stmt is really true (because when=3Dfalse >> overrides mandatory=3Dtrue). Since when-stmts interact, they may need t= o >> be reevaluated (A depends on B, B depends on C, and C depends on A). >> Delete 1 and they maybe they all get deleted. The order the when-stmts >> are evaluated can change the result. >> >>> Or does a conditional augment mean that the augmentation will always be >>> done >>> but all of the augmented nodes "inherit" the augment's when conditions >>> making all of them conditional? This would make much more sense to me. >>> Would >>> this be legal as a potential workaround to dynamically changing a >>> module's >>> schema? What was the group's intention regarding this matter? >>> >> The schema is not static. When-stmt causes nodes to magically appear >> or disappear instantly --- it is applied right away, not at validation >> time. >> The intent was to support conditional nodes. The result is complicated. >> >> Since features are not required to be static either, if-feature-stmt can >> also cause nodes to appear or disappear. > > > I know about if-feature statements since I implemented them for our XML > editor. Selecting a set of enabled features may truncate entire subtrees = of > the schema. But this is not the same as how I described conditional > augmentation. For if-features the user decides before hand (before writin= g > an instance document) what the schema should be. This is a one time only > thing as features of a server do not change that often. When the user > chooses another set of features, she is willingly changing the schema. Bu= t > conditional augments may cue in at any time during the creation of an > instance document, since it decides what the schema shall be. This is not > what I expected. Am I the only one? I mean, this would probably lead to > chicken or the egg dilemmas, would it not? > > These are also the only cases where schema nodes may appear and disappear= at > runtime that I know of as of today. In all other cases the schema is stat= ic. > All the schema nodes are there, but there may be constraints specified on > them which later constrain nodes in an instance document such as a > datastore. I think you are mixing constraints for the schema and constrai= ns > for instance nodes. > > So I disagree that schema nodes may appear at disappear just like that. T= hey > should not. That's why when-stmt exists - so that data based on these sch= ema > nodes may be constrained without changing the schema itself (the structur= e > of leafs, lists, etc.). What I'm trying to say is that when-stmts are par= t > of a static schema. Features do not change that often but they can change, so if you write code that assumes they do not change, it can easily beak. When the schema node disappears, so do all the instance nodes. > > May I have an example of how when-stmt may magically remove/add schema no= des > (which is not a conditional augment)? look at the ABNF. When-stmt is allowed in uses-stmt, choice-stmt, case-stmt, etc. choice foo { when "blah"; case A { when "blah-blah"; uses bar { when "blah-blah-blah"; augment bar1/bar2 { when "etc."; leaf X { when "/on and /on"; type string; } } } } } > > Jernej > >> >>> Jernej >> >> Andy > > Andy From jernej.tuljak@mg-soft.si Wed Aug 1 06:50:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497E321F8D54 for ; Wed, 1 Aug 2012 06:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3hDzTtNa7H3 for ; Wed, 1 Aug 2012 06:50:24 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id DD9F321F866C for ; Wed, 1 Aug 2012 06:49:59 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q71DnvQf018462; Wed, 1 Aug 2012 15:49:57 +0200 Message-ID: <50193401.9080506@mg-soft.com> Date: Wed, 01 Aug 2012 15:49:53 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <20120801.063649.317187839.mbj@tail-f.com> In-Reply-To: <20120801.063649.317187839.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:50:27 -0000 Dne 1.8.2012 15:36, piše Martin Bjorklund: > Jernej Tuljak wrote: >> Dne 31.7.2012 16:21, piše Martin Bjorklund: >>> Hi, >>> >>> Jernej Tuljak wrote: >>>> Dne 29.7.2012 1:34, piše Andy Bierman: >>>>> Hi, >>>>> >>>>> I am getting lots of XPath errors reported from yangdump: >>>>> >>>>> >>>>> >>>>> *** Generated by yangdump 5.0.da08cd7 >>>>> *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. >>>>> >>>>> Warning: no child nodes found in XPath expr '../type = read or ../type = >>>>> write' >>>>> ietf-snmp-proxy.yang:114.24: warning(432): no child node available >>>>> >>>>> Warning: no child nodes found in XPath expr '../type = read or ../type = >>>>> write' >>>>> ietf-snmp-proxy.yang:114.42: warning(432): no child node available >>>>> >>>>> Warning: no child nodes found in XPath expr '../type = trap or ../type = >>>>> inform' >>>>> ietf-snmp-proxy.yang:123.24: warning(432): no child node available >>>>> >>>>> Warning: no child nodes found in XPath expr '../type = trap or ../type = >>>>> inform' >>>>> ietf-snmp-proxy.yang:123.42: warning(432): no child node available >>>>> >>>>> These errors in ietf-snmp-proxy.yang are because the strings need to >>>>> be quoted. When unquoted, they are XPath node names, not strings. >>>>> >>>>> e.g.: >>>>> >>>>> ../type = 'trap' or ../type = 'inform' >>>> I agree. These should be quoted. >>> Fixed. >>> >>>>> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or >>>>> snmp:params/snmp:v2c' >>>>> ietf-snmp-community.yang:196.12: warning(432): no child node available >>>>> >>>>> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or >>>>> snmp:params/snmp:v2c' >>>>> ietf-snmp-community.yang:196.35: warning(432): no child node available >>>>> >>>>> >>>>> There is a missing '/' so XPath this is supposed to be a child node >>>>> >>>>> e.g. >>>>> /snmp:params/snmp:v1 >>>> No. There is no toplevel params node in this module. These should probably >>>> be >>>> "../snmp:v1 or ../snmp:v2c". They appear to be refering to nodes of >>>>> the params choice inside /snmp:snmp/snmp:target. >>> Yes. I fixed this by moving the when stmt up one level: >>> >>> augment /snmp:snmp/snmp:target { >>> when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; >>> leaf mms { >>> ... >> Hmm.. I don't think you can refer to snmp:params in an XPath expression. It's >> a YANG choice statement and will never exist in an instance document when the >> expression is evaluated. This will always result to "false". The context node >> of the above when statement is /snmp:snmp/snmp:target, which will either have >> snmp:v1 or snmp:v2c as a child element but no snmp:params. Unless I'm missing >> something. > Right, this should be > > augment /snmp:snmp/snmp:target { > when "snmp:v1 or snmp:v2c"; > > Sorry about that. > >> This is my first time seeing a conditional augment in action. Does this mean >> that such augmentations should be done dynamically based on the current >> instance document (from a YANG implementation's perspective)? This is >> bad. I've been under the impression that a YANG data model is "static" where >> the entire schema is known before hand, even conditional leaves and >> branches. But this means that the model may not be known until and actual >> instance is present - the schema may change under certain conditions. >> >> Or does a conditional augment mean that the augmentation will always be done >> but all of the augmented nodes "inherit" the augment's when conditions making >> all of them conditional? This would make much more sense to me. > I am not sure I understand the distinction. Let's try an example: > > Given: > > container a { > leaf b { ... } > } > > Then > > augment a { > when "b = 1"; > leaf c { > ... > } > } > > and > > augment a { > leaf c { > when "../b = 1"; > ... > } > } > > produces the same end result. So I guess you can say that the when is > inherited in the augment. Thank you. That's exactly what I wanted to hear. This makes conditional augments non-dynamic and the entire schema known before hand. Simply put, the part of schema nodes under your augment will always be augmented to the target, but will only make sense if there's a b leaf with a value of 1. That doesn't mean that this part of the schema does not exist. Jernej > > /martin From mbj@tail-f.com Wed Aug 1 15:02:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB6411E8334 for ; Wed, 1 Aug 2012 15:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyIYFTV0yfIh for ; Wed, 1 Aug 2012 15:02:16 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A501D11E8195 for ; Wed, 1 Aug 2012 15:02:16 -0700 (PDT) Received: from localhost (dhcp-133c.meeting.ietf.org [130.129.19.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 885A61200D65; Thu, 2 Aug 2012 00:02:14 +0200 (CEST) Date: Wed, 01 Aug 2012 15:02:07 -0700 (PDT) Message-Id: <20120801.150207.342849426.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:02:18 -0000 Hi Jeff, "Lange, Jeffrey K (GE Energy)" wrote: > Looking over the most recent version of the system-mgmt model I was wondering > if it would make sense to pull the configuration-source identity definition > out into a more generic model? This was discussed in the NETMOD session yesterday, and the general feeling was that this should indeed be done. So we propose to add a new module ietf-config-source.yang to draft-ietf-netmod-system-mgmt, with the following content: identity config-source { description "Base for all configuration sources."; } identity local-config { base config-source; description "Local configuration source."; } grouping config-source { leaf-list config-source { type identityref { base config-source; } ordered-by user; description "Indicates the ordered list of configuration source(s) that the server should use for the service."; } } The ietf-system module will then import this module. Note also the the dhcp config source is gone. This was also discussed in the session, and it was suggested that we do a new document with a new (minimal) dhcp client module. This new module will define the "dhcp-config" identity. /martin From mbj@tail-f.com Wed Aug 1 15:46:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA3521F88EA for ; Wed, 1 Aug 2012 15:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugCgGWbAKYmC for ; Wed, 1 Aug 2012 15:46:41 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 765C921F87E2 for ; Wed, 1 Aug 2012 15:46:41 -0700 (PDT) Received: from localhost (dhcp-133c.meeting.ietf.org [130.129.19.60]) by mail.tail-f.com (Postfix) with ESMTPSA id A8A141200048 for ; Thu, 2 Aug 2012 00:46:39 +0200 (CEST) Date: Wed, 01 Aug 2012 15:46:36 -0700 (PDT) Message-Id: <20120801.154636.148603434.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20120731.090257.513496394.mbj@tail-f.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:46:42 -0000 Hi, It seems people want to add the config false "if stack" objects proposed below: Martin Bjorklund wrote: > leaf-list subordinate-if { ... } > leaf-list superior-if { ... } If we add this, I suggest we also add a leaf if-oper-status, with the same syntax and semantics as ifOperStatus, so that clients doesn't have to rely on the MIB data for this rather important object. /martin From chelliot@gmail.com Wed Aug 1 16:31:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8F11E83E6 for ; Wed, 1 Aug 2012 16:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibOwL22FEYi4 for ; Wed, 1 Aug 2012 16:31:10 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE2E11E839E for ; Wed, 1 Aug 2012 16:31:10 -0700 (PDT) Received: by weyu54 with SMTP id u54so6168074wey.31 for ; Wed, 01 Aug 2012 16:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=L4l6m/cpJZSQ0wCjoLVrHsl2qFE82L/CTEvu0+Ulj5o=; b=ajRWMP5If9AZ+KkEngIo8l2Sxwrsw+ibns1L01YvMJMFtQDIASg33gjsN04lrxSaAj 5S4RmaXtXHatJe4Wx5+t8crzIXea0chuLL8frRdgQr2JYf+Il+EmsXEhJYpKq7eOxdZG eK+/0AxmxO3Byzpl9S8yq25s4oCWxDay4NBygTMIIUSn/sBA+RhOXe5ZdsSOj+Ccdp9U 1+1DWzkcaW+gaWcfh4RAnYAa8Ck83MEGlZe0ruvFYg9g/xr2igzjA9vYYb0IHLpFnGQQ xvRo6ygSOgATI+8DJkgXKT3JjqVaYJGFeRoK/RRt9ZJGxL9e2gPZcjOYPWcpOHmRbitH k72w== Received: by 10.216.133.130 with SMTP id q2mr9997851wei.131.1343863869293; Wed, 01 Aug 2012 16:31:09 -0700 (PDT) MIME-Version: 1.0 Sender: chelliot@gmail.com Received: by 10.194.37.197 with HTTP; Wed, 1 Aug 2012 16:30:49 -0700 (PDT) In-Reply-To: <20120801.154636.148603434.mbj@tail-f.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> From: Chris Elliott Date: Wed, 1 Aug 2012 16:30:49 -0700 X-Google-Sender-Auth: YebAgZxE7I8sbDS9_-VvfOsQkSM Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=0016e6de150a8e453004c63cb055 Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chelliot@pobox.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:31:12 -0000 --0016e6de150a8e453004c63cb055 Content-Type: text/plain; charset=ISO-8859-1 +1 On Wed, Aug 1, 2012 at 3:46 PM, Martin Bjorklund wrote: > Hi, > > It seems people want to add the config false "if stack" objects > proposed below: > > Martin Bjorklund wrote: > > leaf-list subordinate-if { ... } > > leaf-list superior-if { ... } > > If we add this, I suggest we also add a leaf if-oper-status, with > the same syntax and semantics as ifOperStatus, so that clients doesn't > have to rely on the MIB data for this rather important object. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Chris Elliott chelliot@pobox.com --0016e6de150a8e453004c63cb055 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Wed, Aug 1, 2012 at 3:46 PM, Martin= Bjorklund <mbj@tail-f.com> wrote:
Hi,

It seems people want to add the config false "if stack" objects proposed below:

Martin Bjorklund <mbj@tail-f.com&g= t; wrote:
> =A0 =A0 leaf-list subordinate-if { ... }
> =A0 =A0 leaf-list superior-if { ... }

If we add this, I suggest we also add a leaf if-oper-status, with
the same syntax and semantics as ifOperStatus, so that clients doesn't<= br> have to rely on the MIB data for this rather important object.


/martin

_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod



--
= Chris Elliott
chelliot@pobox.com

--0016e6de150a8e453004c63cb055-- From lhotka@nic.cz Wed Aug 1 18:31:45 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CBE11E8152 for ; Wed, 1 Aug 2012 18:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6u7YvSrSE-q for ; Wed, 1 Aug 2012 18:31:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E911E8128 for ; Wed, 1 Aug 2012 18:31:43 -0700 (PDT) Received: from [IPv6:2001:df8::64:a01c:9552:9e19:1bc9] (unknown [IPv6:2001:df8:0:64:a01c:9552:9e19:1bc9]) by mail.nic.cz (Postfix) with ESMTPSA id DD76C13FD88; Thu, 2 Aug 2012 03:31:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343871100; bh=dLqf1DCTSeN/Ljd8F2MVvY9NQrEl8enufKPs4HaXz5w=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=i9T1fSNSXfCc4sjgOrBv04/eGfqD+qbNQwBMjbZ6IDki1loxnQLljUZ6FyYNbusns HfpJLWVm3wxLZX00rgSD5vmdwuIS7fJeh0Q2ap1k7KC4toKgZfv+OcDL+YAiyBAm2B RpzKT08hbdu8zBDlWHTcvWsTzwRp0C3QCkPSTxSE= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <5018D91A.20609@mg-soft.com> Date: Wed, 1 Aug 2012 18:31:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:31:45 -0000 On Aug 1, 2012, at 12:22 AM, Jernej Tuljak wrote: > This is my first time seeing a conditional augment in action. Does = this mean that such augmentations should be done dynamically based on = the current instance document (from a YANG implementation's = perspective)? This is bad. I've been under the impression that a YANG = data model is "static" where the entire schema is known before hand, = even conditional leaves and branches. But this means that the model may = not be known until and actual instance is present - the schema may = change under certain conditions. I argued several times exactly as you do, see for example this thread: http://www.ietf.org/mail-archive/web/netmod/current/msg04686.html But I was a lonely voice in a desert. So now we are two, good. Lada >=20 > Or does a conditional augment mean that the augmentation will always = be done but all of the augmented nodes "inherit" the augment's when = conditions making all of them conditional? This would make much more = sense to me. Would this be legal as a potential workaround to = dynamically changing a module's schema? What was the group's intention = regarding this matter? -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Aug 1 18:47:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1E21F892C for ; Wed, 1 Aug 2012 18:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDbvlj2VT0DC for ; Wed, 1 Aug 2012 18:47:19 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D219E21F8938 for ; Wed, 1 Aug 2012 18:47:18 -0700 (PDT) Received: by qcac10 with SMTP id c10so5440164qca.31 for ; Wed, 01 Aug 2012 18:47:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=cj3msISpNvZfPpWlYdbNzoyF3i0tofozS89NgLKDQe8=; b=df7268eG5iqtXnGsayg9a0adGf8kRwfbPimNFCELlqvBd8WUOK2MqfvM4PQV2T0n26 +QmqL8T49HShfCN9avTs1VAMswE6lQgftKyKRHDxQhjgd9g5UgZgRZ6d3kn5RdaCr8sk RRzFXjLyA/iIGvRhJ9K3yb4MckFmxiZxafjp1NaiK3UPcPcJnmwRwJ4A+YYknv3Y3vFj ar0XfGNL5XOjy7xg22JrHaM8XPIOV0FwH5omTJ6m+wWzmZSLI1b3RqVA+B9s69fT8Dv4 2lvS9PFwD8nLP3nP6rAUyYb/CkOeWg9fYisD61vOnZ8nFQQTmGGUZFCxIez1BvBoQcpK GGdw== MIME-Version: 1.0 Received: by 10.229.102.155 with SMTP id g27mr10347994qco.109.1343872038319; Wed, 01 Aug 2012 18:47:18 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Wed, 1 Aug 2012 18:47:18 -0700 (PDT) X-Originating-IP: [130.129.65.206] In-Reply-To: <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> Date: Wed, 1 Aug 2012 18:47:18 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlza5U7lXTBtVrEf6txpnXsj+n7BcrhUEd0a6CEoMuTzO4zo+5Tuhdzu73jKfUQZOjQ4wxi Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:47:19 -0000 On Wed, Aug 1, 2012 at 6:31 PM, Ladislav Lhotka wrote: > > On Aug 1, 2012, at 12:22 AM, Jernej Tuljak wrote: > >> This is my first time seeing a conditional augment in action. Does this = mean that such augmentations should be done dynamically based on the curren= t instance document (from a YANG implementation's perspective)? This is bad= . I've been under the impression that a YANG data model is "static" where t= he entire schema is known before hand, even conditional leaves and branches= . But this means that the model may not be known until and actual instance = is present - the schema may change under certain conditions. > > I argued several times exactly as you do, see for example this thread: > > http://www.ietf.org/mail-archive/web/netmod/current/msg04686.html > > But I was a lonely voice in a desert. So now we are two, good. I think Jernej was right when he wrote that the schema is always static, but the instance document determines if values are allowed or not. Both uses-stmt and augment-stmt behave this way (if when-stmt used in them)= . It is not easy to implement. But I can see how this is problematic. Good thing we overloaded the unknown-element error-tag ;-) It is used for unknown and unexpected elements. If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse we would have= to decide if that node is unknown by the server, vs. an instance of that node is unexpected for the request. > > Lada > Andy >> >> Or does a conditional augment mean that the augmentation will always be = done but all of the augmented nodes "inherit" the augment's when conditions= making all of them conditional? This would make much more sense to me. Wou= ld this be legal as a potential workaround to dynamically changing a module= 's schema? What was the group's intention regarding this matter? > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Wed Aug 1 19:05:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1791B11E818C for ; Wed, 1 Aug 2012 19:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgVU+mBZq1go for ; Wed, 1 Aug 2012 19:05:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CF17E11E811D for ; Wed, 1 Aug 2012 19:05:52 -0700 (PDT) Received: from [IPv6:2001:df8::64:a01c:9552:9e19:1bc9] (unknown [IPv6:2001:df8:0:64:a01c:9552:9e19:1bc9]) by mail.nic.cz (Postfix) with ESMTPSA id 6E24113FD88; Thu, 2 Aug 2012 04:05:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343873145; bh=e9zb+BZr2eywG7fUHHtncVesmLSLY2xWOJRbkV9QmDw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AknG+YRiM0pcLYreiRTTA4vJizcCWX5M0Ercr2PgyEsHALqbSIRTwokPP3SeGuvuN XgJ1bVBIJRyoHGAbsN6vPZgkBODWoGI+LopyAmanHxjXeuEXGe/mjaTJ8sH+q8wSXo EC9QGFKyAw8NaoRA+zvBjA9+Dt/emZ2g9TkgliW8= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: Date: Wed, 1 Aug 2012 19:05:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 02:05:56 -0000 On Aug 1, 2012, at 6:47 PM, Andy Bierman wrote: > On Wed, Aug 1, 2012 at 6:31 PM, Ladislav Lhotka wrote: >>=20 >> On Aug 1, 2012, at 12:22 AM, Jernej Tuljak wrote: >>=20 >>> This is my first time seeing a conditional augment in action. Does = this mean that such augmentations should be done dynamically based on = the current instance document (from a YANG implementation's = perspective)? This is bad. I've been under the impression that a YANG = data model is "static" where the entire schema is known before hand, = even conditional leaves and branches. But this means that the model may = not be known until and actual instance is present - the schema may = change under certain conditions. >>=20 >> I argued several times exactly as you do, see for example this = thread: >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg04686.html >>=20 >> But I was a lonely voice in a desert. So now we are two, good. >=20 > I think Jernej was right when he wrote that the schema is always = static, > but the instance document determines if values are allowed or not. > Both uses-stmt and augment-stmt behave this way (if when-stmt used in = them). > It is not easy to implement. If the schema were static, then leaf foo { mandatory true; when X; =85 } would lead to an error if "foo" is not present (provided its parent is), = no matter what the value of X. Actually, DSDL validation would signal this error because it is done in = two steps: schema validation (RELAX NG) and semantic validation = (Schematron). But I don't think there is agreement that this is the correct = interpretation. Lada >=20 > But I can see how this is problematic. > Good thing we overloaded the unknown-element error-tag ;-) > It is used for unknown and unexpected elements. > If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse we would = have to > decide if that node is unknown by the server, vs. an instance > of that node is unexpected for the request. >=20 >=20 >=20 >>=20 >> Lada >>=20 >=20 > Andy >=20 >=20 >>>=20 >>> Or does a conditional augment mean that the augmentation will always = be done but all of the augmented nodes "inherit" the augment's when = conditions making all of them conditional? This would make much more = sense to me. Would this be legal as a potential workaround to = dynamically changing a module's schema? What was the group's intention = regarding this matter? >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Wed Aug 1 23:53:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F9B11E812A for ; Wed, 1 Aug 2012 23:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLi7LWqtIM8K for ; Wed, 1 Aug 2012 23:53:11 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8298E11E80E1 for ; Wed, 1 Aug 2012 23:53:10 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q726r7lJ026444; Thu, 2 Aug 2012 08:53:08 +0200 Message-ID: <501A23CE.8020504@mg-soft.com> Date: Thu, 02 Aug 2012 08:53:02 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 06:53:12 -0000 Dne 2.8.2012 4:05, piše Ladislav Lhotka: > On Aug 1, 2012, at 6:47 PM, Andy Bierman wrote: > >> On Wed, Aug 1, 2012 at 6:31 PM, Ladislav Lhotka wrote: >>> On Aug 1, 2012, at 12:22 AM, Jernej Tuljak wrote: >>> >>>> This is my first time seeing a conditional augment in action. Does this mean that such augmentations should be done dynamically based on the current instance document (from a YANG implementation's perspective)? This is bad. I've been under the impression that a YANG data model is "static" where the entire schema is known before hand, even conditional leaves and branches. But this means that the model may not be known until and actual instance is present - the schema may change under certain conditions. >>> I argued several times exactly as you do, see for example this thread: >>> >>> http://www.ietf.org/mail-archive/web/netmod/current/msg04686.html >>> >>> But I was a lonely voice in a desert. So now we are two, good. >> I think Jernej was right when he wrote that the schema is always static, >> but the instance document determines if values are allowed or not. >> Both uses-stmt and augment-stmt behave this way (if when-stmt used in them). >> It is not easy to implement. > If the schema were static, then > > leaf foo { > mandatory true; > when X; > … > } > > would lead to an error if "foo" is not present (provided its parent is), no matter what the value of X. > > Actually, DSDL validation would signal this error because it is done in two steps: schema validation (RELAX NG) and semantic validation (Schematron). > > But I don't think there is agreement that this is the correct interpretation. This is a bug actually. RFC6020 (8.2) is quite clear on this. Mandatory-stmt conditon will only be enforced if when-stmt condition evaluates to false. Perhaps such problems should be delegated only to Schematron. That is by always making foo rng:optional, and transforming mandatory-stmt into an XPath expression and moving it together with when condition so they must be satisfied on foo's parent (parent becomes the context node): when foo-parent is present in the instance document -> when X condition for foo is false AND foo does not exist then error for missing mandatory foo -> when X condition for foo is false AND foo exists then error for unsatisfied constraint on foo It doesn't matter how the error is generated. But it should be properly generated. Jernej > Lada > >> But I can see how this is problematic. >> Good thing we overloaded the unknown-element error-tag ;-) >> It is used for unknown and unexpected elements. >> If /foo/bar only exists if when=true, then for when=false we would have to >> decide if that node is unknown by the server, vs. an instance >> of that node is unexpected for the request. >> >> >> >>> Lada >>> >> Andy >> >> >>>> Or does a conditional augment mean that the augmentation will always be done but all of the augmented nodes "inherit" the augment's when conditions making all of them conditional? This would make much more sense to me. Would this be legal as a potential workaround to dynamically changing a module's schema? What was the group's intention regarding this matter? >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From jernej.tuljak@mg-soft.si Thu Aug 2 00:00:20 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E6F21F8BEB for ; Thu, 2 Aug 2012 00:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvV2CUnBTEJl for ; Thu, 2 Aug 2012 00:00:18 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 46E0021F8BEC for ; Thu, 2 Aug 2012 00:00:11 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q72709DC026490; Thu, 2 Aug 2012 09:00:10 +0200 Message-ID: <501A2574.4030003@mg-soft.com> Date: Thu, 02 Aug 2012 09:00:04 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jernej Tuljak References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> In-Reply-To: <501A23CE.8020504@mg-soft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:00:20 -0000 Dne 2.8.2012 8:53, piše Jernej Tuljak: > Dne 2.8.2012 4:05, piše Ladislav Lhotka: >> On Aug 1, 2012, at 6:47 PM, Andy Bierman wrote: >> >>> On Wed, Aug 1, 2012 at 6:31 PM, Ladislav Lhotka wrote: >>>> On Aug 1, 2012, at 12:22 AM, Jernej Tuljak wrote: >>>> >>>>> This is my first time seeing a conditional augment in action. Does >>>>> this mean that such augmentations should be done dynamically based >>>>> on the current instance document (from a YANG implementation's >>>>> perspective)? This is bad. I've been under the impression that a >>>>> YANG data model is "static" where the entire schema is known >>>>> before hand, even conditional leaves and branches. But this means >>>>> that the model may not be known until and actual instance is >>>>> present - the schema may change under certain conditions. >>>> I argued several times exactly as you do, see for example this thread: >>>> >>>> http://www.ietf.org/mail-archive/web/netmod/current/msg04686.html >>>> >>>> But I was a lonely voice in a desert. So now we are two, good. >>> I think Jernej was right when he wrote that the schema is always >>> static, >>> but the instance document determines if values are allowed or not. >>> Both uses-stmt and augment-stmt behave this way (if when-stmt used >>> in them). >>> It is not easy to implement. >> If the schema were static, then >> >> leaf foo { >> mandatory true; >> when X; >> … >> } >> >> would lead to an error if "foo" is not present (provided its parent >> is), no matter what the value of X. >> >> Actually, DSDL validation would signal this error because it is done >> in two steps: schema validation (RELAX NG) and semantic validation >> (Schematron). >> >> But I don't think there is agreement that this is the correct >> interpretation. > > This is a bug actually. RFC6020 (8.2) is quite clear on this. > Mandatory-stmt conditon will only be enforced if when-stmt condition > evaluates to false. Perhaps such problems should be delegated only to > Schematron. That is by always making foo rng:optional, and > transforming mandatory-stmt into an XPath expression and moving it > together with when condition so they must be satisfied on foo's parent > (parent becomes the context node): No. I misread RFC6020. This would stand if the when was defined for parent-foo. Hierarchy of constraints for Ladislav's example appears to be undefined. Jernej > > when foo-parent is present in the instance document > -> when X condition for foo is false AND foo does not exist then error > for missing mandatory foo > -> when X condition for foo is false AND foo exists then error for > unsatisfied constraint on foo > > It doesn't matter how the error is generated. But it should be > properly generated. > > Jernej > >> Lada >> >>> But I can see how this is problematic. >>> Good thing we overloaded the unknown-element error-tag ;-) >>> It is used for unknown and unexpected elements. >>> If /foo/bar only exists if when=true, then for when=false we would >>> have to >>> decide if that node is unknown by the server, vs. an instance >>> of that node is unexpected for the request. >>> >>> >>> >>>> Lada >>>> >>> Andy >>> >>> >>>>> Or does a conditional augment mean that the augmentation will >>>>> always be done but all of the augmented nodes "inherit" the >>>>> augment's when conditions making all of them conditional? This >>>>> would make much more sense to me. Would this be legal as a >>>>> potential workaround to dynamically changing a module's schema? >>>>> What was the group's intention regarding this matter? >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> From andy@yumaworks.com Thu Aug 2 00:39:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7136721F8D36 for ; Thu, 2 Aug 2012 00:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DtJFHFwCX10 for ; Thu, 2 Aug 2012 00:39:45 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96C2121F8D37 for ; Thu, 2 Aug 2012 00:39:45 -0700 (PDT) Received: by qadz3 with SMTP id z3so3090728qad.10 for ; Thu, 02 Aug 2012 00:39:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=wWNQChB6qW1hXdApSQ34SDCYn019xYD1amZ55SYjH+0=; b=fqVGvhV8i+tA7hJKieumLflOonS+atTnyjnQsHjPd+Y/uc3kySVUTFXYTt0hKaHak8 oXwCo9ypdjNlaUKuv253gvb0qOSMmRERvPPxeShPhZL2ss3LZMzxekgtP3559tLVg9Xj FXMe9VHf51FwIfyr5Bdtbec28W8Ad882lj4ZYqFBrlLgVxQpy2d4wZGnccUX74UnnMjA Vsxq/BJStTV33BSioMudy+Zo7iLSjqbhcnRC68YLKCoPjdQdpQND2PTRjUfEciRDPKvn kIYv9rnLIbwr0iAOsXNw73cKLiZ1JoQB3rltebsw7dzVORDYtq947KfuvYcGzsdMUk+A o0Sw== MIME-Version: 1.0 Received: by 10.229.105.205 with SMTP id u13mr10942961qco.9.1343893184878; Thu, 02 Aug 2012 00:39:44 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 00:39:44 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:4559:c044:ab0b:ad52] In-Reply-To: <501A23CE.8020504@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> Date: Thu, 2 Aug 2012 00:39:44 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl7/oaJT83QScUztreQb6207BjmqgxmFnT0auolX+xO8LXKjrht2hSGfsgY8BgmCXKhL7E0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:39:46 -0000 On Wed, Aug 1, 2012 at 11:53 PM, Jernej Tuljak w= rote: > Dne 2.8.2012 4:05, pi=C5=A1e Ladislav Lhotka: >> >> On Aug 1, 2012, at 6:47 PM, Andy Bierman wrote: >> >>> On Wed, Aug 1, 2012 at 6:31 PM, Ladislav Lhotka wrote: >>>> >>>> On Aug 1, 2012, at 12:22 AM, Jernej Tuljak wrote: >>>> >>>>> This is my first time seeing a conditional augment in action. Does th= is >>>>> mean that such augmentations should be done dynamically based on the = current >>>>> instance document (from a YANG implementation's perspective)? This is= bad. >>>>> I've been under the impression that a YANG data model is "static" whe= re the >>>>> entire schema is known before hand, even conditional leaves and branc= hes. >>>>> But this means that the model may not be known until and actual insta= nce is >>>>> present - the schema may change under certain conditions. >>>> >>>> I argued several times exactly as you do, see for example this thread: >>>> >>>> http://www.ietf.org/mail-archive/web/netmod/current/msg04686.html >>>> >>>> But I was a lonely voice in a desert. So now we are two, good. >>> >>> I think Jernej was right when he wrote that the schema is always static= , >>> but the instance document determines if values are allowed or not. >>> Both uses-stmt and augment-stmt behave this way (if when-stmt used in >>> them). >>> It is not easy to implement. >> >> If the schema were static, then >> >> leaf foo { >> mandatory true; >> when X; >> =E2=80=A6 >> } >> >> would lead to an error if "foo" is not present (provided its parent is), >> no matter what the value of X. >> >> Actually, DSDL validation would signal this error because it is done in >> two steps: schema validation (RELAX NG) and semantic validation >> (Schematron). >> >> But I don't think there is agreement that this is the correct >> interpretation. > > > This is a bug actually. RFC6020 (8.2) is quite clear on this. Mandatory-s= tmt > conditon will only be enforced if when-stmt condition evaluates to false. > Perhaps such problems should be delegated only to Schematron. That is by > always making foo rng:optional, and transforming mandatory-stmt into an > XPath expression and moving it together with when condition so they must = be > satisfied on foo's parent (parent becomes the context node): > > when foo-parent is present in the instance document > -> when X condition for foo is false AND foo does not exist then error fo= r > missing mandatory foo > -> when X condition for foo is false AND foo exists then error for > unsatisfied constraint on foo I think you are wrong. when=3Dfalse is not a constraint error. It causes the node to be immediately deleted. When-stmt =3D false means that node is not part of the required child nodes if the parent is present. augment /foo { when "/bar=3D5"; leaf X { type string; mandatory true; } } vs: container foo { leaf X { when "/bar =3D 5"; type string; mandatory true; } } IMO, these should be conceptually equivalent. I don't think the mandatory error is ever triggered if the node is deleted due to when=3Dfalse. > > It doesn't matter how the error is generated. But it should be properly > generated. > > Jernej Andy > >> Lada >> >>> But I can see how this is problematic. >>> Good thing we overloaded the unknown-element error-tag ;-) >>> It is used for unknown and unexpected elements. >>> If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse we would = have >>> to >>> decide if that node is unknown by the server, vs. an instance >>> of that node is unexpected for the request. >>> >>> >>> >>>> Lada >>>> >>> Andy >>> >>> >>>>> Or does a conditional augment mean that the augmentation will always = be >>>>> done but all of the augmented nodes "inherit" the augment's when cond= itions >>>>> making all of them conditional? This would make much more sense to me= . Would >>>>> this be legal as a potential workaround to dynamically changing a mod= ule's >>>>> schema? What was the group's intention regarding this matter? >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> > From jernej.tuljak@mg-soft.si Thu Aug 2 02:38:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09DA21F8E5E for ; Thu, 2 Aug 2012 02:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjDh64MSFSNE for ; Thu, 2 Aug 2012 02:38:31 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 79CCA21F8E5C for ; Thu, 2 Aug 2012 02:38:29 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q729cPJv028072; Thu, 2 Aug 2012 11:38:25 +0200 Message-ID: <501A4A8C.8080107@mg-soft.com> Date: Thu, 02 Aug 2012 11:38:20 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 09:38:31 -0000 Dne 2.8.2012 9:39, piĆĄe Andy Bierman: > On Wed, Aug 1, 2012 at 11:53 PM, Jernej Tuljak wrote: >> Dne 2.8.2012 4:05, piĆĄe Ladislav Lhotka: >>> On Aug 1, 2012, at 6:47 PM, Andy Bierman wrote: >>> >>>> On Wed, Aug 1, 2012 at 6:31 PM, Ladislav Lhotka wrote: >>>>> On Aug 1, 2012, at 12:22 AM, Jernej Tuljak wrote: >>>>> >>>>>> This is my first time seeing a conditional augment in action. Does this >>>>>> mean that such augmentations should be done dynamically based on the current >>>>>> instance document (from a YANG implementation's perspective)? This is bad. >>>>>> I've been under the impression that a YANG data model is "static" where the >>>>>> entire schema is known before hand, even conditional leaves and branches. >>>>>> But this means that the model may not be known until and actual instance is >>>>>> present - the schema may change under certain conditions. >>>>> I argued several times exactly as you do, see for example this thread: >>>>> >>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg04686.html >>>>> >>>>> But I was a lonely voice in a desert. So now we are two, good. >>>> I think Jernej was right when he wrote that the schema is always static, >>>> but the instance document determines if values are allowed or not. >>>> Both uses-stmt and augment-stmt behave this way (if when-stmt used in >>>> them). >>>> It is not easy to implement. >>> If the schema were static, then >>> >>> leaf foo { >>> mandatory true; >>> when X; >>> 
 >>> } >>> >>> would lead to an error if "foo" is not present (provided its parent is), >>> no matter what the value of X. >>> >>> Actually, DSDL validation would signal this error because it is done in >>> two steps: schema validation (RELAX NG) and semantic validation >>> (Schematron). >>> >>> But I don't think there is agreement that this is the correct >>> interpretation. >> >> This is a bug actually. RFC6020 (8.2) is quite clear on this. Mandatory-stmt >> conditon will only be enforced if when-stmt condition evaluates to false. >> Perhaps such problems should be delegated only to Schematron. That is by >> always making foo rng:optional, and transforming mandatory-stmt into an >> XPath expression and moving it together with when condition so they must be >> satisfied on foo's parent (parent becomes the context node): >> >> when foo-parent is present in the instance document >> -> when X condition for foo is false AND foo does not exist then error for >> missing mandatory foo >> -> when X condition for foo is false AND foo exists then error for >> unsatisfied constraint on foo > I think you are wrong. > when=false is not a constraint error. > It causes the node to be immediately deleted. > When-stmt = false means that node is not part of the > required child nodes if the parent is present. > > augment /foo { > when "/bar=5"; > leaf X { type string; mandatory true; } > } > > vs: > > container foo { > leaf X { > when "/bar = 5"; > type string; > mandatory true; > } > } > > IMO, these should be conceptually equivalent. > I don't think the mandatory error is ever triggered > if the node is deleted due to when=false. > I think this is an implementation detail. The correct errors would be reported either way, expressing the intention of the model. Only my way is surely easier to implement and would also put less strain on the device that has to implement it. On second thought, my error may provide more detail, explaining that an instance node cannot appear, because it's when condition is not satisfied, as opposed to saying "unexpected node" which is the only thing you can do. You still seem to be under the impression that schema nodes MUST magically appear and disappear at XPath will (Ladislav referred to this as "run-time modifications to the schema"). That schema may have to be "re-generated" to add missing/remove unnecessary schema nodes according to what the content of an instance document is, which is way too complicated to be useful or to implement. Instead, the way I see it, such nodes are always present but are used only when certain conditions are met, conditions that are governed by instance documents, making YANG a static schema which may be pruned via if-feature statements in a controlled manner. I agree that if-feature statements are different because they actually eliminate parts of a schema before hand the way you described, upon "hello message being received"/"a server being implemented". Those schema nodes temporarily cease to exist (or even permanently if those parts of a module are never implemented on the server). But these are not run-time modifications. At least not until "hot-plugging" of features is supported by NETCONF, but this would simply imply that pluggable parts of the schema should always be present on the server. I think that the idea to completely decouple the schema from instances based on it is the way to go. Your schema is not such a schema, since it needs an instance to determine it's final form (the instance becomes a part of the schema). It's form must be determined after every modification to the instance. Constantly. Not entirely sure how you do it. One other thing. Our generic client application displays the entire schema in a tree graphic component and even offers queries to be made from it. How could it possibly do that if the tree's final form cannot be determined? Also this would make RFC6110 next to useless since the assumption that YANG schema is static is the foundation it builds upon. Generating DSDL schema is an expensive operation...and it would have to be done after every modification to an instance document. The when-stmt only makes its parent data definition statement conditional. There's nothing written in RFC6020 that this would imply modifications to the schema (can't find it). Although multiple paragraphs can be found which serve as workarounds for non-static implementations of YANG schema. The point in 8.3.1 Payload Parsing which relates to when-stmt is an example. Sorry, but I'm completely with Ladislav on this one. Non-static schema or run-time changes to a schema are bad and should never have been allowed to become a part of YANG. I cannot argue that they are not a part of it. Jernej > > >> It doesn't matter how the error is generated. But it should be properly >> generated. >> >> Jernej > Andy > >>> Lada >>> >>>> But I can see how this is problematic. >>>> Good thing we overloaded the unknown-element error-tag ;-) >>>> It is used for unknown and unexpected elements. >>>> If /foo/bar only exists if when=true, then for when=false we would have >>>> to >>>> decide if that node is unknown by the server, vs. an instance >>>> of that node is unexpected for the request. >>>> >>>> >>>> >>>>> Lada >>>>> >>>> Andy >>>> >>>> >>>>>> Or does a conditional augment mean that the augmentation will always be >>>>>> done but all of the augmented nodes "inherit" the augment's when conditions >>>>>> making all of them conditional? This would make much more sense to me. Would >>>>>> this be legal as a potential workaround to dynamically changing a module's >>>>>> schema? What was the group's intention regarding this matter? >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> From andy@yumaworks.com Thu Aug 2 03:12:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F6321F8CA3 for ; Thu, 2 Aug 2012 03:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saDBgZrwhZkj for ; Thu, 2 Aug 2012 03:12:08 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0221F8A83 for ; Thu, 2 Aug 2012 03:12:08 -0700 (PDT) Received: by qaea16 with SMTP id a16so1039647qae.10 for ; Thu, 02 Aug 2012 03:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=eAvOGMFBwdNNJEp+G/VuD0z0r1kkp7BFJq/W04B4h3s=; b=mv6QRPPV9eJy1TTHZC98JKlw1KZ4hD66Lhl1rjpJPghJH3RwtryV1kdW6R29s3tR8C vt+KFUIMxc0LenXa0PoHuyMZqACKVvJRD+wqEEhGkQPxuXMLWfkFoS//JUf5hRoxe7y5 tjsNsbShOSn+IekR4EudoFwDVjzTE0v+XeDGQrhGnPF+m5cY3ZyEV3s5ys23HFInaXIn dMnwpiakfbAqYGGHs9UVNEzG42+G9WgiM7yGfvcQHdMOIS0vPjMyeAAyz2e4rQGz3NJG 7iMSxvn2+BKhBEUTelswCUkmwyZOk+Kl2jVBHP+u/6lDKLbDq4W4rHy6qeFQr6y0IZsM M7Ow== MIME-Version: 1.0 Received: by 10.224.175.6 with SMTP id v6mr17733810qaz.36.1343902327753; Thu, 02 Aug 2012 03:12:07 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 03:12:07 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:4559:c044:ab0b:ad52] In-Reply-To: <501A4A8C.8080107@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> Date: Thu, 2 Aug 2012 03:12:07 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlHKMNQmXzYcxOOMBxI+7iOkbhTVGAZQY6A/3tWdWZb6RjJQ0RvogxoI0lmDZ9C8sxFI/Gh Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 10:12:09 -0000 I agree that all of this is just implementation details. This 2nd bullet in 8.3.2 says that false when-stmt nodes are deleted immediately: During processing: o If the NETCONF operation creates data nodes under a "choice", any existing nodes from other "case" branches are deleted by the server. o If the NETCONF operation modifies a data node such that any node's "when" expression becomes false, then the node with the "when" expression is deleted by the server. This text in 7.19.5 says that the statement containing the when-stmt is conditional, i.e., does not apply if when=3Dfalse: The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. It doesn't matter how an implementation figures out what to do. leaf X { type string; mandatory true; when "blah"; } The text is clear that the mandatory-stmt is not enforced if when=3Dfalse. Andy On Thu, Aug 2, 2012 at 2:38 AM, Jernej Tuljak wr= ote: > Dne 2.8.2012 9:39, pi=C5=A1e Andy Bierman: >> >> On Wed, Aug 1, 2012 at 11:53 PM, Jernej Tuljak >> wrote: >>> >>> Dne 2.8.2012 4:05, pi=C5=A1e Ladislav Lhotka: >>>> >>>> On Aug 1, 2012, at 6:47 PM, Andy Bierman wrote: >>>> >>>>> On Wed, Aug 1, 2012 at 6:31 PM, Ladislav Lhotka wrot= e: >>>>>> >>>>>> On Aug 1, 2012, at 12:22 AM, Jernej Tuljak wrote: >>>>>> >>>>>>> This is my first time seeing a conditional augment in action. Does >>>>>>> this >>>>>>> mean that such augmentations should be done dynamically based on th= e >>>>>>> current >>>>>>> instance document (from a YANG implementation's perspective)? This = is >>>>>>> bad. >>>>>>> I've been under the impression that a YANG data model is "static" >>>>>>> where the >>>>>>> entire schema is known before hand, even conditional leaves and >>>>>>> branches. >>>>>>> But this means that the model may not be known until and actual >>>>>>> instance is >>>>>>> present - the schema may change under certain conditions. >>>>>> >>>>>> I argued several times exactly as you do, see for example this threa= d: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg04686.html >>>>>> >>>>>> But I was a lonely voice in a desert. So now we are two, good. >>>>> >>>>> I think Jernej was right when he wrote that the schema is always >>>>> static, >>>>> but the instance document determines if values are allowed or not. >>>>> Both uses-stmt and augment-stmt behave this way (if when-stmt used in >>>>> them). >>>>> It is not easy to implement. >>>> >>>> If the schema were static, then >>>> >>>> leaf foo { >>>> mandatory true; >>>> when X; >>>> =E2=80=A6 >>>> } >>>> >>>> would lead to an error if "foo" is not present (provided its parent is= ), >>>> no matter what the value of X. >>>> >>>> Actually, DSDL validation would signal this error because it is done i= n >>>> two steps: schema validation (RELAX NG) and semantic validation >>>> (Schematron). >>>> >>>> But I don't think there is agreement that this is the correct >>>> interpretation. >>> >>> >>> This is a bug actually. RFC6020 (8.2) is quite clear on this. >>> Mandatory-stmt >>> conditon will only be enforced if when-stmt condition evaluates to fals= e. >>> Perhaps such problems should be delegated only to Schematron. That is b= y >>> always making foo rng:optional, and transforming mandatory-stmt into an >>> XPath expression and moving it together with when condition so they mus= t >>> be >>> satisfied on foo's parent (parent becomes the context node): >>> >>> when foo-parent is present in the instance document >>> -> when X condition for foo is false AND foo does not exist then error >>> for >>> missing mandatory foo >>> -> when X condition for foo is false AND foo exists then error for >>> unsatisfied constraint on foo >> >> I think you are wrong. >> when=3Dfalse is not a constraint error. >> It causes the node to be immediately deleted. >> When-stmt =3D false means that node is not part of the >> required child nodes if the parent is present. >> >> augment /foo { >> when "/bar=3D5"; >> leaf X { type string; mandatory true; } >> } >> >> vs: >> >> container foo { >> leaf X { >> when "/bar =3D 5"; >> type string; >> mandatory true; >> } >> } >> >> IMO, these should be conceptually equivalent. >> I don't think the mandatory error is ever triggered >> if the node is deleted due to when=3Dfalse. >> > > I think this is an implementation detail. The correct errors would be > reported either way, expressing the intention of the model. Only my way i= s > surely easier to implement and would also put less strain on the device t= hat > has to implement it. On second thought, my error may provide more detail, > explaining that an instance node cannot appear, because it's when conditi= on > is not satisfied, as opposed to saying "unexpected node" which is the onl= y > thing you can do. > > You still seem to be under the impression that schema nodes MUST magicall= y > appear and disappear at XPath will (Ladislav referred to this as "run-tim= e > modifications to the schema"). That schema may have to be "re-generated" = to > add missing/remove unnecessary schema nodes according to what the content= of > an instance document is, which is way too complicated to be useful or to > implement. Instead, the way I see it, such nodes are always present but a= re > used only when certain conditions are met, conditions that are governed b= y > instance documents, making YANG a static schema which may be pruned via > if-feature statements in a controlled manner. > > I agree that if-feature statements are different because they actually > eliminate parts of a schema before hand the way you described, upon "hell= o > message being received"/"a server being implemented". Those schema nodes > temporarily cease to exist (or even permanently if those parts of a modul= e > are never implemented on the server). But these are not run-time > modifications. At least not until "hot-plugging" of features is supported= by > NETCONF, but this would simply imply that pluggable parts of the schema > should always be present on the server. > > I think that the idea to completely decouple the schema from instances ba= sed > on it is the way to go. Your schema is not such a schema, since it needs = an > instance to determine it's final form (the instance becomes a part of the > schema). It's form must be determined after every modification to the > instance. Constantly. Not entirely sure how you do it. > > One other thing. Our generic client application displays the entire schem= a > in a tree graphic component and even offers queries to be made from it. H= ow > could it possibly do that if the tree's final form cannot be determined? > > Also this would make RFC6110 next to useless since the assumption that YA= NG > schema is static is the foundation it builds upon. Generating DSDL schema= is > an expensive operation...and it would have to be done after every > modification to an instance document. > > The when-stmt only makes its parent data definition statement conditional= . > There's nothing written in RFC6020 that this would imply modifications to > the schema (can't find it). Although multiple paragraphs can be found whi= ch > serve as workarounds for non-static implementations of YANG schema. The > point in 8.3.1 Payload Parsing which relates to when-stmt is an example. > > Sorry, but I'm completely with Ladislav on this one. Non-static schema or > run-time changes to a schema are bad and should never have been allowed t= o > become a part of YANG. I cannot argue that they are not a part of it. > > Jernej > >> >> >>> It doesn't matter how the error is generated. But it should be properly >>> generated. >>> >>> Jernej >> >> Andy >> >>>> Lada >>>> >>>>> But I can see how this is problematic. >>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>> It is used for unknown and unexpected elements. >>>>> If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse we woul= d have >>>>> to >>>>> decide if that node is unknown by the server, vs. an instance >>>>> of that node is unexpected for the request. >>>>> >>>>> >>>>> >>>>>> Lada >>>>>> >>>>> Andy >>>>> >>>>> >>>>>>> Or does a conditional augment mean that the augmentation will alway= s >>>>>>> be >>>>>>> done but all of the augmented nodes "inherit" the augment's when >>>>>>> conditions >>>>>>> making all of them conditional? This would make much more sense to >>>>>>> me. Would >>>>>>> this be legal as a potential workaround to dynamically changing a >>>>>>> module's >>>>>>> schema? What was the group's intention regarding this matter? >>>>>> >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> > From pgili@cisco.com Thu Aug 2 04:52:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7AB21F8E2A for ; Thu, 2 Aug 2012 04:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRz3bwfJoUJB for ; Thu, 2 Aug 2012 04:52:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CAAF521F8DA3 for ; Thu, 2 Aug 2012 04:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=1015; q=dns/txt; s=iport; t=1343908338; x=1345117938; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RlKaWw0xPvI7v5vl5A7VGb36A5pzrt5+NkYzGoNhCOs=; b=f9c+ZDFwQeJv8788aL6reLmcBfxsQNpdwrsTKLUR8+mYbmiZFXAZr+y2 USZ7MUg3nLXxqdjDQMde4BM4rJqjOU8NB1xzq8W5xHlR8VhVOFICBfwTy fzEa7s0ZLr1moKD/EXdBpRHjqARtjvTc61Aw0fhvwSSZJ22Ty5A8yiqW9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAppGlCtJXG//2dsb2JhbABFhTSzWIEHgiABAQEEAQEBDwEnNBcEAgEIDgMEAQEBChQJBycLFAkIAgQBEggah2sLnQGgMwSLSYYkYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,699,1336348800"; d="scan'208";a="107590465" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 02 Aug 2012 11:52:17 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q72BqH87023746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 11:52:17 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.145]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 06:52:17 -0500 From: "Patrick Gili (pgili)" To: Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNcDeBpLzaXn+U8UWilvWloQKDDJdGaagQ Date: Thu, 2 Aug 2012 11:52:16 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> In-Reply-To: <20120801.154636.148603434.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.76] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004 x-tm-as-result: No--30.046400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 11:52:18 -0000 Hi Martin, If we take this step, which I am not opposed to, and following your reasoni= ng, then why not go the full nine yards and come up with a YANG equivalent = of the IF-MIB? Patrick -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Martin Bjorklund Sent: Wednesday, August 01, 2012 6:47 PM To: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module Hi, It seems people want to add the config false "if stack" objects proposed be= low: Martin Bjorklund wrote: > leaf-list subordinate-if { ... } > leaf-list superior-if { ... } If we add this, I suggest we also add a leaf if-oper-status, with the same = syntax and semantics as ifOperStatus, so that clients doesn't have to rely = on the MIB data for this rather important object. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From ietfc@btconnect.com Thu Aug 2 07:06:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4140B21E8042 for ; Thu, 2 Aug 2012 07:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGHdZIAGoYLB for ; Thu, 2 Aug 2012 07:06:00 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37121E803F for ; Thu, 2 Aug 2012 07:05:59 -0700 (PDT) Received: from mail49-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 14:05:58 +0000 Received: from mail49-am1 (localhost [127.0.0.1]) by mail49-am1-R.bigfish.com (Postfix) with ESMTP id 22AD31C031A; Thu, 2 Aug 2012 14:05:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT008.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I542M1432I1418Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah107ah304l) Received: from mail49-am1 (localhost.localdomain [127.0.0.1]) by mail49-am1 (MessageSwitch) id 1343916357441838_6819; Thu, 2 Aug 2012 14:05:57 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.243]) by mail49-am1.bigfish.com (Postfix) with ESMTP id 69ED73A0051; Thu, 2 Aug 2012 14:05:57 +0000 (UTC) Received: from DB3PRD0702HT008.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 14:05:54 +0000 Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by pod51017.outlook.com (10.3.4.173) with Microsoft SMTP Server (TLS) id 14.15.86.1; Thu, 2 Aug 2012 14:05:46 +0000 Message-ID: <006701cd70b7$4f0b9e60$4001a8c0@gateway.2wire.net> From: t.petch To: "Yi Yang (yiya)" , Ladislav Lhotka References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com><1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com><5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:06:06 -0000 ----- Original Message ----- From: "Yi Yang (yiya)" To: "Ladislav Lhotka" Cc: Sent: Tuesday, July 31, 2012 3:29 PM Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 Hi Ladislav, >>>> I am not an expert on Junos, but here is the output of "show route forwarding-table", from http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command -summary/show-route-forwarding-table-mpls-ex-series.html >>>> >>>> user@switch> show route forwarding-table >>>> Routing table: default.inet >>>> Internet: >>>> Destination Type RtRef Next hop Type Index NhRef Netif >>>> default user 2 0:12:f2:21:cf:0 ucst 333 5 me0.0 >>>> default perm 0 rjct 36 2 >>>> 0.0.0.0/32 perm 0 dscd 34 1 >>>> 2.2.2.0/24 intf 0 rslv 1309 1 ae0.0 >>>> ....... >>>> >>>> Compared to the output of "show route", from >>>> http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command -summary/show-route.html >>>> >>>> user@host> show route >>>> inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) >>>> + =3D Active Route, - =3D Last Active, * =3D Both >>>> 0.0.0.0/0 *[Static/5] 1w5d 20:30:29 >>>> Discard >>>> 10.255.245.51/32 *[Direct/0] 2w4d 13:11:14 >>>>> via lo0.0 >>>> 172.16.0.0/12 *[Static/5] 2w4d 13:11:14 >>>>> to 192.168.167.254 via fxp0.0 >>>> 192.168.0.0/18 *[Static/5] 1w5d 20:30:29 >>>>> to 192.168.167.254 via fxp0.0 >>>> >>>> As mentioned earlier, source/age are not shown in the forwarding table, unless they are hidden intentionally? Maybe someone familiar with Junos can comment on this? >>> >>> Would it help if "age" and "source-protocol" were not mandatory? >> >> I am inclined to separate forwarding table from routing table. The forwarding table is so special that it has a different data structure, doesn't interact with routing protocol directly, and doesn't support export filters=85 > > This is certainly an option - somebody can write such an extension as a separate module. But, as I said, some implementations do not use a forwarding table. Or, forwarding table as an optional? IMO, no matter if forwarding table is specified in a separate module, or specified as an optional node, the reference of forwarding table and FIB in the draft should be clarified as they are not routing tables. In a sense I agree with you, in a sense I think the exact opposite. This topic of what tables there are in a box that routes packets has surfaced before. I see, in a typical I-D produced about routing, reference to FIB and RIB, without any need to define or explain the terms, they are that well known, they are what routers and other boxes have as a matter or course. For me, it is the FIB that is always present; if you do not know where to send a packet, how to route it, then you are not an IP box of any shape or form - you must have a FIB.. In simple boxes, like Linux or Windows, then that is all you have. In more sophisticated boxes, 'proper' routers, for some meaning of the word proper, then you need much more data, which may closely model the FIB, as with RIP, or may be utterly different, as with OSPF, and for this, I see the term RIB used, initially with BGP but latterly with any routing protocol. RIBs vary widely with the routing protocol and so are properly part of routing protocol extensions. So I think that this I-D gets the terminology quite wrong; as I say, this has surfaced before without any visible change to the I-D. I was surprised that this topic attracted no comment from the Routing Directorate. Tom Petch Yi _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Thu Aug 2 07:56:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFA011E80BA for ; Thu, 2 Aug 2012 07:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV9w8F2QtA3N for ; Thu, 2 Aug 2012 07:56:46 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C178411E8072 for ; Thu, 2 Aug 2012 07:56:46 -0700 (PDT) Received: by qadz3 with SMTP id z3so3357588qad.10 for ; Thu, 02 Aug 2012 07:56:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=kdbvUkY0vBmAbF8K5I5ASfio19yLN+diKX1N1ujSoKU=; b=mi8sdiSQ4eQ/RQ7k6dyP/EGDqi7//XcUpJ/TZoLgtBtSmFL+thcecHy64QtUAMoIOW aSkmIxO2s1CH6sjyqTUXiRxocvTwU6jKdMDln+w/m0rpx/cg0SiNCgzNhXVxFImzLGqH DoERyYH3bksizSbEHp1/nKRg8AXXlvllJ0ToxFz23++S/bvSnY1Uqfe24AIo3HEj2zt0 ryHUh6Dp397W1CZVCmA8ECvws+UaYKAzkVWeOqTmboIkChfMboA/S9g/IP9NVFl6611+ B07zYAsbbW+z6Dw06/7vkziD+zYcBsK2jvAuzXlOkWigfcykgQBu1UEzPrEbwtoXmU+K pGRQ== MIME-Version: 1.0 Received: by 10.224.175.6 with SMTP id v6mr19214504qaz.36.1343919406263; Thu, 02 Aug 2012 07:56:46 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 07:56:46 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:4559:c044:ab0b:ad52] In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> Date: Thu, 2 Aug 2012 07:56:46 -0700 Message-ID: From: Andy Bierman To: "Patrick Gili (pgili)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm4ZBOrvo2Nimw8bqD7fx2VAdj/kjiVM86HPRpV6iXBnO6GEPo/QAD2XE05e21rNYRSSrBa Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:56:47 -0000 On Thu, Aug 2, 2012 at 4:52 AM, Patrick Gili (pgili) wrote: > Hi Martin, > > If we take this step, which I am not opposed to, and following your reasoning, then why not go the full nine yards and come up with a YANG equivalent of the IF-MIB? > Agreed. This data is too important to rely on SNMP for some of it. We made a custom YANG version of ifType just to add some description-stmts. This seems much more important than that. Perhaps we have learned some things about interface management since IF-MIB was published, and the direct SMIv2 to YANG translation is not sufficient. IMO, the scope should lean towards complete management, not just configuration. > Patrick > Andy > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Wednesday, August 01, 2012 6:47 PM > To: netmod@ietf.org > Subject: Re: [netmod] comment on ietf-interfaces module > > Hi, > > It seems people want to add the config false "if stack" objects proposed below: > > Martin Bjorklund wrote: >> leaf-list subordinate-if { ... } >> leaf-list superior-if { ... } > > If we add this, I suggest we also add a leaf if-oper-status, with the same syntax and semantics as ifOperStatus, so that clients doesn't have to rely on the MIB data for this rather important object. > > > /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 j.schoenwaelder@jacobs-university.de Thu Aug 2 08:47:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A0621F8620 for ; Thu, 2 Aug 2012 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeBzwhIoO5r4 for ; Thu, 2 Aug 2012 08:47:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA3721F868A for ; Thu, 2 Aug 2012 08:47:39 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 125B220C19; Thu, 2 Aug 2012 17:47:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dXNiTGMil1dm; Thu, 2 Aug 2012 17:47:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C35120C07; Thu, 2 Aug 2012 17:47:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 75FCE21019E5; Thu, 2 Aug 2012 17:47:36 +0200 (CEST) Date: Thu, 2 Aug 2012 17:47:36 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120802154735.GA86274@elstar.local> Mail-Followup-To: Andy Bierman , "Patrick Gili (pgili)" , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:47:40 -0000 On Thu, Aug 02, 2012 at 07:56:46AM -0700, Andy Bierman wrote: > On Thu, Aug 2, 2012 at 4:52 AM, Patrick Gili (pgili) wrote: > > Hi Martin, > > > > If we take this step, which I am not opposed to, and following your reasoning, then why not go the full nine yards and come up with a YANG equivalent of the IF-MIB? > > > > Agreed. This data is too important to rely on SNMP for some of it. > We made a custom YANG version of ifType just to add some > description-stmts. This seems much more important than that. > Perhaps we have learned some things about interface management > since IF-MIB was published, and the direct SMIv2 to YANG translation > is not sufficient. IMO, the scope should lean towards complete > management, not just configuration. > Is redefining all the counters really a high priority activity given that there is already a way of retrieving them via NETCONF? /js (speaking as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From pgili@cisco.com Thu Aug 2 08:48:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8A721F86C7 for ; Thu, 2 Aug 2012 08:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qZmmtKbnMpg for ; Thu, 2 Aug 2012 08:48:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8804B21F86A7 for ; Thu, 2 Aug 2012 08:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=4738; q=dns/txt; s=iport; t=1343922513; x=1345132113; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zYcBt/mu1jOTBGbgGTOWdQVlukRdCJW63TTi/bN9Sg4=; b=OMISUHHrLxt4nXp25PsPeA5DURouaH74hcBoO1Q2jGbVJqf592Dg+UEL 0uY3k2qyd+pjz9PuH4VkOmrrBU7dc5iw6f/GQQcjZMoABtWosv6Ho3lR2 4NRXdo2Ik6phaKd443nq4UcTB3qOS7LdpRospnO8//LOrFejXj+kzpIQ1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPSfGlCtJXG+/2dsb2JhbABFhXuyH3KBB4IgAQEBAwEBAQEPARAROgMIBQcEAgEIEQQBAQECAgYdAwICAiULFAEICAIEDgUIGodlBgucZ40Zky8EgSGKKIVyMmADo26BZoJf X-IronPort-AV: E=Sophos;i="4.77,701,1336348800"; d="scan'208";a="107873043" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 02 Aug 2012 15:48:33 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q72FmXLq008179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 15:48:33 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.239]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 10:46:13 -0500 From: "Patrick Gili (pgili)" To: Andy Bierman Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNcDeBpLzaXn+U8UWilvWloQKDDJdGaagQgACHzQD//7eD4A== Date: Thu, 2 Aug 2012 15:48:32 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--40.100700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:48:34 -0000 V2UndmUgYmVlbiBzY3JhdGNoaW5nIG91ciBoZWFkcyB3b25kZXJpbmcgYWJvdXQgdGhlIFlBTkcg bW9kdWxlcyBjdXJyZW50bHkgZGVmaW5lZCBieSBJLURzIGluIHRoZSBORVRNT0QgV0c6DQoNCi0g V2h5IHRoZSBiaWFzIHRvd2FyZCBjb25maWd1cmF0aW9uPyBJIGRvbid0IGJ1eSB0aGlzIGFyZ3Vt ZW50IHRoYXQgTkVUQ09ORiBpcyBmb3IgY29uZmlndXJhdGlvbiBhbmQgU05NUCBmb3IgbW9uaXRv cmluZy4gSWYgb25lIG9mIG91ciBjdXN0b21lcnMgb3IgcGFydG5lcnMgZGV2ZWxvcGVycyBhIG1h bmFnZW1lbnQgYXBwbGljYXRpb24gd2l0aCB0aGUgY2FwYWJpbGl0eSB0byBtYW5hZ2UgaW50ZXJm YWNlcywgd2h5IGlzIGl0IHRoZSBleHBlY3RhdGlvbiB0aGF0IHVzZSBORVRDT05GIGZvciBjb25m aWd1cmF0aW9uIGFuZCBTTk1QIGZvciBtb25pdG9yaW5nPyBJZiB0aGlzIGlzIG5vdCB0aGUgZXhw ZWN0YXRpb24sIHRoZW4gd2h5IGRlZmluZSBzZXBhcmF0ZSBZQU5HIG1vZHVsZXMuIElmIEkgd2Vy ZSB0byBkZXZlbG9wIGFuIEFQSSB0byBtYW5hZ2UgaW50ZXJmYWNlcyBzdXBwb3J0ZWQgYnkgYSBk ZXZpY2UsIEkgY2VydGFpbmx5IHdvdWxkbid0IGRlZmluZSBvbmUgQVBJIGZvciB0aGUgcHVycG9z ZSBvZiBjb25maWd1cmluZyB0aGVzZSBpbnRlcmZhY2VzIGFuZCBhbm90aGVyIEFQSSBmb3IgdGhl IHB1cnBvc2Ugb2YgbW9uaXRvcmluZyB0aGVtLg0KDQotIFdoeSBhcmUgd2Ugbm90IGJ1aWxkaW5n IG9uIHRoZSB3b3JrIGRvbmUgZm9yIFNOTVAtYmFzZWQgbWFuYWdlbWVudD8gSWYgd2UgYXJlIGlu ZGVlZCBidWlsZGluZyBvbiBpdCwgdGhlbiB0aGUgZGVmaW5pdGlvbnMgb2YgdGhlIFlBTkcgbW9k dWxlcyBkb24ndCBuZWNlc3NhcmlseSByZWZsZWN0IGl0Lg0KDQotIFNNSXYyLXRvLVlBTkcgY29u dmVyc2lvbiBpcyBpbnN1ZmZpY2llbnQgZm9yIHRoZSBzaW1wbGUgcmVhc29uIHRoYXQgWUFORyBw cm92aWRlcyBhIG1vcmUgcm9idXN0IG1ldGEtbW9kZWwgZm9yIHRoZSBwdXJwb3NlIG9mIGRlc2Ny aWJpbmcgIm1hbmFnZWQgZGF0YSIuIEl0IHdvdWxkIGJlIGFraW4gdG8gY29udmVydGluZyBDIGNv ZGUgdG8gSmF2YSB3aXRob3V0IHRha2luZyBhZHZhbnRhZ2Ugb2YgdGhlIG9iamVjdCBvcmllbnRl ZCBjYXBhYmlsaXRpZXMgc3VwcG9ydGVkIGJ5IHRoZSBsYW5ndWFnZS4gVGhyb3VnaCB0aGUgZGVj YWRlcywgdGhlIGltcGxlbWVudGF0aW9uIG9mIE1JQiBtb2R1bGVzIGhhdmUgcHJlc2VudGVkIG5l dHdvcmsgZXF1aXBtZW50IHZlbmRvcnMgd2l0aCB1bmlxdWUgY2hhbGxlbmdlcyB3aGljaCB3ZSBo YXZlIHRoZSBvcHBvcnR1bml0eSB0byBlbGltaW5hdGUsIGJ1dCBvbmx5IGlmIHdlIHRha2UgdGhl IHRpbWUgZGVmaW5lIFlBTkcgbW9kdWxlcyB3aXRoIGNvbnNpZGVyYXRpb24gZm9yIHRoZSByb2J1 c3RuZXNzIG9mIHRoZSBtZXRhLW1vZGVsLCByYXRoZXIgdGhhbiBzaW1wbHkgZW11bGF0aW5nIFNO TVAgb3ZlciBORVRDT05GLg0KDQpQYXRyaWNrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dIA0KU2VudDog VGh1cnNkYXksIEF1Z3VzdCAwMiwgMjAxMiAxMDo1NyBBTQ0KVG86IFBhdHJpY2sgR2lsaSAocGdp bGkpDQpDYzogTWFydGluIEJqb3JrbHVuZDsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W25ldG1vZF0gY29tbWVudCBvbiBpZXRmLWludGVyZmFjZXMgbW9kdWxlDQoNCk9uIFRodSwgQXVn IDIsIDIwMTIgYXQgNDo1MiBBTSwgUGF0cmljayBHaWxpIChwZ2lsaSkgPHBnaWxpQGNpc2NvLmNv bT4gd3JvdGU6DQo+IEhpIE1hcnRpbiwNCj4NCj4gSWYgd2UgdGFrZSB0aGlzIHN0ZXAsIHdoaWNo IEkgYW0gbm90IG9wcG9zZWQgdG8sIGFuZCBmb2xsb3dpbmcgeW91ciByZWFzb25pbmcsIHRoZW4g d2h5IG5vdCBnbyB0aGUgZnVsbCBuaW5lIHlhcmRzIGFuZCBjb21lIHVwIHdpdGggYSBZQU5HIGVx dWl2YWxlbnQgb2YgdGhlIElGLU1JQj8NCj4NCg0KQWdyZWVkLiAgVGhpcyBkYXRhIGlzIHRvbyBp bXBvcnRhbnQgdG8gcmVseSBvbiBTTk1QIGZvciBzb21lIG9mIGl0Lg0KV2UgbWFkZSBhIGN1c3Rv bSBZQU5HIHZlcnNpb24gb2YgaWZUeXBlIGp1c3QgdG8gYWRkIHNvbWUgZGVzY3JpcHRpb24tc3Rt dHMuICBUaGlzIHNlZW1zIG11Y2ggbW9yZSBpbXBvcnRhbnQgdGhhbiB0aGF0Lg0KUGVyaGFwcyB3 ZSBoYXZlIGxlYXJuZWQgc29tZSB0aGluZ3MgYWJvdXQgaW50ZXJmYWNlIG1hbmFnZW1lbnQgc2lu Y2UgSUYtTUlCIHdhcyBwdWJsaXNoZWQsIGFuZCB0aGUgZGlyZWN0IFNNSXYyIHRvIFlBTkcgdHJh bnNsYXRpb24gaXMgbm90IHN1ZmZpY2llbnQuICBJTU8sIHRoZSBzY29wZSBzaG91bGQgbGVhbiB0 b3dhcmRzIGNvbXBsZXRlIG1hbmFnZW1lbnQsIG5vdCBqdXN0IGNvbmZpZ3VyYXRpb24uDQoNCg0K PiBQYXRyaWNrDQo+DQoNCkFuZHkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYu b3JnXSBPbiANCj4gQmVoYWxmIE9mIE1hcnRpbiBCam9ya2x1bmQNCj4gU2VudDogV2VkbmVzZGF5 LCBBdWd1c3QgMDEsIDIwMTIgNjo0NyBQTQ0KPiBUbzogbmV0bW9kQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBjb21tZW50IG9uIGlldGYtaW50ZXJmYWNlcyBtb2R1bGUNCj4NCj4g SGksDQo+DQo+IEl0IHNlZW1zIHBlb3BsZSB3YW50IHRvIGFkZCB0aGUgY29uZmlnIGZhbHNlICJp ZiBzdGFjayIgb2JqZWN0cyBwcm9wb3NlZCBiZWxvdzoNCj4NCj4gTWFydGluIEJqb3JrbHVuZCA8 bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KPj4gICAgIGxlYWYtbGlzdCBzdWJvcmRpbmF0ZS1pZiB7 IC4uLiB9DQo+PiAgICAgbGVhZi1saXN0IHN1cGVyaW9yLWlmIHsgLi4uIH0NCj4NCj4gSWYgd2Ug YWRkIHRoaXMsIEkgc3VnZ2VzdCB3ZSBhbHNvIGFkZCBhIGxlYWYgaWYtb3Blci1zdGF0dXMsIHdp dGggdGhlIHNhbWUgc3ludGF4IGFuZCBzZW1hbnRpY3MgYXMgaWZPcGVyU3RhdHVzLCBzbyB0aGF0 IGNsaWVudHMgZG9lc24ndCBoYXZlIHRvIHJlbHkgb24gdGhlIE1JQiBkYXRhIGZvciB0aGlzIHJh dGhlciBpbXBvcnRhbnQgb2JqZWN0Lg0KPg0KPg0KPiAvbWFydGluDQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxp c3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From pgili@cisco.com Thu Aug 2 08:50:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81E421F85E7 for ; Thu, 2 Aug 2012 08:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNDbRYq49CqN for ; Thu, 2 Aug 2012 08:50:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 34D2921F84F5 for ; Thu, 2 Aug 2012 08:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=1655; q=dns/txt; s=iport; t=1343922608; x=1345132208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EHGqjzqiRFD5iuQHK3geLaFMK3NUehZwjLZiqtHTbKg=; b=RB2kGF9uDm6yRgTxf+Mn62R5SnE0D9J6Gsj49VZHQ0DRP2mFoWH0hcBt DN7APbm6d/YrFJF3uKtmIX9PeuH4l29+xnL+oQHzUqg0IH1ty+PNTJghy dCYbVlOlObkjdu5Asx7VOWrH1N/6AXanmmMf22rX4XC8Xx6HwnO1/t24H Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE6hGlCtJXG+/2dsb2JhbABCA7kMgQeCIAEBAQQSASc/DAICAgEIDgIBBAEBAQoUCQcbFxQJCAIEAQ0FCBqHa5xroFAEi0WDY4JBYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,701,1336348800"; d="scan'208";a="107873542" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 02 Aug 2012 15:50:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q72Fo7Yx009384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 15:50:07 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.239]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 10:50:07 -0500 From: "Patrick Gili (pgili)" To: Juergen Schoenwaelder , Andy Bierman Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNcDeBpLzaXn+U8UWilvWloQKDDJdGaagQgACHzQCAAA40AP//rJow Date: Thu, 2 Aug 2012 15:50:07 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB036D87@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <20120802154735.GA86274@elstar.local> In-Reply-To: <20120802154735.GA86274@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--46.154900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:50:09 -0000 Hi Juergen, I'm not familiar with how one goes about retrieving interface counters via = NETCONF without formally defining them in a YANG module. Could you please e= laborate? Patrick -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, August 02, 2012 11:48 AM To: Andy Bierman Cc: Patrick Gili (pgili); netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module On Thu, Aug 02, 2012 at 07:56:46AM -0700, Andy Bierman wrote: > On Thu, Aug 2, 2012 at 4:52 AM, Patrick Gili (pgili) wr= ote: > > Hi Martin, > > > > If we take this step, which I am not opposed to, and following your rea= soning, then why not go the full nine yards and come up with a YANG equival= ent of the IF-MIB? > > >=20 > Agreed. This data is too important to rely on SNMP for some of it. > We made a custom YANG version of ifType just to add some=20 > description-stmts. This seems much more important than that. > Perhaps we have learned some things about interface management since=20 > IF-MIB was published, and the direct SMIv2 to YANG translation is not=20 > sufficient. IMO, the scope should lean towards complete management,=20 > not just configuration. >=20 Is redefining all the counters really a high priority activity given that t= here is already a way of retrieving them via NETCONF? /js (speaking as contributor) --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 2 09:04:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793CA21E8048 for ; Thu, 2 Aug 2012 09:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITIu-7iX2RbU for ; Thu, 2 Aug 2012 09:04:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7169621E8045 for ; Thu, 2 Aug 2012 09:04:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C67BA20C06; Thu, 2 Aug 2012 18:04:04 +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 JL6Zk9Q2djtK; Thu, 2 Aug 2012 18:04:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64E5C20C03; Thu, 2 Aug 2012 18:04:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 558142101B11; Thu, 2 Aug 2012 18:04:03 +0200 (CEST) Date: Thu, 2 Aug 2012 18:04:03 +0200 From: Juergen Schoenwaelder To: "Patrick Gili (pgili)" Message-ID: <20120802160402.GA86337@elstar.local> Mail-Followup-To: "Patrick Gili (pgili)" , Andy Bierman , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <20120802154735.GA86274@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB036D87@xmb-aln-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB036D87@xmb-aln-x14.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:04:06 -0000 Hi, See RFC 6643 for the details. If you have smidump, run smidump -f yang and there is the YANG module to use. /js On Thu, Aug 02, 2012 at 03:50:07PM +0000, Patrick Gili (pgili) wrote: > Hi Juergen, > > I'm not familiar with how one goes about retrieving interface counters via NETCONF without formally defining them in a YANG module. Could you please elaborate? > > Patrick > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, August 02, 2012 11:48 AM > To: Andy Bierman > Cc: Patrick Gili (pgili); netmod@ietf.org > Subject: Re: [netmod] comment on ietf-interfaces module > > On Thu, Aug 02, 2012 at 07:56:46AM -0700, Andy Bierman wrote: > > On Thu, Aug 2, 2012 at 4:52 AM, Patrick Gili (pgili) wrote: > > > Hi Martin, > > > > > > If we take this step, which I am not opposed to, and following your reasoning, then why not go the full nine yards and come up with a YANG equivalent of the IF-MIB? > > > > > > > Agreed. This data is too important to rely on SNMP for some of it. > > We made a custom YANG version of ifType just to add some > > description-stmts. This seems much more important than that. > > Perhaps we have learned some things about interface management since > > IF-MIB was published, and the direct SMIv2 to YANG translation is not > > sufficient. IMO, the scope should lean towards complete management, > > not just configuration. > > > > Is redefining all the counters really a high priority activity given that there is already a way of retrieving them via NETCONF? > > /js (speaking as contributor) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 2 09:09:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB1C11E80E5 for ; Thu, 2 Aug 2012 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOID+RAOu3oA for ; Thu, 2 Aug 2012 09:09:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 798E411E808D for ; Thu, 2 Aug 2012 09:09:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C810020C07; Thu, 2 Aug 2012 18:09:06 +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 uh4o4x7o7gC8; Thu, 2 Aug 2012 18:09:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A06A20C06; Thu, 2 Aug 2012 18:09:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E91502101B59; Thu, 2 Aug 2012 18:09:05 +0200 (CEST) Date: Thu, 2 Aug 2012 18:09:05 +0200 From: Juergen Schoenwaelder To: "Patrick Gili (pgili)" Message-ID: <20120802160905.GB86337@elstar.local> Mail-Followup-To: "Patrick Gili (pgili)" , Andy Bierman , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:09:08 -0000 On Thu, Aug 02, 2012 at 03:48:32PM +0000, Patrick Gili (pgili) wrote: > - SMIv2-to-YANG conversion is insufficient for the simple reason > that YANG provides a more robust meta-model for the purpose of > describing "managed data". It would be akin to converting C code > to Java without taking advantage of the object oriented > capabilities supported by the language. Through the decades, the > implementation of MIB modules have presented network equipment > vendors with unique challenges which we have the opportunity to > eliminate, but only if we take the time define YANG modules with > consideration for the robustness of the meta-model, rather than > simply emulating SNMP over NETCONF. I do not buy the comparison. For most of the counters, it does not apply. In fact, even if we redefine them, we won't change their semantics because the instrumentation is often embedded in hardware or OS kernels and that stuff won't change. There are things where redefinitions make sense, I doubt that counters are typically good examples for this. Also note that you do not have to go though SNMP implementation complexities to provide the data via NETCONF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 2 09:12:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EDB11E80BA for ; Thu, 2 Aug 2012 09:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgLJ-Q0DCD12 for ; Thu, 2 Aug 2012 09:12:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF1D11E80A4 for ; Thu, 2 Aug 2012 09:12:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61E9620C07; Thu, 2 Aug 2012 18: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 (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QEGhq2dNYn3k; Thu, 2 Aug 2012 18:12:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0E5620C06; Thu, 2 Aug 2012 18:12:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8C1EA2101C03; Thu, 2 Aug 2012 18:12:01 +0200 (CEST) Date: Thu, 2 Aug 2012 18:12:01 +0200 From: Juergen Schoenwaelder To: "Patrick Gili (pgili)" , Andy Bierman , "netmod@ietf.org" Message-ID: <20120802161201.GC86337@elstar.local> Mail-Followup-To: "Patrick Gili (pgili)" , Andy Bierman , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <20120802154735.GA86274@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB036D87@xmb-aln-x14.cisco.com> <20120802160402.GA86337@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120802160402.GA86337@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:12:08 -0000 On Thu, Aug 02, 2012 at 06:04:03PM +0200, Juergen Schoenwaelder wrote: > Hi, > > See RFC 6643 for the details. If you have smidump, run smidump -f yang > and there is the YANG module to use. Well, to be precise, you need a fairly recent version of smidump to get the correct YANG module that is consistent with RFC 6643. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 2 09:30:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5D811E80E9 for ; Thu, 2 Aug 2012 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i08ZVIUnn+mj for ; Thu, 2 Aug 2012 09:30:09 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id D3BB621F842C for ; Thu, 2 Aug 2012 09:29:58 -0700 (PDT) Received: by qaea16 with SMTP id a16so1356668qae.10 for ; Thu, 02 Aug 2012 09:29:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=pXOj+Wd8Tm3rZ9PO5ZwOeAepa4maO4pE9+MFlTqMEB4=; b=GcacQSoY0fzLvjC6fsNSoziPpAZ9uPgdRMb+45+5X/rqKfiPHDpWlwNHuhlRniZ4lU +uwQY+LKM7cbpDCTyMVjGq/N4lptOuvBqWPaLoTCL7kYadxtonk9tEHE5PnbhwpapD3l 40NAse5ZB2OfHAbrrlRYW4tfn9PNWoAY6Z02JZ6uyDrPMpyR1g1Ey+gPj8u01b3G/7cu JwnpIxLEpXcNCLr07Tj/RxOsVdvhyPDRkE8Fc3TTMZfh9J4tnqMdPSwpZP2lKNwCBqz2 NOZ5bTw0ljparc8xCTl9EvxdBd9/Ny8UowREfe+RBgOKJpC7vFp8xJl/E9PzRKYpzY48 YiMQ== MIME-Version: 1.0 Received: by 10.229.136.129 with SMTP id r1mr11500186qct.21.1343924998097; Thu, 02 Aug 2012 09:29:58 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 09:29:58 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:1822:867:5b3f:ccdc] In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> Date: Thu, 2 Aug 2012 09:29:58 -0700 Message-ID: From: Andy Bierman To: "Patrick Gili (pgili)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkeS3ArsaovN4p3TdPDlLpWVVJdLBzavyYmojNfx8h0vbcsXRGvFeWGb08yBtpOiEN29a1c Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:30:11 -0000 On Thu, Aug 2, 2012 at 8:48 AM, Patrick Gili (pgili) wrot= e: > We've been scratching our heads wondering about the YANG modules currentl= y defined by I-Ds in the NETMOD WG: > > - Why the bias toward configuration? I don't buy this argument that NETCO= NF is for configuration and SNMP for monitoring. If one of our customers or= partners developers a management application with the capability to manage= interfaces, why is it the expectation that use NETCONF for configuration a= nd SNMP for monitoring? If this is not the expectation, then why define sep= arate YANG modules. If I were to develop an API to manage interfaces suppor= ted by a device, I certainly wouldn't define one API for the purpose of con= figuring these interfaces and another API for the purpose of monitoring the= m. > > - Why are we not building on the work done for SNMP-based management? If = we are indeed building on it, then the definitions of the YANG modules don'= t necessarily reflect it. > > - SMIv2-to-YANG conversion is insufficient for the simple reason that YAN= G provides a more robust meta-model for the purpose of describing "managed = data". It would be akin to converting C code to Java without taking advanta= ge of the object oriented capabilities supported by the language. Through t= he decades, the implementation of MIB modules have presented network equipm= ent vendors with unique challenges which we have the opportunity to elimina= te, but only if we take the time define YANG modules with consideration for= the robustness of the meta-model, rather than simply emulating SNMP over N= ETCONF. > +1 I do not understand why we are bothering making a new module for something trivial like ifType because the SMIv2 to YANG translation is not good enough, but for important things like the monitoring data, the direct mapping is supposedly good enough. The ifIndex is not even available if the IF-MIB is not also supported in SNMP. Retrieving 1 table to get ifIndex values and then going to another table to retrieve counters based on ifIndex is non-optimal. Forcing SNMP implementation of the IF-MIB in order to allow the server to expose interface counters in NETCONF is unnecessary. This new ietf-interfaces module should be completely usable on its own, without any requirement for the server to implement SNMP. > Patrick Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, August 02, 2012 10:57 AM > To: Patrick Gili (pgili) > Cc: Martin Bjorklund; netmod@ietf.org > Subject: Re: [netmod] comment on ietf-interfaces module > > On Thu, Aug 2, 2012 at 4:52 AM, Patrick Gili (pgili) wr= ote: >> Hi Martin, >> >> If we take this step, which I am not opposed to, and following your reas= oning, then why not go the full nine yards and come up with a YANG equivale= nt of the IF-MIB? >> > > Agreed. This data is too important to rely on SNMP for some of it. > We made a custom YANG version of ifType just to add some description-stmt= s. This seems much more important than that. > Perhaps we have learned some things about interface management since IF-M= IB was published, and the direct SMIv2 to YANG translation is not sufficien= t. IMO, the scope should lean towards complete management, not just config= uration. > > >> Patrick >> > > Andy > >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >> Behalf Of Martin Bjorklund >> Sent: Wednesday, August 01, 2012 6:47 PM >> To: netmod@ietf.org >> Subject: Re: [netmod] comment on ietf-interfaces module >> >> Hi, >> >> It seems people want to add the config false "if stack" objects proposed= below: >> >> Martin Bjorklund wrote: >>> leaf-list subordinate-if { ... } >>> leaf-list superior-if { ... } >> >> If we add this, I suggest we also add a leaf if-oper-status, with the sa= me syntax and semantics as ifOperStatus, so that clients doesn't have to re= ly on the MIB data for this rather important object. >> >> >> /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 j.schoenwaelder@jacobs-university.de Thu Aug 2 09:33:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779FC21F842E for ; Thu, 2 Aug 2012 09:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-9Z-wpRFmQf for ; Thu, 2 Aug 2012 09:33:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BF8DB11E80F4 for ; Thu, 2 Aug 2012 09:33:25 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D90B20C14; Thu, 2 Aug 2012 18:33:25 +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 Ua1E70LtqR-e; Thu, 2 Aug 2012 18:33:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B04FC20BDE; Thu, 2 Aug 2012 18:33:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 159D12101E61; Thu, 2 Aug 2012 18:33:24 +0200 (CEST) Date: Thu, 2 Aug 2012 18:33:23 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120802163323.GA86561@elstar.local> Mail-Followup-To: Andy Bierman , "Patrick Gili (pgili)" , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:33:26 -0000 On Thu, Aug 02, 2012 at 09:29:58AM -0700, Andy Bierman wrote: > > I do not understand why we are bothering making a new module > for something trivial like ifType because the SMIv2 to YANG translation > is not good enough, but for important things like the monitoring > data, the direct mapping is supposedly good enough. Lets recall, the interface type is needed for type specific interface augmentations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From pgili@cisco.com Thu Aug 2 09:35:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42DB11E80E9 for ; Thu, 2 Aug 2012 09:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtgj5OB8Gck0 for ; Thu, 2 Aug 2012 09:35:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EC9A121F844F for ; Thu, 2 Aug 2012 09:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=2451; q=dns/txt; s=iport; t=1343925328; x=1345134928; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eCm87uuX1q79l6YgWc4XaPvWQOKDrRFvUh6jUK136LA=; b=EpeDObWQc96CfFEu8m6jk0KCDER1FxOt0RQ+cd98RvGizQl74rNk4eDA yBYuYX1EaC03pSlbFazj/eWHaiHWrK9ihDMDoDaaevCKMS66nwBVwvD+s /2A81CW2AVJLKfABgz+BebpJdpyvd/juNOFXRFAQ5CL055DPpO1A6cMu9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA2sGlCtJV2Y/2dsb2JhbABCA7kYgQeCIAEBAQQSASc3CAwCAgIBCA4CAQQBAQsUCQcbFxQJCAIEDgUIGodrnGagUASLRoNjgkFgA6NugWaCXw X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107888980" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 02 Aug 2012 16:35:17 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72GZH7H003529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 16:35:17 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.239]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 11:35:16 -0500 From: "Patrick Gili (pgili)" To: Juergen Schoenwaelder Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNcDeBpLzaXn+U8UWilvWloQKDDJdGaagQgACHzQD//7eD4IAAXLGA//+xkXA= Date: Thu, 2 Aug 2012 16:35:17 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB036E49@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> <20120802160905.GB86337@elstar.local> In-Reply-To: <20120802160905.GB86337@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--35.759500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:35:28 -0000 I have a lot of problems with this approach: 1) We are relying on vendors/partners/customers to perform this conversion,= and while there is an RFC defining this translation, who is to guarantee t= hat all implementations result in the same YANG module? 2) There is a lot of potential for overlap with YANG modules defined by sta= ndards bodies, such as the IETF and IEEE. Consider the example we're discus= sing in this thread. If I run the IF-MIB through a translator to generate a= YANG module, then there is certainly a lot of overlap with ietf-interfaces= YANG module. Worse, the keys are different. 3) When done, I still don't have a formal, standards document defining a YA= NG module describing interface counters. Patrick -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, August 02, 2012 12:09 PM To: Patrick Gili (pgili) Cc: Andy Bierman; netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module On Thu, Aug 02, 2012 at 03:48:32PM +0000, Patrick Gili (pgili) wrote: > - SMIv2-to-YANG conversion is insufficient for the simple reason > that YANG provides a more robust meta-model for the purpose of > describing "managed data". It would be akin to converting C code > to Java without taking advantage of the object oriented > capabilities supported by the language. Through the decades, the > implementation of MIB modules have presented network equipment > vendors with unique challenges which we have the opportunity to > eliminate, but only if we take the time define YANG modules with > consideration for the robustness of the meta-model, rather than > simply emulating SNMP over NETCONF. I do not buy the comparison. For most of the counters, it does not apply. I= n fact, even if we redefine them, we won't change their semantics because t= he instrumentation is often embedded in hardware or OS kernels and that stu= ff won't change. There are things where redefinitions make sense, I doubt that counters are = typically good examples for this. Also note that you do not have to go thou= gh SNMP implementation complexities to provide the data via NETCONF. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 2 09:45:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0058A21E8063 for ; Thu, 2 Aug 2012 09:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yWwxg9Zl6C9 for ; Thu, 2 Aug 2012 09:45:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0116C21E805A for ; Thu, 2 Aug 2012 09:45:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5478C20C16; Thu, 2 Aug 2012 18:45:56 +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 q0MulExrLZKR; Thu, 2 Aug 2012 18:45:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAA9320C15; Thu, 2 Aug 2012 18:45:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A41F12101F56; Thu, 2 Aug 2012 18:45:54 +0200 (CEST) Date: Thu, 2 Aug 2012 18:45:54 +0200 From: Juergen Schoenwaelder To: "Patrick Gili (pgili)" Message-ID: <20120802164553.GB86593@elstar.local> Mail-Followup-To: "Patrick Gili (pgili)" , Andy Bierman , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> <20120802160905.GB86337@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB036E49@xmb-aln-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB036E49@xmb-aln-x14.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:45:58 -0000 On Thu, Aug 02, 2012 at 04:35:17PM +0000, Patrick Gili (pgili) wrote: > I have a lot of problems with this approach: > > 1) We are relying on vendors/partners/customers to perform this conversion, and while there is an RFC defining this translation, who is to guarantee that all implementations result in the same YANG module? > > 2) There is a lot of potential for overlap with YANG modules defined by standards bodies, such as the IETF and IEEE. Consider the example we're discussing in this thread. If I run the IF-MIB through a translator to generate a YANG module, then there is certainly a lot of overlap with ietf-interfaces YANG module. Worse, the keys are different. > > 3) When done, I still don't have a formal, standards document defining a YANG module describing interface counters. > There is a standard for the input and a standard for the translation. If needed, someone can perhaps post the translation result on a common public place to help people. The value here is that you can start today - no need to wait for yangification of > 100 IETF MIB modules and the publication of corresponding RFCs. And if needed, one can even write tools that automate the implementation by generating the code hooking into existing SNMP instrumentation. Of course, this is implementation specific. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From pgili@cisco.com Thu Aug 2 09:56:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9644121E80C2 for ; Thu, 2 Aug 2012 09:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vkTNwd+G6Ov for ; Thu, 2 Aug 2012 09:56:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A723321E80C1 for ; Thu, 2 Aug 2012 09:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=3063; q=dns/txt; s=iport; t=1343926567; x=1345136167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N0qHLVWE4jM4bo/kzHT9ci1QDCDFcrpSqYhuIH/nDMg=; b=BbNLUGK1lHqeHDiI/w3y5NxgMJom8pzngvL+FQNXsBRGzY1CorR8WkdO 24xLVgL5Fvfh9UG8T+dBQjmCL1XSIQP0diLuDdEjxiSWfWsslSfmLb6mu b5UBfk9i39zBwPzIKfqdUGSODH76ukhIJf1mnyrQW3SqCKJ3PU0RXkJEP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAESwGlCtJXG9/2dsb2JhbABCA7kYgQeCIAEBAQQSASc3CAwCAgIBCA4CAQQBAQEKFAkHGxcUCQgCBA4FCBqHa5xwoFMEi0aDY4JBYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107924799" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2012 16:56:07 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q72Gu7ug011014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 16:56:07 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.239]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 11:56:06 -0500 From: "Patrick Gili (pgili)" To: Juergen Schoenwaelder Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNcDeBpLzaXn+U8UWilvWloQKDDJdGaagQgACHzQD//7eD4IAAXLGA//+xkXCAAFi5AP//rMsQ Date: Thu, 2 Aug 2012 16:56:05 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB0376D9@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> <20120802160905.GB86337@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB036E49@xmb-aln-x14.cisco.com> <20120802164553.GB86593@elstar.local> In-Reply-To: <20120802164553.GB86593@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--38.729700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:56:08 -0000 Juergen, I'm not arguing the value of having a SMIv2-to-YANG translator, so much as = I'm questioning the approach we're taking to define YANG modules. As long a= s we're defining a YANG module for the purpose of describing the common man= agement data relating to network interfaces, why not make the effort to do = it right. In the meantime, someone waiting for the IEEE to crank out an Eth= erlike YANG module using smidump. However, when the IEEE does eventually de= fine an Etherlike YANG module, I hope that use the robustness of YANG and p= roperly augment the ietf-interfaces YANG module. However, it still raises questions when namespaces aren't aligned. For exam= ple, interface-related MIB modules uniquely identifies interfaces using ifI= ndex, while the ietf-interfaces YANG module uniquely identifies interfaces = using an interface's name. An Andy raises an appropriate question regarding devices that implement the= IF-MIB (or maybe they forego SNMP altogether). I notice a lot of discussio= n regarding "constrained devices". Personally, if I had to start making dec= isions based on memory footprint, SNMP would be at the top of my list of fe= atures to punt. Patrick -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, August 02, 2012 12:46 PM To: Patrick Gili (pgili) Cc: Andy Bierman; netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module On Thu, Aug 02, 2012 at 04:35:17PM +0000, Patrick Gili (pgili) wrote: > I have a lot of problems with this approach: >=20 > 1) We are relying on vendors/partners/customers to perform this conversio= n, and while there is an RFC defining this translation, who is to guarantee= that all implementations result in the same YANG module? >=20 > 2) There is a lot of potential for overlap with YANG modules defined by s= tandards bodies, such as the IETF and IEEE. Consider the example we're disc= ussing in this thread. If I run the IF-MIB through a translator to generate= a YANG module, then there is certainly a lot of overlap with ietf-interfac= es YANG module. Worse, the keys are different. >=20 > 3) When done, I still don't have a formal, standards document defining a = YANG module describing interface counters. >=20 There is a standard for the input and a standard for the translation. If needed, someone can perhaps post the translation result on a common publ= ic place to help people. The value here is that you can start today - no ne= ed to wait for yangification of > 100 IETF MIB modules and the publication = of corresponding RFCs. And if needed, one can even write tools that automat= e the implementation by generating the code hooking into existing SNMP inst= rumentation. Of course, this is implementation specific. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 2 10:03:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A821C21E80CD for ; Thu, 2 Aug 2012 10:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbJDPCkUAw7f for ; Thu, 2 Aug 2012 10:03:18 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE02E11E80A2 for ; Thu, 2 Aug 2012 10:03:17 -0700 (PDT) Received: by qcac10 with SMTP id c10so6019332qca.31 for ; Thu, 02 Aug 2012 10:03:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=VYq1k5ssO+lfhO/8+ZofUQiMEVBuQ8b1R6G0/gIQOUk=; b=WhXtKDI5xd1JZgHvgOfiOnMrA5vuLCn9AcRWKUD4BP6IT7yKNI8TkcnOWh9/nhh0Xq 4eBPtzOPk1WL47kfb+6fidnl+oz4hwXhPcxAUqOE6SJQM2FgYw2+cNBvQEl4L2KakmCa 54pGx5yTl8c5QkftuNHFe14qzi7qJJsaMFPYO/t6q5E6qVVuzzr7HgfLqHRKHzyPO87R eH9ad6fMMEAEm0CgxWui4Z+Hta9rCx9Nci7F0XYG4vvvyX4/zl3PGnJnY+T9nWxlV+i6 qxCljhzudXLTQegoxvM3wnMOBH7QeO5XOc+oHDtfy7IKAkflhbaOBYgv1suldSqWa2H0 ZZEA== MIME-Version: 1.0 Received: by 10.229.134.213 with SMTP id k21mr2200151qct.106.1343926997361; Thu, 02 Aug 2012 10:03:17 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 10:03:17 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:e55b:8747:ab19:155b] In-Reply-To: <20120802163323.GA86561@elstar.local> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> <20120802163323.GA86561@elstar.local> Date: Thu, 2 Aug 2012 10:03:17 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Patrick Gili (pgili)" , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl/COf8iMO0rrrmEMzNcEZTHnw1hu+kJREaEIqCfSOCiSbezf/3qB0CKB1qZD8bit3zMGrL Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:03:19 -0000 On Thu, Aug 2, 2012 at 9:33 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 02, 2012 at 09:29:58AM -0700, Andy Bierman wrote: >> >> I do not understand why we are bothering making a new module >> for something trivial like ifType because the SMIv2 to YANG translation >> is not good enough, but for important things like the monitoring >> data, the direct mapping is supposedly good enough. > > Lets recall, the interface type is needed for type specific interface > augmentations. So you are making Patrick's point. We could rely on the SMIv2 translation of IANAifType-MIB and not publish the iana-if-type.yang module. IMO, it is unacceptable to rely on the existence of IF-MIB in order to retrieve interface counters. I think this will become more true over time, not less. Assuming all NETCONF servers are co-located with SNMP agents is not a good idea for the long-term. The IF-MIB translation does not put counters in the /interfaces/interface list entry. It is a completely different data structure, so it is not good enough. > > /js Andy From pgili@cisco.com Thu Aug 2 10:07:20 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D439521E80C0 for ; Thu, 2 Aug 2012 10:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3nYW4k5Wh1N for ; Thu, 2 Aug 2012 10:07:19 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2554521E8090 for ; Thu, 2 Aug 2012 10:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=2292; q=dns/txt; s=iport; t=1343927239; x=1345136839; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OXjf+VEg1WKGzKvaNOB1q09yp7DpUIJDltkhLdrKNbc=; b=ScjX2vapQypRTZOJM0XlAk2Sf9pOzHZWA/cRkRblxqZaIhzNCoHSCqT7 vk9ZInp5VN+SvyjD0PamapzraB8mnxax5CocDLkEhBbsLkmVImcFl/GR9 h6VU8ZedzW6ThgdkJa273KP7NoF/HL/8REx+Ksqaj34TR94wL14wMdY2j g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOiyGlCtJV2b/2dsb2JhbABFhXuyKnOBB4IgAQEBBBIBEBFRBAIBCBABBAEBAQICBh0DAgICMBQBCAgCBAESCBqHa5xpjRmTO4EhiimFcjJgA6NugWaCXw X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107910281" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 02 Aug 2012 17:07:18 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q72H7I9i023927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 17:07:18 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.239]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 12:07:18 -0500 From: "Patrick Gili (pgili)" To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNcDeBpLzaXn+U8UWilvWloQKDDJdGaagQgACHzQD//7eD4IAAYocAgAAA9ICAAAhbgP//rJ7A Date: Thu, 2 Aug 2012 17:07:18 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB037709@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> <20120802163323.GA86561@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--28.244200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:07:20 -0000 VGhlcmUgYXJlIGFscmVhZHkgImNvbnN0cmFpbmVkIGRldmljZXMiIG9uIHRoZSBtYXJrZXQgdGhh dCBoYXZlIG1hZGUgdGhlIGNob2ljZSwgYW5kIHRoZXkgaGF2ZSBkZWNpZGVkIHRvIGdvIHdpdGgg TkVUQ09ORiBvciBSRVNUIGludGVyZmFjZXMgb3ZlciBTTk1QLiBTdWNoIGRldmljZXMgd291bGQg YmUgYXQgY2VydGFpbiBkaXNhZHZhbnRhZ2UgaWYgdGhleSBoYWQgdG8gcmVseSBvbiBZQU5HIG1v ZHVsZXMgdGhhdCB3ZXJlIG1lcmVseSBhIHRyYW5zbGF0aW9uIG9mIE1JQiBtb2R1bGVzLg0KDQpQ YXRyaWNrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbmR5IEJpZXJtYW4g W21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dIA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwMiwg MjAxMiAxOjAzIFBNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBBbmR5IEJpZXJtYW47IFBh dHJpY2sgR2lsaSAocGdpbGkpOyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9k XSBjb21tZW50IG9uIGlldGYtaW50ZXJmYWNlcyBtb2R1bGUNCg0KT24gVGh1LCBBdWcgMiwgMjAx MiBhdCA5OjMzIEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+IE9uIFRodSwgQXVnIDAyLCAyMDEyIGF0IDA5OjI5 OjU4QU0gLTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZToNCj4+DQo+PiBJIGRvIG5vdCB1bmRlcnN0 YW5kIHdoeSB3ZSBhcmUgYm90aGVyaW5nIG1ha2luZyBhIG5ldyBtb2R1bGUgZm9yIA0KPj4gc29t ZXRoaW5nIHRyaXZpYWwgbGlrZSBpZlR5cGUgYmVjYXVzZSB0aGUgU01JdjIgdG8gWUFORyB0cmFu c2xhdGlvbiANCj4+IGlzIG5vdCBnb29kIGVub3VnaCwgYnV0IGZvciBpbXBvcnRhbnQgdGhpbmdz IGxpa2UgdGhlIG1vbml0b3JpbmcgDQo+PiBkYXRhLCB0aGUgZGlyZWN0IG1hcHBpbmcgaXMgc3Vw cG9zZWRseSBnb29kIGVub3VnaC4NCj4NCj4gTGV0cyByZWNhbGwsIHRoZSBpbnRlcmZhY2UgdHlw ZSBpcyBuZWVkZWQgZm9yIHR5cGUgc3BlY2lmaWMgaW50ZXJmYWNlIA0KPiBhdWdtZW50YXRpb25z Lg0KDQoNClNvIHlvdSBhcmUgbWFraW5nIFBhdHJpY2sncyBwb2ludC4NCldlIGNvdWxkIHJlbHkg b24gdGhlIFNNSXYyIHRyYW5zbGF0aW9uIG9mIElBTkFpZlR5cGUtTUlCIGFuZCBub3QgcHVibGlz aCB0aGUgaWFuYS1pZi10eXBlLnlhbmcgbW9kdWxlLg0KDQpJTU8sIGl0IGlzIHVuYWNjZXB0YWJs ZSB0byByZWx5IG9uIHRoZSBleGlzdGVuY2Ugb2YgSUYtTUlCIGluIG9yZGVyIHRvIHJldHJpZXZl IGludGVyZmFjZSBjb3VudGVycy4gIEkgdGhpbmsgdGhpcyB3aWxsIGJlY29tZSBtb3JlIHRydWUg b3ZlciB0aW1lLCBub3QgbGVzcy4gIEFzc3VtaW5nIGFsbCBORVRDT05GIHNlcnZlcnMgYXJlIGNv LWxvY2F0ZWQgd2l0aCBTTk1QIGFnZW50cyBpcyBub3QgYSBnb29kIGlkZWEgZm9yIHRoZSBsb25n LXRlcm0uDQoNClRoZSBJRi1NSUIgdHJhbnNsYXRpb24gZG9lcyBub3QgcHV0IGNvdW50ZXJzIGlu IHRoZSAvaW50ZXJmYWNlcy9pbnRlcmZhY2UgbGlzdCBlbnRyeS4gIEl0IGlzIGEgY29tcGxldGVs eSBkaWZmZXJlbnQgZGF0YSBzdHJ1Y3R1cmUsIHNvIGl0IGlzIG5vdCBnb29kIGVub3VnaC4NCg0K DQo+DQo+IC9qcw0KDQpBbmR5DQo= From j.schoenwaelder@jacobs-university.de Thu Aug 2 10:14:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B33E11E8170 for ; Thu, 2 Aug 2012 10:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSU9RdkPbMTi for ; Thu, 2 Aug 2012 10:14:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15E11E8153 for ; Thu, 2 Aug 2012 10:14:39 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C87220BF4; Thu, 2 Aug 2012 19:14:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Sx4Uu6DsVNm4; Thu, 2 Aug 2012 19:14:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2679020BEE; Thu, 2 Aug 2012 19:14:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1823A210222E; Thu, 2 Aug 2012 19:14:35 +0200 (CEST) Date: Thu, 2 Aug 2012 19:14:35 +0200 From: Juergen Schoenwaelder To: "Patrick Gili (pgili)" Message-ID: <20120802171435.GA86714@elstar.local> Mail-Followup-To: "Patrick Gili (pgili)" , Andy Bierman , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> <20120802163323.GA86561@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB037709@xmb-aln-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB037709@xmb-aln-x14.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:14:40 -0000 On Thu, Aug 02, 2012 at 05:07:18PM +0000, Patrick Gili (pgili) wrote: > There are already "constrained devices" on the market that have made the choice, and they have decided to go with NETCONF or REST interfaces over SNMP. Such devices would be at certain disadvantage if they had to rely on YANG modules that were merely a translation of MIB modules. You can implement these YANG modules however you like. There is no required dependency on SNMP. I am fine accepting your standpoint, but I do not buy the implementation complexity arguments etc. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 2 10:24:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDD711E8186 for ; Thu, 2 Aug 2012 10:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utbyBUf9L0rG for ; Thu, 2 Aug 2012 10:24:46 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18FA811E8184 for ; Thu, 2 Aug 2012 10:24:45 -0700 (PDT) Received: by qcac10 with SMTP id c10so6044237qca.31 for ; Thu, 02 Aug 2012 10:24:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=nP8ECQZNtklPr8H3r2fi8IfPSGac2vmgs7qXVgSwGFo=; b=nS8QmcX583bWMjzoubJlqKxhJ4Pt7pGScu9NlO5TbkXWMJcFkqzyh1epykegU0fY24 syGgV7Csu7YsDxnmaDA6nTOrg2PzSjOjcosjHjv9l/0+B1lyycVQuLiecvQVdXaXO+dJ fwwhF/EfxfDruqTCu+9e80v6d9trVQtIgNQhA0R+hvOrd0GzHwZJhT2s0lZEFDMdk6Kw HkWBG4EsobZmG+1tLyYENhteUFLK3Kqv2d0/1XBtUKWzfU1H2kqfhyOQVWke50soUH1H n3cAqblZ7EiSRCL2G3mUhkj9CBMWHzTvYdOmKOChlsnONvFsc5kGGeFsrQXt0VHrwGrH qKQA== MIME-Version: 1.0 Received: by 10.224.35.130 with SMTP id p2mr42970516qad.21.1343928285562; Thu, 02 Aug 2012 10:24:45 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 10:24:45 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:e55b:8747:ab19:155b] In-Reply-To: <20120802171435.GA86714@elstar.local> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> <20120802163323.GA86561@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB037709@xmb-aln-x14.cisco.com> <20120802171435.GA86714@elstar.local> Date: Thu, 2 Aug 2012 10:24:45 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Patrick Gili (pgili)" , Andy Bierman , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm5l1BrfXbnSKAwsDU/84//Os2qSzxH1Dj5haX3xra4b1CVCbk+aNDxFzEkNQOxkkyiSFQ6 Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:24:46 -0000 On Thu, Aug 2, 2012 at 10:14 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 02, 2012 at 05:07:18PM +0000, Patrick Gili (pgili) wrote: >> There are already "constrained devices" on the market that have made the= choice, and they have decided to go with NETCONF or REST interfaces over S= NMP. Such devices would be at certain disadvantage if they had to rely on Y= ANG modules that were merely a translation of MIB modules. > > You can implement these YANG modules however you like. There is no > required dependency on SNMP. I am fine accepting your standpoint, but > I do not buy the implementation complexity arguments etc. But we are supposed to buy these arguments to justify NETCONF Light? Vendors will end up ignoring what this module says and augmenting the interface list entry with counters in their own namespace. Protocol performance and efficiency have always been a concern of vendors and pretending it is not an issue won't work. > > /js Andy From jeffrey.K.lange@ge.com Thu Aug 2 10:27:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F17711E80D1 for ; Thu, 2 Aug 2012 10:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amKcC4ywuAhX for ; Thu, 2 Aug 2012 10:27:45 -0700 (PDT) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id 748B611E817C for ; Thu, 2 Aug 2012 10:27:45 -0700 (PDT) Received: from cinmlip11.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKUBq4kNsjEeYgusuWEFCoizS9BKJAEZ0d@postini.com; Thu, 02 Aug 2012 10:27:45 PDT Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by cinmlip11.e2k.ad.ge.com with ESMTP; 02 Aug 2012 13:27:43 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 13:27:43 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 13:27:41 -0400 Received: from CINMBAPD02.e2k.ad.ge.com (3.159.212.68) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 2 Aug 2012 13:27:39 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBAPD02.e2k.ad.ge.com ([169.254.8.57]) with mapi id 14.02.0283.003; Thu, 2 Aug 2012 13:27:39 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman , Juergen Schoenwaelder , "Patrick Gili (pgili)" , "netmod@ietf.org" Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNbpZBQt5RBp6L1kOv85u5YHECdZdClmwAgAACpICAAAXyAIAAAmOAgAAhk4CAALKuAIAAXCKAgAIDHACAANuDAIAAM40AgAAOdgCAAAuUAIAAAPSAgAAIW4CAAAEfAIAAAgmAgAAC14D//716oA== Date: Thu, 2 Aug 2012 17:27:38 +0000 Message-ID: References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120801.154636.148603434.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02A585@xmb-aln-x14.cisco.com> <50E64ADF99EAEE4CACEC18958F0FC0AB036564@xmb-aln-x14.cisco.com> <20120802163323.GA86561@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB037709@xmb-aln-x14.cisco.com> <20120802171435.GA86714@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Aug 2012 17:27:41.0542 (UTC) FILETIME=[1EC81860:01CD70D4] Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:27:46 -0000 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, August 02, 2012 1:25 PM > To: Juergen Schoenwaelder; Patrick Gili (pgili); Andy Bierman; > netmod@ietf.org > Subject: Re: [netmod] comment on ietf-interfaces module >=20 > On Thu, Aug 2, 2012 at 10:14 AM, Juergen Schoenwaelder > wrote: > > On Thu, Aug 02, 2012 at 05:07:18PM +0000, Patrick Gili (pgili) wrote: > >> There are already "constrained devices" on the market that have made t= he > choice, and they have decided to go with NETCONF or REST interfaces over > SNMP. Such devices would be at certain disadvantage if they had to rely o= n > YANG modules that were merely a translation of MIB modules. > > > > You can implement these YANG modules however you like. There is no > > required dependency on SNMP. I am fine accepting your standpoint, but > > I do not buy the implementation complexity arguments etc. >=20 > But we are supposed to buy these arguments to justify NETCONF Light? > Vendors will end up ignoring what this module says and augmenting the > interface list entry with counters in their own namespace. As a point of reference, this is exactly what I have done for the current s= ystem I am working on, as it does not have any SNMP support. -Jeff > Protocol performance and efficiency have always been a concern of vendors > and pretending it is not an issue won't work. >=20 > > > > /js >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Thu Aug 2 16:00:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBA11E8155 for ; Thu, 2 Aug 2012 16:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWJG99CXgFoA for ; Thu, 2 Aug 2012 16:00:22 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 80CCA11E810D for ; Thu, 2 Aug 2012 16:00:19 -0700 (PDT) Received: from localhost (dhcp-133c.meeting.ietf.org [130.129.19.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 074031200D78 for ; Fri, 3 Aug 2012 01:00:17 +0200 (CEST) Date: Thu, 02 Aug 2012 16:00:15 -0700 (PDT) Message-Id: <20120802.160015.289535832.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:00:23 -0000 Hi, I got the following comments from an off-line reviewer, called ps below. ps> feature "non-contiguous-netmasks" should be called ps> "ipv4-non-contiguous-netmasks", since it is ipv4-specific. I think this make sense. ps> container ipv4 and ipv6 should be presence containers, since ps> otherwise both ipv4 and ipv6 are enabled by default. This is an important point. The question to the WG is if these address families should be enabled by default or not. I think this was discussed at some point, but I cannot find this in the archives now. ps> list "neighbor" should be called "static-address-map" I do not have a strong preference; I used "neighbor" b/c it is called Neighbor Cache in ipv6. "static-address-map" might be a better name if we want to augment it with (static) proxy arp entries in some future... Comments from the WG? ps> since RFC 4941 is optional to implement, we should add a feature ps> and use if-feature in the leafs from this rfc. I think this makes sense, and propose: feature ipv6-privacy-autoconf { description "Indicates support for Privacy Extensions for Stateless Address Autoconfiguration in IPv6."; reference "RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6"; } ps> the leafs "create-global-addresses" and "create-temporary-address" ps> should be named in singular. My reading of RFC 4862 is that there can actually be multiple global (and thus temporary) addresses per interface. /martin From lhotka@nic.cz Thu Aug 2 16:10:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5311E81CD for ; Thu, 2 Aug 2012 16:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-n2mwZ091Jb for ; Thu, 2 Aug 2012 16:10:57 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 44F4B11E81CB for ; Thu, 2 Aug 2012 16:10:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 591F9540436; Fri, 3 Aug 2012 01:10:54 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJj1RKpzRef0; Fri, 3 Aug 2012 01:10:49 +0200 (CEST) Received: from localhost (dhcp-16a6.meeting.ietf.org [130.129.22.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6D09E5400CB; Fri, 3 Aug 2012 01:10:47 +0200 (CEST) From: Ladislav Lhotka To: "t.petch" , "Yi Yang \(yiya\)" In-Reply-To: <006701cd70b7$4f0b9e60$4001a8c0@gateway.2wire.net> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> <006701cd70b7$4f0b9e60$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "t.petch" , "Yi Yang \(yiya\)" , netmod@ietf.org Date: Thu, 02 Aug 2012 16:10:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:10:58 -0000 "t.petch" writes: > > In a sense I agree with you, in a sense I think the exact opposite. > > This topic of what tables there are in a box that routes packets has > surfaced before. I see, in a typical I-D produced about routing, > reference to FIB and RIB, without any need to define or explain the > terms, they are that well known, they are what routers and other boxes > have as a matter or course. Yes, it's been my problem that I couldn't find a precise definition of these acronyms, and I understand most routing experts use the definition "you know it when you see it". > > For me, it is the FIB that is always present; if you do not know where > to send a packet, how to route it, then you are not an IP box of any > shape or form - you must have a FIB.. In simple boxes, like Linux or > Windows, then that is all you have. > > In more sophisticated boxes, 'proper' routers, for some meaning of the > word proper, then you need much more data, which may closely model the > FIB, as with RIP, or may be utterly different, as with OSPF, and for > this, I see the term RIB used, initially with BGP but latterly with any > routing protocol. RIBs vary widely with the routing protocol and so are > properly part of routing protocol extensions. So at the level of the present core routing model we are dealing with FIBs, but as soon as a BGP module augments routes with that sophisticated stuff a FIB gets promoted to a RIB, right? But this may be quite confusing from the point of view of the I-D text, and in this case I would probably prefer to avoid these acronyms entirely and use only "routing table". > > So I think that this I-D gets the terminology quite wrong; as I say, > this has surfaced before without any visible change to the I-D. I was > surprised that this topic attracted no comment from the Routing > Directorate. Can you suggest what to do in order to get the terminology right? Anyway, I think that Yi Yang's comments were about "forwarding table", i.e. a (simplified) routing table which by definition contains only active routes. Thanks, Lada > > Tom Petch > > Yi > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Aug 2 16:15:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67ABE21E8043 for ; Thu, 2 Aug 2012 16:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-rCre9qDiwd for ; Thu, 2 Aug 2012 16:15:11 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C15D321E8039 for ; Thu, 2 Aug 2012 16:15:11 -0700 (PDT) Received: from localhost (dhcp-133c.meeting.ietf.org [130.129.19.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 687F71200D78 for ; Fri, 3 Aug 2012 01:15:10 +0200 (CEST) Date: Thu, 02 Aug 2012 16:15:06 -0700 (PDT) Message-Id: <20120802.161506.153811452.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20120801.150207.342849426.mbj@tail-f.com> References: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> <20120801.150207.342849426.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] configuration source (Was: I-D Action: draft-ietf-netmod-system-mgmt-01.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:15:12 -0000 Hi, I wonder if the config-source is such a good idea. There are a bunch of DHCP options, and as soon as we define an object that also can be set using DHCP, we'd have to have a config-source equivalent. For example, in the ip-model we have: leaf ip-forwarding { ... } list address { ... } Now, you can of course get the ip address over dhcp, so we could do: leaf ip-forwarding { ... } list address { ... } uses config-source; // possibly set ip address from dhcp But RFC 2132 also specifies an DHCP option to control ip forwarding. So we'd have to do: container ip-forwarding { leaf enabled { ... } uses config-source; } container addresses { list address { ... } uses config-source; } Not very pretty. There's also an Interface MTU option (hmm). For the routing draft there's an option for static routes. Further, for the system draft, there are options in RFC 4833 to set the timezone using dhcp. So we have to add it in one more place. These are the alternatives I see: 1. For each parameter that can be set over dhcp, make sure to include a config-source. - This does not really work since the set of DHCP options really is open ended. 2. Drop the config-source idea and configure which dhcp options to use in the upcoming dhcp client module. 3. A mix of 1 & 2 - use config-source only for some "common" objects (dns, ip address, ntp), but use 2 for other options. - Inconsistent, and difficult to define what "common" means. So I propose solution 2 - drop the idea of a configuration source leaf (i.e. remove it from the system draft), and leave it to a dhcp client model (or whatever) to introduce proper enable/disable toggles and to clarify how it interacts with local config (e.g., enabling DHCP overwrites the usage of local config if DHCP is successful). /martin From j.schoenwaelder@jacobs-university.de Thu Aug 2 16:30:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA6821F8AD8 for ; Thu, 2 Aug 2012 16:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0iWjSzPTZDw for ; Thu, 2 Aug 2012 16:30:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC9D11E81EA for ; Thu, 2 Aug 2012 16:30:01 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F7C120C03; Fri, 3 Aug 2012 01:30:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GJh_37EZSdXz; Fri, 3 Aug 2012 01:30:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBEF520C02; Fri, 3 Aug 2012 01:29:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 94B7F2102DD1; Fri, 3 Aug 2012 01:29:58 +0200 (CEST) Date: Fri, 3 Aug 2012 01:29:57 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120802232957.GA87351@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> <20120801.150207.342849426.mbj@tail-f.com> <20120802.161506.153811452.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120802.161506.153811452.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] configuration source (Was: I-D Action: draft-ietf-netmod-system-mgmt-01.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:30:03 -0000 On Thu, Aug 02, 2012 at 04:15:06PM -0700, Martin Bjorklund wrote: > These are the alternatives I see: > > 1. For each parameter that can be set over dhcp, make sure to > include a config-source. > > - This does not really work since the set of DHCP options really > is open ended. > > 2. Drop the config-source idea and configure which dhcp options to > use in the upcoming dhcp client module. > > 3. A mix of 1 & 2 - use config-source only for some "common" > objects (dns, ip address, ntp), but use 2 for other options. > > - Inconsistent, and difficult to define what "common" means. > > > So I propose solution 2 - drop the idea of a configuration source leaf > (i.e. remove it from the system draft), and leave it to a dhcp client > model (or whatever) to introduce proper enable/disable toggles and to > clarify how it interacts with local config (e.g., enabling DHCP > overwrites the usage of local config if DHCP is successful). I agree. /js (speaking as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 2 16:37:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAF611E80F0 for ; Thu, 2 Aug 2012 16:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SwCm+3YsozG for ; Thu, 2 Aug 2012 16:37:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA3611E8072 for ; Thu, 2 Aug 2012 16:37:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD78C20C03; Fri, 3 Aug 2012 01:37:25 +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 nrpI1763UwKq; Fri, 3 Aug 2012 01:37:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BF9620C02; Fri, 3 Aug 2012 01:37:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BF32E2102E21; Fri, 3 Aug 2012 01:37:24 +0200 (CEST) Date: Fri, 3 Aug 2012 01:37:24 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120802233724.GB87351@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120802.160015.289535832.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120802.160015.289535832.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:37:27 -0000 On Thu, Aug 02, 2012 at 04:00:15PM -0700, Martin Bjorklund wrote: > Hi, > > I got the following comments from an off-line reviewer, called ps > below. > > ps> feature "non-contiguous-netmasks" should be called > ps> "ipv4-non-contiguous-netmasks", since it is ipv4-specific. > > I think this make sense. ack > ps> container ipv4 and ipv6 should be presence containers, since > ps> otherwise both ipv4 and ipv6 are enabled by default. > > This is an important point. The question to the WG is if > these address families should be enabled by default or not. I think > this was discussed at some point, but I cannot find this in the > archives now. Now that we are sunsetting ipv4... ;-) I think there are enabled leafs so I think the question boils down to whether the default is true or false and not whether we need presence containers. That said, I assume either both true or both false are the options we really have. What is the concern with the both true defaults? > ps> list "neighbor" should be called "static-address-map" > > I do not have a strong preference; I used "neighbor" b/c it is called > Neighbor Cache in ipv6. "static-address-map" might be a better name > if we want to augment it with (static) proxy arp entries in some > future... Comments from the WG? Well, if we call it _static_-address-map, then we will not be able to use these definitions for operational state. I personally think 'neighbor' is just fine. > ps> since RFC 4941 is optional to implement, we should add a feature > ps> and use if-feature in the leafs from this rfc. > > I think this makes sense, and propose: > > feature ipv6-privacy-autoconf { > description > "Indicates support for Privacy Extensions for Stateless Address > Autoconfiguration in IPv6."; > reference > "RFC 4941: Privacy Extensions for Stateless Address > Autoconfiguration in IPv6"; > } Makese sense. > ps> the leafs "create-global-addresses" and "create-temporary-address" > ps> should be named in singular. > > My reading of RFC 4862 is that there can actually be multiple global > (and thus temporary) addresses per interface. I agree, plural seems to be correct here. /js (speaking as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Thu Aug 2 17:02:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5583411E810D for ; Thu, 2 Aug 2012 17:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnweqsBt2ew3 for ; Thu, 2 Aug 2012 17:02:12 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1A711E8108 for ; Thu, 2 Aug 2012 17:02:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A163C540436; Fri, 3 Aug 2012 02:02:11 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPpskF2BMNie; Fri, 3 Aug 2012 02:02:07 +0200 (CEST) Received: from localhost (dhcp-16a6.meeting.ietf.org [130.129.22.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id D88CC54005A; Fri, 3 Aug 2012 02:02:05 +0200 (CEST) From: Ladislav Lhotka To: Jernej Tuljak , Andy Bierman In-Reply-To: <501A4A8C.8080107@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Jernej Tuljak , Andy Bierman , Jernej Tuljak , netmod@ietf.org Date: Thu, 02 Aug 2012 17:02:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 00:02:17 -0000 Jernej Tuljak writes: > > I think that the idea to completely decouple the schema from instances > based on it is the way to go. Your schema is not such a schema, since it > needs an instance to determine it's final form (the instance becomes a > part of the schema). It's form must be determined after every > modification to the instance. Constantly. Not entirely sure how you do it. In fact the solution can already be found in RFC 6110: make 'when' statement essentially equivalent to 'must', except for a different error message. > > One other thing. Our generic client application displays the entire > schema in a tree graphic component and even offers queries to be made > from it. How could it possibly do that if the tree's final form cannot > be determined? > > Also this would make RFC6110 next to useless since the assumption that > YANG schema is static is the foundation it builds upon. Generating DSDL > schema is an expensive operation...and it would have to be done after > every modification to an instance document. Absolutely. It would be possible to forget about RELAX NG and implement all validation in Schematron. However, such an approach would ignore the lessons learnt by the XML community and embodied in DSDL: Schema-based validation is a very robust procedure that practically cannot be fooled and provides guarantees that the instance document is syntactically correct so that it can be safely parsed. Validation based on checking XPath expressions is much more fragile and is best used only for "business rules" (semantic constrainst) AFTER schema-based validation has been successfully finished. > > The when-stmt only makes its parent data definition statement > conditional. There's nothing written in RFC6020 that this would imply > modifications to the schema (can't find it). Although multiple > paragraphs can be found which serve as workarounds for non-static > implementations of YANG schema. The point in 8.3.1 Payload Parsing which > relates to when-stmt is an example. > > Sorry, but I'm completely with Ladislav on this one. Non-static schema > or run-time changes to a schema are bad and should never have been > allowed to become a part of YANG. I cannot argue that they are not a > part of it. Agreed. Lada > > Jernej > >> >> >>> It doesn't matter how the error is generated. But it should be properly >>> generated. >>> >>> Jernej >> Andy >> >>>> Lada >>>> >>>>> But I can see how this is problematic. >>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>> It is used for unknown and unexpected elements. >>>>> If /foo/bar only exists if when=true, then for when=false we would have >>>>> to >>>>> decide if that node is unknown by the server, vs. an instance >>>>> of that node is unexpected for the request. >>>>> >>>>> >>>>> >>>>>> Lada >>>>>> >>>>> Andy >>>>> >>>>> >>>>>>> Or does a conditional augment mean that the augmentation will always be >>>>>>> done but all of the augmented nodes "inherit" the augment's when conditions >>>>>>> making all of them conditional? This would make much more sense to me. Would >>>>>>> this be legal as a potential workaround to dynamically changing a module's >>>>>>> schema? What was the group's intention regarding this matter? >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Aug 2 17:14:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08B011E808E for ; Thu, 2 Aug 2012 17:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSjiexIIQpho for ; Thu, 2 Aug 2012 17:14:03 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8AC311E8087 for ; Thu, 2 Aug 2012 17:14:03 -0700 (PDT) Received: by qcac10 with SMTP id c10so68402qca.31 for ; Thu, 02 Aug 2012 17:14:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=7nZleQUXw3apU+/E+3RDZH83D7D0qPYIDfY33iX0Mhs=; b=n3tSOD2XPePt2QFuLkKuCSW2hoxkGn7VLbGwFrVcgVjd4iYtpRYAeBJSNUTQmoceSP gR66/I2jPeUBOHYmVKTqO2GRK8LEXD4xS4mVsATiNmfsfnlkX+q3cWDyh0QGcVmIRx60 zuTTKHn70zV7ATUO8+1Ewt/rOvaVHn1DzqGIpQlHlW1URJWUd/K6zLn3FtbW4TgnDyyN 9RKp7PNPdVswWFG9Mkhc0/74A/hCTqBCyY6WUDqfMs55U0rEhOnzYM1s20QjptdhTnbg PXiBaKXdvKZnHHBqR4Z2PXT+MSp+xQJLWVKvZQe4capKLcKl8w9lgyeqNy41qnJ9ht+9 HOsw== MIME-Version: 1.0 Received: by 10.224.180.146 with SMTP id bu18mr144331qab.10.1343952843059; Thu, 02 Aug 2012 17:14:03 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 17:14:03 -0700 (PDT) X-Originating-IP: [130.129.65.206] In-Reply-To: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> Date: Thu, 2 Aug 2012 17:14:03 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak , Andy Bierman , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlCU2zbXcKBjFiIldCK5zIsSxJHxnFlTt6u/Kz9e5oZWspu7GgiW/O3zunK8pcZD4ZWjK8z Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 00:14:04 -0000 Hi, Sorry but YANG does not work the way you think it does for the sake of your static test tool. BTW, pyang does not validate the XPath statement. It validates instance documents against the XPath that it finds. This is hardly the same as verifying the correctness of the YANG statement. A false when-stmt is not an error unless it occurs in the RPC input parameters. (We are insulated from content because it is declared as an 'anyxml' so from a RPC POV, the when-stmts within the data are not relevant to RPC input validation.) The XPath statements are conceptual. There is no requirement by the server to use an XPath validator to implement them. When-stmt is applied right away, not applied at validation time like must-stmt. Andy On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka wrote: > Jernej Tuljak writes: > >> >> I think that the idea to completely decouple the schema from instances >> based on it is the way to go. Your schema is not such a schema, since it >> needs an instance to determine it's final form (the instance becomes a >> part of the schema). It's form must be determined after every >> modification to the instance. Constantly. Not entirely sure how you do i= t. > > In fact the solution can already be found in RFC 6110: make 'when' statem= ent essentially equivalent to 'must', except for a different error message. > >> >> One other thing. Our generic client application displays the entire >> schema in a tree graphic component and even offers queries to be made >> from it. How could it possibly do that if the tree's final form cannot >> be determined? >> >> Also this would make RFC6110 next to useless since the assumption that >> YANG schema is static is the foundation it builds upon. Generating DSDL >> schema is an expensive operation...and it would have to be done after >> every modification to an instance document. > > Absolutely. It would be possible to forget about RELAX NG and implement a= ll validation in Schematron. However, such an approach would ignore the les= sons learnt by the XML community and embodied in DSDL: Schema-based validat= ion is a very robust procedure that practically cannot be fooled and provid= es guarantees that the instance document is syntactically correct so that i= t can be safely parsed. Validation based on checking XPath expressions is m= uch more fragile and is best used only for "business rules" (semantic const= rainst) AFTER schema-based validation has been successfully finished. > >> >> The when-stmt only makes its parent data definition statement >> conditional. There's nothing written in RFC6020 that this would imply >> modifications to the schema (can't find it). Although multiple >> paragraphs can be found which serve as workarounds for non-static >> implementations of YANG schema. The point in 8.3.1 Payload Parsing which >> relates to when-stmt is an example. >> >> Sorry, but I'm completely with Ladislav on this one. Non-static schema >> or run-time changes to a schema are bad and should never have been >> allowed to become a part of YANG. I cannot argue that they are not a >> part of it. > > Agreed. > > Lada > >> >> Jernej >> >>> >>> >>>> It doesn't matter how the error is generated. But it should be properl= y >>>> generated. >>>> >>>> Jernej >>> Andy >>> >>>>> Lada >>>>> >>>>>> But I can see how this is problematic. >>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>> It is used for unknown and unexpected elements. >>>>>> If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse we wou= ld have >>>>>> to >>>>>> decide if that node is unknown by the server, vs. an instance >>>>>> of that node is unexpected for the request. >>>>>> >>>>>> >>>>>> >>>>>>> Lada >>>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>>>> Or does a conditional augment mean that the augmentation will alwa= ys be >>>>>>>> done but all of the augmented nodes "inherit" the augment's when c= onditions >>>>>>>> making all of them conditional? This would make much more sense to= me. Would >>>>>>>> this be legal as a potential workaround to dynamically changing a = module's >>>>>>>> schema? What was the group's intention regarding this matter? >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: E74E8C0C >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From randy_presuhn@mindspring.com Thu Aug 2 20:37:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDDD11E80DB for ; Thu, 2 Aug 2012 20:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzm073klT2j7 for ; Thu, 2 Aug 2012 20:37:55 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2E77C11E80AE for ; Thu, 2 Aug 2012 20:37:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pv+WMLxIR0kGs43KDOvUvWhLMCugcWQJtb1+BDOfl3SNE0b+sXopQSF2X1JwU7n8; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.236.35] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Sx8i1-0000Iv-SJ for netmod@ietf.org; Thu, 02 Aug 2012 23:37:54 -0400 Message-ID: <002201cd712a$1efa55e0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <50165FAA.4040700@mg-soft.com><20120731.072142.385816835.mbj@tail-f.com><5018D91A.20609@mg-soft.com><8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz><501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> Date: Thu, 2 Aug 2012 20:43:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1737f07a6cb7aefc0f419008e4a773a24350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.236.35 Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 03:37:56 -0000 Hi - > From: "Jernej Tuljak" > To: "Andy Bierman" > Cc: > Sent: Thursday, August 02, 2012 2:38 AM > Subject: Re: [netmod] XPath errors in ietf-snmp.yang ... > Sorry, but I'm completely with Ladislav on this one. Non-static schema > or run-time changes to a schema are bad and should never have been > allowed to become a part of YANG. I cannot argue that they are not a > part of it. Perhaps, but they satisfy real needs in open systems, systems with hot-swap and hot-insertion components or subsystems, and application management, to name a few. They are straightforward to support in legacy protocols like CMIP and SNMP and their corresponding data model languages, and whether one likes it or not, coping with schema changes is an important part of configuration management. Perhaps they're not needed for the Netconf space, but recognize that excluding them as possibilities would make Netconf even more limited than what it was supposed to supplant. Randy From jernej.tuljak@mg-soft.si Fri Aug 3 00:21:44 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2198521F8D0C for ; Fri, 3 Aug 2012 00:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.982 X-Spam-Level: X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB3EZbP+eDFb for ; Fri, 3 Aug 2012 00:21:43 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9E80921F8D09 for ; Fri, 3 Aug 2012 00:21:41 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q737LcXi006222; Fri, 3 Aug 2012 09:21:39 +0200 Message-ID: <501B7BFC.3090404@mg-soft.com> Date: Fri, 03 Aug 2012 09:21:32 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 07:21:44 -0000 Hi, that's just the beauty of it. It is not a static test tool. It adapts to whatever changes you make to the modules. It adapts when you choose enabled features and it adapts when you change them. It tells you what you did wrong while you write entire datastores, rpc operations, even when dealing with incomplete XML documents. And it does so in quite a simple way. The way of RFC6110, which extracts the entire schema from available modules and with just a few XSLT transformations you are set to go. Forever. It's quite genius really (credit to Ladislav and others involved with RFC6110 here). I don't understand why anyone would bother reinventing the wheel trying to implement his own way of validating NETCONF content when it's all already out there. I never claimed that pyang checks the validity of XPath expressions. It cannot do so, because XPath expressions cannot be evaluated without context and context can only be found within instance documents, a thing that _never_ exists during YANG module validation. It only exists during NETCONF content validation, when you have an actual instance document to work with. Therefore when-stmt cannot be applied at any other time than during content validation. It represents a semantic constraint on data nodes, not a constraint on the schema nodes. And pyang applies these constraints within pyang.dsdl plugin only when it is validating an XML document against a YANG schema. There is no other way. I don't understand the need to merge YANG validation with NETCONF content validation into a single validation process. It does not make sense. As I understand it, this is exactly what you are doing. Sometimes it even feels like you are saying that a schema node and an instance node are the same thing. It should be clear that a schema node is not an instance node, the former only represents the structure and conditions of appearance of the latter. Schema nodes never get deleted, instance nodes do. Let's return to Ladislav's example: leaf X { type string; mandatory true; when ". = ../foo"; } For when-stmt condition to be evaluated _at all_ an instance of X must exist first, meaning that the mandatory constraint is always satisfied if an evaluation occurred. After all X is the condition expression's context node. You cannot evaluate without context. You can however validate it's syntax at any time - provided that you are using a static schema, which contains all the schema nodes for you to search. If when is ever true or false, one can be sure that the mandatory constraint has been satisfied, eliminating the need to enforce it. The above example represents an instance node, which has to exist and fulfill the condition in the when-stmt at the same time. Anything else is an error. It's actually mandatory which takes precedence here, so what Ladislav currently does (structure first, then semantics) is the correct interpretation, IMO. There's a reason why when-stmt's argument is an XPath expression and not a YANG construct, like a schema-nodeid. Jernej Dne 3.8.2012 2:14, piĆĄe Andy Bierman: > Hi, > > Sorry but YANG does not work the way you think it does for the sake of > your static test tool. BTW, pyang does not validate the XPath statement. > It validates instance documents against the XPath that it finds. > This is hardly the same as verifying the correctness of the YANG statement. > > A false when-stmt is not an error unless it occurs in the RPC input > parameters. (We are insulated from content because it > is declared as an 'anyxml' so from a RPC POV, the when-stmts > within the data are not relevant to RPC input validation.) > > The XPath statements are conceptual. There is no requirement > by the server to use an XPath validator to implement them. > When-stmt is applied right away, not applied at validation > time like must-stmt. > > > Andy > > > On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka wrote: >> Jernej Tuljak writes: >> >>> I think that the idea to completely decouple the schema from instances >>> based on it is the way to go. Your schema is not such a schema, since it >>> needs an instance to determine it's final form (the instance becomes a >>> part of the schema). It's form must be determined after every >>> modification to the instance. Constantly. Not entirely sure how you do it. >> In fact the solution can already be found in RFC 6110: make 'when' statement essentially equivalent to 'must', except for a different error message. >> >>> One other thing. Our generic client application displays the entire >>> schema in a tree graphic component and even offers queries to be made >>> from it. How could it possibly do that if the tree's final form cannot >>> be determined? >>> >>> Also this would make RFC6110 next to useless since the assumption that >>> YANG schema is static is the foundation it builds upon. Generating DSDL >>> schema is an expensive operation...and it would have to be done after >>> every modification to an instance document. >> Absolutely. It would be possible to forget about RELAX NG and implement all validation in Schematron. However, such an approach would ignore the lessons learnt by the XML community and embodied in DSDL: Schema-based validation is a very robust procedure that practically cannot be fooled and provides guarantees that the instance document is syntactically correct so that it can be safely parsed. Validation based on checking XPath expressions is much more fragile and is best used only for "business rules" (semantic constrainst) AFTER schema-based validation has been successfully finished. >> >>> The when-stmt only makes its parent data definition statement >>> conditional. There's nothing written in RFC6020 that this would imply >>> modifications to the schema (can't find it). Although multiple >>> paragraphs can be found which serve as workarounds for non-static >>> implementations of YANG schema. The point in 8.3.1 Payload Parsing which >>> relates to when-stmt is an example. >>> >>> Sorry, but I'm completely with Ladislav on this one. Non-static schema >>> or run-time changes to a schema are bad and should never have been >>> allowed to become a part of YANG. I cannot argue that they are not a >>> part of it. >> Agreed. >> >> Lada >> >>> Jernej >>> >>>> >>>>> It doesn't matter how the error is generated. But it should be properly >>>>> generated. >>>>> >>>>> Jernej >>>> Andy >>>> >>>>>> Lada >>>>>> >>>>>>> But I can see how this is problematic. >>>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>>> It is used for unknown and unexpected elements. >>>>>>> If /foo/bar only exists if when=true, then for when=false we would have >>>>>>> to >>>>>>> decide if that node is unknown by the server, vs. an instance >>>>>>> of that node is unexpected for the request. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Lada >>>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> >>>>>>>>> Or does a conditional augment mean that the augmentation will always be >>>>>>>>> done but all of the augmented nodes "inherit" the augment's when conditions >>>>>>>>> making all of them conditional? This would make much more sense to me. Would >>>>>>>>> this be legal as a potential workaround to dynamically changing a module's >>>>>>>>> schema? What was the group's intention regarding this matter? >>>>>>>> -- >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: E74E8C0C >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Aug 3 01:02:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB10221F8D62 for ; Fri, 3 Aug 2012 01:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaGE3mYIQTU8 for ; Fri, 3 Aug 2012 01:02:31 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 81ECA21F8D3E for ; Fri, 3 Aug 2012 01:02:31 -0700 (PDT) Received: by qaea16 with SMTP id a16so1834406qae.10 for ; Fri, 03 Aug 2012 01:02:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=dVo3Hg7wb3kO09cNDZdq3o2WojjPpfPP4Oejkpw3cxY=; b=ZaJSNB1K+TdjsYY4Vn/FAsIkBfHWdwiJqecjufV76HRzG5UIqRBlbqkLdNB3lnVN6n 0zw1iNmASf03/e7VNNm1Lnszd4qVBx2yxiuF9WZe0jnm+0I6y08N4PP8eoCzY5qoNRBf UEXfvb/nfD8QTk+hZAd7sc0mngPgC2qiovxPcvf/lnI2hwo6O6appJVmgUPhrNcOJRfz 5Q8Vyi0I78WoS6uiknFPXivFX+uJeT3PSm2XUD3/BcO+CBLJ+AamBAAnyyxuBGBtJ1Ak s+lz0e3YxgpqEL+EKEoM5u+WGnbAo+z2aMs34R7JnHwAdW5wpGcbsozA6xEUGH2OZDEl 4lvw== MIME-Version: 1.0 Received: by 10.229.105.205 with SMTP id u13mr398192qco.9.1343980950953; Fri, 03 Aug 2012 01:02:30 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Fri, 3 Aug 2012 01:02:30 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:b5df:e15:cab5:c7f5] In-Reply-To: <501B7BFC.3090404@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> Date: Fri, 3 Aug 2012 01:02:30 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnUYVtqdZcU5N8+PcaiZqPsCg1drZCKHIJ1Frf/A4n2wusVPh19Ln6PPJ2TwvE4FEVyDAts Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 08:02:32 -0000 On Fri, Aug 3, 2012 at 12:21 AM, Jernej Tuljak w= rote: > Hi, > > that's just the beauty of it. It is not a static test tool. It adapts to > whatever changes you make to the modules. It adapts when you choose enabl= ed > features and it adapts when you change them. It tells you what you did wr= ong > while you write entire datastores, rpc operations, even when dealing with > incomplete XML documents. And it does so in quite a simple way. The way o= f > RFC6110, which extracts the entire schema from available modules and with > just a few XSLT transformations you are set to go. Forever. It's quite > genius really (credit to Ladislav and others involved with RFC6110 here).= I > don't understand why anyone would bother reinventing the wheel trying to > implement his own way of validating NETCONF content when it's all already > out there. > > I never claimed that pyang checks the validity of XPath expressions. It > cannot do so, because XPath expressions cannot be evaluated without conte= xt > and context can only be found within instance documents, a thing that > _never_ exists during YANG module validation. It only exists during NETCO= NF > content validation, when you have an actual instance document to work wit= h. > Therefore when-stmt cannot be applied at any other time than during conte= nt > validation. It represents a semantic constraint on data nodes, not a > constraint on the schema nodes. And pyang applies these constraints withi= n > pyang.dsdl plugin only when it is validating an XML document against a YA= NG > schema. There is no other way. The YANG must and when statements can be checked to make sure the XPath is well-formed and all the schema nodes are actually defined. There is really no reason for an YANG must or when stmt to reference garbage nodes that do not exist in the data model. > > I don't understand the need to merge YANG validation with NETCONF content > validation into a single validation process. It does not make sense. As I > understand it, this is exactly what you are doing. Sometimes it even feel= s > like you are saying that a schema node and an instance node are the same > thing. It should be clear that a schema node is not an instance node, the > former only represents the structure and conditions of appearance of the > latter. Schema nodes never get deleted, instance nodes do. > Implementation details do not matter. The server must send the correct responses and alter its internal state correctly. There are many ways this could be done. Some servers allow YANG modules to be loaded and unloaded at run-time. The schema tree is static, meaning once a node is placed in the tree it doesn't move, but the tree can change at run-time. YANG deviations also affect the schema tree, which are allowed to be loaded at any time. > Let's return to Ladislav's example: > > leaf X { > type string; > mandatory true; > when ". =3D ../foo"; > } > Yes, there are some pathological cases that make no semantic sense that cannot be implemented correctly. leaf Y { type int32; mandatory true; when "not(.)"; } > > For when-stmt condition to be evaluated _at all_ an instance of X must ex= ist > first, meaning that the mandatory constraint is always satisfied if an > evaluation occurred. After all X is the condition expression's context no= de. > You cannot evaluate without context. You can however validate it's syntax= at > any time - provided that you are using a static schema, which contains al= l > the schema nodes for you to search. > > If when is ever true or false, one can be sure that the mandatory constra= int > has been satisfied, eliminating the need to enforce it. > > The above example represents an instance node, which has to exist and > fulfill the condition in the when-stmt at the same time. Anything else is= an > error. It's actually mandatory which takes precedence here, so what Ladis= lav > currently does (structure first, then semantics) is the correct > interpretation, IMO. > > There's a reason why when-stmt's argument is an XPath expression and not = a > YANG construct, like a schema-nodeid. Yes, so they generate a boolean result. A schema-nodeid is not relevant here. That is used for augment and path targets. > > Jernej Andy > > Dne 3.8.2012 2:14, pi=C5=A1e Andy Bierman: >> >> Hi, >> >> Sorry but YANG does not work the way you think it does for the sake of >> your static test tool. BTW, pyang does not validate the XPath statement= . >> It validates instance documents against the XPath that it finds. >> This is hardly the same as verifying the correctness of the YANG >> statement. >> >> A false when-stmt is not an error unless it occurs in the RPC input >> parameters. (We are insulated from content because it >> is declared as an 'anyxml' so from a RPC POV, the when-stmts >> within the data are not relevant to RPC input validation.) >> >> The XPath statements are conceptual. There is no requirement >> by the server to use an XPath validator to implement them. >> When-stmt is applied right away, not applied at validation >> time like must-stmt. >> >> >> Andy >> >> >> On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka wrote: >>> >>> Jernej Tuljak writes: >>> >>>> I think that the idea to completely decouple the schema from instances >>>> based on it is the way to go. Your schema is not such a schema, since = it >>>> needs an instance to determine it's final form (the instance becomes a >>>> part of the schema). It's form must be determined after every >>>> modification to the instance. Constantly. Not entirely sure how you do >>>> it. >>> >>> In fact the solution can already be found in RFC 6110: make 'when' >>> statement essentially equivalent to 'must', except for a different erro= r >>> message. >>> >>>> One other thing. Our generic client application displays the entire >>>> schema in a tree graphic component and even offers queries to be made >>>> from it. How could it possibly do that if the tree's final form cannot >>>> be determined? >>>> >>>> Also this would make RFC6110 next to useless since the assumption that >>>> YANG schema is static is the foundation it builds upon. Generating DSD= L >>>> schema is an expensive operation...and it would have to be done after >>>> every modification to an instance document. >>> >>> Absolutely. It would be possible to forget about RELAX NG and implement >>> all validation in Schematron. However, such an approach would ignore th= e >>> lessons learnt by the XML community and embodied in DSDL: Schema-based >>> validation is a very robust procedure that practically cannot be fooled= and >>> provides guarantees that the instance document is syntactically correct= so >>> that it can be safely parsed. Validation based on checking XPath expres= sions >>> is much more fragile and is best used only for "business rules" (semant= ic >>> constrainst) AFTER schema-based validation has been successfully finish= ed. >>> >>>> The when-stmt only makes its parent data definition statement >>>> conditional. There's nothing written in RFC6020 that this would imply >>>> modifications to the schema (can't find it). Although multiple >>>> paragraphs can be found which serve as workarounds for non-static >>>> implementations of YANG schema. The point in 8.3.1 Payload Parsing whi= ch >>>> relates to when-stmt is an example. >>>> >>>> Sorry, but I'm completely with Ladislav on this one. Non-static schema >>>> or run-time changes to a schema are bad and should never have been >>>> allowed to become a part of YANG. I cannot argue that they are not a >>>> part of it. >>> >>> Agreed. >>> >>> Lada >>> >>>> Jernej >>>> >>>>> >>>>>> It doesn't matter how the error is generated. But it should be >>>>>> properly >>>>>> generated. >>>>>> >>>>>> Jernej >>>>> >>>>> Andy >>>>> >>>>>>> Lada >>>>>>> >>>>>>>> But I can see how this is problematic. >>>>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>>>> It is used for unknown and unexpected elements. >>>>>>>> If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse we w= ould >>>>>>>> have >>>>>>>> to >>>>>>>> decide if that node is unknown by the server, vs. an instance >>>>>>>> of that node is unexpected for the request. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Lada >>>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> >>>>>>>>>> Or does a conditional augment mean that the augmentation will >>>>>>>>>> always be >>>>>>>>>> done but all of the augmented nodes "inherit" the augment's when >>>>>>>>>> conditions >>>>>>>>>> making all of them conditional? This would make much more sense = to >>>>>>>>>> me. Would >>>>>>>>>> this be legal as a potential workaround to dynamically changing = a >>>>>>>>>> module's >>>>>>>>>> schema? What was the group's intention regarding this matter? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> netmod mailing list >>>>>>>>> netmod@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>> >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: E74E8C0C >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > From jernej.tuljak@mg-soft.si Fri Aug 3 03:17:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6C21F8D98 for ; Fri, 3 Aug 2012 03:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTn8fHzLUuL8 for ; Fri, 3 Aug 2012 03:17:11 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0420D21F8D97 for ; Fri, 3 Aug 2012 03:17:10 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q73AH72W007769; Fri, 3 Aug 2012 12:17:08 +0200 Message-ID: <501BA51D.4070404@mg-soft.com> Date: Fri, 03 Aug 2012 12:17:01 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 10:17:12 -0000 Dne 3.8.2012 10:02, piĆĄe Andy Bierman: > On Fri, Aug 3, 2012 at 12:21 AM, Jernej Tuljak wrote: >> Hi, >> >> that's just the beauty of it. It is not a static test tool. It adapts to >> whatever changes you make to the modules. It adapts when you choose enabled >> features and it adapts when you change them. It tells you what you did wrong >> while you write entire datastores, rpc operations, even when dealing with >> incomplete XML documents. And it does so in quite a simple way. The way of >> RFC6110, which extracts the entire schema from available modules and with >> just a few XSLT transformations you are set to go. Forever. It's quite >> genius really (credit to Ladislav and others involved with RFC6110 here). I >> don't understand why anyone would bother reinventing the wheel trying to >> implement his own way of validating NETCONF content when it's all already >> out there. >> >> I never claimed that pyang checks the validity of XPath expressions. It >> cannot do so, because XPath expressions cannot be evaluated without context >> and context can only be found within instance documents, a thing that >> _never_ exists during YANG module validation. It only exists during NETCONF >> content validation, when you have an actual instance document to work with. >> Therefore when-stmt cannot be applied at any other time than during content >> validation. It represents a semantic constraint on data nodes, not a >> constraint on the schema nodes. And pyang applies these constraints within >> pyang.dsdl plugin only when it is validating an XML document against a YANG >> schema. There is no other way. > The YANG must and when statements can be checked to make sure > the XPath is well-formed and all the schema nodes are actually defined. > There is really no reason for an YANG must or when stmt to reference > garbage nodes that do not exist in the data model. > > >> I don't understand the need to merge YANG validation with NETCONF content >> validation into a single validation process. It does not make sense. As I >> understand it, this is exactly what you are doing. Sometimes it even feels >> like you are saying that a schema node and an instance node are the same >> thing. It should be clear that a schema node is not an instance node, the >> former only represents the structure and conditions of appearance of the >> latter. Schema nodes never get deleted, instance nodes do. >> > Implementation details do not matter. > The server must send the correct responses and alter its > internal state correctly. There are many ways this could > be done. > > Some servers allow YANG modules to be loaded and unloaded > at run-time. The schema tree is static, meaning once a node > is placed in the tree it doesn't move, but the tree can change at run-time. > YANG deviations also affect the schema tree, which are allowed to > be loaded at any time. Of course. That's what makes YANG great. That it's extensible the way any other schema is. A each set of modules may provide a different schema. A single additional module may change the existing schema tree significantly making it another schema. If-features are also great. But do note that these are not the "runtime modifications to the schema tree" me and Ladislav were talking about. What I've been saying all along is that if we have a module set of size one (a single module) it's schema is always the same. A schema node count will always be the same for it. The only way to modify the count is via features or by adding new modules to the set, which does happen, but not often. That's what I mean when I say that YANG is a static schema. An extensible but static schema. Adding a module with deviations, augments, etc. to the set creates a new but also static schema. But none of this should have anything to do with NETCONF content validation. Allowing the schema count to be modified during validation with when-stmt's is just...well, bad. RFC6020 should have never allowed it. Separation of YANG validation/compiling which results in a read-only schema tree and NETCONF content validation, which only uses this schema tree to validate an XML document, should have been enforced. I don't see any merit in this being a single process. Jernej > >> Let's return to Ladislav's example: >> >> leaf X { >> type string; >> mandatory true; >> when ". = ../foo"; >> } >> > Yes, there are some pathological cases that make no > semantic sense that cannot be implemented correctly. > > leaf Y { > type int32; > mandatory true; > when "not(.)"; > } > > >> For when-stmt condition to be evaluated _at all_ an instance of X must exist >> first, meaning that the mandatory constraint is always satisfied if an >> evaluation occurred. After all X is the condition expression's context node. >> You cannot evaluate without context. You can however validate it's syntax at >> any time - provided that you are using a static schema, which contains all >> the schema nodes for you to search. >> >> If when is ever true or false, one can be sure that the mandatory constraint >> has been satisfied, eliminating the need to enforce it. >> >> The above example represents an instance node, which has to exist and >> fulfill the condition in the when-stmt at the same time. Anything else is an >> error. It's actually mandatory which takes precedence here, so what Ladislav >> currently does (structure first, then semantics) is the correct >> interpretation, IMO. >> >> There's a reason why when-stmt's argument is an XPath expression and not a >> YANG construct, like a schema-nodeid. > Yes, so they generate a boolean result. > A schema-nodeid is not relevant here. > That is used for augment and path targets. > > > >> Jernej > > Andy > >> Dne 3.8.2012 2:14, piĆĄe Andy Bierman: >>> Hi, >>> >>> Sorry but YANG does not work the way you think it does for the sake of >>> your static test tool. BTW, pyang does not validate the XPath statement. >>> It validates instance documents against the XPath that it finds. >>> This is hardly the same as verifying the correctness of the YANG >>> statement. >>> >>> A false when-stmt is not an error unless it occurs in the RPC input >>> parameters. (We are insulated from content because it >>> is declared as an 'anyxml' so from a RPC POV, the when-stmts >>> within the data are not relevant to RPC input validation.) >>> >>> The XPath statements are conceptual. There is no requirement >>> by the server to use an XPath validator to implement them. >>> When-stmt is applied right away, not applied at validation >>> time like must-stmt. >>> >>> >>> Andy >>> >>> >>> On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka wrote: >>>> Jernej Tuljak writes: >>>> >>>>> I think that the idea to completely decouple the schema from instances >>>>> based on it is the way to go. Your schema is not such a schema, since it >>>>> needs an instance to determine it's final form (the instance becomes a >>>>> part of the schema). It's form must be determined after every >>>>> modification to the instance. Constantly. Not entirely sure how you do >>>>> it. >>>> In fact the solution can already be found in RFC 6110: make 'when' >>>> statement essentially equivalent to 'must', except for a different error >>>> message. >>>> >>>>> One other thing. Our generic client application displays the entire >>>>> schema in a tree graphic component and even offers queries to be made >>>>> from it. How could it possibly do that if the tree's final form cannot >>>>> be determined? >>>>> >>>>> Also this would make RFC6110 next to useless since the assumption that >>>>> YANG schema is static is the foundation it builds upon. Generating DSDL >>>>> schema is an expensive operation...and it would have to be done after >>>>> every modification to an instance document. >>>> Absolutely. It would be possible to forget about RELAX NG and implement >>>> all validation in Schematron. However, such an approach would ignore the >>>> lessons learnt by the XML community and embodied in DSDL: Schema-based >>>> validation is a very robust procedure that practically cannot be fooled and >>>> provides guarantees that the instance document is syntactically correct so >>>> that it can be safely parsed. Validation based on checking XPath expressions >>>> is much more fragile and is best used only for "business rules" (semantic >>>> constrainst) AFTER schema-based validation has been successfully finished. >>>> >>>>> The when-stmt only makes its parent data definition statement >>>>> conditional. There's nothing written in RFC6020 that this would imply >>>>> modifications to the schema (can't find it). Although multiple >>>>> paragraphs can be found which serve as workarounds for non-static >>>>> implementations of YANG schema. The point in 8.3.1 Payload Parsing which >>>>> relates to when-stmt is an example. >>>>> >>>>> Sorry, but I'm completely with Ladislav on this one. Non-static schema >>>>> or run-time changes to a schema are bad and should never have been >>>>> allowed to become a part of YANG. I cannot argue that they are not a >>>>> part of it. >>>> Agreed. >>>> >>>> Lada >>>> >>>>> Jernej >>>>> >>>>>>> It doesn't matter how the error is generated. But it should be >>>>>>> properly >>>>>>> generated. >>>>>>> >>>>>>> Jernej >>>>>> Andy >>>>>> >>>>>>>> Lada >>>>>>>> >>>>>>>>> But I can see how this is problematic. >>>>>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>>>>> It is used for unknown and unexpected elements. >>>>>>>>> If /foo/bar only exists if when=true, then for when=false we would >>>>>>>>> have >>>>>>>>> to >>>>>>>>> decide if that node is unknown by the server, vs. an instance >>>>>>>>> of that node is unexpected for the request. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Lada >>>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Or does a conditional augment mean that the augmentation will >>>>>>>>>>> always be >>>>>>>>>>> done but all of the augmented nodes "inherit" the augment's when >>>>>>>>>>> conditions >>>>>>>>>>> making all of them conditional? This would make much more sense to >>>>>>>>>>> me. Would >>>>>>>>>>> this be legal as a potential workaround to dynamically changing a >>>>>>>>>>> module's >>>>>>>>>>> schema? What was the group's intention regarding this matter? >>>>>>>>>> -- >>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> netmod mailing list >>>>>>>>>> netmod@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>> -- >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: E74E8C0C >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >> From lhotka@nic.cz Fri Aug 3 07:25:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8E821F8D15 for ; Fri, 3 Aug 2012 07:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d4w0AwjPQ9Q for ; Fri, 3 Aug 2012 07:25:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C158521F8D06 for ; Fri, 3 Aug 2012 07:25:57 -0700 (PDT) Received: from dhcp-4101.meeting.ietf.org (dhcp-4101.meeting.ietf.org [130.129.65.1]) by mail.nic.cz (Postfix) with ESMTPSA id D250013F906; Fri, 3 Aug 2012 16:25:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344003956; bh=APWjrdQD/lEYPvgRZPDqTgyTruHn7pClrriE2jc9+v4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tBteGgk4QXlkrDIg7V6f2j7cQsF1ntoF84gp82++2wsaNpBv0T+HymCMVLZrfSDMM 1PS67sDcr2seG+6iZpo8y8Ek40HrGvvQAlohb+PTPWSn+rIBFUXFc092fdjmVEoBsJ Z5EZw8+0zRJUyzat84ZDxb2y34gLjqbmV9ZRcoHk= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <002201cd712a$1efa55e0$6b01a8c0@oemcomputer> Date: Fri, 3 Aug 2012 07:25:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50165FAA.4040700@mg-soft.com><20120731.072142.385816835.mbj@tail-f.com><5018D91A.20609@mg-soft.com><8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz><501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <002201cd712a$1efa55e0$6b01a8c0@oemcomputer> To: Randy Presuhn X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:25:58 -0000 On Aug 2, 2012, at 8:43 PM, Randy Presuhn wrote: > Hi - >=20 >> From: "Jernej Tuljak" >> To: "Andy Bierman" >> Cc: >> Sent: Thursday, August 02, 2012 2:38 AM >> Subject: Re: [netmod] XPath errors in ietf-snmp.yang > ... >> Sorry, but I'm completely with Ladislav on this one. Non-static = schema=20 >> or run-time changes to a schema are bad and should never have been=20 >> allowed to become a part of YANG. I cannot argue that they are not a=20= >> part of it. >=20 > Perhaps, but they satisfy real needs in open systems, systems > with hot-swap and hot-insertion components or subsystems, and > application management, to name a few. They are straightforward to > support in legacy protocols like CMIP and SNMP and their corresponding > data model languages, and whether one likes it or not, coping with > schema changes is an important part of configuration management. > Perhaps they're not needed for the Netconf space, but recognize that > excluding them as possibilities would make Netconf even more limited > than what it was supposed to supplant. This is of course still possible - 'when' conditions are checked as = semantic constraints at the same time as 'must'. In order to have a = static schema (i.e. independent of the instance document it is supposed = to check), one only needs to acknowledge that validation is split into = two phases - syntactic (grammar + datatypes) and semantic (rules = involving instance values). Lada >=20 > Randy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Aug 3 07:31:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05A321F8D8F for ; Fri, 3 Aug 2012 07:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u69dmDZ306l for ; Fri, 3 Aug 2012 07:31:28 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77A21F8D6A for ; Fri, 3 Aug 2012 07:31:28 -0700 (PDT) Received: by qcac10 with SMTP id c10so487377qca.31 for ; Fri, 03 Aug 2012 07:31:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=e4cmlIyKkdiWiVfwpsNcUfuzfYT1fhTGq7ASO/DcLO8=; b=b1WILZ8TMTeBFO8/+FHQeMURVjYa6u3BPMkuxXVvM3+lLDXceUeBlLUZTUdZ3H9oHx IM+pDL8toPxLQJJl2aJSIlb5EnKpJOm6kNcDACaYOHcwibcWAiP/IK/RUi4goSANKSFm 5XfDazrHUcvDnCR2Qfs1nfVM21p+6yKIe8AF4vsYbpW/Cw+IwWB8yEjKjTqeQU9kJEh7 GI6bh3fjPOJuqrWEm9/kaR8fpiYztCFU9s5nO/gKrhbxuKZMKS7eLOTV2BK0DJ6vcM+i 4GkVLKkAwQaNSs/7bH1ENLTq13tJqzqdh4FOsKuexgBATcdS9qOPfquv/TAsmBlNq/mc Z6rQ== MIME-Version: 1.0 Received: by 10.229.136.135 with SMTP id r7mr919240qct.133.1344004286310; Fri, 03 Aug 2012 07:31:26 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Fri, 3 Aug 2012 07:31:26 -0700 (PDT) X-Originating-IP: [130.129.65.206] In-Reply-To: <501BA51D.4070404@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> Date: Fri, 3 Aug 2012 07:31:26 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlNIv9VHrhGp949q5ujpvftI+tlm2yUGHM18eRbVvL0GRd8qa2O3PATTdjsfK3JRjimMteQ Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:31:29 -0000 I don't think there is much point to discussing implementation details on the WG mailing list. Andy On Fri, Aug 3, 2012 at 3:17 AM, Jernej Tuljak wr= ote: > Dne 3.8.2012 10:02, pi=C5=A1e Andy Bierman: >> >> On Fri, Aug 3, 2012 at 12:21 AM, Jernej Tuljak >> wrote: >>> >>> Hi, >>> >>> that's just the beauty of it. It is not a static test tool. It adapts t= o >>> whatever changes you make to the modules. It adapts when you choose >>> enabled >>> features and it adapts when you change them. It tells you what you did >>> wrong >>> while you write entire datastores, rpc operations, even when dealing wi= th >>> incomplete XML documents. And it does so in quite a simple way. The way >>> of >>> RFC6110, which extracts the entire schema from available modules and wi= th >>> just a few XSLT transformations you are set to go. Forever. It's quite >>> genius really (credit to Ladislav and others involved with RFC6110 here= ). >>> I >>> don't understand why anyone would bother reinventing the wheel trying t= o >>> implement his own way of validating NETCONF content when it's all alrea= dy >>> out there. >>> >>> I never claimed that pyang checks the validity of XPath expressions. It >>> cannot do so, because XPath expressions cannot be evaluated without >>> context >>> and context can only be found within instance documents, a thing that >>> _never_ exists during YANG module validation. It only exists during >>> NETCONF >>> content validation, when you have an actual instance document to work >>> with. >>> Therefore when-stmt cannot be applied at any other time than during >>> content >>> validation. It represents a semantic constraint on data nodes, not a >>> constraint on the schema nodes. And pyang applies these constraints >>> within >>> pyang.dsdl plugin only when it is validating an XML document against a >>> YANG >>> schema. There is no other way. >> >> The YANG must and when statements can be checked to make sure >> the XPath is well-formed and all the schema nodes are actually defined. >> There is really no reason for an YANG must or when stmt to reference >> garbage nodes that do not exist in the data model. >> >> >>> I don't understand the need to merge YANG validation with NETCONF conte= nt >>> validation into a single validation process. It does not make sense. As= I >>> understand it, this is exactly what you are doing. Sometimes it even >>> feels >>> like you are saying that a schema node and an instance node are the sam= e >>> thing. It should be clear that a schema node is not an instance node, t= he >>> former only represents the structure and conditions of appearance of th= e >>> latter. Schema nodes never get deleted, instance nodes do. >>> >> Implementation details do not matter. >> The server must send the correct responses and alter its >> internal state correctly. There are many ways this could >> be done. >> >> Some servers allow YANG modules to be loaded and unloaded >> at run-time. The schema tree is static, meaning once a node >> is placed in the tree it doesn't move, but the tree can change at >> run-time. >> YANG deviations also affect the schema tree, which are allowed to >> be loaded at any time. > > > Of course. That's what makes YANG great. That it's extensible the way any > other schema is. A each set of modules may provide a different schema. A > single additional module may change the existing schema tree significantl= y > making it another schema. If-features are also great. But do note that th= ese > are not the "runtime modifications to the schema tree" me and Ladislav we= re > talking about. What I've been saying all along is that if we have a modul= e > set of size one (a single module) it's schema is always the same. A schem= a > node count will always be the same for it. The only way to modify the cou= nt > is via features or by adding new modules to the set, which does happen, b= ut > not often. That's what I mean when I say that YANG is a static schema. An > extensible but static schema. Adding a module with deviations, augments, > etc. to the set creates a new but also static schema. > > But none of this should have anything to do with NETCONF content validati= on. > Allowing the schema count to be modified during validation with when-stmt= 's > is just...well, bad. RFC6020 should have never allowed it. Separation of > YANG validation/compiling which results in a read-only schema tree and > NETCONF content validation, which only uses this schema tree to validate = an > XML document, should have been enforced. I don't see any merit in this be= ing > a single process. > > Jernej > >> >>> Let's return to Ladislav's example: >>> >>> leaf X { >>> type string; >>> mandatory true; >>> when ". =3D ../foo"; >>> } >>> >> Yes, there are some pathological cases that make no >> semantic sense that cannot be implemented correctly. >> >> leaf Y { >> type int32; >> mandatory true; >> when "not(.)"; >> } >> >> >>> For when-stmt condition to be evaluated _at all_ an instance of X must >>> exist >>> first, meaning that the mandatory constraint is always satisfied if an >>> evaluation occurred. After all X is the condition expression's context >>> node. >>> You cannot evaluate without context. You can however validate it's synt= ax >>> at >>> any time - provided that you are using a static schema, which contains >>> all >>> the schema nodes for you to search. >>> >>> If when is ever true or false, one can be sure that the mandatory >>> constraint >>> has been satisfied, eliminating the need to enforce it. >>> >>> The above example represents an instance node, which has to exist and >>> fulfill the condition in the when-stmt at the same time. Anything else = is >>> an >>> error. It's actually mandatory which takes precedence here, so what >>> Ladislav >>> currently does (structure first, then semantics) is the correct >>> interpretation, IMO. >>> >>> There's a reason why when-stmt's argument is an XPath expression and no= t >>> a >>> YANG construct, like a schema-nodeid. >> >> Yes, so they generate a boolean result. >> A schema-nodeid is not relevant here. >> That is used for augment and path targets. >> >> >> >>> Jernej >> >> >> Andy >> >>> Dne 3.8.2012 2:14, pi=C5=A1e Andy Bierman: >>>> >>>> Hi, >>>> >>>> Sorry but YANG does not work the way you think it does for the sake of >>>> your static test tool. BTW, pyang does not validate the XPath >>>> statement. >>>> It validates instance documents against the XPath that it finds. >>>> This is hardly the same as verifying the correctness of the YANG >>>> statement. >>>> >>>> A false when-stmt is not an error unless it occurs in the RPC input >>>> parameters. (We are insulated from content because it >>>> is declared as an 'anyxml' so from a RPC POV, the when-stmts >>>> within the data are not relevant to RPC input validation.) >>>> >>>> The XPath statements are conceptual. There is no requirement >>>> by the server to use an XPath validator to implement them. >>>> When-stmt is applied right away, not applied at validation >>>> time like must-stmt. >>>> >>>> >>>> Andy >>>> >>>> >>>> On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka wrote= : >>>>> >>>>> Jernej Tuljak writes: >>>>> >>>>>> I think that the idea to completely decouple the schema from instanc= es >>>>>> based on it is the way to go. Your schema is not such a schema, sinc= e >>>>>> it >>>>>> needs an instance to determine it's final form (the instance becomes= a >>>>>> part of the schema). It's form must be determined after every >>>>>> modification to the instance. Constantly. Not entirely sure how you = do >>>>>> it. >>>>> >>>>> In fact the solution can already be found in RFC 6110: make 'when' >>>>> statement essentially equivalent to 'must', except for a different >>>>> error >>>>> message. >>>>> >>>>>> One other thing. Our generic client application displays the entire >>>>>> schema in a tree graphic component and even offers queries to be mad= e >>>>>> from it. How could it possibly do that if the tree's final form cann= ot >>>>>> be determined? >>>>>> >>>>>> Also this would make RFC6110 next to useless since the assumption th= at >>>>>> YANG schema is static is the foundation it builds upon. Generating >>>>>> DSDL >>>>>> schema is an expensive operation...and it would have to be done afte= r >>>>>> every modification to an instance document. >>>>> >>>>> Absolutely. It would be possible to forget about RELAX NG and impleme= nt >>>>> all validation in Schematron. However, such an approach would ignore >>>>> the >>>>> lessons learnt by the XML community and embodied in DSDL: Schema-base= d >>>>> validation is a very robust procedure that practically cannot be fool= ed >>>>> and >>>>> provides guarantees that the instance document is syntactically corre= ct >>>>> so >>>>> that it can be safely parsed. Validation based on checking XPath >>>>> expressions >>>>> is much more fragile and is best used only for "business rules" >>>>> (semantic >>>>> constrainst) AFTER schema-based validation has been successfully >>>>> finished. >>>>> >>>>>> The when-stmt only makes its parent data definition statement >>>>>> conditional. There's nothing written in RFC6020 that this would impl= y >>>>>> modifications to the schema (can't find it). Although multiple >>>>>> paragraphs can be found which serve as workarounds for non-static >>>>>> implementations of YANG schema. The point in 8.3.1 Payload Parsing >>>>>> which >>>>>> relates to when-stmt is an example. >>>>>> >>>>>> Sorry, but I'm completely with Ladislav on this one. Non-static sche= ma >>>>>> or run-time changes to a schema are bad and should never have been >>>>>> allowed to become a part of YANG. I cannot argue that they are not a >>>>>> part of it. >>>>> >>>>> Agreed. >>>>> >>>>> Lada >>>>> >>>>>> Jernej >>>>>> >>>>>>>> It doesn't matter how the error is generated. But it should be >>>>>>>> properly >>>>>>>> generated. >>>>>>>> >>>>>>>> Jernej >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>>>> Lada >>>>>>>>> >>>>>>>>>> But I can see how this is problematic. >>>>>>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>>>>>> It is used for unknown and unexpected elements. >>>>>>>>>> If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse we= would >>>>>>>>>> have >>>>>>>>>> to >>>>>>>>>> decide if that node is unknown by the server, vs. an instance >>>>>>>>>> of that node is unexpected for the request. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Lada >>>>>>>>>>> >>>>>>>>>> Andy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Or does a conditional augment mean that the augmentation will >>>>>>>>>>>> always be >>>>>>>>>>>> done but all of the augmented nodes "inherit" the augment's wh= en >>>>>>>>>>>> conditions >>>>>>>>>>>> making all of them conditional? This would make much more sens= e >>>>>>>>>>>> to >>>>>>>>>>>> me. Would >>>>>>>>>>>> this be legal as a potential workaround to dynamically changin= g >>>>>>>>>>>> a >>>>>>>>>>>> module's >>>>>>>>>>>> schema? What was the group's intention regarding this matter? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> netmod mailing list >>>>>>>>>>> netmod@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>> >>> > From ietfc@btconnect.com Fri Aug 3 07:38:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F1C21F8DB9 for ; Fri, 3 Aug 2012 07:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXt+fOYmRTWH for ; Fri, 3 Aug 2012 07:38:49 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id BB6D621F8D96 for ; Fri, 3 Aug 2012 07:38:48 -0700 (PDT) Received: from mail103-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 14:38:47 +0000 Received: from mail103-ch1 (localhost [127.0.0.1]) by mail103-ch1-R.bigfish.com (Postfix) with ESMTP id 4DDB24E0525; Fri, 3 Aug 2012 14:38:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz9371I146fI542M1432I1418I4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail103-ch1 (localhost.localdomain [127.0.0.1]) by mail103-ch1 (MessageSwitch) id 1344004725575599_23399; Fri, 3 Aug 2012 14:38:45 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail103-ch1.bigfish.com (Postfix) with ESMTP id 812E54A00CE; Fri, 3 Aug 2012 14:38:45 +0000 (UTC) Received: from DB3PRD0702HT001.eurprd07.prod.outlook.com (157.55.224.141) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 14:38:43 +0000 Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by pod51017.outlook.com (10.3.4.141) with Microsoft SMTP Server (TLS) id 14.15.108.4; Fri, 3 Aug 2012 14:38:38 +0000 Message-ID: <005a01cd7185$0fce9bc0$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> <006701cd70b7$4f0b9e60$4001a8c0@gateway.2wire.net> Date: Fri, 3 Aug 2012 15:34:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.21] X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:38:50 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" ; "Yi Yang (yiya)" Cc: Sent: Friday, August 03, 2012 12:10 AM > "t.petch" writes: > > > > In a sense I agree with you, in a sense I think the exact opposite. > > > > This topic of what tables there are in a box that routes packets has > > surfaced before. I see, in a typical I-D produced about routing, > > reference to FIB and RIB, without any need to define or explain the > > terms, they are that well known, they are what routers and other boxes > > have as a matter or course. > > Yes, it's been my problem that I couldn't find a precise definition of these acronyms, and I understand most routing experts use the definition "you know it when you see it". > > > > > For me, it is the FIB that is always present; if you do not know where > > to send a packet, how to route it, then you are not an IP box of any > > shape or form - you must have a FIB.. In simple boxes, like Linux or > > Windows, then that is all you have. > > > > In more sophisticated boxes, 'proper' routers, for some meaning of the > > word proper, then you need much more data, which may closely model the > > FIB, as with RIP, or may be utterly different, as with OSPF, and for > > this, I see the term RIB used, initially with BGP but latterly with any > > routing protocol. RIBs vary widely with the routing protocol and so are > > properly part of routing protocol extensions. > > So at the level of the present core routing model we are dealing with FIBs, but as soon as a BGP module augments routes with that sophisticated stuff a FIB gets promoted to a RIB, right? But this may be quite confusing from the point of view of the I-D text, and in this case I would probably prefer to avoid these acronyms entirely and use only "routing table". > > > > > So I think that this I-D gets the terminology quite wrong; as I say, > > this has surfaced before without any visible change to the I-D. I was > > surprised that this topic attracted no comment from the Routing > > Directorate. > > Can you suggest what to do in order to get the terminology right? > > Anyway, I think that Yi Yang's comments were about "forwarding table", i.e. a (simplified) routing table which by definition contains only active routes. I think this a misuse of forwarding table:-( RIB is defined in RFC1771 (BGP) and later BGP RFC such as RFC2439 (Nov 1998) and RFC4771; it is clearly not the routing table, containing everything including the kitchen sink and its structure is specific to BGP. But I see the term applied generically to what is learnt by an instance of a routing protocol, and so could be applied to the equivalent structures of EIGRP or IS-IS, which are very different in kind. Sometimes I see it used generically to include everything learnt by all instances of all routing protocols but I think that that is wrong. FIB appears in RFC1812 "The goal of the next-hop selection process is to examine the entries in the router's Forwarding Information Base (FIB) and select the best route (if there is one) for the packet from those available in the FIB." which is what, in popular parlance, is a routing table. For example, Moy, writing on OSPF, says "A router's routing table instructs the router how to forward packets. Given a packet, the router performs a routing table lookup, using the packet's IP destination address as a key. This lookup returns the best matching routing table entry ..." I would not expect the term FIB to include all the baggage that routing protocols provide nor for it to include any route which is not available, as far as the host or router knows, for immediate use. But the terms FIB and RIB are a bit specialised; I-Ds such as draft-uttaro-idr-bgp-persistence-01 and draft-ietf-grow-simple-va-11 use them without any explanation as do posters on many if not most of the WG lists in Routing and parts of Operations Areas, but that is probably not appropriate for this I-D, just as the terms are not used in, eg, RFC2096, which is entitled 'IP Forwarding Table MIB' but then defines 'IP CIDR Route Table', the DESCRIPTION of which is "This entity's IP Routing table."; oh dear, you can't win! So I think that conceptually, you should be defining the FIB, of usable routes from which the next hop or interface of a packet is selected on the basis of longest match, but probably calling it a route or routing table since that is the term most widely used. Where individual router manufactuers do clever things on line cards, then that is best modelled by clever router manufacturers, even if they are all doing something similar - the speed and rate of change of those data structures probably makes them unsuitable for MIB, yang or anything else. You should allow for augmentation, or some such; BGP revolves around peers and path attributes (RFC4273) and avoids all mention of FIB, RIB or the IP Route Table. OSPF (RFC4750) covers interfaces, neighbors, areas and link states, and has a reference to the Forwarding Table. RIP(RFC1724) has interfaces and peers and refers to the "the IP Route Database by RIP" Yup, you can't win, but referring to RFC1812 is unlikely to lose. Tom Petch > Thanks, Lada > > > > > Tom Petch > > > > Yi > > From mbj@tail-f.com Fri Aug 3 07:45:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676A221F8D39 for ; Fri, 3 Aug 2012 07:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miL5LTv6URSx for ; Fri, 3 Aug 2012 07:45:43 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D906821F8D9F for ; Fri, 3 Aug 2012 07:45:42 -0700 (PDT) Received: from localhost (dhcp-414b.meeting.ietf.org [130.129.65.75]) by mail.tail-f.com (Postfix) with ESMTPSA id E8E6D1200D66; Fri, 3 Aug 2012 16:45:39 +0200 (CEST) Date: Fri, 03 Aug 2012 07:45:37 -0700 (PDT) Message-Id: <20120803.074537.496599422.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20120802163323.GA86561@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:45:43 -0000 Andy Bierman wrote: > IMO, it is unacceptable to rely on the existence of IF-MIB > in order to retrieve interface counters. So which objects are we talking about? For example, does it still make sense to include both the 32-bit and 64-bit counters? How do we represent speed/highspeed? Do we keep the ifCounterDiscontinuityTime, defined in terms of sysUpTime? /martin From andy@yumaworks.com Fri Aug 3 08:08:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E94421F8D9F for ; Fri, 3 Aug 2012 08:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tv9e4YxF0uI for ; Fri, 3 Aug 2012 08:08:36 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D49D121F8D9A for ; Fri, 3 Aug 2012 08:08:35 -0700 (PDT) Received: by qadz3 with SMTP id z3so4198861qad.10 for ; Fri, 03 Aug 2012 08:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=75uAk/ZWDDxXzEEAb5Sd1fVq34/CNLzOAuaZT1Kb4e4=; b=UyEcRRFIFm1zbjvSbEe5+tVr+abCoHFkBN+0emflmGiWcVhTgrpq9UfZny6C9EGq3i 7F+WPyftyCJMgL1p6t/JDTfNVNagnp41TVZv9AsVDZAv4iQKcQ4EmtpT9fky5rHQVDs9 q3X1KcZhZWKF9d0kwYPj04oPullS0rj1BDNkG5I7h5GF9Gn9agKDNiP5JbHxWwIpvSuZ T9V+6yXb0LEacyZptZEXckGQeJfY33+AfdrMqozEDPtDC84nbFARdn8mUrdR8+CRAJTN PmgxoGdq2/NImBo2MkpZnKyaCrEIiET3BBC7t4qhKjE1VjnaD8cgTgmeQM6s57bSRcuo /HaA== MIME-Version: 1.0 Received: by 10.224.42.76 with SMTP id r12mr3172513qae.96.1344006515314; Fri, 03 Aug 2012 08:08:35 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Fri, 3 Aug 2012 08:08:35 -0700 (PDT) X-Originating-IP: [130.129.65.206] In-Reply-To: <20120803.074537.496599422.mbj@tail-f.com> References: <20120802163323.GA86561@elstar.local> <20120803.074537.496599422.mbj@tail-f.com> Date: Fri, 3 Aug 2012 08:08:35 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlDa3s0l3joi1j/ctZnOwsqMU+ROlbgyp00kX9b4NssT5PY8MXm4WZ0iy0RnV68nUwnXXIr Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:08:36 -0000 On Fri, Aug 3, 2012 at 7:45 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO, it is unacceptable to rely on the existence of IF-MIB >> in order to retrieve interface counters. > > So which objects are we talking about? For example, does it still > make sense to include both the 32-bit and 64-bit counters? How do we > represent speed/highspeed? Do we keep the ifCounterDiscontinuityTime, > defined in terms of sysUpTime? > I would say just 64-bit counters and use a date-and-time object, not sysUpTime. > > /martin Andy From pgili@cisco.com Fri Aug 3 08:09:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C0D21F8DB5 for ; Fri, 3 Aug 2012 08:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 022iPaifLJGs for ; Fri, 3 Aug 2012 08:09:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E9DD521F8D9A for ; Fri, 3 Aug 2012 08:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=1336; q=dns/txt; s=iport; t=1344006594; x=1345216194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DpBNOBqtPDKFvyK1KTiPwKwxhd8SVx8WxnKn0JH+hvI=; b=ZmAumo8AqMlThvyFI4BOzPf7dgfeXHvKYtGcEHqHGAzw0trCPnUZWRI4 YizCEMbkqyxuzghY8Xpz656OHlDA72Ya8Xbzcr6zXUT7PrA0Nujm9nXoh xp1SyYHlrKuPLsMiT+w2w04ZDgkvfhsH2mFnz7ivk0yh38m9NS24Lqsvx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAFXoG1CtJV2Y/2dsb2JhbABFhTRHsi91gQeCIAEBAQQSARARRQwEAgEIEAEEAQEBAgIGHQMCAgIwFAEICAIEAQ0FCBqHa5xGjRmTEYEhiieFcjJgA6NxgWaCXw X-IronPort-AV: E=Sophos;i="4.77,706,1336348800"; d="scan'208";a="108231118" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 03 Aug 2012 15:09:51 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q73F9pog026770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 15:09:51 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.239]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 10:09:51 -0500 From: "Patrick Gili (pgili)" To: Andy Bierman , Martin Bjorklund Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNcDeBpLzaXn+U8UWilvWloQKDDJdGaagQgACHzQD//7eD4IAAYocAgAAA9ICAAAhbgIABa96AgAAGa4D//6xooA== Date: Fri, 3 Aug 2012 15:09:51 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB037D2B@xmb-aln-x14.cisco.com> References: <20120802163323.GA86561@elstar.local> <20120803.074537.496599422.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--26.934600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:09:56 -0000 RGlzY29udGludWl0eSB0aW1lIGlzIHN0aWxsIHZlcnkgaW1wb3J0YW50LCBpbmRlcGVuZGVudCBv ZiB3aGF0IHdlIHVzZSBmb3IgdGhlIGVwb2NoLg0KDQpQYXRyaWNrDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5j b21dIA0KU2VudDogRnJpZGF5LCBBdWd1c3QgMDMsIDIwMTIgMTE6MDkgQU0NClRvOiBNYXJ0aW4g QmpvcmtsdW5kDQpDYzogai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlOyBQYXRy aWNrIEdpbGkgKHBnaWxpKTsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0g Y29tbWVudCBvbiBpZXRmLWludGVyZmFjZXMgbW9kdWxlDQoNCk9uIEZyaSwgQXVnIDMsIDIwMTIg YXQgNzo0NSBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KPiBB bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+PiBJTU8sIGl0IGlzIHVu YWNjZXB0YWJsZSB0byByZWx5IG9uIHRoZSBleGlzdGVuY2Ugb2YgSUYtTUlCIGluIG9yZGVyIA0K Pj4gdG8gcmV0cmlldmUgaW50ZXJmYWNlIGNvdW50ZXJzLg0KPg0KPiBTbyB3aGljaCBvYmplY3Rz IGFyZSB3ZSB0YWxraW5nIGFib3V0PyAgRm9yIGV4YW1wbGUsIGRvZXMgaXQgc3RpbGwgDQo+IG1h a2Ugc2Vuc2UgdG8gaW5jbHVkZSBib3RoIHRoZSAzMi1iaXQgYW5kIDY0LWJpdCBjb3VudGVycz8g IEhvdyBkbyB3ZSANCj4gcmVwcmVzZW50IHNwZWVkL2hpZ2hzcGVlZD8gIERvIHdlIGtlZXAgdGhl IGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lLCANCj4gZGVmaW5lZCBpbiB0ZXJtcyBvZiBzeXNV cFRpbWU/DQo+DQoNCkkgd291bGQgc2F5IGp1c3QgNjQtYml0IGNvdW50ZXJzIGFuZCB1c2UgYSBk YXRlLWFuZC10aW1lIG9iamVjdCwgbm90IHN5c1VwVGltZS4NCg0KDQo+DQo+IC9tYXJ0aW4NCg0K QW5keQ0K From jonathan@hansfords.net Fri Aug 3 08:59:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9E821F8D62 for ; Fri, 3 Aug 2012 08:59:48 -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=-1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2bDUjcTRMRm for ; Fri, 3 Aug 2012 08:59:42 -0700 (PDT) Received: from avasout02.plus.net (avasout02.plus.net [212.159.14.17]) by ietfa.amsl.com (Postfix) with ESMTP id B737E21F8D5B for ; Fri, 3 Aug 2012 08:59:40 -0700 (PDT) Received: from webmail.plus.net ([212.159.8.87]) by avasout02 with smtp id iFzd1j0021sg6PG01Fzevy; Fri, 03 Aug 2012 16:59:39 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=GvbACzJC c=1 sm=1 a=w/v6d3Yw9YqO0eqsxHCYQw==:17 a=HaVFzea3niEA:10 a=fIUNk3G47tUA:10 a=KLC-wCkyHdQA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=48vgC7mUAAAA:8 a=9eYffA1A2n14GRuIHWAA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=XoTe7g0phlLHtYUXFvkA:9 a=_W_S_7VecoQA:10 a=-E4n7_KIpDVQyQT3:21 a=YkIHqJgUXfH1_HOT:21 a=w/v6d3Yw9YqO0eqsxHCYQw==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-16.in-addr.btopenworld.com ([81.136.210.16]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 03 Aug 2012 16:59:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_cf4f35db7501c6ddc0edb529dbddf32f" Date: Fri, 03 Aug 2012 16:59:37 +0100 From: Jonathan Hansford To: In-Reply-To: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> Message-ID: <78939758ee86bdf7a321b5acb037c7f7@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.16] Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:59:48 -0000 --=_cf4f35db7501c6ddc0edb529dbddf32f Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Protocol Independent Network Management Data Modeling Languages - Lessons Learned from the SMIng Project (draft-schoenw-sming-lessons-01), a document I believe helped inform the development of YANG, states "preference should be give to solutions that simplify the task of readers. Reduction of the efforts required by writers is of secondary importance and the reduction of the efforts required by tool developers is of least important preference." As someone who is still getting up-to-speed on YANG and therefore considers himself primarily a reader for now, I hope the issues that have been discussed in this thread only generate this level of uncertainty for tool developers and the task of readers remains simplified. How esoteric are these discussions? Are we looking at corner cases, or are these issues at the core of YANG module development? Jonathan On 03.08.2012 15:31, Andy Bierman wrote: > I don't think there is much point to discussing implementation details > on the WG mailing list. > > Andy > > On Fri, Aug 3, 2012 at 3:17 AM, Jernej Tuljak wrote: > >> Dne 3.8.2012 10:02, piĆĄe Andy Bierman: >> >>> On Fri, Aug 3, 2012 at 12:21 AM, Jernej Tuljak wrote: >>> >>>> Hi, that's just the beauty of it. It is not a static test tool. It adapts to whatever changes you make to the modules. It adapts when you choose enabled features and it adapts when you change them. It tells you what you did wrong while you write entire datastores, rpc operations, even when dealing with incomplete XML documents. And it does so in quite a simple way. The way of RFC6110, which extracts the entire schema from available modules and with just a few XSLT transformations you are set to go. Forever. It's quite genius really (credit to Ladislav and others involved with RFC6110 here). I don't understand why anyone would bother reinventing the wheel trying to implement his own way of validating NETCONF content when it's all already out there. I never claimed that pyang checks the validity of XPath expressions. It cannot do so, because XPath expressions cannot be evaluated without context and context can only be found within instance documents, a thing that _never_ exists during YANG module validation. It only exists during NETCONF content validation, when you have an actual instance document to work with. Therefore when-stmt cannot be applied at any other time than during content validation. It represents a semantic constraint on data nodes, not a constraint on the schema nodes. And pyang applies these constraints within pyang.dsdl plugin only when it is validating an XML document against a YANG schema. There is no other way. >>> The YANG must and when statements can be checked to make sure the XPath is well-formed and all the schema nodes are actually defined. There is really no reason for an YANG must or when stmt to reference garbage nodes that do not exist in the data model. >>> >>>> I don't understand the need to merge YANG validation with NETCONF content validation into a single validation process. It does not make sense. As I understand it, this is exactly what you are doing. Sometimes it even feels like you are saying that a schema node and an instance node are the same thing. It should be clear that a schema node is not an instance node, the former only represents the structure and conditions of appearance of the latter. Schema nodes never get deleted, instance nodes do. >>> Implementation details do not matter. The server must send the correct responses and alter its internal state correctly. There are many ways this could be done. Some servers allow YANG modules to be loaded and unloaded at run-time. The schema tree is static, meaning once a node is placed in the tree it doesn't move, but the tree can change at run-time. YANG deviations also affect the schema tree, which are allowed to be loaded at any time. >> Of course. That's what makes YANG great. That it's extensible the way any other schema is. A each set of modules may provide a different schema. A single additional module may change the existing schema tree significantly making it another schema. If-features are also great. But do note that these are not the "runtime modifications to the schema tree" me and Ladislav were talking about. What I've been saying all along is that if we have a module set of size one (a single module) it's schema is always the same. A schema node count will always be the same for it. The only way to modify the count is via features or by adding new modules to the set, which does happen, but not often. That's what I mean when I say that YANG is a static schema. An extensible but static schema. Adding a module with deviations, augments, etc. to the set creates a new but also static schema. But none of this should have anything to do with NETCONF content validation. Allowing the schema count to be modified during validation with when-stmt's is just...well, bad. RFC6020 should have never allowed it. Separation of YANG validation/compiling which results in a read-only schema tree and NETCONF content validation, which only uses this schema tree to validate an XML document, should have been enforced. I don't see any merit in this being a single process. Jernej >> >>>> Let's return to Ladislav's example: leaf X { type string; mandatory true; when ". = ../foo"; } >>> Yes, there are some pathological cases that make no semantic sense that cannot be implemented correctly. leaf Y { type int32; mandatory true; when "not(.)"; } >>> >>>> For when-stmt condition to be evaluated _at all_ an instance of X must exist first, meaning that the mandatory constraint is always satisfied if an evaluation occurred. After all X is the condition expression's context node. You cannot evaluate without context. You can however validate it's syntax at any time - provided that you are using a static schema, which contains all the schema nodes for you to search. If when is ever true or false, one can be sure that the mandatory constraint has been satisfied, eliminating the need to enforce it. The above example represents an instance node, which has to exist and fulfill the condition in the when-stmt at the same time. Anything else is an error. It's actually mandatory which takes precedence here, so what Ladislav currently does (structure first, then semantics) is the correct interpretation, IMO. There's a reason why when-stmt's argument is an XPath expression and not a YANG construct, like a schema-nodeid. >>> Yes, so they generate a boolean result. A schema-nodeid is not relevant here. That is used for augment and path targets. Dne 3.8.2012 2:14, piĆĄe Andy Bierman: > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Links: ------ [1] mailto:jernej.tuljak@mg-soft.si [2] mailto:netmod@ietf.org [3] https://www.ietf.org/mailman/listinfo/netmod [4] mailto:jernej.tuljak@mg-soft.si [5] mailto:lhotka@nic.cz --=_cf4f35db7501c6ddc0edb529dbddf32f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 
Protocol Independent Network Management Data Modeling Languages - Less=
ons Learned from the SMIng Project (draft-schoenw-sming-lessons-01), a docu=
ment I believe helped inform the development of YANG, states "preference sh=
ould be give to solutions that simplify the task of readers. Reduction of t=
he efforts required by writers is of secondary importance and the reduction=
 of the efforts required by tool developers is of least important preferenc=
e." 
 
As someone who is still getting up-to-speed on YANG and therefore cons=
iders himself primarily a reader for now, I hope the issues that have been =
discussed in this thread only generate this level of uncertainty for tool d=
evelopers and the task of readers remains simplified. How esoteric are thes=
e discussions? Are we looking at corner cases, or are these issues at the c=
ore of YANG module development?
 
Jonathan

On 03.08.2012 15:31, Andy Bierman wrote:

I don't think there is much point to discussing implementation details
on the WG mailing list.


Andy


On Fri, Aug 3, 2012 at 3:17 AM, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
Dne 3.8.2012 10:02, piše Andy = Bierman:
On Fri, Aug 3, 2012 at 12:21 AM, Jern= ej Tuljak<jernej.tuljak@mg-s= oft.si> wrote:
Hi, that's just the beauty of it. It = is not a static test tool. It adapts to whatever changes you make to the mo= dules. It adapts when you choose enabled features and it adapts when you ch= ange them. It tells you what you did wrong while you write entire datastore= s, rpc operations, even when dealing with incomplete XML documents. And it = does so in quite a simple way. The way of RFC6110, which extracts the entir= e schema from available modules and with just a few XSLT transformations yo= u are set to go. Forever. It's quite genius really (credit to Ladislav and = others involved with RFC6110 here). I don't understand why anyone would bot= her reinventing the wheel trying to implement his own way of validating NET= CONF content when it's all already out there. I never claimed that pyang ch= ecks the validity of XPath expressions. It cannot do so, because XPath expr= essions cannot be evaluated without context and context can only be found w= ithin instance documents, a thing that _never_ exists during YANG module va= lidation. It only exists during NETCONF content validation, when you have a= n actual instance document to work with. Therefore when-stmt cannot be appl= ied at any other time than during content validation. It represents a seman= tic constraint on data nodes, not a constraint on the schema nodes. And pya= ng applies these constraints within pyang.dsdl plugin only when it is valid= ating an XML document against a YANG schema. There is no other way. The YANG must and when statements can be checked to make sure the XPath is = well-formed and all the schema nodes are actually defined. There is really = no reason for an YANG must or when stmt to reference garbage nodes that do = not exist in the data model.
I don't understand the need to merge = YANG validation with NETCONF content validation into a single validation pr= ocess. It does not make sense. As I understand it, this is exactly what you= are doing. Sometimes it even feels like you are saying that a schema node = and an instance node are the same thing. It should be clear that a schema n= ode is not an instance node, the former only represents the structure and c= onditions of appearance of the latter. Schema nodes never get deleted, inst= ance nodes do.
Implementation details do not matter. The server must send the correct resp= onses and alter its internal state correctly. There are many ways this coul= d be done. Some servers allow YANG modules to be loaded and unloaded at run= -time. The schema tree is static, meaning once a node is placed in the tree= it doesn't move, but the tree can change at run-time. YANG deviations also= affect the schema tree, which are allowed to be loaded at any time. Of course. That's what makes YANG great. That it's extensible the way any o= ther schema is. A each set of modules may provide a different schema. A sin= gle additional module may change the existing schema tree significantly mak= ing it another schema. If-features are also great. But do note that these a= re not the "runtime modifications to the schema tree" me and Ladislav were = talking about. What I've been saying all along is that if we have a module = set of size one (a single module) it's schema is always the same. A schema = node count will always be the same for it. The only way to modify the count= is via features or by adding new modules to the set, which does happen, bu= t not often. That's what I mean when I say that YANG is a static schema. An= extensible but static schema. Adding a module with deviations, augments, e= tc. to the set creates a new but also static schema. But none of this shoul= d have anything to do with NETCONF content validation. Allowing the schema = count to be modified during validation with when-stmt's is just...well, bad= =2E RFC6020 should have never allowed it. Separation of YANG validation/com= piling which results in a read-only schema tree and NETCONF content validat= ion, which only uses this schema tree to validate an XML document, should h= ave been enforced. I don't see any merit in this being a single process. Je= rnej
Let's return to Ladislav's example: l= eaf X { type string; mandatory true; when ". =3D ../foo"; }
Yes, there are some pathological cases that make no semantic sense that can= not be implemented correctly. leaf Y { type int32; mandatory true; when "no= t(.)"; }
For when-stmt condition to be evaluat= ed _at all_ an instance of X must exist first, meaning that the mandatory c= onstraint is always satisfied if an evaluation occurred. After all X is the= condition expression's context node. You cannot evaluate without context= =2E You can however validate it's syntax at any time - provided that you ar= e using a static schema, which contains all the schema nodes for you to sea= rch. If when is ever true or false, one can be sure that the mandatory cons= traint has been satisfied, eliminating the need to enforce it. The above ex= ample represents an instance node, which has to exist and fulfill the condi= tion in the when-stmt at the same time. Anything else is an error. It's act= ually mandatory which takes precedence here, so what Ladislav currently doe= s (structure first, then semantics) is the correct interpretation, IMO. The= re's a reason why when-stmt's argument is an XPath expression and not a YAN= G construct, like a schema-nodeid.
Yes, so they generate a boolean result. A schema-nodeid is not relevant her= e. That is used for augment and path targets.
Jernej
Andy
Dne 3.8.2012 2:14, piše Andy B= ierman:
Hi, Sorry but YANG does not work the = way you think it does for the sake of your static test tool. BTW, pyang doe= s not validate the XPath statement. It validates instance documents against= the XPath that it finds. This is hardly the same as verifying the correctn= ess of the YANG statement. A false when-stmt is not an error unless it occu= rs in the RPC input parameters. (We are insulated fromcontent because it is= declared as an 'anyxml' so from a RPC POV, the when-stmts within the data = are not relevant to RPC input validation.) The XPath statements are concept= ual. There is no requirement by the server to use an XPath validator to imp= lement them. When-stmt is applied right away, not applied at validation tim= e like must-stmt. Andy On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka<<= a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz> wrote:
Jernej Tuljak<jernej.tuljak@mg-soft.si> writes:
I think that the idea to completely d= ecouple the schema from instances based on it is the way to go. Your schema= is not such a schema, since it needs an instance to determine it's final f= orm (the instance becomes a part of the schema). It's form must be determin= ed after every modification to the instance. Constantly. Not entirely sure = how you do it.
In fact the solution can already be found in RFC 6110: make 'when' statemen= t essentially equivalent to 'must', except for a different error message.
One other thing. Our generic client a= pplication displays the entire schema in a tree graphic component and even = offers queries to be made from it. How could it possibly do that if the tre= e's final form cannot be determined? Also this would make RFC6110 next to u= seless since the assumption that YANG schema is static is the foundation it= builds upon. Generating DSDL schema is an expensive operation...and it wou= ld have to be done after every modification to an instance document. Absolutely. It would be possible to forget about RELAX NG and implement all= validation in Schematron. However, such an approach would ignore the lesso= ns learnt by the XML community and embodied in DSDL: Schema-based validatio= n is a very robust procedure that practically cannot be fooled and provides= guarantees that the instance document is syntactically correct so that it = can be safely parsed. Validation based on checking XPath expressions is muc= h more fragile and is best used only for "business rules" (semantic constra= inst) AFTER schema-based validation has been successfully finished.
The when-stmt only makes its parent d= ata definition statement conditional. There's nothing written in RFC6020 th= at this would imply modifications to the schema (can't find it). Although m= ultiple paragraphs can be found which serve as workarounds for non-static i= mplementations of YANG schema. The point in 8.3.1 Payload Parsing which rel= ates to when-stmt is an example. Sorry, but I'm completely with Ladislav on= this one. Non-static schema or run-time changes to a schema are bad and sh= ould never have been allowed to become a part of YANG. I cannot argue that = they are not a part of it.
Agreed. Lada
Jernej
It doesn't matter how the error is ge= nerated. But it should be properly generated. Jernej
Andy
Lada
But I can see how this is problematic= =2E Good thing we overloaded the unknown-element error-tag ;-) It is used f= or unknown and unexpected elements. If /foo/bar only exists if when=3Dtrue,= then for when=3Dfalse we would have to decide if that node is unknown by t= he server, vs. an instance of that node is unexpected for the request.
Lada
Andy
Or does a conditional augment mean th= at the augmentation will always be done but all of the augmented nodes "inh= erit" the augment's when conditions making all of them conditional? This wo= uld make much more sense to me. Would this be legal as a potential workarou= nd to dynamically changing a module's schema? What was the group's intentio= n regarding this matter?
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ______________________= _________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf=
=2Eorg/mailman/listinfo/netmod
 
--=_cf4f35db7501c6ddc0edb529dbddf32f-- From j.schoenwaelder@jacobs-university.de Fri Aug 3 09:09:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F6621F8E14 for ; Fri, 3 Aug 2012 09:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J79TkRr5BFBI for ; Fri, 3 Aug 2012 09:09:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCD721F8E10 for ; Fri, 3 Aug 2012 09:09:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F97A20C0F; Fri, 3 Aug 2012 18:09:13 +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 PZwvA9OjGXdY; Fri, 3 Aug 2012 18:09:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C6E920BFD; Fri, 3 Aug 2012 18:09:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4D52B2103E89; Fri, 3 Aug 2012 18:09:12 +0200 (CEST) Date: Fri, 3 Aug 2012 18:09:12 +0200 From: Juergen Schoenwaelder To: Jonathan Hansford Message-ID: <20120803160911.GA88788@elstar.local> Mail-Followup-To: Jonathan Hansford , netmod@ietf.org References: <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> <78939758ee86bdf7a321b5acb037c7f7@imap.plus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78939758ee86bdf7a321b5acb037c7f7@imap.plus.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:09:18 -0000 On Fri, Aug 03, 2012 at 04:59:37PM +0100, Jonathan Hansford wrote: > > As someone who is still getting > up-to-speed on YANG and therefore considers himself primarily a reader > for now, I hope the issues that have been discussed in this thread only > generate this level of uncertainty for tool developers and the task of > readers remains simplified. How esoteric are these discussions? Are we > looking at corner cases, or are these issues at the core of YANG module > development? > My take is that these discussions, as important they might be for implementors, are for most users a non issue, especially readers. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Fri Aug 3 10:01:20 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F8121F8E23 for ; Fri, 3 Aug 2012 10:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R6SEE-hI2m7 for ; Fri, 3 Aug 2012 10:01:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 344CC21F8E19 for ; Fri, 3 Aug 2012 10:01:18 -0700 (PDT) Received: from [IPv6:2001:df8::16:e007:eac8:1110:3edd] (unknown [IPv6:2001:df8:0:16:e007:eac8:1110:3edd]) by mail.nic.cz (Postfix) with ESMTPSA id 7128613FE09; Fri, 3 Aug 2012 19:01:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344013277; bh=Ns2h6l6gPXCZtaWPJB3OXToCB/mgxbPYAi8bvjucZ3E=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iyIaSZqw1JtfyJ9Qm5gy9KFmAl2Fn3Ese0DcZZcDz/N5AfnX0xA1DYtpvm3wB3xml qiXYWMVgCX2xDAelnMoonk4cY6jLqJfaw5k6i0Pxyhfrx4Kxt/LVnBFu50S4dYXck1 vn/5zwZ6mz4SEUit2H5O8Rze1rwvSeknpuMQUtgU= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: Date: Fri, 3 Aug 2012 10:01:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:01:20 -0000 On Aug 3, 2012, at 7:31 AM, Andy Bierman wrote: > I don't think there is much point to discussing implementation details > on the WG mailing list. It is not an implementation detail! What Jernej and I are trying to = communicate is that the current handling of 'when' constraints and the = related "auto-deletion" of nodes is not only hard-to-implement but also = ill-defined and broken. But as long as you dismiss any evidence of this = plain fact as "corner cases" we can hardly make our point. The thing is: With increasing complexity of our data models, we must be = sure that our foundation is rock solid. With a complex model, such a = "corner case" can lead to mysterious behaviour or outright failures. Let = me paraphrase a Czech saying: A hundred corner cases are able to plague = a donkey. Anyway, here is another corner case that we already had in our private = discussion: container foo { when "bar !=3D 42"; leaf bar { type uint8; mandatory "true"; } } 1. The "bar" leaf is set to 42 by the client. 2. The "foo" container is auto-deleted. 3. The XPath expression in 'when' loses its context node, so the = expression is not properly defined and cannot be used=20 for any argumentation about validity. 4. But then there is no reason why the mandatory leaf and container are = missing. 5. So what? Lada =20 =20 >=20 >=20 > Andy >=20 >=20 > On Fri, Aug 3, 2012 at 3:17 AM, Jernej Tuljak = wrote: >> Dne 3.8.2012 10:02, pi=9Ae Andy Bierman: >>>=20 >>> On Fri, Aug 3, 2012 at 12:21 AM, Jernej = Tuljak >>> wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> that's just the beauty of it. It is not a static test tool. It = adapts to >>>> whatever changes you make to the modules. It adapts when you choose >>>> enabled >>>> features and it adapts when you change them. It tells you what you = did >>>> wrong >>>> while you write entire datastores, rpc operations, even when = dealing with >>>> incomplete XML documents. And it does so in quite a simple way. The = way >>>> of >>>> RFC6110, which extracts the entire schema from available modules = and with >>>> just a few XSLT transformations you are set to go. Forever. It's = quite >>>> genius really (credit to Ladislav and others involved with RFC6110 = here). >>>> I >>>> don't understand why anyone would bother reinventing the wheel = trying to >>>> implement his own way of validating NETCONF content when it's all = already >>>> out there. >>>>=20 >>>> I never claimed that pyang checks the validity of XPath = expressions. It >>>> cannot do so, because XPath expressions cannot be evaluated without >>>> context >>>> and context can only be found within instance documents, a thing = that >>>> _never_ exists during YANG module validation. It only exists during >>>> NETCONF >>>> content validation, when you have an actual instance document to = work >>>> with. >>>> Therefore when-stmt cannot be applied at any other time than during >>>> content >>>> validation. It represents a semantic constraint on data nodes, not = a >>>> constraint on the schema nodes. And pyang applies these constraints >>>> within >>>> pyang.dsdl plugin only when it is validating an XML document = against a >>>> YANG >>>> schema. There is no other way. >>>=20 >>> The YANG must and when statements can be checked to make sure >>> the XPath is well-formed and all the schema nodes are actually = defined. >>> There is really no reason for an YANG must or when stmt to reference >>> garbage nodes that do not exist in the data model. >>>=20 >>>=20 >>>> I don't understand the need to merge YANG validation with NETCONF = content >>>> validation into a single validation process. It does not make = sense. As I >>>> understand it, this is exactly what you are doing. Sometimes it = even >>>> feels >>>> like you are saying that a schema node and an instance node are the = same >>>> thing. It should be clear that a schema node is not an instance = node, the >>>> former only represents the structure and conditions of appearance = of the >>>> latter. Schema nodes never get deleted, instance nodes do. >>>>=20 >>> Implementation details do not matter. >>> The server must send the correct responses and alter its >>> internal state correctly. There are many ways this could >>> be done. >>>=20 >>> Some servers allow YANG modules to be loaded and unloaded >>> at run-time. The schema tree is static, meaning once a node >>> is placed in the tree it doesn't move, but the tree can change at >>> run-time. >>> YANG deviations also affect the schema tree, which are allowed to >>> be loaded at any time. >>=20 >>=20 >> Of course. That's what makes YANG great. That it's extensible the way = any >> other schema is. A each set of modules may provide a different = schema. A >> single additional module may change the existing schema tree = significantly >> making it another schema. If-features are also great. But do note = that these >> are not the "runtime modifications to the schema tree" me and = Ladislav were >> talking about. What I've been saying all along is that if we have a = module >> set of size one (a single module) it's schema is always the same. A = schema >> node count will always be the same for it. The only way to modify the = count >> is via features or by adding new modules to the set, which does = happen, but >> not often. That's what I mean when I say that YANG is a static = schema. An >> extensible but static schema. Adding a module with deviations, = augments, >> etc. to the set creates a new but also static schema. >>=20 >> But none of this should have anything to do with NETCONF content = validation. >> Allowing the schema count to be modified during validation with = when-stmt's >> is just...well, bad. RFC6020 should have never allowed it. Separation = of >> YANG validation/compiling which results in a read-only schema tree = and >> NETCONF content validation, which only uses this schema tree to = validate an >> XML document, should have been enforced. I don't see any merit in = this being >> a single process. >>=20 >> Jernej >>=20 >>>=20 >>>> Let's return to Ladislav's example: >>>>=20 >>>> leaf X { >>>> type string; >>>> mandatory true; >>>> when ". =3D ../foo"; >>>> } >>>>=20 >>> Yes, there are some pathological cases that make no >>> semantic sense that cannot be implemented correctly. >>>=20 >>> leaf Y { >>> type int32; >>> mandatory true; >>> when "not(.)"; >>> } >>>=20 >>>=20 >>>> For when-stmt condition to be evaluated _at all_ an instance of X = must >>>> exist >>>> first, meaning that the mandatory constraint is always satisfied if = an >>>> evaluation occurred. After all X is the condition expression's = context >>>> node. >>>> You cannot evaluate without context. You can however validate it's = syntax >>>> at >>>> any time - provided that you are using a static schema, which = contains >>>> all >>>> the schema nodes for you to search. >>>>=20 >>>> If when is ever true or false, one can be sure that the mandatory >>>> constraint >>>> has been satisfied, eliminating the need to enforce it. >>>>=20 >>>> The above example represents an instance node, which has to exist = and >>>> fulfill the condition in the when-stmt at the same time. Anything = else is >>>> an >>>> error. It's actually mandatory which takes precedence here, so what >>>> Ladislav >>>> currently does (structure first, then semantics) is the correct >>>> interpretation, IMO. >>>>=20 >>>> There's a reason why when-stmt's argument is an XPath expression = and not >>>> a >>>> YANG construct, like a schema-nodeid. >>>=20 >>> Yes, so they generate a boolean result. >>> A schema-nodeid is not relevant here. >>> That is used for augment and path targets. >>>=20 >>>=20 >>>=20 >>>> Jernej >>>=20 >>>=20 >>> Andy >>>=20 >>>> Dne 3.8.2012 2:14, pi=9Ae Andy Bierman: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Sorry but YANG does not work the way you think it does for the = sake of >>>>> your static test tool. BTW, pyang does not validate the XPath >>>>> statement. >>>>> It validates instance documents against the XPath that it finds. >>>>> This is hardly the same as verifying the correctness of the YANG >>>>> statement. >>>>>=20 >>>>> A false when-stmt is not an error unless it occurs in the RPC = input >>>>> parameters. (We are insulated from content because it >>>>> is declared as an 'anyxml' so from a RPC POV, the when-stmts >>>>> within the data are not relevant to RPC input validation.) >>>>>=20 >>>>> The XPath statements are conceptual. There is no requirement >>>>> by the server to use an XPath validator to implement them. >>>>> When-stmt is applied right away, not applied at validation >>>>> time like must-stmt. >>>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>> On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka = wrote: >>>>>>=20 >>>>>> Jernej Tuljak writes: >>>>>>=20 >>>>>>> I think that the idea to completely decouple the schema from = instances >>>>>>> based on it is the way to go. Your schema is not such a schema, = since >>>>>>> it >>>>>>> needs an instance to determine it's final form (the instance = becomes a >>>>>>> part of the schema). It's form must be determined after every >>>>>>> modification to the instance. Constantly. Not entirely sure how = you do >>>>>>> it. >>>>>>=20 >>>>>> In fact the solution can already be found in RFC 6110: make = 'when' >>>>>> statement essentially equivalent to 'must', except for a = different >>>>>> error >>>>>> message. >>>>>>=20 >>>>>>> One other thing. Our generic client application displays the = entire >>>>>>> schema in a tree graphic component and even offers queries to be = made >>>>>>> from it. How could it possibly do that if the tree's final form = cannot >>>>>>> be determined? >>>>>>>=20 >>>>>>> Also this would make RFC6110 next to useless since the = assumption that >>>>>>> YANG schema is static is the foundation it builds upon. = Generating >>>>>>> DSDL >>>>>>> schema is an expensive operation...and it would have to be done = after >>>>>>> every modification to an instance document. >>>>>>=20 >>>>>> Absolutely. It would be possible to forget about RELAX NG and = implement >>>>>> all validation in Schematron. However, such an approach would = ignore >>>>>> the >>>>>> lessons learnt by the XML community and embodied in DSDL: = Schema-based >>>>>> validation is a very robust procedure that practically cannot be = fooled >>>>>> and >>>>>> provides guarantees that the instance document is syntactically = correct >>>>>> so >>>>>> that it can be safely parsed. Validation based on checking XPath >>>>>> expressions >>>>>> is much more fragile and is best used only for "business rules" >>>>>> (semantic >>>>>> constrainst) AFTER schema-based validation has been successfully >>>>>> finished. >>>>>>=20 >>>>>>> The when-stmt only makes its parent data definition statement >>>>>>> conditional. There's nothing written in RFC6020 that this would = imply >>>>>>> modifications to the schema (can't find it). Although multiple >>>>>>> paragraphs can be found which serve as workarounds for = non-static >>>>>>> implementations of YANG schema. The point in 8.3.1 Payload = Parsing >>>>>>> which >>>>>>> relates to when-stmt is an example. >>>>>>>=20 >>>>>>> Sorry, but I'm completely with Ladislav on this one. Non-static = schema >>>>>>> or run-time changes to a schema are bad and should never have = been >>>>>>> allowed to become a part of YANG. I cannot argue that they are = not a >>>>>>> part of it. >>>>>>=20 >>>>>> Agreed. >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>> Jernej >>>>>>>=20 >>>>>>>>> It doesn't matter how the error is generated. But it should be >>>>>>>>> properly >>>>>>>>> generated. >>>>>>>>>=20 >>>>>>>>> Jernej >>>>>>>>=20 >>>>>>>> Andy >>>>>>>>=20 >>>>>>>>>> Lada >>>>>>>>>>=20 >>>>>>>>>>> But I can see how this is problematic. >>>>>>>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>>>>>>> It is used for unknown and unexpected elements. >>>>>>>>>>> If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse = we would >>>>>>>>>>> have >>>>>>>>>>> to >>>>>>>>>>> decide if that node is unknown by the server, vs. an = instance >>>>>>>>>>> of that node is unexpected for the request. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> Lada >>>>>>>>>>>>=20 >>>>>>>>>>> Andy >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>> Or does a conditional augment mean that the augmentation = will >>>>>>>>>>>>> always be >>>>>>>>>>>>> done but all of the augmented nodes "inherit" the = augment's when >>>>>>>>>>>>> conditions >>>>>>>>>>>>> making all of them conditional? This would make much more = sense >>>>>>>>>>>>> to >>>>>>>>>>>>> me. Would >>>>>>>>>>>>> this be legal as a potential workaround to dynamically = changing >>>>>>>>>>>>> a >>>>>>>>>>>>> module's >>>>>>>>>>>>> schema? What was the group's intention regarding this = matter? >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> netmod mailing list >>>>>>>>>>>> netmod@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Aug 3 10:08:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179CA21F8DDA for ; Fri, 3 Aug 2012 10:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zipzR+dFLp9h for ; Fri, 3 Aug 2012 10:08:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6521F8DD6 for ; Fri, 3 Aug 2012 10:08:30 -0700 (PDT) Received: from [IPv6:2001:df8::16:e007:eac8:1110:3edd] (unknown [IPv6:2001:df8:0:16:e007:eac8:1110:3edd]) by mail.nic.cz (Postfix) with ESMTPSA id D008D13FE09; Fri, 3 Aug 2012 19:08:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344013706; bh=JQBrXvKd5o3cSskd9rf9PAhpaFWxhgooban/urGXQK8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=L8FKa+aXaiuc5QhShtrZii/zsl1XuEXacZ4vEe4BX43DYIux/zn71CvGREjWBvBdZ 55LYAJwDoFeTqJZx1nhFe1aO+bdWyW+aPIBvtB2mFMZkqA+FI8wAd1yaOH8KooM1id 2lkMoGDIR21x/fUMFQOILiSxyvzQ5BxrEONCZBRc= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120803160911.GA88788@elstar.local> Date: Fri, 3 Aug 2012 10:08:24 -0700 Content-Transfer-Encoding: 7bit Message-Id: <62E386CF-D723-4C27-A6CB-AD00D680C32A@nic.cz> References: <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> <78939758ee86bdf7a321b5acb037c7f7@imap.plus.net> <20120803160911.GA88788@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:08:31 -0000 On Aug 3, 2012, at 9:09 AM, Juergen Schoenwaelder wrote: > On Fri, Aug 03, 2012 at 04:59:37PM +0100, Jonathan Hansford wrote: >> >> As someone who is still getting >> up-to-speed on YANG and therefore considers himself primarily a reader >> for now, I hope the issues that have been discussed in this thread only >> generate this level of uncertainty for tool developers and the task of >> readers remains simplified. How esoteric are these discussions? Are we >> looking at corner cases, or are these issues at the core of YANG module >> development? >> > > My take is that these discussions, as important they might be for > implementors, are for most users a non issue, especially readers. This is an IETF WG mailing list, not "yang-readers". Lada > > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Aug 3 11:45:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E9921F8DA0 for ; Fri, 3 Aug 2012 11:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRSjQToSQpmq for ; Fri, 3 Aug 2012 11:45:39 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4F79B21F8D53 for ; Fri, 3 Aug 2012 11:45:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7320A5402D9; Fri, 3 Aug 2012 20:45:33 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uu5U0GcWRU7; Fri, 3 Aug 2012 20:45:29 +0200 (CEST) Received: from localhost (dhcp-16a6.meeting.ietf.org [130.129.22.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2877A5401E6; Fri, 3 Aug 2012 20:45:26 +0200 (CEST) From: Ladislav Lhotka To: "t.petch" In-Reply-To: <005a01cd7185$0fce9bc0$4001a8c0@gateway.2wire.net> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> <006701cd70b7$4f0b9e60$4001a8c0@gateway.2wire.net> <005a01cd7185$0fce9bc0$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "t.petch" , netmod@ietf.org Date: Fri, 03 Aug 2012 11:45:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:45:40 -0000 Hi Tom, thank you for a detailed explanation. The moral of the story for me is that it is probably better to avoid FIB/RIB and use "routing table" everywhere, although it may look "less sophisticated". As for the term "forwarding table", it is used in this sense in Junos documentation: http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/routing-protocols-routing-databases-overview.html Lada "t.petch" writes: > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "t.petch" ; "Yi Yang (yiya)" > Cc: > Sent: Friday, August 03, 2012 12:10 AM >> "t.petch" writes: >> > >> > In a sense I agree with you, in a sense I think the exact opposite. >> > >> > This topic of what tables there are in a box that routes packets has >> > surfaced before. I see, in a typical I-D produced about routing, >> > reference to FIB and RIB, without any need to define or explain the >> > terms, they are that well known, they are what routers and other > boxes >> > have as a matter or course. >> >> Yes, it's been my problem that I couldn't find a precise definition of > these acronyms, and I understand most routing experts use the definition > "you know it when you see it". >> >> > >> > For me, it is the FIB that is always present; if you do not know > where >> > to send a packet, how to route it, then you are not an IP box of any >> > shape or form - you must have a FIB.. In simple boxes, like Linux > or >> > Windows, then that is all you have. >> > >> > In more sophisticated boxes, 'proper' routers, for some meaning of > the >> > word proper, then you need much more data, which may closely model > the >> > FIB, as with RIP, or may be utterly different, as with OSPF, and for >> > this, I see the term RIB used, initially with BGP but latterly with > any >> > routing protocol. RIBs vary widely with the routing protocol and so > are >> > properly part of routing protocol extensions. >> >> So at the level of the present core routing model we are dealing with > FIBs, but as soon as a BGP module augments routes with that > sophisticated stuff a FIB gets promoted to a RIB, right? But this may be > quite confusing from the point of view of the I-D text, and in this case > I would probably prefer to avoid these acronyms entirely and use only > "routing table". >> >> > >> > So I think that this I-D gets the terminology quite wrong; as I say, >> > this has surfaced before without any visible change to the I-D. I > was >> > surprised that this topic attracted no comment from the Routing >> > Directorate. >> >> Can you suggest what to do in order to get the terminology right? >> >> Anyway, I think that Yi Yang's comments were about "forwarding table", > i.e. a (simplified) routing table which by definition contains only > active routes. > > I think this a misuse of forwarding table:-( > > RIB is defined in RFC1771 (BGP) and later BGP RFC such as RFC2439 (Nov > 1998) and RFC4771; it is clearly not the routing table, containing > everything including the kitchen sink and its structure is specific to > BGP. But I see the term applied generically to what is learnt by an > instance of a routing protocol, and so could be applied to the > equivalent structures of EIGRP or IS-IS, which are very different in > kind. Sometimes I see it used generically to include everything learnt > by all instances of all routing protocols but I think that that is > wrong. > > FIB appears in RFC1812 > "The goal of the next-hop selection process is to examine the entries > in the router's Forwarding Information Base (FIB) and select the best > route (if there is one) for the packet from those available in the > FIB." > which is what, in popular parlance, is a routing table. For example, > Moy, writing on OSPF, says > "A router's routing table instructs the router how to forward packets. > Given a packet, the router performs a routing table lookup, using the > packet's IP destination address as a key. This lookup returns the best > matching routing table entry ..." > > I would not expect the term FIB to include all the baggage that routing > protocols provide nor for it to include any route which is not > available, as far as the host or router knows, for immediate use. > > But the terms FIB and RIB are a bit specialised; I-Ds such as > draft-uttaro-idr-bgp-persistence-01 > and > draft-ietf-grow-simple-va-11 > use them without any explanation as do posters on many if not most of > the WG lists in Routing and parts of Operations Areas, but that is > probably not appropriate for this I-D, just as the terms are not used > in, eg, RFC2096, which is entitled 'IP Forwarding Table MIB' but then > defines 'IP CIDR Route Table', the DESCRIPTION of which is "This > entity's IP Routing table."; oh dear, you can't win! > > So I think that conceptually, you should be defining the FIB, of usable > routes from which the next hop or interface of a packet is selected on > the basis of longest match, but probably calling it a route or routing > table since that is the term most widely used. Where individual router > manufactuers do clever things on line cards, then that is best modelled > by clever router manufacturers, even if they are all doing something > similar - the speed and rate of change of those data structures probably > makes them unsuitable for MIB, yang or anything else. > > You should allow for augmentation, or some such; BGP revolves around > peers and path attributes (RFC4273) and avoids all mention of FIB, RIB > or the IP Route Table. OSPF (RFC4750) covers interfaces, neighbors, > areas and link states, and has a reference to the Forwarding Table. > RIP(RFC1724) has interfaces and peers and refers to the "the IP Route > Database by RIP" > > Yup, you can't win, but referring to RFC1812 is unlikely to lose. > > Tom Petch > >> Thanks, Lada >> >> > >> > Tom Petch >> > >> > Yi >> > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Aug 3 11:57:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F153221F8D55 for ; Fri, 3 Aug 2012 11:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1EJ20pBxZoa for ; Fri, 3 Aug 2012 11:57:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDFFB21F841D for ; Fri, 3 Aug 2012 11:57:33 -0700 (PDT) Received: by yenm6 with SMTP id m6so892509yen.31 for ; Fri, 03 Aug 2012 11:57:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=CA1qHuTrmwxmoPdSrYs63xq1lSWiytcBLvR40UI1lrY=; b=WcbtNnSDRmTWwfT6eSBkvFiqP7hSentRuCqAgLsagmXCLvZX5q+vt6vnPDUxkgUBR+ AT/CWMF32ujERfGXLonoKSIFJaxy5b7M7ZoT8jDX9Bqo+YRilYYbpchtY/rAfMkKA5x9 nTF6rTNn2Ylmy4XmxQlf93vk8LG1ISB8JFStK56IK1lhyZmMfaYDYIizQCOTrxzqt8lt vxv8diNV3Rk0vKIdWCaTnqDKlqh0yS9PzGa3AZTEbu3O0ne7NrLgcU/0wHzB+N3zg/9s dGEy5V9ERceg9lrSGiElhI2u5bvlodl/NOpIFNHpr02QN02kdYkrRskJSpj7CSUSzVKx K9gg== Received: by 10.236.124.13 with SMTP id w13mr3044828yhh.76.1344020252968; Fri, 03 Aug 2012 11:57:32 -0700 (PDT) Received: from [10.66.68.45] (mobile-166-147-109-018.mycingular.net. [166.147.109.18]) by mx.google.com with ESMTPS id t39sm8944936anh.3.2012.08.03.11.57.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 11:57:32 -0700 (PDT) References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9B206) From: YumaWorks Date: Fri, 3 Aug 2012 11:57:27 -0700 To: Ladislav Lhotka X-Gm-Message-State: ALoCoQnuIE/RZShtqXtbjY+ANnUrIPARiTbkVvEM7oWOWvh/poZmXqdU4r/FeUKayw92Pt9lwvpF Cc: "netmod@ietf.org" Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:57:36 -0000 Sent from my iPhone On Aug 3, 2012, at 10:01, Ladislav Lhotka wrote: >=20 > On Aug 3, 2012, at 7:31 AM, Andy Bierman wrote: >=20 >> I don't think there is much point to discussing implementation details >> on the WG mailing list. >=20 > It is not an implementation detail! What Jernej and I are trying to commun= icate is that the current handling of 'when' constraints and the related "au= to-deletion" of nodes is not only hard-to-implement but also ill-defined and= broken. But as long as you dismiss any evidence of this plain fact as "corn= er cases" we can hardly make our point. >=20 > The thing is: With increasing complexity of our data models, we must be su= re that our foundation is rock solid. With a complex model, such a "corner c= ase" can lead to mysterious behaviour or outright failures. Let me paraphras= e a Czech saying: A hundred corner cases are able to plague a donkey. >=20 > Anyway, here is another corner case that we already had in our private dis= cussion: >=20 > container foo { > when "bar !=3D 42"; > leaf bar { > type uint8; > mandatory "true"; > } > } >=20 But this is a nonsense example A real server would not ever do this These are just implementation details for your tool. YANG does not need to c= hange.=20 Andy > 1. The "bar" leaf is set to 42 by the client. > 2. The "foo" container is auto-deleted. > 3. The XPath expression in 'when' loses its context node, so the expressio= n is not properly defined and cannot be used=20 > for any argumentation about validity. > 4. But then there is no reason why the mandatory leaf and container are mi= ssing. > 5. So what? >=20 > Lada >=20 >=20 >>=20 >>=20 >> Andy >>=20 >>=20 >> On Fri, Aug 3, 2012 at 3:17 AM, Jernej Tuljak w= rote: >>> Dne 3.8.2012 10:02, pi=C5=A1e Andy Bierman: >>>>=20 >>>> On Fri, Aug 3, 2012 at 12:21 AM, Jernej Tuljak >>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> that's just the beauty of it. It is not a static test tool. It adapts t= o >>>>> whatever changes you make to the modules. It adapts when you choose >>>>> enabled >>>>> features and it adapts when you change them. It tells you what you did= >>>>> wrong >>>>> while you write entire datastores, rpc operations, even when dealing w= ith >>>>> incomplete XML documents. And it does so in quite a simple way. The wa= y >>>>> of >>>>> RFC6110, which extracts the entire schema from available modules and w= ith >>>>> just a few XSLT transformations you are set to go. Forever. It's quite= >>>>> genius really (credit to Ladislav and others involved with RFC6110 her= e). >>>>> I >>>>> don't understand why anyone would bother reinventing the wheel trying t= o >>>>> implement his own way of validating NETCONF content when it's all alre= ady >>>>> out there. >>>>>=20 >>>>> I never claimed that pyang checks the validity of XPath expressions. I= t >>>>> cannot do so, because XPath expressions cannot be evaluated without >>>>> context >>>>> and context can only be found within instance documents, a thing that >>>>> _never_ exists during YANG module validation. It only exists during >>>>> NETCONF >>>>> content validation, when you have an actual instance document to work >>>>> with. >>>>> Therefore when-stmt cannot be applied at any other time than during >>>>> content >>>>> validation. It represents a semantic constraint on data nodes, not a >>>>> constraint on the schema nodes. And pyang applies these constraints >>>>> within >>>>> pyang.dsdl plugin only when it is validating an XML document against a= >>>>> YANG >>>>> schema. There is no other way. >>>>=20 >>>> The YANG must and when statements can be checked to make sure >>>> the XPath is well-formed and all the schema nodes are actually defined.= >>>> There is really no reason for an YANG must or when stmt to reference >>>> garbage nodes that do not exist in the data model. >>>>=20 >>>>=20 >>>>> I don't understand the need to merge YANG validation with NETCONF cont= ent >>>>> validation into a single validation process. It does not make sense. A= s I >>>>> understand it, this is exactly what you are doing. Sometimes it even >>>>> feels >>>>> like you are saying that a schema node and an instance node are the sa= me >>>>> thing. It should be clear that a schema node is not an instance node, t= he >>>>> former only represents the structure and conditions of appearance of t= he >>>>> latter. Schema nodes never get deleted, instance nodes do. >>>>>=20 >>>> Implementation details do not matter. >>>> The server must send the correct responses and alter its >>>> internal state correctly. There are many ways this could >>>> be done. >>>>=20 >>>> Some servers allow YANG modules to be loaded and unloaded >>>> at run-time. The schema tree is static, meaning once a node >>>> is placed in the tree it doesn't move, but the tree can change at >>>> run-time. >>>> YANG deviations also affect the schema tree, which are allowed to >>>> be loaded at any time. >>>=20 >>>=20 >>> Of course. That's what makes YANG great. That it's extensible the way an= y >>> other schema is. A each set of modules may provide a different schema. A= >>> single additional module may change the existing schema tree significant= ly >>> making it another schema. If-features are also great. But do note that t= hese >>> are not the "runtime modifications to the schema tree" me and Ladislav w= ere >>> talking about. What I've been saying all along is that if we have a modu= le >>> set of size one (a single module) it's schema is always the same. A sche= ma >>> node count will always be the same for it. The only way to modify the co= unt >>> is via features or by adding new modules to the set, which does happen, b= ut >>> not often. That's what I mean when I say that YANG is a static schema. A= n >>> extensible but static schema. Adding a module with deviations, augments,= >>> etc. to the set creates a new but also static schema. >>>=20 >>> But none of this should have anything to do with NETCONF content validat= ion. >>> Allowing the schema count to be modified during validation with when-stm= t's >>> is just...well, bad. RFC6020 should have never allowed it. Separation of= >>> YANG validation/compiling which results in a read-only schema tree and >>> NETCONF content validation, which only uses this schema tree to validate= an >>> XML document, should have been enforced. I don't see any merit in this b= eing >>> a single process. >>>=20 >>> Jernej >>>=20 >>>>=20 >>>>> Let's return to Ladislav's example: >>>>>=20 >>>>> leaf X { >>>>> type string; >>>>> mandatory true; >>>>> when ". =3D ../foo"; >>>>> } >>>>>=20 >>>> Yes, there are some pathological cases that make no >>>> semantic sense that cannot be implemented correctly. >>>>=20 >>>> leaf Y { >>>> type int32; >>>> mandatory true; >>>> when "not(.)"; >>>> } >>>>=20 >>>>=20 >>>>> For when-stmt condition to be evaluated _at all_ an instance of X must= >>>>> exist >>>>> first, meaning that the mandatory constraint is always satisfied if an= >>>>> evaluation occurred. After all X is the condition expression's context= >>>>> node. >>>>> You cannot evaluate without context. You can however validate it's syn= tax >>>>> at >>>>> any time - provided that you are using a static schema, which contains= >>>>> all >>>>> the schema nodes for you to search. >>>>>=20 >>>>> If when is ever true or false, one can be sure that the mandatory >>>>> constraint >>>>> has been satisfied, eliminating the need to enforce it. >>>>>=20 >>>>> The above example represents an instance node, which has to exist and >>>>> fulfill the condition in the when-stmt at the same time. Anything else= is >>>>> an >>>>> error. It's actually mandatory which takes precedence here, so what >>>>> Ladislav >>>>> currently does (structure first, then semantics) is the correct >>>>> interpretation, IMO. >>>>>=20 >>>>> There's a reason why when-stmt's argument is an XPath expression and n= ot >>>>> a >>>>> YANG construct, like a schema-nodeid. >>>>=20 >>>> Yes, so they generate a boolean result. >>>> A schema-nodeid is not relevant here. >>>> That is used for augment and path targets. >>>>=20 >>>>=20 >>>>=20 >>>>> Jernej >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>> Dne 3.8.2012 2:14, pi=C5=A1e Andy Bierman: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Sorry but YANG does not work the way you think it does for the sake o= f >>>>>> your static test tool. BTW, pyang does not validate the XPath >>>>>> statement. >>>>>> It validates instance documents against the XPath that it finds. >>>>>> This is hardly the same as verifying the correctness of the YANG >>>>>> statement. >>>>>>=20 >>>>>> A false when-stmt is not an error unless it occurs in the RPC input >>>>>> parameters. (We are insulated from content because it >>>>>> is declared as an 'anyxml' so from a RPC POV, the when-stmts >>>>>> within the data are not relevant to RPC input validation.) >>>>>>=20 >>>>>> The XPath statements are conceptual. There is no requirement >>>>>> by the server to use an XPath validator to implement them. >>>>>> When-stmt is applied right away, not applied at validation >>>>>> time like must-stmt. >>>>>>=20 >>>>>>=20 >>>>>> Andy >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka wrot= e: >>>>>>>=20 >>>>>>> Jernej Tuljak writes: >>>>>>>=20 >>>>>>>> I think that the idea to completely decouple the schema from instan= ces >>>>>>>> based on it is the way to go. Your schema is not such a schema, sin= ce >>>>>>>> it >>>>>>>> needs an instance to determine it's final form (the instance become= s a >>>>>>>> part of the schema). It's form must be determined after every >>>>>>>> modification to the instance. Constantly. Not entirely sure how you= do >>>>>>>> it. >>>>>>>=20 >>>>>>> In fact the solution can already be found in RFC 6110: make 'when' >>>>>>> statement essentially equivalent to 'must', except for a different >>>>>>> error >>>>>>> message. >>>>>>>=20 >>>>>>>> One other thing. Our generic client application displays the entire= >>>>>>>> schema in a tree graphic component and even offers queries to be ma= de >>>>>>>> from it. How could it possibly do that if the tree's final form can= not >>>>>>>> be determined? >>>>>>>>=20 >>>>>>>> Also this would make RFC6110 next to useless since the assumption t= hat >>>>>>>> YANG schema is static is the foundation it builds upon. Generating >>>>>>>> DSDL >>>>>>>> schema is an expensive operation...and it would have to be done aft= er >>>>>>>> every modification to an instance document. >>>>>>>=20 >>>>>>> Absolutely. It would be possible to forget about RELAX NG and implem= ent >>>>>>> all validation in Schematron. However, such an approach would ignore= >>>>>>> the >>>>>>> lessons learnt by the XML community and embodied in DSDL: Schema-bas= ed >>>>>>> validation is a very robust procedure that practically cannot be foo= led >>>>>>> and >>>>>>> provides guarantees that the instance document is syntactically corr= ect >>>>>>> so >>>>>>> that it can be safely parsed. Validation based on checking XPath >>>>>>> expressions >>>>>>> is much more fragile and is best used only for "business rules" >>>>>>> (semantic >>>>>>> constrainst) AFTER schema-based validation has been successfully >>>>>>> finished. >>>>>>>=20 >>>>>>>> The when-stmt only makes its parent data definition statement >>>>>>>> conditional. There's nothing written in RFC6020 that this would imp= ly >>>>>>>> modifications to the schema (can't find it). Although multiple >>>>>>>> paragraphs can be found which serve as workarounds for non-static >>>>>>>> implementations of YANG schema. The point in 8.3.1 Payload Parsing >>>>>>>> which >>>>>>>> relates to when-stmt is an example. >>>>>>>>=20 >>>>>>>> Sorry, but I'm completely with Ladislav on this one. Non-static sch= ema >>>>>>>> or run-time changes to a schema are bad and should never have been >>>>>>>> allowed to become a part of YANG. I cannot argue that they are not a= >>>>>>>> part of it. >>>>>>>=20 >>>>>>> Agreed. >>>>>>>=20 >>>>>>> Lada >>>>>>>=20 >>>>>>>> Jernej >>>>>>>>=20 >>>>>>>>>> It doesn't matter how the error is generated. But it should be >>>>>>>>>> properly >>>>>>>>>> generated. >>>>>>>>>>=20 >>>>>>>>>> Jernej >>>>>>>>>=20 >>>>>>>>> Andy >>>>>>>>>=20 >>>>>>>>>>> Lada >>>>>>>>>>>=20 >>>>>>>>>>>> But I can see how this is problematic. >>>>>>>>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>>>>>>>> It is used for unknown and unexpected elements. >>>>>>>>>>>> If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse w= e would >>>>>>>>>>>> have >>>>>>>>>>>> to >>>>>>>>>>>> decide if that node is unknown by the server, vs. an instance >>>>>>>>>>>> of that node is unexpected for the request. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> Lada >>>>>>>>>>>>>=20 >>>>>>>>>>>> Andy >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>> Or does a conditional augment mean that the augmentation will= >>>>>>>>>>>>>> always be >>>>>>>>>>>>>> done but all of the augmented nodes "inherit" the augment's w= hen >>>>>>>>>>>>>> conditions >>>>>>>>>>>>>> making all of them conditional? This would make much more sen= se >>>>>>>>>>>>>> to >>>>>>>>>>>>>> me. Would >>>>>>>>>>>>>> this be legal as a potential workaround to dynamically changi= ng >>>>>>>>>>>>>> a >>>>>>>>>>>>>> module's >>>>>>>>>>>>>> schema? What was the group's intention regarding this matter?= >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> netmod mailing list >>>>>>>>>>>>> netmod@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 From andy@yumaworks.com Fri Aug 3 13:08:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FD421F8DD4 for ; Fri, 3 Aug 2012 13:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbWxWMf0JH3h for ; Fri, 3 Aug 2012 13:08:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3782A21F8DC3 for ; Fri, 3 Aug 2012 13:08:25 -0700 (PDT) Received: by yenm6 with SMTP id m6so967031yen.31 for ; Fri, 03 Aug 2012 13:08:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=jjknICNfdDPDrmFmDlne5+AqR53RbSJEOlF0T77DXYU=; b=RTB2G6uRvpMnc9aLpVCQO+ckktLmNTG0+bAv6YvClAwsGOWHSKDwwdH2SvaOfrbhKH SbY7/D0dV8C0wYLFcfErLjLW4lmN8CGWSdrd6kaBpOh9EaCPZL4plzfv65hz55Wucy0X SH5l3eS0PAqk4l4kavZTU+kv7UYAp4GmOS9MkLwbBtosbyCDsWcYUlbnVEEqHZdjLMjj ltQm3bwuGfDIomWg4Aw5LEchDGr5HL6ZYJruwteJlhsyLYohzVoxU8/OuAsbyUuMutE9 ntuaSSRSpINQ9l61Giy/w3npgLfqD4EBd2/u+134cBApHAOFpRZsJ8CJEIlHTq4gqG8b oQtQ== Received: by 10.236.80.34 with SMTP id j22mr3320532yhe.82.1344024504766; Fri, 03 Aug 2012 13:08:24 -0700 (PDT) Received: from [10.128.82.22] (mobile-166-147-110-017.mycingular.net. [166.147.110.17]) by mx.google.com with ESMTPS id o25sm17893489yhm.14.2012.08.03.13.08.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 13:08:24 -0700 (PDT) References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <00432777-777F-40F2-839E-8DD7BA4AB424@yumaworks.com> X-Mailer: iPhone Mail (9B206) From: Andy Bierman Date: Fri, 3 Aug 2012 13:07:50 -0700 To: Ladislav Lhotka X-Gm-Message-State: ALoCoQna1oS3/pZLl51NvI670Ql4ozvB+Tw9CF/1W1lL/7syL9GSHMJEgrrCvaCKB8TaYUpkHVGo Cc: "netmod@ietf.org" Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 20:08:26 -0000 Sent from my iPhone On Aug 3, 2012, at 10:01, Ladislav Lhotka wrote: >=20 > On Aug 3, 2012, at 7:31 AM, Andy Bierman wrote: >=20 >> I don't think there is much point to discussing implementation details >> on the WG mailing list. >=20 > It is not an implementation detail! What Jernej and I are trying to commun= icate is that the current handling of 'when' constraints and the related "au= to-deletion" of nodes is not only hard-to-implement but also ill-defined and= broken. But as long as you dismiss any evidence of this plain fact as "corn= er cases" we can hardly make our point. >=20 It is not ill-defined and broken.=20 I understand you would like to validate requests with an offline tool but th= at is not the purpose of the protocol.=20 Even for a simple 'create' operation the request cannot be validated without= knowing if the data already exists or not. The current state of the system= cannot be ignored.=20 If the real when or must statements in real modules were not implementable t= hen I would be concerned but that is not the case. =20 Andy > The thing is: With increasing complexity of our data models, we must be su= re that our foundation is rock solid. With a complex model, such a "corner c= ase" can lead to mysterious behaviour or outright failures. Let me paraphras= e a Czech saying: A hundred corner cases are able to plague a donkey. >=20 > Anyway, here is another corner case that we already had in our private dis= cussion: >=20 > container foo { > when "bar !=3D 42"; > leaf bar { > type uint8; > mandatory "true"; > } > } >=20 > 1. The "bar" leaf is set to 42 by the client. > 2. The "foo" container is auto-deleted. > 3. The XPath expression in 'when' loses its context node, so the expressio= n is not properly defined and cannot be used=20 > for any argumentation about validity. > 4. But then there is no reason why the mandatory leaf and container are mi= ssing. > 5. So what? >=20 > Lada >=20 >=20 >>=20 >>=20 >> Andy >>=20 >>=20 >> On Fri, Aug 3, 2012 at 3:17 AM, Jernej Tuljak w= rote: >>> Dne 3.8.2012 10:02, pi=C5=A1e Andy Bierman: >>>>=20 >>>> On Fri, Aug 3, 2012 at 12:21 AM, Jernej Tuljak >>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> that's just the beauty of it. It is not a static test tool. It adapts t= o >>>>> whatever changes you make to the modules. It adapts when you choose >>>>> enabled >>>>> features and it adapts when you change them. It tells you what you did= >>>>> wrong >>>>> while you write entire datastores, rpc operations, even when dealing w= ith >>>>> incomplete XML documents. And it does so in quite a simple way. The wa= y >>>>> of >>>>> RFC6110, which extracts the entire schema from available modules and w= ith >>>>> just a few XSLT transformations you are set to go. Forever. It's quite= >>>>> genius really (credit to Ladislav and others involved with RFC6110 her= e). >>>>> I >>>>> don't understand why anyone would bother reinventing the wheel trying t= o >>>>> implement his own way of validating NETCONF content when it's all alre= ady >>>>> out there. >>>>>=20 >>>>> I never claimed that pyang checks the validity of XPath expressions. I= t >>>>> cannot do so, because XPath expressions cannot be evaluated without >>>>> context >>>>> and context can only be found within instance documents, a thing that >>>>> _never_ exists during YANG module validation. It only exists during >>>>> NETCONF >>>>> content validation, when you have an actual instance document to work >>>>> with. >>>>> Therefore when-stmt cannot be applied at any other time than during >>>>> content >>>>> validation. It represents a semantic constraint on data nodes, not a >>>>> constraint on the schema nodes. And pyang applies these constraints >>>>> within >>>>> pyang.dsdl plugin only when it is validating an XML document against a= >>>>> YANG >>>>> schema. There is no other way. >>>>=20 >>>> The YANG must and when statements can be checked to make sure >>>> the XPath is well-formed and all the schema nodes are actually defined.= >>>> There is really no reason for an YANG must or when stmt to reference >>>> garbage nodes that do not exist in the data model. >>>>=20 >>>>=20 >>>>> I don't understand the need to merge YANG validation with NETCONF cont= ent >>>>> validation into a single validation process. It does not make sense. A= s I >>>>> understand it, this is exactly what you are doing. Sometimes it even >>>>> feels >>>>> like you are saying that a schema node and an instance node are the sa= me >>>>> thing. It should be clear that a schema node is not an instance node, t= he >>>>> former only represents the structure and conditions of appearance of t= he >>>>> latter. Schema nodes never get deleted, instance nodes do. >>>>>=20 >>>> Implementation details do not matter. >>>> The server must send the correct responses and alter its >>>> internal state correctly. There are many ways this could >>>> be done. >>>>=20 >>>> Some servers allow YANG modules to be loaded and unloaded >>>> at run-time. The schema tree is static, meaning once a node >>>> is placed in the tree it doesn't move, but the tree can change at >>>> run-time. >>>> YANG deviations also affect the schema tree, which are allowed to >>>> be loaded at any time. >>>=20 >>>=20 >>> Of course. That's what makes YANG great. That it's extensible the way an= y >>> other schema is. A each set of modules may provide a different schema. A= >>> single additional module may change the existing schema tree significant= ly >>> making it another schema. If-features are also great. But do note that t= hese >>> are not the "runtime modifications to the schema tree" me and Ladislav w= ere >>> talking about. What I've been saying all along is that if we have a modu= le >>> set of size one (a single module) it's schema is always the same. A sche= ma >>> node count will always be the same for it. The only way to modify the co= unt >>> is via features or by adding new modules to the set, which does happen, b= ut >>> not often. That's what I mean when I say that YANG is a static schema. A= n >>> extensible but static schema. Adding a module with deviations, augments,= >>> etc. to the set creates a new but also static schema. >>>=20 >>> But none of this should have anything to do with NETCONF content validat= ion. >>> Allowing the schema count to be modified during validation with when-stm= t's >>> is just...well, bad. RFC6020 should have never allowed it. Separation of= >>> YANG validation/compiling which results in a read-only schema tree and >>> NETCONF content validation, which only uses this schema tree to validate= an >>> XML document, should have been enforced. I don't see any merit in this b= eing >>> a single process. >>>=20 >>> Jernej >>>=20 >>>>=20 >>>>> Let's return to Ladislav's example: >>>>>=20 >>>>> leaf X { >>>>> type string; >>>>> mandatory true; >>>>> when ". =3D ../foo"; >>>>> } >>>>>=20 >>>> Yes, there are some pathological cases that make no >>>> semantic sense that cannot be implemented correctly. >>>>=20 >>>> leaf Y { >>>> type int32; >>>> mandatory true; >>>> when "not(.)"; >>>> } >>>>=20 >>>>=20 >>>>> For when-stmt condition to be evaluated _at all_ an instance of X must= >>>>> exist >>>>> first, meaning that the mandatory constraint is always satisfied if an= >>>>> evaluation occurred. After all X is the condition expression's context= >>>>> node. >>>>> You cannot evaluate without context. You can however validate it's syn= tax >>>>> at >>>>> any time - provided that you are using a static schema, which contains= >>>>> all >>>>> the schema nodes for you to search. >>>>>=20 >>>>> If when is ever true or false, one can be sure that the mandatory >>>>> constraint >>>>> has been satisfied, eliminating the need to enforce it. >>>>>=20 >>>>> The above example represents an instance node, which has to exist and >>>>> fulfill the condition in the when-stmt at the same time. Anything else= is >>>>> an >>>>> error. It's actually mandatory which takes precedence here, so what >>>>> Ladislav >>>>> currently does (structure first, then semantics) is the correct >>>>> interpretation, IMO. >>>>>=20 >>>>> There's a reason why when-stmt's argument is an XPath expression and n= ot >>>>> a >>>>> YANG construct, like a schema-nodeid. >>>>=20 >>>> Yes, so they generate a boolean result. >>>> A schema-nodeid is not relevant here. >>>> That is used for augment and path targets. >>>>=20 >>>>=20 >>>>=20 >>>>> Jernej >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>> Dne 3.8.2012 2:14, pi=C5=A1e Andy Bierman: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Sorry but YANG does not work the way you think it does for the sake o= f >>>>>> your static test tool. BTW, pyang does not validate the XPath >>>>>> statement. >>>>>> It validates instance documents against the XPath that it finds. >>>>>> This is hardly the same as verifying the correctness of the YANG >>>>>> statement. >>>>>>=20 >>>>>> A false when-stmt is not an error unless it occurs in the RPC input >>>>>> parameters. (We are insulated from content because it >>>>>> is declared as an 'anyxml' so from a RPC POV, the when-stmts >>>>>> within the data are not relevant to RPC input validation.) >>>>>>=20 >>>>>> The XPath statements are conceptual. There is no requirement >>>>>> by the server to use an XPath validator to implement them. >>>>>> When-stmt is applied right away, not applied at validation >>>>>> time like must-stmt. >>>>>>=20 >>>>>>=20 >>>>>> Andy >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka wrot= e: >>>>>>>=20 >>>>>>> Jernej Tuljak writes: >>>>>>>=20 >>>>>>>> I think that the idea to completely decouple the schema from instan= ces >>>>>>>> based on it is the way to go. Your schema is not such a schema, sin= ce >>>>>>>> it >>>>>>>> needs an instance to determine it's final form (the instance become= s a >>>>>>>> part of the schema). It's form must be determined after every >>>>>>>> modification to the instance. Constantly. Not entirely sure how you= do >>>>>>>> it. >>>>>>>=20 >>>>>>> In fact the solution can already be found in RFC 6110: make 'when' >>>>>>> statement essentially equivalent to 'must', except for a different >>>>>>> error >>>>>>> message. >>>>>>>=20 >>>>>>>> One other thing. Our generic client application displays the entire= >>>>>>>> schema in a tree graphic component and even offers queries to be ma= de >>>>>>>> from it. How could it possibly do that if the tree's final form can= not >>>>>>>> be determined? >>>>>>>>=20 >>>>>>>> Also this would make RFC6110 next to useless since the assumption t= hat >>>>>>>> YANG schema is static is the foundation it builds upon. Generating >>>>>>>> DSDL >>>>>>>> schema is an expensive operation...and it would have to be done aft= er >>>>>>>> every modification to an instance document. >>>>>>>=20 >>>>>>> Absolutely. It would be possible to forget about RELAX NG and implem= ent >>>>>>> all validation in Schematron. However, such an approach would ignore= >>>>>>> the >>>>>>> lessons learnt by the XML community and embodied in DSDL: Schema-bas= ed >>>>>>> validation is a very robust procedure that practically cannot be foo= led >>>>>>> and >>>>>>> provides guarantees that the instance document is syntactically corr= ect >>>>>>> so >>>>>>> that it can be safely parsed. Validation based on checking XPath >>>>>>> expressions >>>>>>> is much more fragile and is best used only for "business rules" >>>>>>> (semantic >>>>>>> constrainst) AFTER schema-based validation has been successfully >>>>>>> finished. >>>>>>>=20 >>>>>>>> The when-stmt only makes its parent data definition statement >>>>>>>> conditional. There's nothing written in RFC6020 that this would imp= ly >>>>>>>> modifications to the schema (can't find it). Although multiple >>>>>>>> paragraphs can be found which serve as workarounds for non-static >>>>>>>> implementations of YANG schema. The point in 8.3.1 Payload Parsing >>>>>>>> which >>>>>>>> relates to when-stmt is an example. >>>>>>>>=20 >>>>>>>> Sorry, but I'm completely with Ladislav on this one. Non-static sch= ema >>>>>>>> or run-time changes to a schema are bad and should never have been >>>>>>>> allowed to become a part of YANG. I cannot argue that they are not a= >>>>>>>> part of it. >>>>>>>=20 >>>>>>> Agreed. >>>>>>>=20 >>>>>>> Lada >>>>>>>=20 >>>>>>>> Jernej >>>>>>>>=20 >>>>>>>>>> It doesn't matter how the error is generated. But it should be >>>>>>>>>> properly >>>>>>>>>> generated. >>>>>>>>>>=20 >>>>>>>>>> Jernej >>>>>>>>>=20 >>>>>>>>> Andy >>>>>>>>>=20 >>>>>>>>>>> Lada >>>>>>>>>>>=20 >>>>>>>>>>>> But I can see how this is problematic. >>>>>>>>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>>>>>>>> It is used for unknown and unexpected elements. >>>>>>>>>>>> If /foo/bar only exists if when=3Dtrue, then for when=3Dfalse w= e would >>>>>>>>>>>> have >>>>>>>>>>>> to >>>>>>>>>>>> decide if that node is unknown by the server, vs. an instance >>>>>>>>>>>> of that node is unexpected for the request. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> Lada >>>>>>>>>>>>>=20 >>>>>>>>>>>> Andy >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>> Or does a conditional augment mean that the augmentation will= >>>>>>>>>>>>>> always be >>>>>>>>>>>>>> done but all of the augmented nodes "inherit" the augment's w= hen >>>>>>>>>>>>>> conditions >>>>>>>>>>>>>> making all of them conditional? This would make much more sen= se >>>>>>>>>>>>>> to >>>>>>>>>>>>>> me. Would >>>>>>>>>>>>>> this be legal as a potential workaround to dynamically changi= ng >>>>>>>>>>>>>> a >>>>>>>>>>>>>> module's >>>>>>>>>>>>>> schema? What was the group's intention regarding this matter?= >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> netmod mailing list >>>>>>>>>>>>> netmod@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 From j.schoenwaelder@jacobs-university.de Sat Aug 4 08:31:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C001621F87C9 for ; Sat, 4 Aug 2012 08:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSIcbE3z-sBm for ; Sat, 4 Aug 2012 08:31:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0653021F87BC for ; Sat, 4 Aug 2012 08:31:52 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99C1520C3C; Sat, 4 Aug 2012 17:31:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PBWKmZUsZMmG; Sat, 4 Aug 2012 17:31:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA3B920C2A; Sat, 4 Aug 2012 17:31:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 677022104D33; Sat, 4 Aug 2012 17:31:49 +0200 (CEST) Date: Sat, 4 Aug 2012 17:31:49 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120804153149.GA90332@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] draft vancouver meeting minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 15:31:53 -0000 Hi, the draft minutes can be found here: http://www.ietf.org/proceedings/84/minutes/minutes-84-netmod Please drop me a note if something needs correction. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Sat Aug 4 10:21:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F152E21F87F9 for ; Sat, 4 Aug 2012 10:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnMpXpwPuWZW for ; Sat, 4 Aug 2012 10:21:30 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDCCC21F87C4 for ; Sat, 4 Aug 2012 10:21:24 -0700 (PDT) Received: by qadz3 with SMTP id z3so234592qad.10 for ; Sat, 04 Aug 2012 10:21:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8WbK3zedHKu46XqL9cZzO7vZNrJMT8hkM17xd4QpR4E=; b=Ho5bGj6VTh0HUVhWHpQfQ6dD4pXYzid/bh8s2LcCrfLK1qMi3IBr4pdMp0ucixXo48 XZiLgEjtnkFlTHvSeRtb43JZRML3RfIGWY7oHvmmuTNi8lSOWMKnLKrd3wSHHpbLb068 wsfQWbSZzNKaAKtnXVhEWu5z2hwjHQOslLHtxyvpbtHk4UI74hq7748tCDRsTpT1WDLa 916BVC4/mY5LTjGzK9ofes0ORZE8QSmxFRXnByW/ovHjmnGw+wsk2brL1mV4FC61Zm0E gwEmUcN3TRB7KkRX04vaKeLtNejFT1U/dtzNl/WGzkUxvZcVM9lhbB11BVYDU7HFb9Y0 pWzw== MIME-Version: 1.0 Received: by 10.224.105.193 with SMTP id u1mr9014193qao.85.1344100884379; Sat, 04 Aug 2012 10:21:24 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sat, 4 Aug 2012 10:21:24 -0700 (PDT) In-Reply-To: <20120803.074537.496599422.mbj@tail-f.com> References: <20120802163323.GA86561@elstar.local> <20120803.074537.496599422.mbj@tail-f.com> Date: Sat, 4 Aug 2012 10:21:24 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm6apL/8ey++OUkArBGnu2yhtP9SSfmutsE+w3XSSjpFuH01EzbRBRu6UIm0yM9595WcjME Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 17:21:31 -0000 On Fri, Aug 3, 2012 at 7:45 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO, it is unacceptable to rely on the existence of IF-MIB >> in order to retrieve interface counters. > > So which objects are we talking about? For example, does it still > make sense to include both the 32-bit and 64-bit counters? How do we > represent speed/highspeed? Do we keep the ifCounterDiscontinuityTime, > defined in terms of sysUpTime? > > My 2 cents: 11 leafs: ifOperStatus ifLastChange ifHCInOctets ifHCInUcastPkts ifHCInMulticastPkts ifHCInBroadcastPkts ifHCOutOctets ifHCOutUcastPkts ifHCOutMulticastPkts ifHCOutBroadcastPkts ifCounterDiscontinuityTime Change timeticks to date-and-time. > /martin Andy From pgili@cisco.com Sat Aug 4 10:30:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1021F8818 for ; Sat, 4 Aug 2012 10:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF4V-1tA5Erl for ; Sat, 4 Aug 2012 10:30:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A557B21F8812 for ; Sat, 4 Aug 2012 10:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=1570; q=dns/txt; s=iport; t=1344101412; x=1345311012; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QhAuyjYT7WsNBjeuu1YAWqCwnfI19p8sZB9ltK8x1mk=; b=Ot/ij/R1iKvCMPL0YoumUQpoDlpa8uPTxWGs3skqAlKe78tf1JynKNPO AVizmoTI7pbZzibLYSUjjG3VBHlgcQ4qusdFZgPFdKOjhGAZRbO+1Z5M9 eygZ5L8PQex2Xl1D2nU4M4JNzSYvwY3MgQzyLQJR9u00j3PKgMM1lTLbW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACNbHVCtJXHB/2dsb2JhbABEhXuyTHaBB4IgAQEBBBIBEBFFDAQCAQgQAQQBAQECAgYdAwICAjAUAQgIAgQBDQUIGodrmziNGZItgSGKKYVyMmADo2+BZoJf X-IronPort-AV: E=Sophos;i="4.77,713,1336348800"; d="scan'208";a="108466421" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 04 Aug 2012 17:30:11 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q74HUBUQ000644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Aug 2012 17:30:11 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.239]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sat, 4 Aug 2012 12:30:10 -0500 From: "Patrick Gili (pgili)" To: Andy Bierman , Martin Bjorklund Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNcmWSpLzaXn+U8UWilvWloQKDDJdJ6LVg Date: Sat, 4 Aug 2012 17:30:10 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB038036@xmb-aln-x14.cisco.com> References: <20120802163323.GA86561@elstar.local> <20120803.074537.496599422.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19084.004 x-tm-as-result: No--24.934600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 17:30:13 -0000 V2h5IG5vdCBlcnJvciBhbmQgZGlzY2FyZCBjb3VudGVycz8NCg0KUGF0cmljaw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1h d29ya3MuY29tXSANClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMDQsIDIwMTIgMToyMSBQTQ0KVG86 IE1hcnRpbiBCam9ya2x1bmQNCkNjOiBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU7IFBhdHJpY2sgR2lsaSAocGdpbGkpOyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb bmV0bW9kXSBjb21tZW50IG9uIGlldGYtaW50ZXJmYWNlcyBtb2R1bGUNCg0KT24gRnJpLCBBdWcg MywgMjAxMiBhdCA3OjQ1IEFNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3Jv dGU6DQo+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4+IElNTywg aXQgaXMgdW5hY2NlcHRhYmxlIHRvIHJlbHkgb24gdGhlIGV4aXN0ZW5jZSBvZiBJRi1NSUIgaW4g b3JkZXIgDQo+PiB0byByZXRyaWV2ZSBpbnRlcmZhY2UgY291bnRlcnMuDQo+DQo+IFNvIHdoaWNo IG9iamVjdHMgYXJlIHdlIHRhbGtpbmcgYWJvdXQ/ICBGb3IgZXhhbXBsZSwgZG9lcyBpdCBzdGls bCANCj4gbWFrZSBzZW5zZSB0byBpbmNsdWRlIGJvdGggdGhlIDMyLWJpdCBhbmQgNjQtYml0IGNv dW50ZXJzPyAgSG93IGRvIHdlIA0KPiByZXByZXNlbnQgc3BlZWQvaGlnaHNwZWVkPyAgRG8gd2Ug a2VlcCB0aGUgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUsIA0KPiBkZWZpbmVkIGluIHRlcm1z IG9mIHN5c1VwVGltZT8NCj4NCj4NCg0KTXkgMiBjZW50czogMTEgbGVhZnM6DQoNCiAgIGlmT3Bl clN0YXR1cw0KICAgaWZMYXN0Q2hhbmdlDQogICBpZkhDSW5PY3RldHMNCiAgIGlmSENJblVjYXN0 UGt0cw0KICAgaWZIQ0luTXVsdGljYXN0UGt0cw0KICAgaWZIQ0luQnJvYWRjYXN0UGt0cw0KICAg aWZIQ091dE9jdGV0cw0KICAgaWZIQ091dFVjYXN0UGt0cw0KICAgaWZIQ091dE11bHRpY2FzdFBr dHMNCiAgIGlmSENPdXRCcm9hZGNhc3RQa3RzDQogICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGlt ZQ0KDQpDaGFuZ2UgdGltZXRpY2tzIHRvIGRhdGUtYW5kLXRpbWUuDQoNCj4gL21hcnRpbg0KDQpB bmR5DQo= From andy@yumaworks.com Sat Aug 4 10:34:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C0821F8643 for ; Sat, 4 Aug 2012 10:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TIkNMhxmfH1 for ; Sat, 4 Aug 2012 10:34:42 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C92AF21F8624 for ; Sat, 4 Aug 2012 10:34:41 -0700 (PDT) Received: by qcac10 with SMTP id c10so1167945qca.31 for ; Sat, 04 Aug 2012 10:34:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=fQtwhAla0xpOv1aK+Qtlox8VZZqr/RHXXvzYc+yW02k=; b=bLmB3UfStNG+LkH+EfGYUkyruO2BnDeIrHQFKsZsHKvZm9HbachJlKAgkyrqOX9rO5 dty1xYJ3mXO3DY7M/dpHRmsXhVtQk77J6Vk9H6aQ4m0GXWhvVq1XJrikGi/R1PjkZL7A vU58fVJCUAN0hsPkj7e6BOUEExkEeAWEQQDZEwi0eQXq/xcyAq/J8iIS0ZC2iyGGcRdZ FXytIqveX+/kz28uqnpgPpaBS0X/afrjPOmyjoVfDctHr16CFVx8X5YiiEHDtIT1sNs3 /YW0VKvQNMpX8G1Ibe0X3pwnxbplwiM0wEQC+rpHeGwg4spm1zBPZzxYSfoyRpZapjDj vVkQ== MIME-Version: 1.0 Received: by 10.224.214.69 with SMTP id gz5mr357325qab.21.1344101681180; Sat, 04 Aug 2012 10:34:41 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sat, 4 Aug 2012 10:34:41 -0700 (PDT) In-Reply-To: <20120803160911.GA88788@elstar.local> References: <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> <78939758ee86bdf7a321b5acb037c7f7@imap.plus.net> <20120803160911.GA88788@elstar.local> Date: Sat, 4 Aug 2012 10:34:41 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jonathan Hansford , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlu/txg04RvX2fKDvU6/U4K+mqmEaAvjfOgg/pZyg/aTaKxdEs1IIp7HXZMhDY5QpD7LNHX Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 17:34:42 -0000 On Fri, Aug 3, 2012 at 9:09 AM, Juergen Schoenwaelder wrote: > On Fri, Aug 03, 2012 at 04:59:37PM +0100, Jonathan Hansford wrote: >> >> As someone who is still getting >> up-to-speed on YANG and therefore considers himself primarily a reader >> for now, I hope the issues that have been discussed in this thread only >> generate this level of uncertainty for tool developers and the task of >> readers remains simplified. How esoteric are these discussions? Are we >> looking at corner cases, or are these issues at the core of YANG module >> development? >> > > My take is that these discussions, as important they might be for > implementors, are for most users a non issue, especially readers. > There are advanced YANG usage issues for YANG module writers. Here are a few: * Never reference descendant-or-self nodes in a when-stmt * Should refer to descendant-or-self nodes in a must-stmt (Choose easy to understand stmt placement) * Use when-stmt in choice, case, uses with extreme care. Be careful to identify the correct context node * Make sure there are never any circular dependencies across multiple when-stmts; best to refer only to static objects in when-stmt (like the keys and mandatory nodes) * For must/when, be careful of referencing nodes in different YANG features than the context node > /js > Andy From andy@yumaworks.com Sat Aug 4 10:36:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE2621F853D for ; Sat, 4 Aug 2012 10:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyx2QRBhQUr1 for ; Sat, 4 Aug 2012 10:36:17 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8896321F852C for ; Sat, 4 Aug 2012 10:36:17 -0700 (PDT) Received: by qcac10 with SMTP id c10so1168313qca.31 for ; Sat, 04 Aug 2012 10:36:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=zkGhLzxKlDxtSuM4eAKAE/f4JEyY19z6R/FRi3uluKU=; b=HY4/ZNrMeT3E0R7zSr0w7w1FffRa/mjoJ/TWCmRryC0nQaGtjp3Nnk0dyP+XeVkByP sZcXCz2t93rpxo1r76a0yu98pFK+CEhbxTfemAJkureC0mKEpZm5te6a5E1rMw5at5f/ IZCuy2g7hSS52keUlc7+WCnMKYo3ftuCj3Yy9liiDNPdi2/WQ348/lMZ4t887j8ZA7Er 2GbiwQApy374sXEGRE8RAP00ic+Pk2BMy5mUp77CR21OXHI6oS8nLo2gBEmqSSLP+VxK dQLecC9ztGLcHhBfxnzO0F8lAvSmV9EGU6E22bh8nc+86IIST66MxeKL/5mEg/EpxXWr X8Eg== MIME-Version: 1.0 Received: by 10.224.42.76 with SMTP id r12mr9041840qae.96.1344101777044; Sat, 04 Aug 2012 10:36:17 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sat, 4 Aug 2012 10:36:16 -0700 (PDT) In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB038036@xmb-aln-x14.cisco.com> References: <20120802163323.GA86561@elstar.local> <20120803.074537.496599422.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB038036@xmb-aln-x14.cisco.com> Date: Sat, 4 Aug 2012 10:36:16 -0700 Message-ID: From: Andy Bierman To: "Patrick Gili (pgili)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlrtBmjD+KXnp/G7JG8s+u3uVgBt2Ts/xksQX81oKoxU1i3xOPln9NiSPEgnv511O3tquko Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 17:36:19 -0000 On Sat, Aug 4, 2012 at 10:30 AM, Patrick Gili (pgili) wrote: > Why not error and discard counters? > OK -- must have missed them because I skipped the 32 bit counters. Change them to 64 bit, and of course change all the names to something readable. > Patrick Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Saturday, August 04, 2012 1:21 PM > To: Martin Bjorklund > Cc: j.schoenwaelder@jacobs-university.de; Patrick Gili (pgili); netmod@ietf.org > Subject: Re: [netmod] comment on ietf-interfaces module > > On Fri, Aug 3, 2012 at 7:45 AM, Martin Bjorklund wrote: >> Andy Bierman wrote: >>> IMO, it is unacceptable to rely on the existence of IF-MIB in order >>> to retrieve interface counters. >> >> So which objects are we talking about? For example, does it still >> make sense to include both the 32-bit and 64-bit counters? How do we >> represent speed/highspeed? Do we keep the ifCounterDiscontinuityTime, >> defined in terms of sysUpTime? >> >> > > My 2 cents: 11 leafs: > > ifOperStatus > ifLastChange > ifHCInOctets > ifHCInUcastPkts > ifHCInMulticastPkts > ifHCInBroadcastPkts > ifHCOutOctets > ifHCOutUcastPkts > ifHCOutMulticastPkts > ifHCOutBroadcastPkts > ifCounterDiscontinuityTime > > Change timeticks to date-and-time. > >> /martin > > Andy From calle@tail-f.com Sat Aug 4 15:04:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B496C21F86C5 for ; Sat, 4 Aug 2012 15:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKu1Vm73zdrg for ; Sat, 4 Aug 2012 15:04:10 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2129221F8694 for ; Sat, 4 Aug 2012 15:04:10 -0700 (PDT) Received: from [10.168.58.176] (host-95-199-26-176.mobileonline.telia.com [95.199.26.176]) by mail.tail-f.com (Postfix) with ESMTPSA id 122CA1200D66; Sun, 5 Aug 2012 00:04:08 +0200 (CEST) References: <20120802163323.GA86561@elstar.local> <20120803.074537.496599422.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB038036@xmb-aln-x14.cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Carl Moberg Date: Sun, 5 Aug 2012 00:04:02 +0200 To: Andy Bierman Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 22:04:10 -0000 On 4 aug 2012, at 19:36, Andy Bierman wrote: > On Sat, Aug 4, 2012 at 10:30 AM, Patrick Gili (pgili) wr= ote: >> Why not error and discard counters? >>=20 >=20 > OK -- must have missed them because I skipped the 32 bit counters. > Change them to 64 bit, and of course change all the names to > something readable. >=20 >> Patrick >=20 > Andy >=20 >>=20 >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Saturday, August 04, 2012 1:21 PM >> To: Martin Bjorklund >> Cc: j.schoenwaelder@jacobs-university.de; Patrick Gili (pgili); netmod@ie= tf.org >> Subject: Re: [netmod] comment on ietf-interfaces module >>=20 >> On Fri, Aug 3, 2012 at 7:45 AM, Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> IMO, it is unacceptable to rely on the existence of IF-MIB in order >>>> to retrieve interface counters. >>>=20 >>> So which objects are we talking about? For example, does it still >>> make sense to include both the 32-bit and 64-bit counters? How do we >>> represent speed/highspeed? Do we keep the ifCounterDiscontinuityTime, >>> defined in terms of sysUpTime? >>>=20 >>>=20 >>=20 >> My 2 cents: 11 leafs: >>=20 >> ifOperStatus >> ifLastChange >> ifHCInOctets >> ifHCInUcastPkts >> ifHCInMulticastPkts >> ifHCInBroadcastPkts >> ifHCOutOctets >> ifHCOutUcastPkts >> ifHCOutMulticastPkts >> ifHCOutBroadcastPkts >> ifCounterDiscontinuityTime >>=20 >> Change timeticks to date-and-time. >>=20 >>> /martin >>=20 >> Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Sun Aug 5 04:14:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9665D21F849D for ; Sun, 5 Aug 2012 04:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKIFUu8IsA9N for ; Sun, 5 Aug 2012 04:14:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 77BDA21F849C for ; Sun, 5 Aug 2012 04:14:20 -0700 (PDT) Received: from [172.29.2.202] (ablesys.cust.sloane.cz [62.240.166.138]) by mail.nic.cz (Postfix) with ESMTPSA id 96A231402E4; Sun, 5 Aug 2012 13:14:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344165257; bh=uyf+na2YksG7lA7UVQLLmovWEHL/KNrvHJvG9svJJ+c=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=X4ZvLIgVerAG+HXSDtOcHtmxrdImvUM3XvqbNj0QF2/7YHLYXAJfFI866Fg1mnRUM sF7Sdb19/OOJ2LfmvfSXcfvtbSZ/uaPzEW7fg8gHGjX98l3v0UVWFLf1kDyM029Qpe F1ZpRS0AjngJ4Ivz7RdeySmah6qVRvdqLlBKPlg8= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: Date: Sun, 5 Aug 2012 13:14:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> To: YumaWorks X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 11:14:36 -0000 On Aug 3, 2012, at 8:57 PM, YumaWorks wrote: >=20 >=20 > Sent from my iPhone >=20 > On Aug 3, 2012, at 10:01, Ladislav Lhotka wrote: >=20 >>=20 >> On Aug 3, 2012, at 7:31 AM, Andy Bierman wrote: >>=20 >>> I don't think there is much point to discussing implementation = details >>> on the WG mailing list. >>=20 >> It is not an implementation detail! What Jernej and I are trying to = communicate is that the current handling of 'when' constraints and the = related "auto-deletion" of nodes is not only hard-to-implement but also = ill-defined and broken. But as long as you dismiss any evidence of this = plain fact as "corner cases" we can hardly make our point. >>=20 >> The thing is: With increasing complexity of our data models, we must = be sure that our foundation is rock solid. With a complex model, such a = "corner case" can lead to mysterious behaviour or outright failures. Let = me paraphrase a Czech saying: A hundred corner cases are able to plague = a donkey. >>=20 >> Anyway, here is another corner case that we already had in our = private discussion: >>=20 >> container foo { >> when "bar !=3D 42"; >> leaf bar { >> type uint8; >> mandatory "true"; >> } >> } >>=20 >=20 >=20 > But this is a nonsense example > A real server would not ever do this It is valid YANG, so at least it is a flaw in language definition. Moreover, it doesn't really matter what the XPath expression is in my = example above, the problem is still the same: if "foo" is not present, = then the context node for the XPath expression doesn't exist end the = expression is therefore undefined. The 'when' statements thus cannot be = applied to make the mandatory property of "foo" conditional. Lada =20 >=20 > These are just implementation details for your tool. YANG does not = need to change.=20 >=20 >=20 > Andy >=20 >> 1. The "bar" leaf is set to 42 by the client. >> 2. The "foo" container is auto-deleted. >> 3. The XPath expression in 'when' loses its context node, so the = expression is not properly defined and cannot be used=20 >> for any argumentation about validity. >> 4. But then there is no reason why the mandatory leaf and container = are missing. >> 5. So what? >>=20 >> Lada >>=20 >>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>> On Fri, Aug 3, 2012 at 3:17 AM, Jernej Tuljak = wrote: >>>> Dne 3.8.2012 10:02, pi=9Ae Andy Bierman: >>>>>=20 >>>>> On Fri, Aug 3, 2012 at 12:21 AM, Jernej = Tuljak >>>>> wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> that's just the beauty of it. It is not a static test tool. It = adapts to >>>>>> whatever changes you make to the modules. It adapts when you = choose >>>>>> enabled >>>>>> features and it adapts when you change them. It tells you what = you did >>>>>> wrong >>>>>> while you write entire datastores, rpc operations, even when = dealing with >>>>>> incomplete XML documents. And it does so in quite a simple way. = The way >>>>>> of >>>>>> RFC6110, which extracts the entire schema from available modules = and with >>>>>> just a few XSLT transformations you are set to go. Forever. It's = quite >>>>>> genius really (credit to Ladislav and others involved with = RFC6110 here). >>>>>> I >>>>>> don't understand why anyone would bother reinventing the wheel = trying to >>>>>> implement his own way of validating NETCONF content when it's all = already >>>>>> out there. >>>>>>=20 >>>>>> I never claimed that pyang checks the validity of XPath = expressions. It >>>>>> cannot do so, because XPath expressions cannot be evaluated = without >>>>>> context >>>>>> and context can only be found within instance documents, a thing = that >>>>>> _never_ exists during YANG module validation. It only exists = during >>>>>> NETCONF >>>>>> content validation, when you have an actual instance document to = work >>>>>> with. >>>>>> Therefore when-stmt cannot be applied at any other time than = during >>>>>> content >>>>>> validation. It represents a semantic constraint on data nodes, = not a >>>>>> constraint on the schema nodes. And pyang applies these = constraints >>>>>> within >>>>>> pyang.dsdl plugin only when it is validating an XML document = against a >>>>>> YANG >>>>>> schema. There is no other way. >>>>>=20 >>>>> The YANG must and when statements can be checked to make sure >>>>> the XPath is well-formed and all the schema nodes are actually = defined. >>>>> There is really no reason for an YANG must or when stmt to = reference >>>>> garbage nodes that do not exist in the data model. >>>>>=20 >>>>>=20 >>>>>> I don't understand the need to merge YANG validation with NETCONF = content >>>>>> validation into a single validation process. It does not make = sense. As I >>>>>> understand it, this is exactly what you are doing. Sometimes it = even >>>>>> feels >>>>>> like you are saying that a schema node and an instance node are = the same >>>>>> thing. It should be clear that a schema node is not an instance = node, the >>>>>> former only represents the structure and conditions of appearance = of the >>>>>> latter. Schema nodes never get deleted, instance nodes do. >>>>>>=20 >>>>> Implementation details do not matter. >>>>> The server must send the correct responses and alter its >>>>> internal state correctly. There are many ways this could >>>>> be done. >>>>>=20 >>>>> Some servers allow YANG modules to be loaded and unloaded >>>>> at run-time. The schema tree is static, meaning once a node >>>>> is placed in the tree it doesn't move, but the tree can change at >>>>> run-time. >>>>> YANG deviations also affect the schema tree, which are allowed to >>>>> be loaded at any time. >>>>=20 >>>>=20 >>>> Of course. That's what makes YANG great. That it's extensible the = way any >>>> other schema is. A each set of modules may provide a different = schema. A >>>> single additional module may change the existing schema tree = significantly >>>> making it another schema. If-features are also great. But do note = that these >>>> are not the "runtime modifications to the schema tree" me and = Ladislav were >>>> talking about. What I've been saying all along is that if we have a = module >>>> set of size one (a single module) it's schema is always the same. A = schema >>>> node count will always be the same for it. The only way to modify = the count >>>> is via features or by adding new modules to the set, which does = happen, but >>>> not often. That's what I mean when I say that YANG is a static = schema. An >>>> extensible but static schema. Adding a module with deviations, = augments, >>>> etc. to the set creates a new but also static schema. >>>>=20 >>>> But none of this should have anything to do with NETCONF content = validation. >>>> Allowing the schema count to be modified during validation with = when-stmt's >>>> is just...well, bad. RFC6020 should have never allowed it. = Separation of >>>> YANG validation/compiling which results in a read-only schema tree = and >>>> NETCONF content validation, which only uses this schema tree to = validate an >>>> XML document, should have been enforced. I don't see any merit in = this being >>>> a single process. >>>>=20 >>>> Jernej >>>>=20 >>>>>=20 >>>>>> Let's return to Ladislav's example: >>>>>>=20 >>>>>> leaf X { >>>>>> type string; >>>>>> mandatory true; >>>>>> when ". =3D ../foo"; >>>>>> } >>>>>>=20 >>>>> Yes, there are some pathological cases that make no >>>>> semantic sense that cannot be implemented correctly. >>>>>=20 >>>>> leaf Y { >>>>> type int32; >>>>> mandatory true; >>>>> when "not(.)"; >>>>> } >>>>>=20 >>>>>=20 >>>>>> For when-stmt condition to be evaluated _at all_ an instance of X = must >>>>>> exist >>>>>> first, meaning that the mandatory constraint is always satisfied = if an >>>>>> evaluation occurred. After all X is the condition expression's = context >>>>>> node. >>>>>> You cannot evaluate without context. You can however validate = it's syntax >>>>>> at >>>>>> any time - provided that you are using a static schema, which = contains >>>>>> all >>>>>> the schema nodes for you to search. >>>>>>=20 >>>>>> If when is ever true or false, one can be sure that the mandatory >>>>>> constraint >>>>>> has been satisfied, eliminating the need to enforce it. >>>>>>=20 >>>>>> The above example represents an instance node, which has to exist = and >>>>>> fulfill the condition in the when-stmt at the same time. Anything = else is >>>>>> an >>>>>> error. It's actually mandatory which takes precedence here, so = what >>>>>> Ladislav >>>>>> currently does (structure first, then semantics) is the correct >>>>>> interpretation, IMO. >>>>>>=20 >>>>>> There's a reason why when-stmt's argument is an XPath expression = and not >>>>>> a >>>>>> YANG construct, like a schema-nodeid. >>>>>=20 >>>>> Yes, so they generate a boolean result. >>>>> A schema-nodeid is not relevant here. >>>>> That is used for augment and path targets. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Jernej >>>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>> Dne 3.8.2012 2:14, pi=9Ae Andy Bierman: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> Sorry but YANG does not work the way you think it does for the = sake of >>>>>>> your static test tool. BTW, pyang does not validate the XPath >>>>>>> statement. >>>>>>> It validates instance documents against the XPath that it finds. >>>>>>> This is hardly the same as verifying the correctness of the YANG >>>>>>> statement. >>>>>>>=20 >>>>>>> A false when-stmt is not an error unless it occurs in the RPC = input >>>>>>> parameters. (We are insulated from content because it >>>>>>> is declared as an 'anyxml' so from a RPC POV, the when-stmts >>>>>>> within the data are not relevant to RPC input validation.) >>>>>>>=20 >>>>>>> The XPath statements are conceptual. There is no requirement >>>>>>> by the server to use an XPath validator to implement them. >>>>>>> When-stmt is applied right away, not applied at validation >>>>>>> time like must-stmt. >>>>>>>=20 >>>>>>>=20 >>>>>>> Andy >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, Aug 2, 2012 at 5:02 PM, Ladislav Lhotka = wrote: >>>>>>>>=20 >>>>>>>> Jernej Tuljak writes: >>>>>>>>=20 >>>>>>>>> I think that the idea to completely decouple the schema from = instances >>>>>>>>> based on it is the way to go. Your schema is not such a = schema, since >>>>>>>>> it >>>>>>>>> needs an instance to determine it's final form (the instance = becomes a >>>>>>>>> part of the schema). It's form must be determined after every >>>>>>>>> modification to the instance. Constantly. Not entirely sure = how you do >>>>>>>>> it. >>>>>>>>=20 >>>>>>>> In fact the solution can already be found in RFC 6110: make = 'when' >>>>>>>> statement essentially equivalent to 'must', except for a = different >>>>>>>> error >>>>>>>> message. >>>>>>>>=20 >>>>>>>>> One other thing. Our generic client application displays the = entire >>>>>>>>> schema in a tree graphic component and even offers queries to = be made >>>>>>>>> from it. How could it possibly do that if the tree's final = form cannot >>>>>>>>> be determined? >>>>>>>>>=20 >>>>>>>>> Also this would make RFC6110 next to useless since the = assumption that >>>>>>>>> YANG schema is static is the foundation it builds upon. = Generating >>>>>>>>> DSDL >>>>>>>>> schema is an expensive operation...and it would have to be = done after >>>>>>>>> every modification to an instance document. >>>>>>>>=20 >>>>>>>> Absolutely. It would be possible to forget about RELAX NG and = implement >>>>>>>> all validation in Schematron. However, such an approach would = ignore >>>>>>>> the >>>>>>>> lessons learnt by the XML community and embodied in DSDL: = Schema-based >>>>>>>> validation is a very robust procedure that practically cannot = be fooled >>>>>>>> and >>>>>>>> provides guarantees that the instance document is syntactically = correct >>>>>>>> so >>>>>>>> that it can be safely parsed. Validation based on checking = XPath >>>>>>>> expressions >>>>>>>> is much more fragile and is best used only for "business rules" >>>>>>>> (semantic >>>>>>>> constrainst) AFTER schema-based validation has been = successfully >>>>>>>> finished. >>>>>>>>=20 >>>>>>>>> The when-stmt only makes its parent data definition statement >>>>>>>>> conditional. There's nothing written in RFC6020 that this = would imply >>>>>>>>> modifications to the schema (can't find it). Although multiple >>>>>>>>> paragraphs can be found which serve as workarounds for = non-static >>>>>>>>> implementations of YANG schema. The point in 8.3.1 Payload = Parsing >>>>>>>>> which >>>>>>>>> relates to when-stmt is an example. >>>>>>>>>=20 >>>>>>>>> Sorry, but I'm completely with Ladislav on this one. = Non-static schema >>>>>>>>> or run-time changes to a schema are bad and should never have = been >>>>>>>>> allowed to become a part of YANG. I cannot argue that they are = not a >>>>>>>>> part of it. >>>>>>>>=20 >>>>>>>> Agreed. >>>>>>>>=20 >>>>>>>> Lada >>>>>>>>=20 >>>>>>>>> Jernej >>>>>>>>>=20 >>>>>>>>>>> It doesn't matter how the error is generated. But it should = be >>>>>>>>>>> properly >>>>>>>>>>> generated. >>>>>>>>>>>=20 >>>>>>>>>>> Jernej >>>>>>>>>>=20 >>>>>>>>>> Andy >>>>>>>>>>=20 >>>>>>>>>>>> Lada >>>>>>>>>>>>=20 >>>>>>>>>>>>> But I can see how this is problematic. >>>>>>>>>>>>> Good thing we overloaded the unknown-element error-tag ;-) >>>>>>>>>>>>> It is used for unknown and unexpected elements. >>>>>>>>>>>>> If /foo/bar only exists if when=3Dtrue, then for = when=3Dfalse we would >>>>>>>>>>>>> have >>>>>>>>>>>>> to >>>>>>>>>>>>> decide if that node is unknown by the server, vs. an = instance >>>>>>>>>>>>> of that node is unexpected for the request. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Lada >>>>>>>>>>>>>>=20 >>>>>>>>>>>>> Andy >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Or does a conditional augment mean that the augmentation = will >>>>>>>>>>>>>>> always be >>>>>>>>>>>>>>> done but all of the augmented nodes "inherit" the = augment's when >>>>>>>>>>>>>>> conditions >>>>>>>>>>>>>>> making all of them conditional? This would make much = more sense >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> me. Would >>>>>>>>>>>>>>> this be legal as a potential workaround to dynamically = changing >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> module's >>>>>>>>>>>>>>> schema? What was the group's intention regarding this = matter? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> netmod mailing list >>>>>>>>>>>>>> netmod@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>> -- >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: E74E8C0C >>>>>>=20 >>>>>>=20 >>>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Sun Aug 5 04:54:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3115F21F849D for ; Sun, 5 Aug 2012 04:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TdclAmSkdps for ; Sun, 5 Aug 2012 04:54:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 21E0921F8493 for ; Sun, 5 Aug 2012 04:54:51 -0700 (PDT) Received: from [172.29.2.202] (ablesys.cust.sloane.cz [62.240.166.138]) by mail.nic.cz (Postfix) with ESMTPSA id C37031402E4; Sun, 5 Aug 2012 13:54:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344167690; bh=KQXJQpbVa5Fw4I6DNIpfm/SM4Ic8ProPqo8JoiSD+n4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xjT5XfzYo9BI/XbPsnXlrheO7aNvvE0y6r1movJnDOTG6qeCKOVUnMf42f3MYAWFQ fHJNIPhfBhpPNyFqxxVOYHmf9c5xje8zhkkekuW3B4osMoWfRkLoqFSdHiTjgZyc9m 2KimBtSGS26nKhLglkFlpUZ14Ct3NFQp54MrFrYM= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Sun, 5 Aug 2012 13:54:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13E37F5C-2F64-4C9B-B33D-1C7060E646D2@nic.cz> References: <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> <78939758ee86bdf7a321b5acb037c7f7@imap.plus.net> <20120803160911.GA88788@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 11:54:53 -0000 On Aug 4, 2012, at 7:34 PM, Andy Bierman wrote: > On Fri, Aug 3, 2012 at 9:09 AM, Juergen Schoenwaelder > wrote: >> On Fri, Aug 03, 2012 at 04:59:37PM +0100, Jonathan Hansford wrote: >>>=20 >>> As someone who is still getting >>> up-to-speed on YANG and therefore considers himself primarily a = reader >>> for now, I hope the issues that have been discussed in this thread = only >>> generate this level of uncertainty for tool developers and the task = of >>> readers remains simplified. How esoteric are these discussions? Are = we >>> looking at corner cases, or are these issues at the core of YANG = module >>> development? >>>=20 >>=20 >> My take is that these discussions, as important they might be for >> implementors, are for most users a non issue, especially readers. >>=20 >=20 > There are advanced YANG usage issues for YANG module writers. > Here are a few: >=20 > * Never reference descendant-or-self nodes in a when-stmt > * Should refer to descendant-or-self nodes in a must-stmt > (Choose easy to understand stmt placement) > * Use when-stmt in choice, case, uses with extreme care. > Be careful to identify the correct context node The only case when 'when' statement doesn't have the problem with = missing context node is for 'augment'. It is also the only case where = 'when' cannot be replaced with 'must'. IMO, an elegant solution to all these issues therefore would be to allow = 'when' only for making conditional augments, 'must' should suffice = everywhere else. All the caveats that you listed then wouldn't be = necessary. > * Make sure there are never any circular dependencies across > multiple when-stmts; best to refer only to static objects > in when-stmt (like the keys and mandatory nodes) Right, the "corner case" here is, e.g. container a { when "../b/bar =3D 1"; leaf foo { type uint8; mandatory true; } } container b { when "../a/foo =3D 1"; leaf bar { type uint8; mandatory true; } } Both 'when' statements refer to a mandatory node, so your advice doesn't = really help. Such circular dependencies may actually happen and would be hard to = detect, especially in deeper hierarchies. > * For must/when, be careful of referencing nodes in > different YANG features than the context node I don't think this can ever be a problem for 'must'. Do you have an = example? Lada >=20 >> /js >>=20 >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sun Aug 5 05:01:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB5F21F84A7 for ; Sun, 5 Aug 2012 05:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BemoaSv1oqpE for ; Sun, 5 Aug 2012 05:01:50 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EABA721F84A6 for ; Sun, 5 Aug 2012 05:01:49 -0700 (PDT) Received: by qcac10 with SMTP id c10so1395026qca.31 for ; Sun, 05 Aug 2012 05:01:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Mqtlg6j920oLpYda0AcDXc/3mkp0SNhRttcZvQ81u8I=; b=RL/bVnfpHKiILeReI9VPDvnS6c0srbN6Cf0hOiNTZ1SuctgSKEEji+kAyZq2Ybh5gM 8jKXglQf6MRNTq8Z7HcFq123RorMlBzJ8+U9UelxUrFoUZsOEb2misgC2byvWhj3p5T6 nMA5deWn4LxQ+lBfzEWwrDu2y4opHjJYtgRqsB7jx/kijAZMjFTfwOef2Zfr+u/HHG24 J5RVZTkiCkNhRm3HSxu3dQRG+0c4hklyetGdAk/TzvwM5UDVHDEazDFBZ4EZ1q3i49VU STZQEPzfZI/xRJKONdbI6GRQIXL2qCehqNoGn5g5tYz7HhIrQJ24+X/PZ7Za33sZE23V 4jSQ== MIME-Version: 1.0 Received: by 10.229.135.198 with SMTP id o6mr3786876qct.147.1344168109308; Sun, 05 Aug 2012 05:01:49 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sun, 5 Aug 2012 05:01:49 -0700 (PDT) In-Reply-To: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> Date: Sun, 5 Aug 2012 05:01:49 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkeJmxEfPFA+9GxZfV7Naa1W/kY8FtldwaKQ284GomAQ/J+hWyaNcDHhV0k1sPwi/hfrbSA Cc: "netmod@ietf.org" Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 12:01:50 -0000 ... >> But this is a nonsense example >> A real server would not ever do this > > It is valid YANG, so at least it is a flaw in language definition. > > Moreover, it doesn't really matter what the XPath expression is in my exa= mple above, the problem is still the same: if "foo" is not present, then th= e context node for the XPath expression doesn't exist end the expression is= therefore undefined. The 'when' statements thus cannot be applied to make = the mandatory property of "foo" conditional. > This is a well-known issue that only matters if the when-expr contains any descendant-or-self node references. This makes no semantic sense and probably should be made illegal in YANG. As long as the path-expr nodes point outside the subtree, it is OK to make a dummy (empty) context node to test for when-stmt. > Lada > Andy From andy@yumaworks.com Sun Aug 5 05:06:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CE521F84A7 for ; Sun, 5 Aug 2012 05:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBZRCvkvL0wT for ; Sun, 5 Aug 2012 05:06:17 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBF821F8497 for ; Sun, 5 Aug 2012 05:06:17 -0700 (PDT) Received: by qcac10 with SMTP id c10so1395987qca.31 for ; Sun, 05 Aug 2012 05:06:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=S3Gu402r9gFKhs1XVYmwJZD4328lqh0kkZMKbNgNdpY=; b=HrRhSQDW1hMLLJsT/qQ/dsQ4mmYS6AXu9HRZzubgXJ4GlAOvEp57cXabXr3DcCVwCh EPLrMJv8yS6nbhgL8/49LeNuFPep2XYE+rYhxKvpLxtT2P+XS5ffWXUbz+Twgcgj8PnE dO+bhkFKG71D/JXOoFV0G6bSLefPdAwb8oARzHfKIiKprE6O0QdtfFMtny7S0dmC5zyn Z0VNgKrAwp51+/97YvEtZBejN7DJ/+qftQ1xwIHknrJqQx4tP0Jn1yIcsucVbbQxSwmq No8HPrIHsOanENUU2HrYuVYpKwwx8FoTv2a08rDFfJr+MJsTTb0P2y88LXNw75XVmHo9 Gryw== MIME-Version: 1.0 Received: by 10.229.134.213 with SMTP id k21mr3795594qct.106.1344168376587; Sun, 05 Aug 2012 05:06:16 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sun, 5 Aug 2012 05:06:16 -0700 (PDT) In-Reply-To: <13E37F5C-2F64-4C9B-B33D-1C7060E646D2@nic.cz> References: <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> <78939758ee86bdf7a321b5acb037c7f7@imap.plus.net> <20120803160911.GA88788@elstar.local> <13E37F5C-2F64-4C9B-B33D-1C7060E646D2@nic.cz> Date: Sun, 5 Aug 2012 05:06:16 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkQKxzJowcSIiPcTNJDp2/XkWIio6UjYV31n2DF3XXdT5t06Smb1BRToa4Fd1yuJD01mdPK Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 12:06:18 -0000 On Sun, Aug 5, 2012 at 4:54 AM, Ladislav Lhotka wrote: > > On Aug 4, 2012, at 7:34 PM, Andy Bierman wrote: > >> On Fri, Aug 3, 2012 at 9:09 AM, Juergen Schoenwaelder >> wrote: >>> On Fri, Aug 03, 2012 at 04:59:37PM +0100, Jonathan Hansford wrote: >>>> >>>> As someone who is still getting >>>> up-to-speed on YANG and therefore considers himself primarily a reader >>>> for now, I hope the issues that have been discussed in this thread only >>>> generate this level of uncertainty for tool developers and the task of >>>> readers remains simplified. How esoteric are these discussions? Are we >>>> looking at corner cases, or are these issues at the core of YANG module >>>> development? >>>> >>> >>> My take is that these discussions, as important they might be for >>> implementors, are for most users a non issue, especially readers. >>> >> >> There are advanced YANG usage issues for YANG module writers. >> Here are a few: >> >> * Never reference descendant-or-self nodes in a when-stmt > >> * Should refer to descendant-or-self nodes in a must-stmt >> (Choose easy to understand stmt placement) >> * Use when-stmt in choice, case, uses with extreme care. >> Be careful to identify the correct context node > > The only case when 'when' statement doesn't have the problem with missing context node is for 'augment'. It is also the only case where 'when' cannot be replaced with 'must'. > This is wrong. It occurs in all cases where min-elements or mandatory=tree may be applied to missing instances, and the schema node has when-stmts tied to it. Inherited when-stmts from uses/choice/case are real fun to implement. > IMO, an elegant solution to all these issues therefore would be to allow 'when' only for making conditional augments, 'must' should suffice everywhere else. All the caveats that you listed then wouldn't be necessary. > No -- when-stmt is too useful. Some lines of code are harder than others to write. > >> * Make sure there are never any circular dependencies across >> multiple when-stmts; best to refer only to static objects >> in when-stmt (like the keys and mandatory nodes) > > Right, the "corner case" here is, e.g. > > container a { > when "../b/bar = 1"; > leaf foo { > type uint8; > mandatory true; > } > } > container b { > when "../a/foo = 1"; > leaf bar { > type uint8; > mandatory true; > } > } > > Both 'when' statements refer to a mandatory node, so your advice doesn't really help. > > Such circular dependencies may actually happen and would be hard to detect, especially in deeper hierarchies. > >> * For must/when, be careful of referencing nodes in >> different YANG features than the context node > > I don't think this can ever be a problem for 'must'. Do you have an example? > > Lada > Andy From lhotka@nic.cz Sun Aug 5 06:06:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2B221F845D for ; Sun, 5 Aug 2012 06:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNakRtYh3Xg9 for ; Sun, 5 Aug 2012 06:06:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CBC3221F8448 for ; Sun, 5 Aug 2012 06:06:52 -0700 (PDT) Received: from [172.29.2.202] (ablesys.cust.sloane.cz [62.240.166.138]) by mail.nic.cz (Postfix) with ESMTPSA id D4EBB1402E4; Sun, 5 Aug 2012 15:06:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344172011; bh=cNU3bJ1Wg4fbeZbTSm00StKSr8c+/WmLNGT6HHH+7nU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TmGF1CzXSd4J5B0yvAum2DXgmjQlUn5MBqUhibNTbPDv0GAxtnKelmUyOApxF2Cbe P3MOYdSljvf+WQLuiGY2726rfqxtEaDkBlGqW42BzoizREIa/MrqlZfJUvPafXZAgb Es6bAsLSc/Ct/yoyihBxu1oWvf1lZj92w/Kw89ME= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Sun, 5 Aug 2012 15:06:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 13:06:53 -0000 On Aug 5, 2012, at 2:01 PM, Andy Bierman wrote: > ... >>> But this is a nonsense example >>> A real server would not ever do this >>=20 >> It is valid YANG, so at least it is a flaw in language definition. >>=20 >> Moreover, it doesn't really matter what the XPath expression is in my = example above, the problem is still the same: if "foo" is not present, = then the context node for the XPath expression doesn't exist end the = expression is therefore undefined. The 'when' statements thus cannot be = applied to make the mandatory property of "foo" conditional. >>=20 >=20 > This is a well-known issue that only matters if the when-expr > contains any descendant-or-self node references. This makes > no semantic sense and probably should be made illegal in YANG. > As long as the path-expr nodes point outside the subtree, it is OK > to make a dummy (empty) context node to test for when-stmt. This is of course non-standard and other implementations may decide to = do something else, potentially with different results. Standard XPath = implementations are not able to do this, and that's why RFC 6110 is not = compatible with this kludge and indeed its validation results are = different for this special case. Lada =20 >=20 >=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Sun Aug 5 06:25:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEFA21F8475 for ; Sun, 5 Aug 2012 06:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCPqkMZkDh+Q for ; Sun, 5 Aug 2012 06:25:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 26AFD21F845E for ; Sun, 5 Aug 2012 06:25:33 -0700 (PDT) Received: from [172.29.2.202] (ablesys.cust.sloane.cz [62.240.166.138]) by mail.nic.cz (Postfix) with ESMTPSA id 5611C1402E4; Sun, 5 Aug 2012 15:25:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344173132; bh=Rztf+p4oal2x78VSPzsps4IZYnLxIJ8KZse6ZjnlF7w=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gBtIpNfUgrN4JcfB+MoIQE2xGutNrmOP0cbcQo5VA7GVbn3MF6vtKwYB8IIAQnHkv jOG6qoasZHWUMAx/G2mmGfKgglCdtFI7Ou8pmWFMPoylHAHEiNaewxwXoOahfVK5kk hGq3X/pOqrkokd5nOx12JbeG5B+BfS132EAT3yuQ= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Sun, 5 Aug 2012 15:25:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D537A77-E8DE-44B5-BC0D-5CFAA86FEFCF@nic.cz> References: <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> <78939758ee86bdf7a321b5acb037c7f7@imap.plus.net> <20120803160911.GA88788@elstar.local> <13E37F5C-2F64-4C9B-B33D-1C7060E646D2@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 13:25:34 -0000 On Aug 5, 2012, at 2:06 PM, Andy Bierman wrote: > On Sun, Aug 5, 2012 at 4:54 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 4, 2012, at 7:34 PM, Andy Bierman wrote: >>=20 >>> On Fri, Aug 3, 2012 at 9:09 AM, Juergen Schoenwaelder >>> wrote: >>>> On Fri, Aug 03, 2012 at 04:59:37PM +0100, Jonathan Hansford wrote: >>>>>=20 >>>>> As someone who is still getting >>>>> up-to-speed on YANG and therefore considers himself primarily a = reader >>>>> for now, I hope the issues that have been discussed in this thread = only >>>>> generate this level of uncertainty for tool developers and the = task of >>>>> readers remains simplified. How esoteric are these discussions? = Are we >>>>> looking at corner cases, or are these issues at the core of YANG = module >>>>> development? >>>>>=20 >>>>=20 >>>> My take is that these discussions, as important they might be for >>>> implementors, are for most users a non issue, especially readers. >>>>=20 >>>=20 >>> There are advanced YANG usage issues for YANG module writers. >>> Here are a few: >>>=20 >>> * Never reference descendant-or-self nodes in a when-stmt >>=20 >>> * Should refer to descendant-or-self nodes in a must-stmt >>> (Choose easy to understand stmt placement) >>> * Use when-stmt in choice, case, uses with extreme care. >>> Be careful to identify the correct context node >>=20 >> The only case when 'when' statement doesn't have the problem with = missing context node is for 'augment'. It is also the only case where = 'when' cannot be replaced with 'must'. >>=20 >=20 > This is wrong. >=20 > It occurs in all cases where min-elements or mandatory=3Dtree may > be applied to missing instances, and the schema node has when-stmts > tied to it. Inherited when-stmts from uses/choice/case are real fun > to implement. No, 'when' under 'augment' doesn't suffer from these problems because 1. 'augment' cannot add mandatory contents, 2. the context node (augment target) is not removed if the XPath = expression in 'when' evaluates to false. >=20 >=20 >> IMO, an elegant solution to all these issues therefore would be to = allow 'when' only for making conditional augments, 'must' should suffice = everywhere else. All the caveats that you listed then wouldn't be = necessary. >>=20 >=20 > No -- when-stmt is too useful. Can you be more specific? What are the cases where 'when' gives you more = than 'must'? FWIW, in the routing model I systematically replaced all = non-augment whens with musts and it doesn't seem to matter (except that = Martin complained about it in his review). Lada =20 > Some lines of code are harder than others to write. >=20 >=20 >=20 >=20 >>=20 >>> * Make sure there are never any circular dependencies across >>> multiple when-stmts; best to refer only to static objects >>> in when-stmt (like the keys and mandatory nodes) >>=20 >> Right, the "corner case" here is, e.g. >>=20 >> container a { >> when "../b/bar =3D 1"; >> leaf foo { >> type uint8; >> mandatory true; >> } >> } >> container b { >> when "../a/foo =3D 1"; >> leaf bar { >> type uint8; >> mandatory true; >> } >> } >>=20 >> Both 'when' statements refer to a mandatory node, so your advice = doesn't really help. >>=20 >> Such circular dependencies may actually happen and would be hard to = detect, especially in deeper hierarchies. >>=20 >>> * For must/when, be careful of referencing nodes in >>> different YANG features than the context node >>=20 >> I don't think this can ever be a problem for 'must'. Do you have an = example? >>=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sun Aug 5 06:53:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015E021F84E1 for ; Sun, 5 Aug 2012 06:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y-tvWbp63Lr for ; Sun, 5 Aug 2012 06:53:33 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4826121F84A6 for ; Sun, 5 Aug 2012 06:53:33 -0700 (PDT) Received: by qaea16 with SMTP id a16so454803qae.10 for ; Sun, 05 Aug 2012 06:53:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=dGHDae6cCpBhZuDdcOXBC5gTEY7a+H1p9332DazVJrQ=; b=RcTXNQ6qCawUZ25yL38sLzyWIQYrJ3lhaAzbqJ3mdEzyAtZL1F2NUx6Tv0lT5dSK6w GE6VTC4ftmNFvp9EM0ptSc+lmp1s0FM45Il/YVUb+q97FD90X2xsUi6uKuiKP6rTssMB l9V9I6u3WlO8nKfhw8MNn6h23PPHzPzJUMpGThGQURdl/DpPe/+XkDEUWxvY1Znt8GeR WAsI108yp3cWtz5btgULUBBguXQ2SXwCgcMO/53nGZS2grofBw+m1WIzLBhmdh/jqSEK p7ge4TG6IIO5PEC/kkw9f+kUXGi9SkBp8AkJeL3mZAvnWn5P7bgFCRiymquQr+5sK10f 71bg== MIME-Version: 1.0 Received: by 10.229.134.213 with SMTP id k21mr3904303qct.106.1344174812555; Sun, 05 Aug 2012 06:53:32 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sun, 5 Aug 2012 06:53:32 -0700 (PDT) In-Reply-To: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> Date: Sun, 5 Aug 2012 06:53:32 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl5Iaqvy6joHSLud4c5gVXCKhtd4p2+BVy4DrKKJyU23UhMSdMjwDLzi/4keLiK7gEVObIJ Cc: "netmod@ietf.org" Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 13:53:34 -0000 On Sun, Aug 5, 2012 at 6:06 AM, Ladislav Lhotka wrote: > > On Aug 5, 2012, at 2:01 PM, Andy Bierman wrote: > >> ... >>>> But this is a nonsense example >>>> A real server would not ever do this >>> >>> It is valid YANG, so at least it is a flaw in language definition. >>> >>> Moreover, it doesn't really matter what the XPath expression is in my e= xample above, the problem is still the same: if "foo" is not present, then = the context node for the XPath expression doesn't exist end the expression = is therefore undefined. The 'when' statements thus cannot be applied to mak= e the mandatory property of "foo" conditional. >>> >> >> This is a well-known issue that only matters if the when-expr >> contains any descendant-or-self node references. This makes >> no semantic sense and probably should be made illegal in YANG. >> As long as the path-expr nodes point outside the subtree, it is OK >> to make a dummy (empty) context node to test for when-stmt. > > This is of course non-standard and other implementations may decide to do= something else, potentially with different results. Standard XPath impleme= ntations are not able to do this, and that's why RFC 6110 is not compatible= with this kludge and indeed its validation results are different for this = special case. > What do you mean it is non-standard? However the server produces the correct answer is fine. These are conceptual statements anyway -- it says so right in the RFC. The server does not have to use XPath to implement the constraint. I do not agree that we need to change the ABNF for YANG to make when-stmt simpler to implement. It has been pointed out that there are many ways to achieve the same resulting nodes in YANG (i.e., inline vs. augment vs. grouping/uses). There is nothing special about augment wrt/ when-stmt processing. (It's just as hard as the other corner-cases ;-) I objected to the DSDL draft several times because the normative behavior for a NETCONF server can only be determined by the NETCONF server, and not some static message on the wire approach. There are limitations to offline validation and the correct solution is to document those limitations, not change the server to match them. > Lada Andy From lhotka@nic.cz Sun Aug 5 11:09:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE6621F8533 for ; Sun, 5 Aug 2012 11:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sOrSCqVoFqI for ; Sun, 5 Aug 2012 11:09:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8775921F852E for ; Sun, 5 Aug 2012 11:09:21 -0700 (PDT) Received: from [172.29.2.202] (ablesys.cust.sloane.cz [62.240.166.138]) by mail.nic.cz (Postfix) with ESMTPSA id 4DA541402E4; Sun, 5 Aug 2012 20:09:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344190160; bh=4j82ABL693NmDVJtbJVUuLSE+peNPEFVci9vLLICxvM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=JfN58O2HOjRv/1SdxGmfR2eHfAVQgrNKDRVSTgluNX22yzfvMJ2TBq5yvVvX661B6 Z6Z5vbWUKUce84PEB6GAN9kp5MFL1pTbKHj0L62DPrs7qZNe2P3ziHxFnZEPgaoae8 HUOIzlj8hdq9ec03RENfih/gWDG4btb/LUvS1D/Q= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Sun, 5 Aug 2012 20:09:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50165FAA.4040700@mg-soft.com> <20120731.072142.385816835.mbj@tail-f.com> <5018D91A.20609@mg-soft.com> <8C38DBBC-5489-4857-A743-9360F23B197F@nic.cz> <501A23CE.8020504@mg-soft.com> <501A4A8C.8080107@mg-soft.com> <501B7BFC.3090404@mg-soft.com> <501BA51D.4070404@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 18:09:22 -0000 On Aug 5, 2012, at 3:53 PM, Andy Bierman wrote: > On Sun, Aug 5, 2012 at 6:06 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 5, 2012, at 2:01 PM, Andy Bierman wrote: >>=20 >>> ... >>>>> But this is a nonsense example >>>>> A real server would not ever do this >>>>=20 >>>> It is valid YANG, so at least it is a flaw in language definition. >>>>=20 >>>> Moreover, it doesn't really matter what the XPath expression is in = my example above, the problem is still the same: if "foo" is not = present, then the context node for the XPath expression doesn't exist = end the expression is therefore undefined. The 'when' statements thus = cannot be applied to make the mandatory property of "foo" conditional. >>>>=20 >>>=20 >>> This is a well-known issue that only matters if the when-expr >>> contains any descendant-or-self node references. This makes >>> no semantic sense and probably should be made illegal in YANG. >>> As long as the path-expr nodes point outside the subtree, it is OK >>> to make a dummy (empty) context node to test for when-stmt. >>=20 >> This is of course non-standard and other implementations may decide = to do something else, potentially with different results. Standard XPath = implementations are not able to do this, and that's why RFC 6110 is not = compatible with this kludge and indeed its validation results are = different for this special case. >>=20 >=20 > What do you mean it is non-standard? > However the server produces the correct answer is fine. > These are conceptual statements anyway -- it says so right > in the RFC. The server does not have to use XPath to > implement the constraint. I am not aware of any text about adding dummy nodes in 6020. The = adjective "conceptually" is clearly explained in sec. 7.19.5: "This = means that an implementation does not have to use an XPath evaluator on = the device." Nothing about tinkering with the instance document. >=20 > I do not agree that we need to change the ABNF for YANG to > make when-stmt simpler to implement. It has been pointed out > that there are many ways to achieve the same resulting nodes > in YANG (i.e., inline vs. augment vs. grouping/uses). There is > nothing special about augment wrt/ when-stmt processing. > (It's just as hard as the other corner-cases ;-) Maybe it's not necessary to change the ABNF. I actually propose the = following compromise: 1. For validation purposes, 'when' is essentially equivalent to 'must'. = In terms of RFC 6020 it only means to remove two words '"when" or' in = the first paragraph of sec. 8.2, and perhaps explicitly say that "when" = conditions do not override mandatory properties of nodes as defined in = sec. 3.1. BTW, features are really different because their presence or absence is = known beforehand and they don't depend on instance documents. 2. Operationally, if the server finds out that the value of a "when" = condition on an existing data node changes from false to true and the = node is not mandatory (as per sec. 3.1), it will remove that node and = its descendants. I believe that your caveats for YANG writers would then be no more = necessary and no changes to existing modules would be needed.=20 Lada >=20 > I objected to the DSDL draft several times because the normative > behavior for a NETCONF server can only be determined by the > NETCONF server, and not some static message on the wire approach. >=20 > There are limitations to offline validation and the correct solution > is to document those limitations, not change the server to match them. >=20 >=20 >> Lada >=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Sun Aug 5 12:38:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3008321F854A for ; Sun, 5 Aug 2012 12:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZUs6+UtIRRT for ; Sun, 5 Aug 2012 12:38:29 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9671B21F853F for ; Sun, 5 Aug 2012 12:38:29 -0700 (PDT) Received: from localhost (213-65-181-96-no181.tbcn.telia.com [213.65.181.96]) by mail.tail-f.com (Postfix) with ESMTPSA id 7710D12008BF; Sun, 5 Aug 2012 21:38:27 +0200 (CEST) Date: Sun, 05 Aug 2012 21:38:25 +0200 (CEST) Message-Id: <20120805.213825.278234967.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 19:38:30 -0000 Hi, I agree fully with Andy on this issue. The main problem seems to be that the DSDL mapping cannot handle "when" properly when it is combined with mandatory true. But this is a not a problem with 6020. The evaluation mechanism is (conceptually) as follows. If a node with a when stmt exists, the when expression is evaluated with the node as context node. If the expression evaluates to false, the node is deleted. If a node with a when expression is about to be created, it is added to the tree (I think this is what Andy refers to as the dummy node), and the when expression is evaluated with the node as context node. If the expression is evaluated to false, the error specified in 8.3.1 is returned. With this model, it is even clear what happens if a when expression refers to descendant-or-self (Andy's recommendation still applies - don't do this b/c it is probably not what you want). The only problematic case is if there is a loop (a refers to b and b refers to a). This could have been clarified in the text (e.g., by stating that the behavior in such a pathological case is implementation dependent). /martin From mbj@tail-f.com Sun Aug 5 12:47:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4941D21F854A for ; Sun, 5 Aug 2012 12:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqn605neL6XF for ; Sun, 5 Aug 2012 12:47:18 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B00E521F8549 for ; Sun, 5 Aug 2012 12:47:18 -0700 (PDT) Received: from localhost (213-65-181-96-no181.tbcn.telia.com [213.65.181.96]) by mail.tail-f.com (Postfix) with ESMTPSA id F192B12008BF; Sun, 5 Aug 2012 21:47:17 +0200 (CEST) Date: Sun, 05 Aug 2012 21:47:16 +0200 (CEST) Message-Id: <20120805.214716.349497832.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <20120805.213825.278234967.mbj@tail-f.com> References: <20120805.213825.278234967.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 19:47:19 -0000 Martin Bjorklund wrote: > Hi, > > I agree fully with Andy on this issue. The main problem seems to be > that the DSDL mapping cannot handle "when" properly when it is > combined with mandatory true. But this is a not a problem with 6020. > > The evaluation mechanism is (conceptually) as follows. If a node with > a when stmt exists, the when expression is evaluated with the node as > context node. If the expression evaluates to false, the node is > deleted. If a node with a when expression is about to be created, it > is added to the tree (I think this is what Andy refers to as the dummy > node), and the when expression is evaluated with the node as context > node. If the expression is evaluated to false, the error specified in > 8.3.1 is returned. I forgot to add that if the when expression is false, the mandatory / min-elements stmts are not checked. Also, the when expression does *not* dynamically change the schema tree. It only has implications on the data tree. /martin From lhotka@nic.cz Sun Aug 5 13:45:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7F021F854A for ; Sun, 5 Aug 2012 13:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAsInA0s1G-e for ; Sun, 5 Aug 2012 13:45:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 93EBF21F855E for ; Sun, 5 Aug 2012 13:45:05 -0700 (PDT) Received: from [172.29.2.202] (ablesys.cust.sloane.cz [62.240.166.138]) by mail.nic.cz (Postfix) with ESMTPSA id 4CC791402E4; Sun, 5 Aug 2012 22:45:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344199504; bh=Krw4sg0rOKGWTF7kgTy90KpZajZGneAIc7pXAd9OwiY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hFBHpyTJmoe/VCQbmYnrGb8Mb4vL+vLN2k4eAzj3DfTtHyrPJbAEw7Qo3GL2GHQRK 1IRjP8T0IUZ+hc6LdKnxAuuzfmxcQulxWTnPNNfEiu+sFFqDSfTy/tA9wVgNxugtCR ojY6kjhxtKDqAbGovyUNXR0c7FTmsDjm8+wCCwTk= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120805.213825.278234967.mbj@tail-f.com> Date: Sun, 5 Aug 2012 22:45:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120805.213825.278234967.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 20:45:06 -0000 On Aug 5, 2012, at 9:38 PM, Martin Bjorklund wrote: > Hi, >=20 > I agree fully with Andy on this issue. The main problem seems to be > that the DSDL mapping cannot handle "when" properly when it is > combined with mandatory true. But this is a not a problem with 6020. Sorry, I cannot agree. Sec. 7.19.5 defines the context node for 'when' = XPath expression as follows: o If the "when" statement is a child of any other data definition statement, the context node is the data definition's node in the data tree. It doesn't say what happens if "data definition's node" is absent in the = data tree. And without a context node, the XPath expression is not = well-defined. =20 >=20 > The evaluation mechanism is (conceptually) as follows. If a node with > a when stmt exists, the when expression is evaluated with the node as > context node. If the expression evaluates to false, the node is > deleted. If a node with a when expression is about to be created, it > is added to the tree (I think this is what Andy refers to as the dummy > node), and the when expression is evaluated with the node as context > node. If the expression is evaluated to false, the error specified in > 8.3.1 is returned. OK, but what about this: leaf enable-foo { type boolean; } container foo { when "../enable-foo =3D 'true'"; leaf bar { type uint8; mandatory true; } } Now, consider an instance document containing = false but not , i.e. the XPath context = node is missing. Simple question: is this a valid document? If your = answer is yes, could you explain how the validity follows from 6020? I think this is where Andy needs to temporarily insert as his = dummy element, which is however not "about to be created" as you write, = at least not as a result of client's action. This has no support in = 6020, the alone XPath. Lada =20 >=20 > With this model, it is even clear what happens if a when expression > refers to descendant-or-self (Andy's recommendation still applies - > don't do this b/c it is probably not what you want). The only > problematic case is if there is a loop (a refers to b and b refers to > a). This could have been clarified in the text (e.g., by stating that > the behavior in such a pathological case is implementation dependent). >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sun Aug 5 14:58:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB45721F856D for ; Sun, 5 Aug 2012 14:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9l0V-456wRZ for ; Sun, 5 Aug 2012 14:58:26 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E3AA821F8568 for ; Sun, 5 Aug 2012 14:58:25 -0700 (PDT) Received: by qaea16 with SMTP id a16so558686qae.10 for ; Sun, 05 Aug 2012 14:58:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=qv8US6+6aw548ap0cMIDlwsH8+Hnfe8YABtkEd7I6oQ=; b=Jqqm4ay1l0xhwi+ZyPR+SBdJErK51XM3CRquKjqsB/PgMW1VQ0A+nonOBI7QPT7G9e U0f6VHTZKQzXpW96QgTe6UJq8LmaXVocIit3Ls35iZgcW4DaiNG8eY84aERC5320CuGJ RyC+mOLpxees12KN/PxBaBD0+tqZ1LJ/Fer8RWiCcMx0tc3wR6mqKB3BrNLviZjLO4aI bT1QKKJ/1MNiM16YJA4IRYyCXATVzR2DKfTYBASfpRyqmC4OT59EwM9nHgSNEZLMfcFA t/l2FFYLej4NGr9AbpqxHK9Xtn8+ezYf5B4ZcpuZ/9hlVi+Cs+lDj4qMfuPkaB7EEvZS kiXQ== MIME-Version: 1.0 Received: by 10.224.42.76 with SMTP id r12mr14601605qae.96.1344203905437; Sun, 05 Aug 2012 14:58:25 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sun, 5 Aug 2012 14:58:25 -0700 (PDT) In-Reply-To: References: <20120805.213825.278234967.mbj@tail-f.com> Date: Sun, 5 Aug 2012 14:58:25 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl+DWgQCRY2p1cE3t9fPKQQPWKdDVjK+N8Z2xAReRH/lKJtpMjwRbsBD73RvKybkI4o7NfA Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 21:58:26 -0000 On Sun, Aug 5, 2012 at 1:45 PM, Ladislav Lhotka wrote: > > On Aug 5, 2012, at 9:38 PM, Martin Bjorklund wrote: > >> Hi, >> >> I agree fully with Andy on this issue. The main problem seems to be >> that the DSDL mapping cannot handle "when" properly when it is >> combined with mandatory true. But this is a not a problem with 6020. > > Sorry, I cannot agree. Sec. 7.19.5 defines the context node for 'when' XPath expression as follows: > > o If the "when" statement is a child of any other data definition > statement, the context node is the data definition's node in the > data tree. > > It doesn't say what happens if "data definition's node" is absent in the data tree. And without a context node, the XPath expression is not well-defined. > > >> >> The evaluation mechanism is (conceptually) as follows. If a node with >> a when stmt exists, the when expression is evaluated with the node as >> context node. If the expression evaluates to false, the node is >> deleted. If a node with a when expression is about to be created, it >> is added to the tree (I think this is what Andy refers to as the dummy >> node), and the when expression is evaluated with the node as context >> node. If the expression is evaluated to false, the error specified in >> 8.3.1 is returned. > > OK, but what about this: > > leaf enable-foo { > type boolean; > } > container foo { > when "../enable-foo = 'true'"; > leaf bar { > type uint8; > mandatory true; > } > } > > Now, consider an instance document containing false but not , i.e. the XPath context node is missing. Simple question: is this a valid document? If your answer is yes, could you explain how the validity follows from 6020? > > I think this is where Andy needs to temporarily insert as his dummy element, which is however not "about to be created" as you write, at least not as a result of client's action. This has no support in 6020, the alone XPath. > It is just an implementation choice to use a data tree at all. A temporary node that only exists during some internal server state and is never visible to the client is not a standards issue. > Lada Andy > >> >> With this model, it is even clear what happens if a when expression >> refers to descendant-or-self (Andy's recommendation still applies - >> don't do this b/c it is probably not what you want). The only >> problematic case is if there is a loop (a refers to b and b refers to >> a). This could have been clarified in the text (e.g., by stating that >> the behavior in such a pathological case is implementation dependent). >> >> >> /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From j.schoenwaelder@jacobs-university.de Mon Aug 6 02:00:44 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4473021F8598 for ; Mon, 6 Aug 2012 02:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL4zf2iur7bL for ; Mon, 6 Aug 2012 02:00:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5576721F84E4 for ; Mon, 6 Aug 2012 02:00:43 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 011F82092C; Mon, 6 Aug 2012 11:00:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TPpvaCGANbB0; Mon, 6 Aug 2012 11:00:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81E98207E0; Mon, 6 Aug 2012 11:00:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9F93F21065FC; Mon, 6 Aug 2012 11:00:40 +0200 (CEST) Date: Mon, 6 Aug 2012 11:00:40 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120806090040.GA93000@elstar.local> Mail-Followup-To: Martin Bjorklund , pgili@cisco.com, netmod@ietf.org References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120731.090257.513496394.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 09:00:44 -0000 On Tue, Jul 31, 2012 at 09:02:57AM -0700, Martin Bjorklund wrote: > Hi, > > "Patrick Gili (pgili)" wrote: > > Also, it is convenient to traverse interface stacks bottom-up, rather than > > top-down. This is the reason why RFC 2864 came about. > > Does this mean that you suggest we add something like: > > list interface { > ... > leaf-list superior-if { > type interface-ref; > config false; > } > } > > or would you like to see both: > > leaf-list subordinate-if { ... } > leaf-list superior-if { ... } The interfaces MIB calls these higher-layer and lower-layer interfaces. (It actually uses the terms "higher sub-layer" and "lower sub-layer", probably because sometimes a single network protocol layer may actually have a stack of interfaces.) Unless these terms are broken, I would rather stick to them since this might reduce confusion. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From pgili@cisco.com Mon Aug 6 03:04:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FFB21F8627 for ; Mon, 6 Aug 2012 03:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izVT1b4uAQYv for ; Mon, 6 Aug 2012 03:04:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B332821F8622 for ; Mon, 6 Aug 2012 03:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=1627; q=dns/txt; s=iport; t=1344247466; x=1345457066; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GZI3hXKOTpghazZZvAkzvQpN2aMMHn4/JZ0ZqOwcyto=; b=krgB2ythNTil+48RWZHH4bDT+tamSK9+fa2SCJqDfo15XcJ4ICnPuLn4 qNkOiycctxyf5XM7lIh5uRU9nCFS71S2W/EatQ3B46Y3LTov0lTXu5iB8 4M6o5X+YFFiaetSXWCTuBoUsqMW0HveP33QRytn/tP/MHkmrNHGGJJoRB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAuWH1CtJXG//2dsb2JhbABCA7k+gQeCIAEBAQQSASc/DAICAgEIDgIBBAEBAQoUCQcbFxQJCAIEAQ0FCBqHa5tBn2kEi0aDY4JBYAOjb4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,718,1336348800"; d="scan'208";a="108769172" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 06 Aug 2012 10:04:26 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q76A4QIs011306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 10:04:26 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.192]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 05:04:25 -0500 From: "Patrick Gili (pgili)" To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNbpZApLzaXn+U8UWilvWloQKDDJdCpy8AgAACpICAAAXyAIAAAmSAgAAhk4CAAF1OIIAJVbZegAARjyA= Date: Mon, 6 Aug 2012 10:04:25 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB04264A@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120806090040.GA93000@elstar.local> In-Reply-To: <20120806090040.GA93000@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.006 x-tm-as-result: No--50.832700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 10:04:27 -0000 Hi Juergen, I think these names are broken. If you read section 3.1.1 of RFC 2863, you'= ll find the formal definitions of superior and subordinate interfaces. Patrick -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, August 06, 2012 5:01 AM To: Martin Bjorklund Cc: Patrick Gili (pgili); netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module On Tue, Jul 31, 2012 at 09:02:57AM -0700, Martin Bjorklund wrote: > Hi, >=20 > "Patrick Gili (pgili)" wrote: > > Also, it is convenient to traverse interface stacks bottom-up,=20 > > rather than top-down. This is the reason why RFC 2864 came about. >=20 > Does this mean that you suggest we add something like: >=20 > list interface { > ... > leaf-list superior-if { > type interface-ref; > config false; > } > } =20 >=20 > or would you like to see both: >=20 > leaf-list subordinate-if { ... } > leaf-list superior-if { ... } The interfaces MIB calls these higher-layer and lower-layer interfaces. (I= t actually uses the terms "higher sub-layer" and "lower sub-layer", probabl= y because sometimes a single network protocol layer may actually have a sta= ck of interfaces.) Unless these terms are broken, I would rather stick to t= hem since this might reduce confusion. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 6 03:37:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3E321F862B for ; Mon, 6 Aug 2012 03:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq9-JbxOB-jC for ; Mon, 6 Aug 2012 03:37:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C194421F8628 for ; Mon, 6 Aug 2012 03:37:04 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23A4D20C0F; Mon, 6 Aug 2012 12:37:04 +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 S5Fe-tWQ1P9n; Mon, 6 Aug 2012 12:37:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A94B120C1C; Mon, 6 Aug 2012 12:37:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8FDF12106ADA; Mon, 6 Aug 2012 12:37:03 +0200 (CEST) Date: Mon, 6 Aug 2012 12:37:03 +0200 From: Juergen Schoenwaelder To: "Patrick Gili (pgili)" Message-ID: <20120806103703.GC93276@elstar.local> Mail-Followup-To: "Patrick Gili (pgili)" , Martin Bjorklund , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> <20120806090040.GA93000@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB04264A@xmb-aln-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB04264A@xmb-aln-x14.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 10:37:05 -0000 On Mon, Aug 06, 2012 at 10:04:25AM +0000, Patrick Gili (pgili) wrote: > Hi Juergen, > > I think these names are broken. If you read section 3.1.1 of RFC 2863, you'll find the formal definitions of superior and subordinate interfaces. > Formal definitions? I find these words only in quotes. Not sure what that suggests. I am worried if we name things differently in YANG models and SMIv2 models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Aug 6 13:17:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D490011E809A for ; Mon, 6 Aug 2012 13:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4GlV1IGuL4s for ; Mon, 6 Aug 2012 13:17:59 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD2911E8098 for ; Mon, 6 Aug 2012 13:17:59 -0700 (PDT) Received: from localhost (213-65-181-96-no181.tbcn.telia.com [213.65.181.96]) by mail.tail-f.com (Postfix) with ESMTPSA id 16F3E1200D5B; Mon, 6 Aug 2012 22:17:57 +0200 (CEST) Date: Mon, 06 Aug 2012 22:17:55 +0200 (CEST) Message-Id: <20120806.221755.449072128.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120805.213825.278234967.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:18:00 -0000 Ladislav Lhotka wrote: > > On Aug 5, 2012, at 9:38 PM, Martin Bjorklund wrote: > > > Hi, > > > > I agree fully with Andy on this issue. The main problem seems to be > > that the DSDL mapping cannot handle "when" properly when it is > > combined with mandatory true. But this is a not a problem with 6020. > > Sorry, I cannot agree. Sec. 7.19.5 defines the context node for 'when' XPath > expression as follows: > > o If the "when" statement is a child of any other data definition > statement, the context node is the data definition's node in the > data tree. > > It doesn't say what happens if "data definition's node" is absent in the data > tree. And without a context node, the XPath expression is not well-defined. > > > > > > The evaluation mechanism is (conceptually) as follows. If a node with > > a when stmt exists, the when expression is evaluated with the node as > > context node. If the expression evaluates to false, the node is > > deleted. If a node with a when expression is about to be created, it > > is added to the tree (I think this is what Andy refers to as the dummy > > node), and the when expression is evaluated with the node as context > > node. If the expression is evaluated to false, the error specified in > > 8.3.1 is returned. > > OK, but what about this: > > leaf enable-foo { > type boolean; > } > container foo { > when "../enable-foo = 'true'"; > leaf bar { > type uint8; > mandatory true; > } > } > > Now, consider an instance document containing false > but not , i.e. the XPath context node is missing. Simple question: is > this a valid document? If your answer is yes, could you explain how the > validity follows from 6020? > > I think this is where Andy needs to temporarily insert as his dummy > element, which is however not "about to be created" as you write, at least not > as a result of client's action. This has no support in 6020, the alone XPath. Ok, I see your point. But this doesn't seem to be related to the original issue in this thread - that "when" somehow modifies the *schema tree*. /martin From andy@yumaworks.com Mon Aug 6 13:36:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E2911E80A6 for ; Mon, 6 Aug 2012 13:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ5ot+KzYYy1 for ; Mon, 6 Aug 2012 13:36:35 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1A611E80DB for ; Mon, 6 Aug 2012 13:36:34 -0700 (PDT) Received: by qaea16 with SMTP id a16so1264258qae.10 for ; Mon, 06 Aug 2012 13:36:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=eorDjzq9pCGFPgIeF6Omx9/OHlCud4dapKWhiZOHcJE=; b=FPv0C4diWpXF1LahxyiUdHAi3AkJ+OODny19YkB239gXcrjZGy6nIY45Fntbe3Q1U0 3VnMJJq6NEo1Jiw7/FF7b/6hHb2b9cst+LJtrtcnV15UUK8ownssaVi/1vLKTmSGpbV5 YHtDNQqOosDQpIJNIHBvQDvceBs5GdiTDTy/GPmjNteocBj2pgqOPCcFRyGnsfA5u5S/ LqasUuwDj9VVe1vvWaVcmoaBlLnskf8tg4oo7Ilep7cnoG3LZxzOCHLnd98a4vX0kX82 EZrZlPNflEVLfqpP2c1PLfET5jFepDg5toL/Yq4xwTwSsWGy3l65foXEUTL+cZp58uuX 9CvA== MIME-Version: 1.0 Received: by 10.224.213.74 with SMTP id gv10mr19890299qab.25.1344285394496; Mon, 06 Aug 2012 13:36:34 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Mon, 6 Aug 2012 13:36:34 -0700 (PDT) In-Reply-To: <20120806.221755.449072128.mbj@tail-f.com> References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> Date: Mon, 6 Aug 2012 13:36:34 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkI7/vvub5bYxAQa1nOtiyxWY4oSq3bxIc7CenWA0lboEvgJqu4PY96jbGTnNmR0qUO+hj5 Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:36:36 -0000 On Mon, Aug 6, 2012 at 1:17 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> On Aug 5, 2012, at 9:38 PM, Martin Bjorklund wrote: >> >> > Hi, >> > >> > I agree fully with Andy on this issue. The main problem seems to be >> > that the DSDL mapping cannot handle "when" properly when it is >> > combined with mandatory true. But this is a not a problem with 6020. >> >> Sorry, I cannot agree. Sec. 7.19.5 defines the context node for 'when' XPath >> expression as follows: >> >> o If the "when" statement is a child of any other data definition >> statement, the context node is the data definition's node in the >> data tree. >> >> It doesn't say what happens if "data definition's node" is absent in the data >> tree. And without a context node, the XPath expression is not well-defined. >> >> >> > >> > The evaluation mechanism is (conceptually) as follows. If a node with >> > a when stmt exists, the when expression is evaluated with the node as >> > context node. If the expression evaluates to false, the node is >> > deleted. If a node with a when expression is about to be created, it >> > is added to the tree (I think this is what Andy refers to as the dummy >> > node), and the when expression is evaluated with the node as context >> > node. If the expression is evaluated to false, the error specified in >> > 8.3.1 is returned. >> >> OK, but what about this: >> >> leaf enable-foo { >> type boolean; >> } >> container foo { >> when "../enable-foo = 'true'"; >> leaf bar { >> type uint8; >> mandatory true; >> } >> } >> >> Now, consider an instance document containing false >> but not , i.e. the XPath context node is missing. Simple question: is >> this a valid document? If your answer is yes, could you explain how the >> validity follows from 6020? >> >> I think this is where Andy needs to temporarily insert as his dummy >> element, which is however not "about to be created" as you write, at least not >> as a result of client's action. This has no support in 6020, the alone XPath. > > Ok, I see your point. But this doesn't seem to be related to the > original issue in this thread - that "when" somehow modifies the > *schema tree*. > I agree. I was not clear when I referred to schema nodes appearing and disappearing out of the schema tree. Technically, the implementation does not add or remove any schema nodes (independently of load and unload module operations). Schema nodes have some saved state, and when the API functions that find schema nodes are used, the disabled nodes are skipped. So the yuma schema tree is static. > > /martin Andy From ietfc@btconnect.com Tue Aug 7 02:32:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A753B21F8673 for ; Tue, 7 Aug 2012 02:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.645 X-Spam-Level: X-Spam-Status: No, score=-3.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RIHnb0oBpLb for ; Tue, 7 Aug 2012 02:32:26 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6D05821F8671 for ; Tue, 7 Aug 2012 02:32:25 -0700 (PDT) Received: from mail72-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 09:32:21 +0000 Received: from mail72-co1 (localhost [127.0.0.1]) by mail72-co1-R.bigfish.com (Postfix) with ESMTP id 9C30BA80359; Tue, 7 Aug 2012 09:32:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail72-co1 (localhost.localdomain [127.0.0.1]) by mail72-co1 (MessageSwitch) id 1344331939723313_30796; Tue, 7 Aug 2012 09:32:19 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.236]) by mail72-co1.bigfish.com (Postfix) with ESMTP id AE9E88800EB; Tue, 7 Aug 2012 09:32:19 +0000 (UTC) Received: from DB3PRD0702HT001.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 09:32:17 +0000 Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by pod51017.outlook.com (10.3.4.141) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 7 Aug 2012 09:32:09 +0000 Message-ID: <033201cd747e$e666a3c0$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Martin Bjorklund References: <20120802163323.GA86561@elstar.local><20120803.074537.496599422.mbj@tail-f.com> Date: Tue, 7 Aug 2012 10:27:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:32:29 -0000 ---- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: Sent: Saturday, August 04, 2012 6:21 PM > On Fri, Aug 3, 2012 at 7:45 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> IMO, it is unacceptable to rely on the existence of IF-MIB > >> in order to retrieve interface counters. > > > > So which objects are we talking about? For example, does it still > > make sense to include both the 32-bit and 64-bit counters? How do we > > represent speed/highspeed? Do we keep the ifCounterDiscontinuityTime, > > defined in terms of sysUpTime? > > My 2 cents: 11 leafs: > > ifOperStatus > ifLastChange > ifHCInOctets > ifHCInUcastPkts > ifHCInMulticastPkts > ifHCInBroadcastPkts > ifHCOutOctets > ifHCOutUcastPkts > ifHCOutMulticastPkts > ifHCOutBroadcastPkts > ifCounterDiscontinuityTime > > Change timeticks to date-and-time. The logic of timeticks was that every box had a timer that popped every few mS or more often, but not all boxes, perhaps not many boxes, had a date-and-time facility (something I am reminded of every power cut when I have to reinput day of week to my answerphone which can do very clever things but never knows what date it is). I do not know how current hubs, switches etc stack up on this. Tom Petch > > /martin > > Andy From ietfc@btconnect.com Tue Aug 7 02:38:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAAB21F8670 for ; Tue, 7 Aug 2012 02:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.143 X-Spam-Level: X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=1.456, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUQ11RSRG0qA for ; Tue, 7 Aug 2012 02:38:38 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6538621F866E for ; Tue, 7 Aug 2012 02:38:38 -0700 (PDT) Received: from mail43-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 09:38:32 +0000 Received: from mail43-tx2 (localhost [127.0.0.1]) by mail43-tx2-R.bigfish.com (Postfix) with ESMTP id A413444013D; Tue, 7 Aug 2012 09:38:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT010.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail43-tx2 (localhost.localdomain [127.0.0.1]) by mail43-tx2 (MessageSwitch) id 1344332311246700_13199; Tue, 7 Aug 2012 09:38:31 +0000 (UTC) Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.243]) by mail43-tx2.bigfish.com (Postfix) with ESMTP id 393F92015D; Tue, 7 Aug 2012 09:38:31 +0000 (UTC) Received: from DB3PRD0702HT010.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 09:38:30 +0000 Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by pod51017.outlook.com (10.3.4.178) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 7 Aug 2012 09:38:23 +0000 Message-ID: <033a01cd747f$c4ec46e0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , "Patrick Gili (pgili)" References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com><20120731.090257.513496394.mbj@tail-f.com><20120806090040.GA93000@elstar.local><50E64ADF99EAEE4CACEC18958F0FC0AB04264A@xmb-aln-x14.cisco.com> <20120806103703.GC93276@elstar.local> Date: Tue, 7 Aug 2012 10:33:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:38:41 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Patrick Gili (pgili)" Cc: Sent: Monday, August 06, 2012 11:37 AM > On Mon, Aug 06, 2012 at 10:04:25AM +0000, Patrick Gili (pgili) wrote: > > Hi Juergen, > > > > I think these names are broken. If you read section 3.1.1 of RFC 2863, you'll find the formal definitions of superior and subordinate interfaces. > > > > Formal definitions? I find these words only in quotes. Not sure what > that suggests. I am worried if we name things differently in YANG > models and SMIv2 models. I agree. Where the names have been long established and the semantics are the same, then we should resist the temptation to 'improve' the names; of course we can, but we do our users a disservice by doing so. Tom Petch > > /js > From lhotka@nic.cz Wed Aug 8 09:18:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D7911E8106 for ; Wed, 8 Aug 2012 09:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eToCksfqC27 for ; Wed, 8 Aug 2012 09:18:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4021F86E4 for ; Wed, 8 Aug 2012 09:18:16 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.21]) by mail.nic.cz (Postfix) with ESMTPSA id 40557140496; Wed, 8 Aug 2012 18:18:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344442695; bh=u0QAd35FU8RJOtq8EZrnNMD2yxqkPniMrNLgeU15o08=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=JT5VgYG3ViQWqlM9a7iVuK1JJdbfsX7jbyqBhPTa7dvBPdgoyQt+X9CFZW49UrnzW fM9D+2jwSjvRv02AFL7/n1dEjnYA8QPT4ROsKYdytVDE3l/oljurMFGGJj8S87H/v1 lkhl2malmm+yH0ih420xzZ7im8BDJKvfpxFkVae4= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120806.221755.449072128.mbj@tail-f.com> Date: Wed, 8 Aug 2012 18:18:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:18:18 -0000 On Aug 6, 2012, at 10:17 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Aug 5, 2012, at 9:38 PM, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> I agree fully with Andy on this issue. The main problem seems to be >>> that the DSDL mapping cannot handle "when" properly when it is >>> combined with mandatory true. But this is a not a problem with = 6020. >>=20 >> Sorry, I cannot agree. Sec. 7.19.5 defines the context node for = 'when' XPath >> expression as follows: >>=20 >> o If the "when" statement is a child of any other data definition >> statement, the context node is the data definition's node in the >> data tree. >>=20 >> It doesn't say what happens if "data definition's node" is absent in = the data >> tree. And without a context node, the XPath expression is not = well-defined. >>=20 >>=20 >>>=20 >>> The evaluation mechanism is (conceptually) as follows. If a node = with >>> a when stmt exists, the when expression is evaluated with the node = as >>> context node. If the expression evaluates to false, the node is >>> deleted. If a node with a when expression is about to be created, = it >>> is added to the tree (I think this is what Andy refers to as the = dummy >>> node), and the when expression is evaluated with the node as context >>> node. If the expression is evaluated to false, the error specified = in >>> 8.3.1 is returned. >>=20 >> OK, but what about this: >>=20 >> leaf enable-foo { >> type boolean; >> } >> container foo { >> when "../enable-foo =3D 'true'"; >> leaf bar { >> type uint8; >> mandatory true; >> } >> } >>=20 >> Now, consider an instance document containing = false >> but not , i.e. the XPath context node is missing. Simple = question: is >> this a valid document? If your answer is yes, could you explain how = the >> validity follows from 6020? >>=20 >> I think this is where Andy needs to temporarily insert as his = dummy >> element, which is however not "about to be created" as you write, at = least not >> as a result of client's action. This has no support in 6020, the = alone XPath. >=20 > Ok, I see your point. But this doesn't seem to be related to the > original issue in this thread - that "when" somehow modifies the > *schema tree*. Not schema tree but schema, with which one can check the structure of an = XML document without looking into element values of the validated = document (think of a RELAX NG or XSD schema). The 'mandatory' statement and the rules of section 3.1 in RFC 6020 = result in schema constraints, but 'when' is a semantic constraint which = should have no influence on the schema. Anyway, if we can agree that the instance document in my example above = is *not* valid, I will be satisfied. Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Aug 8 09:49:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF2211E8107 for ; Wed, 8 Aug 2012 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myl3IVXhliNZ for ; Wed, 8 Aug 2012 09:49:30 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7929C11E8097 for ; Wed, 8 Aug 2012 09:49:30 -0700 (PDT) Received: by qcac10 with SMTP id c10so699962qca.31 for ; Wed, 08 Aug 2012 09:49:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nHq8w6GqXRiS16jNDMgOzFHpEcgBdXdtfbkR1a34glU=; b=FEuyl6FOBM0e/vG1RkbxGVjsV6TznY0UaROZR99Npmzs/mLZRESsJuxJ8trUTq38yN OTmd5cpJ+uOlwHH0ISk/cvOaCgi5GI7Ck5m2hxDdvasWdb8qjO/YSuWp93uOTQSZyq4N RT4WTgMkzoiM5fu74X59mPVBd4/ioMCWSgZNqw9szJnDdgdgjkW5SFE6pOVQnbMkV4xg LmJa84s7q0hhWICw/QptgtL//DyZK7txLF9TwLN/d1glL6J4IidodrpgLiTbQxtRMLws xKqJFm7lMEt4wMo9Yeqpnc6itBV/EDY+DhNo6P9m34wsjUCNUxXdOOhH8+9rIkUkHI/W riDw== MIME-Version: 1.0 Received: by 10.224.214.69 with SMTP id gz5mr22060409qab.21.1344444569955; Wed, 08 Aug 2012 09:49:29 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Wed, 8 Aug 2012 09:49:29 -0700 (PDT) In-Reply-To: References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> Date: Wed, 8 Aug 2012 09:49:29 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmCI2K0YVO9Nq1dhLD93sgdaGwcQWdO5dtYH239Mt+L7DhSo8Y4+w5yKrytM9Gf/lCG4eyd Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:49:31 -0000 On Wed, Aug 8, 2012 at 9:18 AM, Ladislav Lhotka wrote: > > On Aug 6, 2012, at 10:17 PM, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >>> >>> On Aug 5, 2012, at 9:38 PM, Martin Bjorklund wrote: >>> >>>> Hi, >>>> >>>> I agree fully with Andy on this issue. The main problem seems to be >>>> that the DSDL mapping cannot handle "when" properly when it is >>>> combined with mandatory true. But this is a not a problem with 6020. >>> >>> Sorry, I cannot agree. Sec. 7.19.5 defines the context node for 'when' XPath >>> expression as follows: >>> >>> o If the "when" statement is a child of any other data definition >>> statement, the context node is the data definition's node in the >>> data tree. >>> >>> It doesn't say what happens if "data definition's node" is absent in the data >>> tree. And without a context node, the XPath expression is not well-defined. >>> >>> >>>> >>>> The evaluation mechanism is (conceptually) as follows. If a node with >>>> a when stmt exists, the when expression is evaluated with the node as >>>> context node. If the expression evaluates to false, the node is >>>> deleted. If a node with a when expression is about to be created, it >>>> is added to the tree (I think this is what Andy refers to as the dummy >>>> node), and the when expression is evaluated with the node as context >>>> node. If the expression is evaluated to false, the error specified in >>>> 8.3.1 is returned. >>> >>> OK, but what about this: >>> >>> leaf enable-foo { >>> type boolean; >>> } >>> container foo { >>> when "../enable-foo = 'true'"; >>> leaf bar { >>> type uint8; >>> mandatory true; >>> } >>> } >>> >>> Now, consider an instance document containing false >>> but not , i.e. the XPath context node is missing. Simple question: is >>> this a valid document? If your answer is yes, could you explain how the >>> validity follows from 6020? >>> >>> I think this is where Andy needs to temporarily insert as his dummy >>> element, which is however not "about to be created" as you write, at least not >>> as a result of client's action. This has no support in 6020, the alone XPath. >> >> Ok, I see your point. But this doesn't seem to be related to the >> original issue in this thread - that "when" somehow modifies the >> *schema tree*. > > Not schema tree but schema, with which one can check the structure of an XML document without looking into element values of the validated document (think of a RELAX NG or XSD schema). > > The 'mandatory' statement and the rules of section 3.1 in RFC 6020 result in schema constraints, but 'when' is a semantic constraint which should have no influence on the schema. > > Anyway, if we can agree that the instance document in my example above is *not* valid, I will be satisfied. > Not sure what instance document you mean, but no, I do not agree that an offline validation tool can ignore the nodes that are currently in the target datastore for every possible NETCONF request. The 'when-stmt' is a useful tool that allows many database tasks to be automated. The protocol operations are written for a server to implement, and they often require that the current values in the target datastore be examined to process the client request correctly. The use of edit-config as a 'patch' tool is a feature, not a bug. To do complete validation, the offline validation tool needs a correct copy of the current target datastore. > Lada > Andy From andy@yumaworks.com Wed Aug 8 10:47:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F0621F86BB for ; Wed, 8 Aug 2012 10:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw7qyBZFV-aU for ; Wed, 8 Aug 2012 10:47:56 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B561321F86B9 for ; Wed, 8 Aug 2012 10:47:56 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1174410ghb.31 for ; Wed, 08 Aug 2012 10:47:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nr9IA/dJUylFlmB1kdRZkEE+hesOylePeQNOhOkkJIs=; b=i+H6X4Dnfbo+2VgdUXZYadMqtrkvVMEVRFns+ht0FhByWRA5ud7GdsgJqr86Jf170X hsnrqzrbuvQ99xNVrGwxB2CCtnIuby6pQzDV7OMnuGMZANhPOagS61GJJhxkvqkIGGJZ Rt7W6rg4TNVQPvpgAH4Db2O4TVd7U4J5HiO1drEofGHuVr9ZiYUutRQ67MFZrQ0hdvrX S5JWMxGkMF02A0gfscMwVJB5xzi2lTR2n7SJ+1a8+wnvA13AGQteOB6u03peq/gVgNxM s/ATbDKwfw05bWVpK9us6KMzcb0Zdo3GmINRa9oJcR/lugMuGrERwuQWqdFaLuoNUN6f ZHIA== MIME-Version: 1.0 Received: by 10.50.15.229 with SMTP id a5mr1832766igd.21.1344448070795; Wed, 08 Aug 2012 10:47:50 -0700 (PDT) Received: by 10.50.23.2 with HTTP; Wed, 8 Aug 2012 10:47:50 -0700 (PDT) In-Reply-To: References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> Date: Wed, 8 Aug 2012 10:47:50 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlLVORN5nUZUAnDdHQZVc2Fr1J7ZOzpb/fuPIEzuG0Tt/AC/u/cJ42v7Nv6Bt/XYBUFzHX8 Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:47:57 -0000 ..... >>>> OK, but what about this: >>>> >>>> leaf enable-foo { >>>> type boolean; >>>> } >>>> container foo { >>>> when "../enable-foo = 'true'"; >>>> leaf bar { >>>> type uint8; >>>> mandatory true; >>>> } >>>> } >>>> >>>> Now, consider an instance document containing false >>>> but not , i.e. the XPath context node is missing. Simple question: is >>>> this a valid document? If your answer is yes, could you explain how the >>>> validity follows from 6020? >>>> I assume these are the contents of the node in an edit-config operation. The edit-config operation and the when statement are very clear about when-stmts that are applied to the context node vs. those which are applied to a conceptual datastore + state document. In your example, setting enable-foo=false or deleting it will cause the /foo container to be deleted by the server. The YANG statements like when/must apply to conceptual datastores, not to NETCONF messages. >>>> I think this is where Andy needs to temporarily insert as his dummy >>>> element, which is however not "about to be created" as you write, at least not >>>> as a result of client's action. This has no support in 6020, the alone XPath. >>> >>> Ok, I see your point. But this doesn't seem to be related to the >>> original issue in this thread - that "when" somehow modifies the >>> *schema tree*. >> >> Not schema tree but schema, with which one can check the structure of an XML document without looking into element values of the validated document (think of a RELAX NG or XSD schema). >> A static off-line validation tool is limited in its inherent capabilities. The protocol clearly defines the operations in terms of the behavior on the server and the target datastore. An offline tool cannot provide datastore validation without knowing what is in it. .... >> Lada >> > Andy From lhotka@nic.cz Wed Aug 8 12:51:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEE011E810E for ; Wed, 8 Aug 2012 12:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1QRsjt+nh3C for ; Wed, 8 Aug 2012 12:51:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 50D2511E810C for ; Wed, 8 Aug 2012 12:51:00 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.21]) by mail.nic.cz (Postfix) with ESMTPSA id 86FF014048B; Wed, 8 Aug 2012 21:50:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344455459; bh=M9M0kkwYVEfiOoKx6Bvkf/cRsLqjo+UyS/zAW+/EZ5I=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=V4sjj+a1QiLqZZY6kCAYkVi10sQm81kFLWLHviXqzLwhwNE/CIGW0xRLN2EC+uhfW k+JP5Ts5TzRDSjlbaDYjZvhKFyLw59NdB2/XNcjej7TFLAIGF7Mx6clpbEebhHjy6w lVnhz2b9Zy8RIfSH+Z5qow9Vqq6B71ZM9pOQAGX0= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Wed, 8 Aug 2012 21:50:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D9E992F-A4DD-4943-97AB-A7F0B79A5E2D@nic.cz> References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 19:51:04 -0000 On Aug 8, 2012, at 6:49 PM, Andy Bierman wrote: > On Wed, Aug 8, 2012 at 9:18 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 6, 2012, at 10:17 PM, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On Aug 5, 2012, at 9:38 PM, Martin Bjorklund wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I agree fully with Andy on this issue. The main problem seems to = be >>>>> that the DSDL mapping cannot handle "when" properly when it is >>>>> combined with mandatory true. But this is a not a problem with = 6020. >>>>=20 >>>> Sorry, I cannot agree. Sec. 7.19.5 defines the context node for = 'when' XPath >>>> expression as follows: >>>>=20 >>>> o If the "when" statement is a child of any other data definition >>>> statement, the context node is the data definition's node in = the >>>> data tree. >>>>=20 >>>> It doesn't say what happens if "data definition's node" is absent = in the data >>>> tree. And without a context node, the XPath expression is not = well-defined. >>>>=20 >>>>=20 >>>>>=20 >>>>> The evaluation mechanism is (conceptually) as follows. If a node = with >>>>> a when stmt exists, the when expression is evaluated with the node = as >>>>> context node. If the expression evaluates to false, the node is >>>>> deleted. If a node with a when expression is about to be created, = it >>>>> is added to the tree (I think this is what Andy refers to as the = dummy >>>>> node), and the when expression is evaluated with the node as = context >>>>> node. If the expression is evaluated to false, the error = specified in >>>>> 8.3.1 is returned. >>>>=20 >>>> OK, but what about this: >>>>=20 >>>> leaf enable-foo { >>>> type boolean; >>>> } >>>> container foo { >>>> when "../enable-foo =3D 'true'"; >>>> leaf bar { >>>> type uint8; >>>> mandatory true; >>>> } >>>> } >>>>=20 >>>> Now, consider an instance document containing = false >>>> but not , i.e. the XPath context node is missing. Simple = question: is >>>> this a valid document? If your answer is yes, could you explain how = the >>>> validity follows from 6020? >>>>=20 >>>> I think this is where Andy needs to temporarily insert as his = dummy >>>> element, which is however not "about to be created" as you write, = at least not >>>> as a result of client's action. This has no support in 6020, the = alone XPath. >>>=20 >>> Ok, I see your point. But this doesn't seem to be related to the >>> original issue in this thread - that "when" somehow modifies the >>> *schema tree*. >>=20 >> Not schema tree but schema, with which one can check the structure of = an XML document without looking into element values of the validated = document (think of a RELAX NG or XSD schema). >>=20 >> The 'mandatory' statement and the rules of section 3.1 in RFC 6020 = result in schema constraints, but 'when' is a semantic constraint which = should have no influence on the schema. >>=20 >> Anyway, if we can agree that the instance document in my example = above is *not* valid, I will be satisfied. >>=20 >=20 > Not sure what instance document you mean, but no, I do The document that contains false but not . > not agree that an offline validation tool can ignore > the nodes that are currently in the target datastore > for every possible NETCONF request. The 'when-stmt' I don't understand. > is a useful tool that allows many database tasks to be automated. >=20 > The protocol operations are written for a server to implement, > and they often require that the current values in the target datastore > be examined to process the client request correctly. Are these server actions documented in any standard? >=20 > The use of edit-config as a 'patch' tool is a feature, not a bug. I have nothing against it, provided that the resulting datastore content = is valid. > To do complete validation, the offline validation tool needs a correct > copy of the current target datastore. Is this correct copy different from what a client obtains after sending = a without a filter? Lada >=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Aug 8 13:04:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BD911E810E for ; Wed, 8 Aug 2012 13:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGdy4W7tRrbb for ; Wed, 8 Aug 2012 13:04:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 96C3411E80F3 for ; Wed, 8 Aug 2012 13:04:41 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.21]) by mail.nic.cz (Postfix) with ESMTPSA id BEBEB14048B; Wed, 8 Aug 2012 22:04:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344456280; bh=0qZhOXi1H+zjvLZTPMdng1Op8LwvNX/mgMBqyPgD/mk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=C5jUVPH/hj8LWAOq52NqbJbr2D+PHaYaP+2kSJuE/rFvgoms9MP01pZY9gE2SFAtA qKdWHHFAEXUacHRAnLVtAS/PuouVYu/mdzREqoQDsDSoiQD8Dma/Y0sNxtLUGnfDi8 7zQFRy8Mi/LcrZ63VFbuBkq70aWRLnbhXE8Ip9Y8= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Wed, 8 Aug 2012 22:04:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 20:04:42 -0000 On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote: > ..... >>>>> OK, but what about this: >>>>>=20 >>>>> leaf enable-foo { >>>>> type boolean; >>>>> } >>>>> container foo { >>>>> when "../enable-foo =3D 'true'"; >>>>> leaf bar { >>>>> type uint8; >>>>> mandatory true; >>>>> } >>>>> } >>>>>=20 >>>>> Now, consider an instance document containing = false >>>>> but not , i.e. the XPath context node is missing. Simple = question: is >>>>> this a valid document? If your answer is yes, could you explain = how the >>>>> validity follows from 6020? >>>>>=20 >=20 > I assume these are the contents of the node in an edit-config To keep things simple, it could be the content of a . > operation. The edit-config operation and the when statement are very = clear > about when-stmts that are applied to the context node vs. > those which are applied to a conceptual datastore + state document. >=20 > In your example, setting enable-foo=3Dfalse or deleting it will cause = the > /foo container to be deleted by the server. The YANG statements > like when/must apply to conceptual datastores, not to NETCONF > messages. If the server does this, the resulting datastore content is invalid = because from sec. 3.1 in 6020 it follows that the "foo" container is = mandatory. The 'when' statement cannot change this because its XPath = expression has no context node and is therefore undefined. Lada >=20 >=20 >=20 >>>>> I think this is where Andy needs to temporarily insert as = his dummy >>>>> element, which is however not "about to be created" as you write, = at least not >>>>> as a result of client's action. This has no support in 6020, the = alone XPath. >>>>=20 >>>> Ok, I see your point. But this doesn't seem to be related to the >>>> original issue in this thread - that "when" somehow modifies the >>>> *schema tree*. >>>=20 >>> Not schema tree but schema, with which one can check the structure = of an XML document without looking into element values of the validated = document (think of a RELAX NG or XSD schema). >>>=20 >=20 > A static off-line validation tool is limited in its inherent = capabilities. > The protocol clearly defines the operations in terms of the > behavior on the server and the target datastore. An offline tool > cannot provide datastore validation without knowing what is in it. >=20 > .... >>> Lada >>>=20 >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@gmail.com Wed Aug 8 15:49:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E368F11E8141 for ; Wed, 8 Aug 2012 15:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=2.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NycpYoFri-m for ; Wed, 8 Aug 2012 15:49:56 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 951BE11E813F for ; Wed, 8 Aug 2012 15:49:55 -0700 (PDT) Received: by lahm15 with SMTP id m15so735503lah.31 for ; Wed, 08 Aug 2012 15:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7K7g0gsugnvvae2DZBjn4AwBUvGRhbcCBMgjF4v54ZU=; b=VKlQld2CXh2YxnASDjdrvU4XC4VfWI9Fl/GM/4MkDnjGqepCCj0vN7IHZV0iUk902H ROP+N0z9MMFzOLELlVdHeIagJjls8IJ4Y/7j3h+qBDRwYCxOJRf4C1Klok384KdEr4ga sFQ1iuAd8O4E2RVNUZCnrs7/6DE1q3JYBMOQNHS3pKzPw5ljWQHp4tUPJa91INpcl75p UOyyqCCe/V9g0lZ4TzDZ+krW1/edjqJfLgM1KoLnDa0tB/xSMhGPYIskL9atYiOzi8nr 7Ww+2MP8vm5kumbcjtoeAI/o1kse61Ayenh8OGnVY07fwlEFfv+HAaPYSQS8VKtdC1lN wb3w== MIME-Version: 1.0 Received: by 10.112.98.231 with SMTP id el7mr8609514lbb.14.1344466194485; Wed, 08 Aug 2012 15:49:54 -0700 (PDT) Received: by 10.114.15.7 with HTTP; Wed, 8 Aug 2012 15:49:54 -0700 (PDT) Received: by 10.114.15.7 with HTTP; Wed, 8 Aug 2012 15:49:54 -0700 (PDT) In-Reply-To: References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> Date: Thu, 9 Aug 2012 00:49:54 +0200 Message-ID: From: Jernej Tuljak To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=f46d04016983ef512704c6c8edea Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 22:52:43 -0000 --f46d04016983ef512704c6c8edea Content-Type: text/plain; charset=ISO-8859-1 Are you sure that you used the correct example? Because it does not seem consistent with what you are saying. Container foo is not mandatory.. And there's nothing wrong with an instance of enable-foo being present in a datastore without an instance of foo. There's no such constraint on the enable-foo leaf. It's just a plain old leaf. What you claim would hold if mandatory-stmt and when-stmt were used on the same leaf. A server would delete such a leaf instance if it's when evaluated to false..but doing so would be deleting a mandatory data node - leaving the datastore in an invalid state. Is this what you are saying? Jernej Dne 8. avg. 2012 22:04 je "Ladislav Lhotka" napisal/-a: > > On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote: > > > ..... > >>>>> OK, but what about this: > >>>>> > >>>>> leaf enable-foo { > >>>>> type boolean; > >>>>> } > >>>>> container foo { > >>>>> when "../enable-foo = 'true'"; > >>>>> leaf bar { > >>>>> type uint8; > >>>>> mandatory true; > >>>>> } > >>>>> } > >>>>> > >>>>> Now, consider an instance document containing > false > >>>>> but not , i.e. the XPath context node is missing. Simple > question: is > >>>>> this a valid document? If your answer is yes, could you explain how > the > >>>>> validity follows from 6020? > >>>>> > > > > I assume these are the contents of the node in an edit-config > > To keep things simple, it could be the content of a . > > > operation. The edit-config operation and the when statement are very > clear > > about when-stmts that are applied to the context node vs. > > those which are applied to a conceptual datastore + state document. > > > > In your example, setting enable-foo=false or deleting it will cause the > > /foo container to be deleted by the server. The YANG statements > > like when/must apply to conceptual datastores, not to NETCONF > > messages. > > If the server does this, the resulting datastore content is invalid > because from sec. 3.1 in 6020 it follows that the "foo" container is > mandatory. The 'when' statement cannot change this because its XPath > expression has no context node and is therefore undefined. > > > Lada > > > > > > > > >>>>> I think this is where Andy needs to temporarily insert as his > dummy > >>>>> element, which is however not "about to be created" as you write, at > least not > >>>>> as a result of client's action. This has no support in 6020, the > alone XPath. > >>>> > >>>> Ok, I see your point. But this doesn't seem to be related to the > >>>> original issue in this thread - that "when" somehow modifies the > >>>> *schema tree*. > >>> > >>> Not schema tree but schema, with which one can check the structure of > an XML document without looking into element values of the validated > document (think of a RELAX NG or XSD schema). > >>> > > > > A static off-line validation tool is limited in its inherent > capabilities. > > The protocol clearly defines the operations in terms of the > > behavior on the server and the target datastore. An offline tool > > cannot provide datastore validation without knowing what is in it. > > > > .... > >>> Lada > >>> > >> > > > > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f46d04016983ef512704c6c8edea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Are you sure that you used the correct example? Because it does not seem= consistent with what you are saying. Container foo is not mandatory.. And = there's nothing wrong with an instance of enable-foo being present in a= datastore without an instance of foo. There's no such constraint on th= e enable-foo leaf. It's just a plain old leaf.

What you claim would hold if mandatory-stmt and when-stmt were used on t= he same leaf. A server would delete such a leaf instance if it's when e= valuated to false..but doing so would be deleting a mandatory data node - l= eaving the datastore in an invalid state. Is this what you are saying?

Jernej

Dne 8. avg. 2012 22:04 je "Ladislav Lhotka&= quot; <lhotka@nic.cz> napisal/-a= :

On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote:

> .....
>>>>> OK, but what about this:
>>>>>
>>>>> leaf enable-foo {
>>>>> =A0 type boolean;
>>>>> }
>>>>> container foo {
>>>>> =A0 when "../enable-foo =3D 'true'";=
>>>>> =A0 leaf bar {
>>>>> =A0 =A0 =A0 type uint8;
>>>>> =A0 =A0 =A0 mandatory true;
>>>>> =A0 }
>>>>> }
>>>>>
>>>>> Now, consider an instance document containing <enab= le-foo>false</enable-foo>
>>>>> but not <foo>, i.e. the XPath context node is mi= ssing. Simple question: is
>>>>> this a valid document? If your answer is yes, could yo= u explain how the
>>>>> validity follows from 6020?
>>>>>
>
> I assume these are the contents of the <config> node in an edit-= config

To keep things simple, it could be the content of a <copy-config>.
> operation. =A0The edit-config operation and the when statement are ver= y clear
> about when-stmts that are applied to the <rpc> context node vs.<= br> > those which are applied to a conceptual datastore + state document. >
> In your example, setting enable-foo=3Dfalse or deleting it will cause = the
> /foo container to be deleted by the server. =A0The YANG statements
> like when/must apply to conceptual datastores, not to NETCONF
> messages.

If the server does this, the resulting datastore content is invalid because= from sec. 3.1 in 6020 it follows that the "foo" container is man= datory. The 'when' statement cannot change this because its XPath e= xpression has no context node and is therefore undefined.


Lada

>
>
>
>>>>> I think this is where Andy needs to temporarily insert= <foo> as his dummy
>>>>> element, which is however not "about to be create= d" as you write, at least not
>>>>> as a result of client's action. This has no suppor= t in 6020, the alone XPath.
>>>>
>>>> Ok, I see your point. =A0But this doesn't seem to be r= elated to the
>>>> original issue in this thread - that "when" some= how modifies the
>>>> *schema tree*.
>>>
>>> Not schema tree but schema, with which one can check the struc= ture of an XML document without looking into element values of the validate= d document (think of a RELAX NG or XSD schema).
>>>
>
> A static off-line validation tool is limited in its inherent capabilit= ies.
> The protocol clearly defines the operations in terms of the
> behavior on the server and the target datastore. =A0An offline tool > cannot provide datastore validation without knowing what is in it.
>
> ....
>>> Lada
>>>
>>
>
> Andy

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod
--f46d04016983ef512704c6c8edea-- From lhotka@nic.cz Wed Aug 8 21:50:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6008921E8049 for ; Wed, 8 Aug 2012 21:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaxcwiMjuAj0 for ; Wed, 8 Aug 2012 21:50:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 05F2311E8193 for ; Wed, 8 Aug 2012 21:50:06 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.21]) by mail.nic.cz (Postfix) with ESMTPSA id 3B05313F86E; Thu, 9 Aug 2012 06:49:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344487798; bh=5lIpqhHhXnpLRef+3CIyWsKaeJ0em2IY1lU7bd4uYOk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wIv2PBIpasUtd8rIg6TByA9giCfZ2Rz4KX1ovKqqTOsrvUJcQM7SfH8iw6Ty47yZX BnPKqiF4396Fgt6Yp+jHTAlMkPnDSK5nhAx9f36+x7y90KA8nch1tma70BfsWneyZx 1MChMfy7adcHppkJsC1Yt0tIM9/AGTNtmVUyN6gk= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: Date: Thu, 9 Aug 2012 06:49:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1611C3F1-68E3-4ECB-80AA-2E531B3BEADA@nic.cz> References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 04:50:08 -0000 On Aug 9, 2012, at 12:49 AM, Jernej Tuljak wrote: > Are you sure that you used the correct example? Because it does not = seem consistent with what you are saying. Container foo is not = mandatory.. And there's nothing wrong with an instance of enable-foo = being present in a datastore without an instance of foo. There's no such = constraint on the enable-foo leaf. It's just a plain old leaf. Container "foo" is mandatory due to Sec. 3.1 in RFC 6020 (third bullet). Lada >=20 > What you claim would hold if mandatory-stmt and when-stmt were used on = the same leaf. A server would delete such a leaf instance if it's when = evaluated to false..but doing so would be deleting a mandatory data node = - leaving the datastore in an invalid state. Is this what you are = saying? >=20 > Jernej >=20 > Dne 8. avg. 2012 22:04 je "Ladislav Lhotka" = napisal/-a: >=20 > On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote: >=20 > > ..... > >>>>> OK, but what about this: > >>>>> > >>>>> leaf enable-foo { > >>>>> type boolean; > >>>>> } > >>>>> container foo { > >>>>> when "../enable-foo =3D 'true'"; > >>>>> leaf bar { > >>>>> type uint8; > >>>>> mandatory true; > >>>>> } > >>>>> } > >>>>> > >>>>> Now, consider an instance document containing = false > >>>>> but not , i.e. the XPath context node is missing. Simple = question: is > >>>>> this a valid document? If your answer is yes, could you explain = how the > >>>>> validity follows from 6020? > >>>>> > > > > I assume these are the contents of the node in an = edit-config >=20 > To keep things simple, it could be the content of a . >=20 > > operation. The edit-config operation and the when statement are = very clear > > about when-stmts that are applied to the context node vs. > > those which are applied to a conceptual datastore + state document. > > > > In your example, setting enable-foo=3Dfalse or deleting it will = cause the > > /foo container to be deleted by the server. The YANG statements > > like when/must apply to conceptual datastores, not to NETCONF > > messages. >=20 > If the server does this, the resulting datastore content is invalid = because from sec. 3.1 in 6020 it follows that the "foo" container is = mandatory. The 'when' statement cannot change this because its XPath = expression has no context node and is therefore undefined. >=20 >=20 > Lada >=20 > > > > > > > >>>>> I think this is where Andy needs to temporarily insert as = his dummy > >>>>> element, which is however not "about to be created" as you = write, at least not > >>>>> as a result of client's action. This has no support in 6020, the = alone XPath. > >>>> > >>>> Ok, I see your point. But this doesn't seem to be related to the > >>>> original issue in this thread - that "when" somehow modifies the > >>>> *schema tree*. > >>> > >>> Not schema tree but schema, with which one can check the structure = of an XML document without looking into element values of the validated = document (think of a RELAX NG or XSD schema). > >>> > > > > A static off-line validation tool is limited in its inherent = capabilities. > > The protocol clearly defines the operations in terms of the > > behavior on the server and the target datastore. An offline tool > > cannot provide datastore validation without knowing what is in it. > > > > .... > >>> Lada > >>> > >> > > > > Andy >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Thu Aug 9 05:44:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FC221F8661 for ; Thu, 9 Aug 2012 05:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuC1bGrt+ZrJ for ; Thu, 9 Aug 2012 05:44:40 -0700 (PDT) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id E15EA21F867B for ; Thu, 9 Aug 2012 05:44:39 -0700 (PDT) Received: from alpmlip14.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKUCOwtqqsjmAMijcR7SAsUg8ya1QwgfGy@postini.com; Thu, 09 Aug 2012 05:44:40 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip14.e2k.ad.ge.com with ESMTP; 09 Aug 2012 08:44:31 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Aug 2012 08:44:31 -0400 Received: from CINMBAPD03.e2k.ad.ge.com (3.159.212.69) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 9 Aug 2012 08:44:30 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBAPD03.e2k.ad.ge.com ([169.254.9.12]) with mapi id 14.02.0283.003; Thu, 9 Aug 2012 08:44:31 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: ietf-system & GPS coordinates Thread-Index: Ac12LApxnMu4NeNTSoubScMmB3+5FQ== Date: Thu, 9 Aug 2012 12:44:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB2421CINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2012 12:44:31.0134 (UTC) FILETIME=[B899D3E0:01CD762C] Subject: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:44:41 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB2421CINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With more and more devices having built in GPS receivers, and the need for = network administrators to map out the location of multiple devices, it woul= d be nice if there was a standard way to set and retrieve the geographical = location of a device. I have created the following container that I think = would fit nicely into the ietf-system data model. The verbiage was taken fr= om RFC 1712 container geographical-location { leaf latitude { type decimal64 { fraction-digits 16; range "-180 .. 180"; } description "The latitude of the system expressed in degrees. Positive numbers indicate locations east of the prime meridian."; } leaf longitude { type decimal64 { fraction-digits 16; range "-90 .. 90"; } description "The longitude of the system expressed in degrees. Positive numbers indicate locations north of the equator."; } leaf altitude { type decimal64 { fraction-digits 15; } description "The altitude of the system expressed in meters."; } } Thoughts? -Jeff --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB2421CINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With more and more devices having built in GPS recei= vers, and the need for network administrators to map out the location of mu= ltiple devices, it would be nice if there was a standard way to set and ret= rieve the geographical location of a device.  I have created the following container that I think would = fit nicely into the ietf-system data model. The verbiage was taken from RFC= 1712

 

    container geographical-location {=

      leaf latitude {<= /o:p>

        type deci= mal64 {

        &nbs= p; fraction-digits 16;

        &nbs= p; range "-180 .. 180";

        }

        descripti= on

        &nbs= p; "The latitude of the system expressed in degrees.

        &nbs= p;  Positive numbers indicate locations east of the

        &nbs= p;  prime meridian.";

      }

      leaf longitude {=

        type deci= mal64 {

        &nbs= p; fraction-digits 16;

        &nbs= p; range "-90 .. 90";

        }

        descripti= on

        &nbs= p; "The longitude of the system expressed in degrees.

        &nbs= p;  Positive numbers indicate locations north of the

        &nbs= p;  equator.";

      }

      leaf altitude {<= /o:p>

        type deci= mal64 {

        &nbs= p; fraction-digits 15;

        }

        descripti= on

        &nbs= p; "The altitude of the system expressed in meters.";<= /p>

      }

    }

 

Thoughts?

 

-Jeff

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB2421CINMBCNA02e2kad_-- From andy@yumaworks.com Thu Aug 9 06:57:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B996421F8665 for ; Thu, 9 Aug 2012 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT39OI-4-unW for ; Thu, 9 Aug 2012 06:57:00 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0011021F8592 for ; Thu, 9 Aug 2012 06:56:55 -0700 (PDT) Received: by qadz3 with SMTP id z3so209722qad.10 for ; Thu, 09 Aug 2012 06:56:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=yM4RLm8B7xHEXxGauPX4nPAm1Y0Q9wmrK0K18krfEtE=; b=VoZcWJeC7cPDwTjjQJVBljk/hVF7hjeRzTk55gbmgoi6VnnjiFwjwg6FPEDKxx6D69 yPC1p1MjWmWRUHBx8pF4o9R/6UiBaVvi/aygjPmPIwblgzNKto0cMfq3AT4mbM5ZGOzq 7fmqn2kKyJwIL7eak6U+jncQ3ndl0I4VgNd+LH6INEzrxyWSBRG2yu3Sy69fMOqBKSBB CoqqhkV7sNq96t6x0W9h841BLenrGmk2M9Qu96+9xSvwhvP9Z+NdIoXoAfrUG6iYaxvr aeuXr3myH0URT70wGADrRBcpVPImqi34GxMuFhvzgEUMRGfPpKtomkIWx3bQzR4p84cd jcsA== MIME-Version: 1.0 Received: by 10.50.6.168 with SMTP id c8mr1080030iga.21.1344520615026; Thu, 09 Aug 2012 06:56:55 -0700 (PDT) Received: by 10.50.23.2 with HTTP; Thu, 9 Aug 2012 06:56:54 -0700 (PDT) In-Reply-To: <1611C3F1-68E3-4ECB-80AA-2E531B3BEADA@nic.cz> References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> <1611C3F1-68E3-4ECB-80AA-2E531B3BEADA@nic.cz> Date: Thu, 9 Aug 2012 06:56:54 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnKpfHOD+NXC6VSRgiNFrfBA7fEL83t2+VFmBi68kbd9HVwXCpu2i30ykdXY/yZk8N8Uemo Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:57:03 -0000 Hi, Why are we debating an implementation detail? There are lots of combinations where the when-stmt needs to be conceptually evaluated on a missing node to determine if that node is triggering an error or not. So what? We have the same situation with conceptual NP containers that contain default leafs: leaf if-foobar { when "../foobar"; type string; } container foobar { leaf def { type int32; default 42; } } The when-stmt is always true, whether the server has a /foobar node or not. It is an implementation detail. Andy On Wed, Aug 8, 2012 at 9:49 PM, Ladislav Lhotka wrote: > > On Aug 9, 2012, at 12:49 AM, Jernej Tuljak wrote: > >> Are you sure that you used the correct example? Because it does not seem= consistent with what you are saying. Container foo is not mandatory.. And = there's nothing wrong with an instance of enable-foo being present in a dat= astore without an instance of foo. There's no such constraint on the enable= -foo leaf. It's just a plain old leaf. > > Container "foo" is mandatory due to Sec. 3.1 in RFC 6020 (third bullet). > > Lada > >> >> What you claim would hold if mandatory-stmt and when-stmt were used on t= he same leaf. A server would delete such a leaf instance if it's when evalu= ated to false..but doing so would be deleting a mandatory data node - leavi= ng the datastore in an invalid state. Is this what you are saying? >> >> Jernej >> >> Dne 8. avg. 2012 22:04 je "Ladislav Lhotka" napisal/-a: >> >> On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote: >> >> > ..... >> >>>>> OK, but what about this: >> >>>>> >> >>>>> leaf enable-foo { >> >>>>> type boolean; >> >>>>> } >> >>>>> container foo { >> >>>>> when "../enable-foo =3D 'true'"; >> >>>>> leaf bar { >> >>>>> type uint8; >> >>>>> mandatory true; >> >>>>> } >> >>>>> } >> >>>>> >> >>>>> Now, consider an instance document containing false >> >>>>> but not , i.e. the XPath context node is missing. Simple ques= tion: is >> >>>>> this a valid document? If your answer is yes, could you explain ho= w the >> >>>>> validity follows from 6020? >> >>>>> >> > >> > I assume these are the contents of the node in an edit-config >> >> To keep things simple, it could be the content of a . >> >> > operation. The edit-config operation and the when statement are very = clear >> > about when-stmts that are applied to the context node vs. >> > those which are applied to a conceptual datastore + state document. >> > >> > In your example, setting enable-foo=3Dfalse or deleting it will cause = the >> > /foo container to be deleted by the server. The YANG statements >> > like when/must apply to conceptual datastores, not to NETCONF >> > messages. >> >> If the server does this, the resulting datastore content is invalid beca= use from sec. 3.1 in 6020 it follows that the "foo" container is mandatory.= The 'when' statement cannot change this because its XPath expression has n= o context node and is therefore undefined. >> >> >> Lada >> >> > >> > >> > >> >>>>> I think this is where Andy needs to temporarily insert as hi= s dummy >> >>>>> element, which is however not "about to be created" as you write, = at least not >> >>>>> as a result of client's action. This has no support in 6020, the a= lone XPath. >> >>>> >> >>>> Ok, I see your point. But this doesn't seem to be related to the >> >>>> original issue in this thread - that "when" somehow modifies the >> >>>> *schema tree*. >> >>> >> >>> Not schema tree but schema, with which one can check the structure o= f an XML document without looking into element values of the validated docu= ment (think of a RELAX NG or XSD schema). >> >>> >> > >> > A static off-line validation tool is limited in its inherent capabilit= ies. >> > The protocol clearly defines the operations in terms of the >> > behavior on the server and the target datastore. An offline tool >> > cannot provide datastore validation without knowing what is in it. >> > >> > .... >> >>> Lada >> >>> >> >> >> > >> > Andy >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From andy@yumaworks.com Thu Aug 9 07:05:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B9021F86B4 for ; Thu, 9 Aug 2012 07:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27Ou5bKPiGMp for ; Thu, 9 Aug 2012 07:05:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A528221F86AF for ; Thu, 9 Aug 2012 07:05:24 -0700 (PDT) Received: by yenm5 with SMTP id m5so527876yen.31 for ; Thu, 09 Aug 2012 07:05:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YSspY2hmo1ol7ut0mqJTq1jmgmQNJSj10JHKRZNP6aU=; b=VapwNVJXk6h8HSPwVnbe9kw+Al+3MI75gPsa84XvK92Rwa0lLwnGT+240Lk8rThNRm AcOisgXrg9YlYjhPwLXC409Coum1i3VjJ+ukVbPldeY515G8QlLpdTCOQgGnh9CR8BQI BBI9u2TUla+M40JdjgsONqf4AfD4I4iV2Mc8A+ovgbOmvWqh09LS8JfMQm98XR6d3Unq vrSmQh+8BcpGbKZuZa9xcHusN1iTOMEHSEwcRCBXS7gi+TZyaNMXvfIQNae43EhUyqYw T5ss+i0Kfie5ItISuAt1As9z8Z8cK9T3/ZiPnqdUwhzk+x8GT7pg+44MdvlyFdjjFnB/ RBcQ== MIME-Version: 1.0 Received: by 10.43.43.194 with SMTP id ud2mr2776537icb.13.1344521123907; Thu, 09 Aug 2012 07:05:23 -0700 (PDT) Received: by 10.50.23.2 with HTTP; Thu, 9 Aug 2012 07:05:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Aug 2012 07:05:23 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlr0bqqDT8ThwOwAUIljZGeNMeey8UJvqOLSAOYr8GpO6wuG+ybI3z+tnNK9hPh7o0WfttA Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:05:25 -0000 This may be OK if there was a YANG feature to make it optional. Andy On Thu, Aug 9, 2012 at 5:44 AM, Lange, Jeffrey K (GE Energy) wrote: > With more and more devices having built in GPS receivers, and the need for > network administrators to map out the location of multiple devices, it would > be nice if there was a standard way to set and retrieve the geographical > location of a device. I have created the following container that I think > would fit nicely into the ietf-system data model. The verbiage was taken > from RFC 1712 > > > > container geographical-location { if-feature geographic-location; > > leaf latitude { > > type decimal64 { > > fraction-digits 16; > > range "-180 .. 180"; > > } > > description > > "The latitude of the system expressed in degrees. > > Positive numbers indicate locations east of the > > prime meridian."; > > } > > leaf longitude { > > type decimal64 { > > fraction-digits 16; > > range "-90 .. 90"; > > } > > description > > "The longitude of the system expressed in degrees. > > Positive numbers indicate locations north of the > > equator."; > > } > > leaf altitude { > > type decimal64 { > > fraction-digits 15; > > } > > description > > "The altitude of the system expressed in meters."; > > } > > } > > > > Thoughts? > > > > -Jeff > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From jeffrey.K.lange@ge.com Thu Aug 9 07:15:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CCE21F86AF for ; Thu, 9 Aug 2012 07:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3serCE-8iw9 for ; Thu, 9 Aug 2012 07:15:11 -0700 (PDT) Received: from exprod5og103.obsmtp.com (exprod5og103.obsmtp.com [64.18.0.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF5321F8669 for ; Thu, 9 Aug 2012 07:15:05 -0700 (PDT) Received: from cinmlip13.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob103.postini.com ([64.18.4.12]) with SMTP ID DSNKUCPF6K2D++R0da02BbHg1Jk4+XBl9W/p@postini.com; Thu, 09 Aug 2012 07:15:06 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by cinmlip13.e2k.ad.ge.com with ESMTP; 09 Aug 2012 10:15:03 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Aug 2012 10:15:02 -0400 Received: from CINMBCNA04.e2k.ad.ge.com (3.159.212.58) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 9 Aug 2012 10:15:02 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBCNA04.e2k.ad.ge.com ([169.254.4.115]) with mapi id 14.02.0283.003; Thu, 9 Aug 2012 10:15:02 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman Thread-Topic: [netmod] ietf-system & GPS coordinates Thread-Index: Ac12LApxnMu4NeNTSoubScMmB3+5FQALYEqAAAgg+VA= Date: Thu, 9 Aug 2012 14:15:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2012 14:15:02.0538 (UTC) FILETIME=[5DF84EA0:01CD7639] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:15:13 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5keSBCaWVybWFuIFtt YWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDA5LCAy MDEyIDEwOjA1IEFNDQo+IFRvOiBMYW5nZSwgSmVmZnJleSBLIChHRSBFbmVyZ3kpDQo+IENjOiBu ZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGlldGYtc3lzdGVtICYgR1BT IGNvb3JkaW5hdGVzDQo+IA0KPiBUaGlzIG1heSBiZSBPSyBpZiB0aGVyZSB3YXMgYSBZQU5HIGZl YXR1cmUgdG8gbWFrZSBpdCBvcHRpb25hbC4NCj4gDQoNCkRvZXNuJ3QgdGhlIGZhY3QgdGhhdCBp dCdzIG5vdCBjb25maWc9ZmFsc2UgaW1wbGljaXRseSBtYWtlIGl0IG9wdGlvbmFsPyAgRXZlcnkg ZGVwbG95ZWQgZGV2aWNlIGluIHRoZSB3b3JsZCBoYXMgYSBnZW9ncmFwaGljYWwgbG9jYXRpb24g YXNzb2NpYXRlZCB3aXRoIGl0LiAgVGhpcyBqdXN0IGdpdmVzIGFuIGFkbWluaXN0cmF0b3IgYSBw bGFjZSB0byBwdXQgdGhhdCBsb2NhdGlvbiBpZiB0aGV5IGhhcHBlbiB0byBrbm93IGl0Lg0KDQot SmVmZg0KDQo+IEFuZHkNCj4gDQo+IE9uIFRodSwgQXVnIDksIDIwMTIgYXQgNTo0NCBBTSwgTGFu Z2UsIEplZmZyZXkgSyAoR0UgRW5lcmd5KQ0KPiA8amVmZnJleS5LLmxhbmdlQGdlLmNvbT4gd3Jv dGU6DQo+ID4gV2l0aCBtb3JlIGFuZCBtb3JlIGRldmljZXMgaGF2aW5nIGJ1aWx0IGluIEdQUyBy ZWNlaXZlcnMsIGFuZCB0aGUgbmVlZA0KPiA+IGZvciBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIHRv IG1hcCBvdXQgdGhlIGxvY2F0aW9uIG9mIG11bHRpcGxlDQo+ID4gZGV2aWNlcywgaXQgd291bGQg YmUgbmljZSBpZiB0aGVyZSB3YXMgYSBzdGFuZGFyZCB3YXkgdG8gc2V0IGFuZA0KPiA+IHJldHJp ZXZlIHRoZSBnZW9ncmFwaGljYWwgbG9jYXRpb24gb2YgYSBkZXZpY2UuICBJIGhhdmUgY3JlYXRl ZCB0aGUNCj4gPiBmb2xsb3dpbmcgY29udGFpbmVyIHRoYXQgSSB0aGluayB3b3VsZCBmaXQgbmlj ZWx5IGludG8gdGhlIGlldGYtc3lzdGVtDQo+ID4gZGF0YSBtb2RlbC4gVGhlIHZlcmJpYWdlIHdh cyB0YWtlbiBmcm9tIFJGQyAxNzEyDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgIGNvbnRhaW5lciBn ZW9ncmFwaGljYWwtbG9jYXRpb24gew0KPiANCj4gICAgaWYtZmVhdHVyZSBnZW9ncmFwaGljLWxv Y2F0aW9uOw0KPiANCj4gPg0KPiA+ICAgICAgIGxlYWYgbGF0aXR1ZGUgew0KPiA+DQo+ID4gICAg ICAgICB0eXBlIGRlY2ltYWw2NCB7DQo+ID4NCj4gPiAgICAgICAgICAgZnJhY3Rpb24tZGlnaXRz IDE2Ow0KPiA+DQo+ID4gICAgICAgICAgIHJhbmdlICItMTgwIC4uIDE4MCI7DQo+ID4NCj4gPiAg ICAgICAgIH0NCj4gPg0KPiA+ICAgICAgICAgZGVzY3JpcHRpb24NCj4gPg0KPiA+ICAgICAgICAg ICAiVGhlIGxhdGl0dWRlIG9mIHRoZSBzeXN0ZW0gZXhwcmVzc2VkIGluIGRlZ3JlZXMuDQo+ID4N Cj4gPiAgICAgICAgICAgIFBvc2l0aXZlIG51bWJlcnMgaW5kaWNhdGUgbG9jYXRpb25zIGVhc3Qg b2YgdGhlDQo+ID4NCj4gPiAgICAgICAgICAgIHByaW1lIG1lcmlkaWFuLiI7DQo+ID4NCj4gPiAg ICAgICB9DQo+ID4NCj4gPiAgICAgICBsZWFmIGxvbmdpdHVkZSB7DQo+ID4NCj4gPiAgICAgICAg IHR5cGUgZGVjaW1hbDY0IHsNCj4gPg0KPiA+ICAgICAgICAgICBmcmFjdGlvbi1kaWdpdHMgMTY7 DQo+ID4NCj4gPiAgICAgICAgICAgcmFuZ2UgIi05MCAuLiA5MCI7DQo+ID4NCj4gPiAgICAgICAg IH0NCj4gPg0KPiA+ICAgICAgICAgZGVzY3JpcHRpb24NCj4gPg0KPiA+ICAgICAgICAgICAiVGhl IGxvbmdpdHVkZSBvZiB0aGUgc3lzdGVtIGV4cHJlc3NlZCBpbiBkZWdyZWVzLg0KPiA+DQo+ID4g ICAgICAgICAgICBQb3NpdGl2ZSBudW1iZXJzIGluZGljYXRlIGxvY2F0aW9ucyBub3J0aCBvZiB0 aGUNCj4gPg0KPiA+ICAgICAgICAgICAgZXF1YXRvci4iOw0KPiA+DQo+ID4gICAgICAgfQ0KPiA+ DQo+ID4gICAgICAgbGVhZiBhbHRpdHVkZSB7DQo+ID4NCj4gPiAgICAgICAgIHR5cGUgZGVjaW1h bDY0IHsNCj4gPg0KPiA+ICAgICAgICAgICBmcmFjdGlvbi1kaWdpdHMgMTU7DQo+ID4NCj4gPiAg ICAgICAgIH0NCj4gPg0KPiA+ICAgICAgICAgZGVzY3JpcHRpb24NCj4gPg0KPiA+ICAgICAgICAg ICAiVGhlIGFsdGl0dWRlIG9mIHRoZSBzeXN0ZW0gZXhwcmVzc2VkIGluIG1ldGVycy4iOw0KPiA+ DQo+ID4gICAgICAgfQ0KPiA+DQo+ID4gICAgIH0NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaG91Z2h0 cz8NCj4gPg0KPiA+DQo+ID4NCj4gPiAtSmVmZg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2Qg bWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0K From andy@yumaworks.com Thu Aug 9 08:15:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D970721F87C3 for ; Thu, 9 Aug 2012 08:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JQ0TslyjS3y for ; Thu, 9 Aug 2012 08:15:11 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E20621F87BA for ; Thu, 9 Aug 2012 08:15:11 -0700 (PDT) Received: by qcac10 with SMTP id c10so383879qca.31 for ; Thu, 09 Aug 2012 08:15:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=eI75cVZzK8UKbzWW+TmxMKOcKesVT4CYeTMiBuulMO8=; b=Zr0EMTj2EpIr2O6+e+h0FBiztqG6HuYQXwGSm9iq2nLNdLj0A70XfApohfbBjE9wBx bvvLXh8OzOvw17rAD3jIr9Ll4dxWYGcB/7HJbISQXNGGywDNYWkjS1OHF/OczV1fQmaV /trOIWqBZvJf7Qa8A/zImf0XtVdO39vdMp+jgOWfe6cVMXbYjXiwWSNGjPRaHDMOxHrz wj6Y3ymWHAsXZvfBa6IdqXiBLxwEU3IZzWZm7bpDZGqu3Dqlkr1pBfcNHnETBI4CWW+a zIWfK6muYMVCZa8eOXqPAKrzXbntR0WJMQr1i22SYokc1FAFrQEqMPph/7kQjpY5zAVa 1HeQ== MIME-Version: 1.0 Received: by 10.224.180.146 with SMTP id bu18mr3403951qab.10.1344525310772; Thu, 09 Aug 2012 08:15:10 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 9 Aug 2012 08:15:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Aug 2012 08:15:10 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnRugekjB44y3Wa9Yjh+GiDOYwyXTSqvFIYEBqM1ZNassnADso4QF5/xZ6eyutbr4jB4sFb Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 15:15:12 -0000 On Thu, Aug 9, 2012 at 7:15 AM, Lange, Jeffrey K (GE Energy) wrote: > > >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Thursday, August 09, 2012 10:05 AM >> To: Lange, Jeffrey K (GE Energy) >> Cc: netmod@ietf.org >> Subject: Re: [netmod] ietf-system & GPS coordinates >> >> This may be OK if there was a YANG feature to make it optional. >> > > Doesn't the fact that it's not config=false implicitly make it optional? Every deployed device in the world has a geographical location associated with it. This just gives an administrator a place to put that location if they happen to know it. > None of the networking boxes in my house except my phone has GPS. config=false is for the server to fill in, not the client. You can use the /system/location string for this purpose if you want. I don't consider this to be part of the base conformance for the module, so I would add a YANG feature to make that clear. But I don't think we should add these objects because the location string is available for what you want and most networking devices to not report their GPS coordinates in monitoring information. I think 'location' might be a separate module all by itself. I doubt these 3 leafs will be sufficient for that. > -Jeff > >> Andy Andy From j.schoenwaelder@jacobs-university.de Thu Aug 9 09:34:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0882221F86B0 for ; Thu, 9 Aug 2012 09:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEHshJstVc72 for ; Thu, 9 Aug 2012 09:34:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3688721F86AD for ; Thu, 9 Aug 2012 09:34:00 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1279120BFA; Thu, 9 Aug 2012 18:33:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kKhCMZrQoSO6; Thu, 9 Aug 2012 18:33:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8095C20BD4; Thu, 9 Aug 2012 18:33:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 95D0C2113933; Thu, 9 Aug 2012 18:33:57 +0200 (CEST) Date: Thu, 9 Aug 2012 18:33:56 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120809163356.GA1795@elstar.local> Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 16:34:01 -0000 On Thu, Aug 09, 2012 at 08:15:10AM -0700, Andy Bierman wrote: > > None of the networking boxes in my house except my phone > has GPS. config=false is for the server to fill in, not the client. > You can use the /system/location string for this purpose if > you want. > > I don't consider this to be part of the base conformance > for the module, so I would add a YANG feature to make that clear. Some boxes might have GPS, but I assume this is the minority of the network devices (since most of the network gear is typically located inside buildings where GPS usually does not work). So for those boxes, these are post-it objects. There has always been a debate how many post-it objects are useful to have. On the other hand, logitude and latitude carry more precise semantics than system/location, which often refers to a name of a campus or something like that, not really carrying coordinates. I do not really have a preference either way. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 9 09:46:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D7721F870F for ; Thu, 9 Aug 2012 09:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPvJwpDDv5rr for ; Thu, 9 Aug 2012 09:46:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47F1921F8688 for ; Thu, 9 Aug 2012 09:46:06 -0700 (PDT) Received: by qcac10 with SMTP id c10so482949qca.31 for ; Thu, 09 Aug 2012 09:46:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=rQinZVl9wRFdeDXFwo0HtSuhfBz8NF4PAGlxL13upQM=; b=JD953ocy5czGVXeGIOoIheH+8PBCAPC8VG1QjCNfhjugEKgdkysShrrG07IMPOJ+me ZGx4+g/qrcxRxr18yl8U1MNelvaeA1ok7bhbl+iOiSU2f4Q7Y7pHwJZGX29Bkj9vCU4E R07gzxPj1wVEwieNji7QE2DDbKTcfgGcOpGlAf3a1gFtifElXGWI4ur4IwBszcPfYLWI AP8tfpXEkRtc3ZFbnsbciuz/7CRlwLkRdZ704qkf6afuet3OtSlrdcQiYawp7/pwrVfR n8AXBShIUntYtHk8s8dE8yNOcyYvAKOGAf6BoZxeYSe/6yCl6T/CFoafXsQZuu2JzgD2 cNew== MIME-Version: 1.0 Received: by 10.224.214.69 with SMTP id gz5mr3834956qab.21.1344530765792; Thu, 09 Aug 2012 09:46:05 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 9 Aug 2012 09:46:05 -0700 (PDT) In-Reply-To: <20120809163356.GA1795@elstar.local> References: <20120809163356.GA1795@elstar.local> Date: Thu, 9 Aug 2012 09:46:05 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk4WCKcY6SKEhF0HWypvMvKdZpF9Ib6v8rWT9XTaNR6Nspfrv+KeVlC3Bw9IsMZIUWNd+H5 Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 16:46:07 -0000 The post-it notes are limited to 255 chars each. (name, contact, location) Can we raise this hard-wired arbitrary limit to 1023? I think 1 location post-it is good enough for now. Andy On Thu, Aug 9, 2012 at 9:33 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 09, 2012 at 08:15:10AM -0700, Andy Bierman wrote: >> >> None of the networking boxes in my house except my phone >> has GPS. config=false is for the server to fill in, not the client. >> You can use the /system/location string for this purpose if >> you want. >> >> I don't consider this to be part of the base conformance >> for the module, so I would add a YANG feature to make that clear. > > Some boxes might have GPS, but I assume this is the minority of the > network devices (since most of the network gear is typically located > inside buildings where GPS usually does not work). So for those boxes, > these are post-it objects. There has always been a debate how many > post-it objects are useful to have. On the other hand, logitude and > latitude carry more precise semantics than system/location, which > often refers to a name of a campus or something like that, not really > carrying coordinates. I do not really have a preference either way. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From andrewmcgr@gmail.com Thu Aug 9 09:47:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4036A21F8743 for ; Thu, 9 Aug 2012 09:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7DwUVVvP55l for ; Thu, 9 Aug 2012 09:47:06 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC2721F8740 for ; Thu, 9 Aug 2012 09:47:06 -0700 (PDT) Received: by yhq56 with SMTP id 56so736684yhq.31 for ; Thu, 09 Aug 2012 09:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=6C69Fv1IieXiPDN5CMjVFky0XN+/CcXlgVKRsR68rmY=; b=qK18XZTCYPT/dun4OBIvRJM0BuNG6G79RKm7KhfuVuRkNyzzHcLOZcS637bHIFnY6G rGKCgLWaMZvS1y5FgFgx9ahffkfJ6hyaq+Hsz+PtyQGnKQuHy/li6l+kqgi7QszJP/fB TZEC7ypPjlhfvAUAoQaPhGU4X15ZQ/8pxzxsKp6TlnLXIYUab20yjQSuL+UgIRJs5Fg2 FDw52PysVMbWXDeq4cwBsKTED1YNgwzTU+iDl5aYM/hnLVM2Tm2rqWP9QazVaK8Qt/BB NR7SnBGWZFMARxiuVDqP/Z9XBWcu+jVwUiavCj+IiiAIRhp83ZuRyCsNKuqgxqA5s4oW FQ5w== Received: by 10.50.94.166 with SMTP id dd6mr1826702igb.11.1344530825119; Thu, 09 Aug 2012 09:47:05 -0700 (PDT) Received: from ?IPv6:2620::1000:fd2b:74b5:17ea:67e8:d01d? ([2620:0:1000:fd2b:74b5:17ea:67e8:d01d]) by mx.google.com with ESMTPS id gh2sm2339212igb.9.2012.08.09.09.47.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 09:47:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9A627867-CD77-4C14-AA88-270044C8A02A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Andrew McGregor In-Reply-To: Date: Thu, 9 Aug 2012 09:46:56 -0700 Message-Id: <17A6ED43-6B10-4275-8D52-E43DC48BEA71@gmail.com> References: To: "Lange, Jeffrey K (GE Energy)" X-Mailer: Apple Mail (2.1485) Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 16:47:07 -0000 --Apple-Mail=_9A627867-CD77-4C14-AA88-270044C8A02A Content-Type: multipart/alternative; boundary="Apple-Mail=_5E814BEC-7E74-4304-A74D-FB8430445306" --Apple-Mail=_5E814BEC-7E74-4304-A74D-FB8430445306 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Well, that's a reasonable start... but it loses a huge part of the = necessary metadata about a position. Now, one might argue that RFC 1712 = introduces that issue. I guess when specifying this, you just add an 'expressed in WGS84 = coordinates' and you get something more sensible. Geodata is complicated... there are hundreds of projections and datum = systems that might be used, so you really need to specify one or the = interpretation is impossible. WGS84 is a good default, as that is = geographical lat/lon/altitude using the GPS coordinate system, and = everyone can convert to/from that as required. Andrew On 9/08/2012, at 5:44 AM, "Lange, Jeffrey K (GE Energy)" = wrote: > With more and more devices having built in GPS receivers, and the need = for network administrators to map out the location of multiple devices, = it would be nice if there was a standard way to set and retrieve the = geographical location of a device. I have created the following = container that I think would fit nicely into the ietf-system data model. = The verbiage was taken from RFC 1712 > =20 > container geographical-location { > leaf latitude { > type decimal64 { > fraction-digits 16; > range "-180 .. 180"; > } > description > "The latitude of the system expressed in degrees. > Positive numbers indicate locations east of the > prime meridian."; > } > leaf longitude { > type decimal64 { > fraction-digits 16; > range "-90 .. 90"; > } > description > "The longitude of the system expressed in degrees. > Positive numbers indicate locations north of the > equator."; > } > leaf altitude { > type decimal64 { > fraction-digits 15; > } > description > "The altitude of the system expressed in meters."; > } > } > =20 > Thoughts? > =20 > -Jeff > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_5E814BEC-7E74-4304-A74D-FB8430445306 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Well, that's a reasonable = start... but it loses a huge part of the necessary metadata about a = position.  Now, one might argue that RFC 1712 introduces that = issue.

I guess when specifying this, you just add an = 'expressed in WGS84 coordinates' and you get something more = sensible.

Geodata is complicated... there are = hundreds of projections and datum systems that might be used, so you = really need to specify one or the interpretation is impossible. =  WGS84 is a good default, as that is geographical lat/lon/altitude = using the GPS coordinate system, and everyone can convert to/from that = as required.

Andrew

On = 9/08/2012, at 5:44 AM, "Lange, Jeffrey K (GE Energy)" <jeffrey.K.lange@ge.com> = wrote:

With more and more = devices having built in GPS receivers, and the need for network = administrators to map out the location of multiple devices, it would be = nice if there was a standard way to set and retrieve the geographical = location of a device.  I have created the following container that = I think would fit nicely into the ietf-system data model. The verbiage = was taken from RFC 1712
    = container geographical-location {
        type = decimal64 {
        = description
        type = decimal64 {
        = description
      = }
      = leaf altitude {
        = description
, "netmod@ietf.org" References: <20120809163356.GA1795@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:57:39 -0000 On Thu, Aug 09, 2012 at 09:46:05AM -0700, Andy Bierman wrote: > The post-it notes are limited to 255 chars each. > (name, contact, location) > > Can we raise this hard-wired arbitrary limit to 1023? You probably want to start a separate thread as this has nothing to do with GPS coordinates. I assume the 255 is inherited from MIB world. That said, if we consider changing this limit, then we should remote it rather than replacing it by another arbitrary limit, perhaps adding text similar to .../interface/name. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 9 11:09:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B3A21F86FC for ; Thu, 9 Aug 2012 11:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9Fp8WEMlCxE for ; Thu, 9 Aug 2012 11:09:50 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id CB67621F86DE for ; Thu, 9 Aug 2012 11:09:49 -0700 (PDT) Received: by qaea16 with SMTP id a16so458700qae.10 for ; Thu, 09 Aug 2012 11:09:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=zDHe7vQyGL2KeRRQ9PubvmHWTaEVG2gLsq4uimW0f2o=; b=YY1uBDmoG2wRlWAya/epiwPXdirjIvs5tVXlL5CgP6qA7/Kp4rEwH5zegKTEqecl7Z 4fOo1sASHT+OlALHIGaehe8o64VJilreEGn0YzWAreILMQXnUFzQAz1MU4S11OhJ2rqq IsgxPz6U3YFI6aPtBDsyWbazVNuuof/1patYtcZkJYPuX3rpcxZO/g37ra4nMgLpHP4u ZyukqdF2Ob8LQy1QBZhkLlUd+eE1+nirEaxloQ5Y3JVowr3sCbBZey6rQ7VErkIlcEX6 qLfJ5aqs3IN6s5rAyt52Ieij8c36HJRzie+Gb002086rN/PVJvEf9YlBDsIyX1+XW4k2 6DBQ== MIME-Version: 1.0 Received: by 10.224.58.142 with SMTP id g14mr4119098qah.96.1344535789232; Thu, 09 Aug 2012 11:09:49 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 9 Aug 2012 11:09:49 -0700 (PDT) Date: Thu, 9 Aug 2012 11:09:49 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkCeTEO9/4eu/lRhFN11Zt9OdNLXKT22YcE8+y/GX8ju7tIHAX1gQO2XE5tmfClrBUKmuul Subject: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:09:50 -0000 Hi, >> >> Can we raise this hard-wired arbitrary limit to 1023? > > You probably want to start a separate thread as this has nothing to do > with GPS coordinates. I assume the 255 is inherited from MIB > world. That said, if we consider changing this limit, then we should > remote it rather than replacing it by another arbitrary limit, perhaps > adding text similar to .../interface/name. > We should not allow these admin strings to have structure, like the interface name leaf. I thought of no limit, and let the server return a too-big error-tag if it cannot hold the text: Maybe that would be best. e.,g.: [remove length-stmt and reference-stmt] leaf name { type string; description "The administratively assigned system name. The server MUST support values from 0 to 255 characters in length, and MAY support larger values."; } > /js Andy From j.schoenwaelder@jacobs-university.de Thu Aug 9 11:18:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A46B21F8743 for ; Thu, 9 Aug 2012 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw9RiJB2UE0H for ; Thu, 9 Aug 2012 11:18:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 922D621F8749 for ; Thu, 9 Aug 2012 11:18:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA4AA20C01; Thu, 9 Aug 2012 20:18:52 +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 oRQK4jOsLeku; Thu, 9 Aug 2012 20:18:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85FCA20BFA; Thu, 9 Aug 2012 20:18:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD8CE2113C5D; Thu, 9 Aug 2012 20:18:52 +0200 (CEST) Date: Thu, 9 Aug 2012 20:18:52 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120809181852.GC1968@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:18:54 -0000 On Thu, Aug 09, 2012 at 11:09:49AM -0700, Andy Bierman wrote: > Hi, > > > >> > >> Can we raise this hard-wired arbitrary limit to 1023? > > > > You probably want to start a separate thread as this has nothing to do > > with GPS coordinates. I assume the 255 is inherited from MIB > > world. That said, if we consider changing this limit, then we should > > remote it rather than replacing it by another arbitrary limit, perhaps > > adding text similar to .../interface/name. > > > > We should not allow these admin strings to have structure, like > the interface name leaf. > > I thought of no limit, and let the server return a too-big error-tag > if it cannot hold the text: Maybe that would be best. e.,g.: > > [remove length-stmt and reference-stmt] > > leaf name { > type string; > description > "The administratively assigned system name. > The server MUST support values from 0 to 255 characters in length, > and MAY support larger values."; > } This 255 limit seems arbitrarily new. In SNMP land, things are limited to 255 ASCII characters (octets). This description would limit things to 255 UTF-8 encoded characters, that can be very well more than 255 octets. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From alex@cisco.com Thu Aug 9 11:19:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B5121F8759 for ; Thu, 9 Aug 2012 11:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzu3LeIqgipB for ; Thu, 9 Aug 2012 11:19:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 293F721F8755 for ; Thu, 9 Aug 2012 11:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=1636; q=dns/txt; s=iport; t=1344536395; x=1345745995; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PNy6ONL9jr7g9TfLzqqRnqa+K9ExCwKaedNjwskCINk=; b=A8xNSzVyGk+Eu0Ln2DIoSQ5xSbQv9kobL0hHS/ZBFkp81fwfgPNul4Ll +kmbHQwWyF56TotGyBWcYI8SbSaQDceybpk0CiFop03fRQrkw03O0QtHB +txM9AugBwWM3pUNGtyKSI+kZH76SqlBt6ueILH3Vq8IqnA5glmGHYita Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIzgI1CtJV2Y/2dsb2JhbABCA7ligQeCIAEBAQQBAQEPASc0CwwCAgIBCA4CAQQBAQEKFAkHGwwLFAkIAgQBDQUIGodrC5p7oG0EiwsUAYMugkFgA6NygWaCX4FWAQ X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="110063222" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2012 18:19:54 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q79IJspX032688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Aug 2012 18:19:54 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 13:19:52 -0500 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , Andy Bierman Thread-Topic: [netmod] ietf-system & GPS coordinates Thread-Index: Ac12LApxnMu4NeNTSoubScMmB3+5FQANeLuAAABWIYAAAhnJAAACwDoAAABsoYAAAn9DgAAJ6OuA Date: Thu, 9 Aug 2012 18:19:51 +0000 Message-ID: References: <20120809163356.GA1795@elstar.local> <20120809175735.GA1905@elstar.local> In-Reply-To: <20120809175735.GA1905@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.33] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19096.006 x-tm-as-result: No--35.204700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:19:56 -0000 It would seem there is a place for both a "location" name (that is administ= ratively assigned) and a "geo-location". The location is the post it; some= one might include geo location in it. Geo-location would be system provide= d, for the minority of systems that support it (yup, most systems would be = deployed inside, but there are certainly scenarios where it is valid and wo= uld presumably be important, such as equipment on pole tops in a smart grid= ). --- Alex =20 -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Thursday, August 09, 2012 10:58 AM To: Andy Bierman Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system & GPS coordinates On Thu, Aug 09, 2012 at 09:46:05AM -0700, Andy Bierman wrote: > The post-it notes are limited to 255 chars each. > (name, contact, location) >=20 > Can we raise this hard-wired arbitrary limit to 1023? You probably want to start a separate thread as this has nothing to do with GPS coordinates. I assume the 255 is inherited from MIB world. That said, if we consider changing this limit, then we should remote it rather than replacing it by another arbitrary limit, perhaps adding text similar to .../interface/name. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Thu Aug 9 11:22:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5DE21F86B3 for ; Thu, 9 Aug 2012 11:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dva1cd1k99JU for ; Thu, 9 Aug 2012 11:22:51 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83D4E21F86AD for ; Thu, 9 Aug 2012 11:22:51 -0700 (PDT) Received: by qcac10 with SMTP id c10so564850qca.31 for ; Thu, 09 Aug 2012 11:22:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=TXEX+7y+uyuM8ddgOGIU9aoefmZSuIyuBHh6+rjv2VI=; b=mzfGiyVJifZZ71FZx6ZECw3pcVikOHCvL+4EjChusE4b6aEm1WHufT0SGBp2jsg+4X 5Zw1ocorPJWpv3Fl2aFA00O4tekTLQNjZKa+AIfR2V2PUsAaApcQ8H1nOsG/wWp0MQzB pGi+Zat0356+crlihlhYoAoLmva4T7PNGoY1p8BCC2/GgqFLCz4iTsMg6j/lwiSfpcsw 6Ehwq8L5zXt4YKWngE7u3SOIpFV1dirhjYILH352aUfmIz8wvu5ytUwL86QFHDYTWkBg cX3UJWu5qcf2tz+hsrzstLm7zwNkqH8UmsAk9TezJT1uqid7XKFRg+8OMzpZrBXBjqzm yi6g== MIME-Version: 1.0 Received: by 10.224.180.209 with SMTP id bv17mr4249130qab.85.1344536571001; Thu, 09 Aug 2012 11:22:51 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 9 Aug 2012 11:22:50 -0700 (PDT) In-Reply-To: <20120809181852.GC1968@elstar.local> References: <20120809181852.GC1968@elstar.local> Date: Thu, 9 Aug 2012 11:22:50 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn7zt0So3aNG70uOoX+x65MTsO4dard8PC9Lfb0X/Zl7rl6D9ZZU9DoZOpNpMT01WZAu2eJ Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:22:52 -0000 On Thu, Aug 9, 2012 at 11:18 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 09, 2012 at 11:09:49AM -0700, Andy Bierman wrote: >> Hi, >> >> >> >> >> >> Can we raise this hard-wired arbitrary limit to 1023? >> > >> > You probably want to start a separate thread as this has nothing to do >> > with GPS coordinates. I assume the 255 is inherited from MIB >> > world. That said, if we consider changing this limit, then we should >> > remote it rather than replacing it by another arbitrary limit, perhaps >> > adding text similar to .../interface/name. >> > >> >> We should not allow these admin strings to have structure, like >> the interface name leaf. >> >> I thought of no limit, and let the server return a too-big error-tag >> if it cannot hold the text: Maybe that would be best. e.,g.: >> >> [remove length-stmt and reference-stmt] >> >> leaf name { >> type string; >> description >> "The administratively assigned system name. >> The server MUST support values from 0 to 255 characters in length, >> and MAY support larger values."; >> } > > This 255 limit seems arbitrarily new. In SNMP land, things are limited > to 255 ASCII characters (octets). This description would limit things > to 255 UTF-8 encoded characters, that can be very well more than 255 > octets. > How is that any different than the current text: leaf name { type string { length "0 .. 255"; } } This is the same, except the "MAY support larger values" part. This says MUST NOT support larger values. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Thu Aug 9 11:27:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF2821F86E1 for ; Thu, 9 Aug 2012 11:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.83 X-Spam-Level: X-Spam-Status: No, score=-5.83 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdzB0BKZEmFJ for ; Thu, 9 Aug 2012 11:27:15 -0700 (PDT) Received: from exprod5og108.obsmtp.com (exprod5og108.obsmtp.com [64.18.0.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9D421F86B5 for ; Thu, 9 Aug 2012 11:27:14 -0700 (PDT) Received: from cinmlip13.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob108.postini.com ([64.18.4.12]) with SMTP ID DSNKUCQBAiIB5KmSEI1e6Xo4VMJBCsGDf5+o@postini.com; Thu, 09 Aug 2012 11:27:14 PDT Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by cinmlip13.e2k.ad.ge.com with ESMTP; 09 Aug 2012 14:27:06 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Aug 2012 14:27:06 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Aug 2012 14:27:06 -0400 Received: from CINMBCNA04.e2k.ad.ge.com (3.159.212.58) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 9 Aug 2012 14:27:05 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBCNA04.e2k.ad.ge.com ([169.254.4.115]) with mapi id 14.02.0283.003; Thu, 9 Aug 2012 14:27:05 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "Alexander Clemm (alex)" , Juergen Schoenwaelder , Andy Bierman Thread-Topic: [netmod] ietf-system & GPS coordinates Thread-Index: Ac12LApxnMu4NeNTSoubScMmB3+5FQALYEqAAAgg+VD//9J3AIAAFgIAgAADZYCAABP6gIAABjmAgABCMqA= Date: Thu, 9 Aug 2012 18:27:04 +0000 Message-ID: References: <20120809163356.GA1795@elstar.local> <20120809175735.GA1905@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2012 18:27:06.0030 (UTC) FILETIME=[94460CE0:01CD765C] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:27:16 -0000 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Alexander Clemm (alex) > Sent: Thursday, August 09, 2012 2:20 PM > To: Juergen Schoenwaelder; Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] ietf-system & GPS coordinates >=20 > It would seem there is a place for both a "location" name (that is > administratively assigned) and a "geo-location". The location is the pos= t it; > someone might include geo location in it. Geo-location would be system > provided, for the minority of systems that support it (yup, most systems = would > be deployed inside, but there are certainly scenarios where it is valid a= nd > would presumably be important, such as equipment on pole tops in a smart > grid). >=20 I agree. Sure everyone could stick it into the location field, but this de= feats the purpose of having a standard way of doing things. I think it mak= es sense to have a config=3Dtrue geo-location that can be administratively = set, and a config=3Dfalse current-location that is gated on a GPS capabilit= y. We have products that are statically installed on towers, yet the custo= mer wants to keep track of where they are on a map, but we also have produc= ts that are installed into the back of vehicles that have an active GPS con= nection. -Jeff > --- Alex >=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Thursday, August 09, 2012 10:58 AM > To: Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] ietf-system & GPS coordinates >=20 > On Thu, Aug 09, 2012 at 09:46:05AM -0700, Andy Bierman wrote: > > The post-it notes are limited to 255 chars each. > > (name, contact, location) > > > > Can we raise this hard-wired arbitrary limit to 1023? >=20 > You probably want to start a separate thread as this has nothing to do wi= th GPS > coordinates. I assume the 255 is inherited from MIB world. That said, if = we > consider changing this limit, then we should remote it rather than replac= ing it > by another arbitrary limit, perhaps adding text similar to .../interface/= name. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Thu Aug 9 11:33:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9350021F8723 for ; Thu, 9 Aug 2012 11:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuuZFbluoMdW for ; Thu, 9 Aug 2012 11:33:57 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D239D21F8707 for ; Thu, 9 Aug 2012 11:33:56 -0700 (PDT) Received: by qcac10 with SMTP id c10so571447qca.31 for ; Thu, 09 Aug 2012 11:33:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=cdPgEJm16+Lfgv9vE6qhP3XNZpvT2Tulm6tT2C7xIdg=; b=Y2kE3nO6HG5/SHdvlltkXjvMC2bbEGIKCti00qNd7sHOYkvOgW33D8a3Mqpp+/F7TG GuSy30X7pHKawpAwr4b/S9y//BUy0wKGnv0rvdFtbO294R1VrEeanggQU7BA1yf955h2 rcjJL85lXlMvrEMQndG2OUZniAGH6zVYXXObbZ2w4FGkF9IFCj2Ct0VgE4PLGUkgsVrz sj9mA/au3wezfQauS11XT2K9HbI3E4aAfJsS5CUiPSrecveMqxKB98mU8L2z8kKe+qIe FiRoZ8ZgdsYlmEXqk8NDxzF+nP8gnKsvxi0dAL9jUCpvkU04Rv59n6tsSOiMtuRr2MU9 ZwQA== MIME-Version: 1.0 Received: by 10.229.135.198 with SMTP id o6mr81868qct.147.1344537236141; Thu, 09 Aug 2012 11:33:56 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 9 Aug 2012 11:33:56 -0700 (PDT) In-Reply-To: References: <20120809163356.GA1795@elstar.local> <20120809175735.GA1905@elstar.local> Date: Thu, 9 Aug 2012 11:33:56 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnNa582GcORtL1MUiyvI/q6Dg7XIB0G+X/J3fg4XG5bi+8xiH9X/5uHL8TU68AEpHU1sIO1 Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:33:57 -0000 On Thu, Aug 9, 2012 at 11:27 AM, Lange, Jeffrey K (GE Energy) wrote: > >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >> Behalf Of Alexander Clemm (alex) >> Sent: Thursday, August 09, 2012 2:20 PM >> To: Juergen Schoenwaelder; Andy Bierman >> Cc: netmod@ietf.org >> Subject: Re: [netmod] ietf-system & GPS coordinates >> >> It would seem there is a place for both a "location" name (that is >> administratively assigned) and a "geo-location". The location is the po= st it; >> someone might include geo location in it. Geo-location would be system >> provided, for the minority of systems that support it (yup, most systems= would >> be deployed inside, but there are certainly scenarios where it is valid = and >> would presumably be important, such as equipment on pole tops in a smart >> grid). >> > > I agree. Sure everyone could stick it into the location field, but this = defeats the purpose of having a standard way of doing things. I think it m= akes sense to have a config=3Dtrue geo-location that can be administrativel= y set, and a config=3Dfalse current-location that is gated on a GPS capabil= ity. We have products that are statically installed on towers, yet the cus= tomer wants to keep track of where they are on a map, but we also have prod= ucts that are installed into the back of vehicles that have an active GPS c= onnection. > This seems like overkill for most NETCONF deployments. Good thing YANG has the augment-stmt. Otherwise we would never finish any standard YANG module! I think "geoloc" is out of scope for this module. > -Jeff > >> --- Alex Andy >> >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >> Behalf Of Juergen Schoenwaelder >> Sent: Thursday, August 09, 2012 10:58 AM >> To: Andy Bierman >> Cc: netmod@ietf.org >> Subject: Re: [netmod] ietf-system & GPS coordinates >> >> On Thu, Aug 09, 2012 at 09:46:05AM -0700, Andy Bierman wrote: >> > The post-it notes are limited to 255 chars each. >> > (name, contact, location) >> > >> > Can we raise this hard-wired arbitrary limit to 1023? >> >> You probably want to start a separate thread as this has nothing to do w= ith GPS >> coordinates. I assume the 255 is inherited from MIB world. That said, if= we >> consider changing this limit, then we should remote it rather than repla= cing it >> by another arbitrary limit, perhaps adding text similar to .../interface= /name. >> >> /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 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Thu Aug 9 11:56:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6563D21F86D7 for ; Thu, 9 Aug 2012 11:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjAUjnIQo4Ir for ; Thu, 9 Aug 2012 11:56:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBC821F86D1 for ; Thu, 9 Aug 2012 11:56:38 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBD8120C01; Thu, 9 Aug 2012 20:56:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ygWGEDd-0NDK; Thu, 9 Aug 2012 20:56:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 878B020BFA; Thu, 9 Aug 2012 20:56:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0B2792113D1C; Thu, 9 Aug 2012 20:56:36 +0200 (CEST) Date: Thu, 9 Aug 2012 20:56:36 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120809185636.GA2095@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <20120809181852.GC1968@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:56:39 -0000 On Thu, Aug 09, 2012 at 11:22:50AM -0700, Andy Bierman wrote: > On Thu, Aug 9, 2012 at 11:18 AM, Juergen Schoenwaelder > wrote: > > On Thu, Aug 09, 2012 at 11:09:49AM -0700, Andy Bierman wrote: > >> Hi, > >> > >> > >> >> > >> >> Can we raise this hard-wired arbitrary limit to 1023? > >> > > >> > You probably want to start a separate thread as this has nothing to do > >> > with GPS coordinates. I assume the 255 is inherited from MIB > >> > world. That said, if we consider changing this limit, then we should > >> > remote it rather than replacing it by another arbitrary limit, perhaps > >> > adding text similar to .../interface/name. > >> > > >> > >> We should not allow these admin strings to have structure, like > >> the interface name leaf. > >> > >> I thought of no limit, and let the server return a too-big error-tag > >> if it cannot hold the text: Maybe that would be best. e.,g.: > >> > >> [remove length-stmt and reference-stmt] > >> > >> leaf name { > >> type string; > >> description > >> "The administratively assigned system name. > >> The server MUST support values from 0 to 255 characters in length, > >> and MAY support larger values."; > >> } > > > > This 255 limit seems arbitrarily new. In SNMP land, things are limited > > to 255 ASCII characters (octets). This description would limit things > > to 255 UTF-8 encoded characters, that can be very well more than 255 > > octets. > > > > How is that any different than the current text: > > leaf name { > type string { > length "0 .. 255"; > } > } > > This is the same, except the "MAY support larger values" part. > This says MUST NOT support larger values. In both cases, 255 UTF-8 code points is not the same as 255 ASCII characters. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 9 12:00:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0595321F87C9 for ; Thu, 9 Aug 2012 12:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByDkuVZbMAex for ; Thu, 9 Aug 2012 12:00:32 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E07D821F8783 for ; Thu, 9 Aug 2012 12:00:30 -0700 (PDT) Received: by qadz3 with SMTP id z3so484103qad.10 for ; Thu, 09 Aug 2012 12:00:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=tO8mMAgkZXV2O+5Oe/wslZg/FH2tez5S5/3MveDWAS8=; b=pmNAv6TlKb+AMuPX00B7M2dB9Wp9wuRtpMSkCO07Yg3iO8RVenrSDQPZ+nwZmGqens weusef+KqvR+kIPZI7WDf6koBhXP4wiz2KLwDUCvwKO5e6Irh+nSq23wgi1GS7AK/ARy h19h+ir3w3PWnljC3OpGb+hiDQX4UrkkZIn/ad7u8jZ0U4G7RzBL5R/9p1SBvpAMm0CB 5ygfelxPI3DlmAMtWl9bnpvjCsHgjuF5UvBGc/i2rj4fK7GVEaBnGDXKTIPS5gMnPXt4 Wvhj3/lr+QJ4QE4YQivVbWUDIdPSApB2bEX/d53Ue8KWu0tsOtlyonv4IDGqgX+dToEO qOlw== MIME-Version: 1.0 Received: by 10.224.180.146 with SMTP id bu18mr4653703qab.10.1344538829344; Thu, 09 Aug 2012 12:00:29 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 9 Aug 2012 12:00:29 -0700 (PDT) In-Reply-To: <20120809185636.GA2095@elstar.local> References: <20120809181852.GC1968@elstar.local> <20120809185636.GA2095@elstar.local> Date: Thu, 9 Aug 2012 12:00:29 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnRhYtBTr1FsWW0lKsM/EUS81y6xP5FQTYvh1TMnWf64Lzj0l4qJwmWAsHlB+WQ30yQTUyx Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:00:33 -0000 On Thu, Aug 9, 2012 at 11:56 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 09, 2012 at 11:22:50AM -0700, Andy Bierman wrote: >> On Thu, Aug 9, 2012 at 11:18 AM, Juergen Schoenwaelder >> wrote: >> > On Thu, Aug 09, 2012 at 11:09:49AM -0700, Andy Bierman wrote: >> >> Hi, >> >> >> >> >> >> >> >> >> >> Can we raise this hard-wired arbitrary limit to 1023? >> >> > >> >> > You probably want to start a separate thread as this has nothing to do >> >> > with GPS coordinates. I assume the 255 is inherited from MIB >> >> > world. That said, if we consider changing this limit, then we should >> >> > remote it rather than replacing it by another arbitrary limit, perhaps >> >> > adding text similar to .../interface/name. >> >> > >> >> >> >> We should not allow these admin strings to have structure, like >> >> the interface name leaf. >> >> >> >> I thought of no limit, and let the server return a too-big error-tag >> >> if it cannot hold the text: Maybe that would be best. e.,g.: >> >> >> >> [remove length-stmt and reference-stmt] >> >> >> >> leaf name { >> >> type string; >> >> description >> >> "The administratively assigned system name. >> >> The server MUST support values from 0 to 255 characters in length, >> >> and MAY support larger values."; >> >> } >> > >> > This 255 limit seems arbitrarily new. In SNMP land, things are limited >> > to 255 ASCII characters (octets). This description would limit things >> > to 255 UTF-8 encoded characters, that can be very well more than 255 >> > octets. >> > >> >> How is that any different than the current text: >> >> leaf name { >> type string { >> length "0 .. 255"; >> } >> } >> >> This is the same, except the "MAY support larger values" part. >> This says MUST NOT support larger values. > > In both cases, 255 UTF-8 code points is not the same as 255 ASCII > characters. But the YANG length-stmt is in units of characters, not octets. 9.4.4. The length Statement The "length" statement, which is an optional substatement to the "type" statement, takes as an argument a length expression string. It is used to restrict the built-in type "string", or types derived from "string". A "length" statement restricts the number of Unicode characters in the string. > > /js Andy From randy_presuhn@mindspring.com Thu Aug 9 12:08:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660E021F8755 for ; Thu, 9 Aug 2012 12:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJeLAC7KUKPi for ; Thu, 9 Aug 2012 12:08:02 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id CA9B421F8747 for ; Thu, 9 Aug 2012 12:08:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lL7K2LmnL/0EPkHTkS494YbbWCq/PzH+78xSNHye8tH2DN/2a5kiM0ld8Iq1Ycsz; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.160.249] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SzY5P-0001O2-1y for netmod@ietf.org; Thu, 09 Aug 2012 15:07:59 -0400 Message-ID: <00a301cd7663$16055320$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120809163356.GA1795@elstar.local><20120809175735.GA1905@elstar.local> Date: Thu, 9 Aug 2012 12:13:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1bb0721c44ab718e7d77586aa2390d4a8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.249 Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:08:02 -0000 Hi - > From: "Alexander Clemm (alex)" > To: "Juergen Schoenwaelder" ; "Andy Bierman" > Cc: > Sent: Thursday, August 09, 2012 11:19 AM > Subject: Re: [netmod] ietf-system & GPS coordinates > > It would seem there is a place for both a "location" name (that is > administratively assigned) and a "geo-location". The location is the > post it; someone might include geo location in it. Geo-location > would be system provided, for the minority of systems that support > it (yup, most systems would be deployed inside, but there are > certainly scenarios where it is valid and would presumably be > important, such as equipment on pole tops in a smart grid). This whole discussion begs another question. This is something that comes up with surprising frequency when objects originally conceived as "post-its" are implemented in more capable systems. Specifically, what does a writeable location field (whether name or coordinates) mean in a system capable of autonomously changing its location? If I change an autonomously mobile router's location from Fresno to Bakersfield, should I have an expectation that it will be on the road anytime soon? How would we expect it to behave if implemented on a Mars rover? Randy From j.schoenwaelder@jacobs-university.de Thu Aug 9 12:34:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B6721F87A1 for ; Thu, 9 Aug 2012 12:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch-Ypf36LFSV for ; Thu, 9 Aug 2012 12:34:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 90FC221F870F for ; Thu, 9 Aug 2012 12:34:22 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7DDB20BF1; Thu, 9 Aug 2012 21:34:21 +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 px_FG4PNOEvY; Thu, 9 Aug 2012 21:34:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83D8620BD7; Thu, 9 Aug 2012 21:34:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB3592113DE4; Thu, 9 Aug 2012 21:34:21 +0200 (CEST) Date: Thu, 9 Aug 2012 21:34:21 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120809193421.GA2147@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <20120809181852.GC1968@elstar.local> <20120809185636.GA2095@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:34:23 -0000 On Thu, Aug 09, 2012 at 12:00:29PM -0700, Andy Bierman wrote: > On Thu, Aug 9, 2012 at 11:56 AM, Juergen Schoenwaelder > wrote: > > On Thu, Aug 09, 2012 at 11:22:50AM -0700, Andy Bierman wrote: > >> On Thu, Aug 9, 2012 at 11:18 AM, Juergen Schoenwaelder > >> wrote: > >> > On Thu, Aug 09, 2012 at 11:09:49AM -0700, Andy Bierman wrote: > >> >> Hi, > >> >> > >> >> > >> >> >> > >> >> >> Can we raise this hard-wired arbitrary limit to 1023? > >> >> > > >> >> > You probably want to start a separate thread as this has nothing to do > >> >> > with GPS coordinates. I assume the 255 is inherited from MIB > >> >> > world. That said, if we consider changing this limit, then we should > >> >> > remote it rather than replacing it by another arbitrary limit, perhaps > >> >> > adding text similar to .../interface/name. > >> >> > > >> >> > >> >> We should not allow these admin strings to have structure, like > >> >> the interface name leaf. > >> >> > >> >> I thought of no limit, and let the server return a too-big error-tag > >> >> if it cannot hold the text: Maybe that would be best. e.,g.: > >> >> > >> >> [remove length-stmt and reference-stmt] > >> >> > >> >> leaf name { > >> >> type string; > >> >> description > >> >> "The administratively assigned system name. > >> >> The server MUST support values from 0 to 255 characters in length, > >> >> and MAY support larger values."; > >> >> } > >> > > >> > This 255 limit seems arbitrarily new. In SNMP land, things are limited > >> > to 255 ASCII characters (octets). This description would limit things > >> > to 255 UTF-8 encoded characters, that can be very well more than 255 > >> > octets. > >> > > >> > >> How is that any different than the current text: > >> > >> leaf name { > >> type string { > >> length "0 .. 255"; > >> } > >> } > >> > >> This is the same, except the "MAY support larger values" part. > >> This says MUST NOT support larger values. > > > > In both cases, 255 UTF-8 code points is not the same as 255 ASCII > > characters. > > But the YANG length-stmt is in units of characters, not octets. > > 9.4.4. The length Statement > > The "length" statement, which is an optional substatement to the > "type" statement, takes as an argument a length expression string. > It is used to restrict the built-in type "string", or types derived > from "string". > > A "length" statement restricts the number of Unicode characters in > the string. Exactly. 255 characters in YANG != 255 octets in SNMP DisplayStrings. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 9 12:37:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF1421F8659 for ; Thu, 9 Aug 2012 12:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrMHUgiAsTeE for ; Thu, 9 Aug 2012 12:36:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 911A021F842E for ; Thu, 9 Aug 2012 12:36:59 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E996E20BF1; Thu, 9 Aug 2012 21: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 (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WZXIsorx1J5E; Thu, 9 Aug 2012 21:36:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 844DB20BD7; Thu, 9 Aug 2012 21:36:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB75D2113E55; Thu, 9 Aug 2012 21:36:58 +0200 (CEST) Date: Thu, 9 Aug 2012 21:36:58 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20120809193658.GB2147@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20120809163356.GA1795@elstar.local> <20120809175735.GA1905@elstar.local> <00a301cd7663$16055320$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a301cd7663$16055320$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system & GPS coordinates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:37:00 -0000 On Thu, Aug 09, 2012 at 12:13:39PM -0700, Randy Presuhn wrote: > Hi - > > > From: "Alexander Clemm (alex)" > > To: "Juergen Schoenwaelder" ; "Andy Bierman" > > Cc: > > Sent: Thursday, August 09, 2012 11:19 AM > > Subject: Re: [netmod] ietf-system & GPS coordinates > > > > It would seem there is a place for both a "location" name (that is > > administratively assigned) and a "geo-location". The location is the > > post it; someone might include geo location in it. Geo-location > > would be system provided, for the minority of systems that support > > it (yup, most systems would be deployed inside, but there are > > certainly scenarios where it is valid and would presumably be > > important, such as equipment on pole tops in a smart grid). > > This whole discussion begs another question. This is something > that comes up with surprising frequency when objects originally > conceived as "post-its" are implemented in more capable systems. > Specifically, what does a writeable location field (whether name or > coordinates) mean in a system capable of autonomously changing > its location? If I change an autonomously mobile router's location > from Fresno to Bakersfield, should I have an expectation that > it will be on the road anytime soon? Sure, if the device is backed by a robot, it will start to move. > How would we expect it to behave if implemented on a Mars rover? I assume the object won't be instantiated. Did you check yet but just out of curiosity. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 9 12:46:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B583221F8681 for ; Thu, 9 Aug 2012 12:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ihr42gKsSxY for ; Thu, 9 Aug 2012 12:46:07 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1363A21F8665 for ; Thu, 9 Aug 2012 12:46:06 -0700 (PDT) Received: by qadz3 with SMTP id z3so509617qad.10 for ; Thu, 09 Aug 2012 12:46:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Huh8nyAVyrM53zguhsUOhv8zb3X2Z++z+3zCTyhXXiY=; b=ZXq82MUcKkScw1X1zrERkfjeJgn2RxlNGmHWMNCDti323IltrLDTSLgINlRiOdK9nG dMYP3r7CToC5/KvnNfG72D7jAT5VxccMPtGJUcnILJkj72qCkBEYv+rHKdtGhjVU8vFe uuXXuPBMmc3Db6zYLzaynil9PkSEjhgtav/IyPVjr6ymDRwzN31lo8vCzw2HtWPHm97Z /yh1cWYPbPegjTaRXxGXbJLTkqhmprikAKnKkVLOftEgEoQtecEGp6JXtKNuab4z14dc 86Pv9QbUw0b4Jp0SNgmxRWk0SFSaSjtSx/SbO+v/TeeCsO5ir/kkLa+4m2S9sC0urNae 3+xg== MIME-Version: 1.0 Received: by 10.224.213.74 with SMTP id gv10mr4775608qab.25.1344541566484; Thu, 09 Aug 2012 12:46:06 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 9 Aug 2012 12:46:06 -0700 (PDT) In-Reply-To: <20120809193421.GA2147@elstar.local> References: <20120809181852.GC1968@elstar.local> <20120809185636.GA2095@elstar.local> <20120809193421.GA2147@elstar.local> Date: Thu, 9 Aug 2012 12:46:06 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl3Z2wVVS9hZudppQXaGHW0Gg/sbQuvbB55rhCI2/WZX1s6brmCgTbL8oA4Dukg6eAKvuTC Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:46:07 -0000 On Thu, Aug 9, 2012 at 12:34 PM, Juergen Schoenwaelder wrote: > On Thu, Aug 09, 2012 at 12:00:29PM -0700, Andy Bierman wrote: >> On Thu, Aug 9, 2012 at 11:56 AM, Juergen Schoenwaelder >> wrote: >> > On Thu, Aug 09, 2012 at 11:22:50AM -0700, Andy Bierman wrote: >> >> On Thu, Aug 9, 2012 at 11:18 AM, Juergen Schoenwaelder >> >> wrote: >> >> > On Thu, Aug 09, 2012 at 11:09:49AM -0700, Andy Bierman wrote: >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> >> >> Can we raise this hard-wired arbitrary limit to 1023? >> >> >> > >> >> >> > You probably want to start a separate thread as this has nothing to do >> >> >> > with GPS coordinates. I assume the 255 is inherited from MIB >> >> >> > world. That said, if we consider changing this limit, then we should >> >> >> > remote it rather than replacing it by another arbitrary limit, perhaps >> >> >> > adding text similar to .../interface/name. >> >> >> > >> >> >> >> >> >> We should not allow these admin strings to have structure, like >> >> >> the interface name leaf. >> >> >> >> >> >> I thought of no limit, and let the server return a too-big error-tag >> >> >> if it cannot hold the text: Maybe that would be best. e.,g.: >> >> >> >> >> >> [remove length-stmt and reference-stmt] >> >> >> >> >> >> leaf name { >> >> >> type string; >> >> >> description >> >> >> "The administratively assigned system name. >> >> >> The server MUST support values from 0 to 255 characters in length, >> >> >> and MAY support larger values."; >> >> >> } >> >> > >> >> > This 255 limit seems arbitrarily new. In SNMP land, things are limited >> >> > to 255 ASCII characters (octets). This description would limit things >> >> > to 255 UTF-8 encoded characters, that can be very well more than 255 >> >> > octets. >> >> > >> >> >> >> How is that any different than the current text: >> >> >> >> leaf name { >> >> type string { >> >> length "0 .. 255"; >> >> } >> >> } >> >> >> >> This is the same, except the "MAY support larger values" part. >> >> This says MUST NOT support larger values. >> > >> > In both cases, 255 UTF-8 code points is not the same as 255 ASCII >> > characters. >> >> But the YANG length-stmt is in units of characters, not octets. >> >> 9.4.4. The length Statement >> >> The "length" statement, which is an optional substatement to the >> "type" statement, takes as an argument a length expression string. >> It is used to restrict the built-in type "string", or types derived >> from "string". >> >> A "length" statement restricts the number of Unicode characters in >> the string. > > Exactly. 255 characters in YANG != 255 octets in SNMP DisplayStrings. > So. It's been that way from the first version. I removed the reference to the SNMP object. This isn't SNMP and the characters are not limited to DisplayString. I said 'characters', not 'octets'. > /js Andy From j.schoenwaelder@jacobs-university.de Thu Aug 9 12:51:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446EC21F8705 for ; Thu, 9 Aug 2012 12:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X99emmB9jT1t for ; Thu, 9 Aug 2012 12:51:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2822121F859F for ; Thu, 9 Aug 2012 12:51:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6047420BE0; Thu, 9 Aug 2012 21:51:29 +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 eor6V-DnyBHe; Thu, 9 Aug 2012 21:51:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7F2E20BDF; Thu, 9 Aug 2012 21:51:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9FE8C2113EEC; Thu, 9 Aug 2012 21:51:28 +0200 (CEST) Date: Thu, 9 Aug 2012 21:51:28 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120809195128.GA2228@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <20120809181852.GC1968@elstar.local> <20120809185636.GA2095@elstar.local> <20120809193421.GA2147@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:51:31 -0000 On Thu, Aug 09, 2012 at 12:46:06PM -0700, Andy Bierman wrote: > On Thu, Aug 9, 2012 at 12:34 PM, Juergen Schoenwaelder > wrote: > > On Thu, Aug 09, 2012 at 12:00:29PM -0700, Andy Bierman wrote: > >> On Thu, Aug 9, 2012 at 11:56 AM, Juergen Schoenwaelder > >> wrote: > >> > On Thu, Aug 09, 2012 at 11:22:50AM -0700, Andy Bierman wrote: > >> >> On Thu, Aug 9, 2012 at 11:18 AM, Juergen Schoenwaelder > >> >> wrote: > >> >> > On Thu, Aug 09, 2012 at 11:09:49AM -0700, Andy Bierman wrote: > >> >> >> Hi, > >> >> >> > >> >> >> > >> >> >> >> > >> >> >> >> Can we raise this hard-wired arbitrary limit to 1023? > >> >> >> > > >> >> >> > You probably want to start a separate thread as this has nothing to do > >> >> >> > with GPS coordinates. I assume the 255 is inherited from MIB > >> >> >> > world. That said, if we consider changing this limit, then we should > >> >> >> > remote it rather than replacing it by another arbitrary limit, perhaps > >> >> >> > adding text similar to .../interface/name. > >> >> >> > > >> >> >> > >> >> >> We should not allow these admin strings to have structure, like > >> >> >> the interface name leaf. > >> >> >> > >> >> >> I thought of no limit, and let the server return a too-big error-tag > >> >> >> if it cannot hold the text: Maybe that would be best. e.,g.: > >> >> >> > >> >> >> [remove length-stmt and reference-stmt] > >> >> >> > >> >> >> leaf name { > >> >> >> type string; > >> >> >> description > >> >> >> "The administratively assigned system name. > >> >> >> The server MUST support values from 0 to 255 characters in length, > >> >> >> and MAY support larger values."; > >> >> >> } > >> >> > > >> >> > This 255 limit seems arbitrarily new. In SNMP land, things are limited > >> >> > to 255 ASCII characters (octets). This description would limit things > >> >> > to 255 UTF-8 encoded characters, that can be very well more than 255 > >> >> > octets. > >> >> > > >> >> > >> >> How is that any different than the current text: > >> >> > >> >> leaf name { > >> >> type string { > >> >> length "0 .. 255"; > >> >> } > >> >> } > >> >> > >> >> This is the same, except the "MAY support larger values" part. > >> >> This says MUST NOT support larger values. > >> > > >> > In both cases, 255 UTF-8 code points is not the same as 255 ASCII > >> > characters. > >> > >> But the YANG length-stmt is in units of characters, not octets. > >> > >> 9.4.4. The length Statement > >> > >> The "length" statement, which is an optional substatement to the > >> "type" statement, takes as an argument a length expression string. > >> It is used to restrict the built-in type "string", or types derived > >> from "string". > >> > >> A "length" statement restricts the number of Unicode characters in > >> the string. > > > > Exactly. 255 characters in YANG != 255 octets in SNMP DisplayStrings. > > > > So. It's been that way from the first version. > I removed the reference to the SNMP object. > This isn't SNMP and the characters are not limited to DisplayString. > I said 'characters', not 'octets'. So then we finally agree that this is a totally arbitrary limit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 9 13:01:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9621F86FD for ; Thu, 9 Aug 2012 13:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoOoQB9EyEux for ; Thu, 9 Aug 2012 13:01:18 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B38621F86FC for ; Thu, 9 Aug 2012 13:01:18 -0700 (PDT) Received: by qcac10 with SMTP id c10so622990qca.31 for ; Thu, 09 Aug 2012 13:01:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=BbeYWYSKUz83zTvADqrBuci6phhk+/P+GO5ehQlqA8o=; b=bMozQ1BFj/Hsx+my5UdLrOohEpf5qmzjPTZb3AQbQ1R7eWDIY934gKRGni9mm9L6qx 7B8UCobsFNiFEQsFR30EQQaLSxDXKE5BQQxuadYoIHFALWX9Uv5KlHbiQNdxSYzUn+co sC4XkEZneqQBWhzhFk1kmDp7kClBEB8sWeSCQWsa0Efm9NKj6eak5Ewvk8xYv+NZVATP iSIdxq7sYyEeLEfpocLJjQMas0dByXdnqiOVT+7VZ1XMe34bCP8bTU0hydz38csPsTf/ 1xKiLf2M6ISQ3GyLnYDOSzyQNjHYbiXXk1JWuzKXdQet8rl1yYPHWBfS//+dERPftLkD DRRA== MIME-Version: 1.0 Received: by 10.229.134.213 with SMTP id k21mr228568qct.106.1344542471682; Thu, 09 Aug 2012 13:01:11 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 9 Aug 2012 13:01:11 -0700 (PDT) In-Reply-To: <20120809195128.GA2228@elstar.local> References: <20120809181852.GC1968@elstar.local> <20120809185636.GA2095@elstar.local> <20120809193421.GA2147@elstar.local> <20120809195128.GA2228@elstar.local> Date: Thu, 9 Aug 2012 13:01:11 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkLVy3GULNKA4B/YKqxqtb3CAQI0Wz2DbqrXHpu49AoFAzl7hn+MS6l4icqhOgyjHfX+3H6 Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:01:19 -0000 I suggested this leaf 3 emails ago: leaf name { type string; description "The administratively assigned system name. The server MUST support values from 0 to 255 characters in length, and MAY support larger values."; } The client needs a min-limit which I picked arbitrarily to be 255. But we can have no limits and leave it up to the servers to implement something reasonable: leaf name { type string; description "The administratively assigned system name."; } Andy On Thu, Aug 9, 2012 at 12:51 PM, Juergen Schoenwaelder wrote: > On Thu, Aug 09, 2012 at 12:46:06PM -0700, Andy Bierman wrote: >> On Thu, Aug 9, 2012 at 12:34 PM, Juergen Schoenwaelder >> wrote: >> > On Thu, Aug 09, 2012 at 12:00:29PM -0700, Andy Bierman wrote: >> >> On Thu, Aug 9, 2012 at 11:56 AM, Juergen Schoenwaelder >> >> wrote: >> >> > On Thu, Aug 09, 2012 at 11:22:50AM -0700, Andy Bierman wrote: >> >> >> On Thu, Aug 9, 2012 at 11:18 AM, Juergen Schoenwaelder >> >> >> wrote: >> >> >> > On Thu, Aug 09, 2012 at 11:09:49AM -0700, Andy Bierman wrote: >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Can we raise this hard-wired arbitrary limit to 1023? >> >> >> >> > >> >> >> >> > You probably want to start a separate thread as this has nothing to do >> >> >> >> > with GPS coordinates. I assume the 255 is inherited from MIB >> >> >> >> > world. That said, if we consider changing this limit, then we should >> >> >> >> > remote it rather than replacing it by another arbitrary limit, perhaps >> >> >> >> > adding text similar to .../interface/name. >> >> >> >> > >> >> >> >> >> >> >> >> We should not allow these admin strings to have structure, like >> >> >> >> the interface name leaf. >> >> >> >> >> >> >> >> I thought of no limit, and let the server return a too-big error-tag >> >> >> >> if it cannot hold the text: Maybe that would be best. e.,g.: >> >> >> >> >> >> >> >> [remove length-stmt and reference-stmt] >> >> >> >> >> >> >> >> leaf name { >> >> >> >> type string; >> >> >> >> description >> >> >> >> "The administratively assigned system name. >> >> >> >> The server MUST support values from 0 to 255 characters in length, >> >> >> >> and MAY support larger values."; >> >> >> >> } >> >> >> > >> >> >> > This 255 limit seems arbitrarily new. In SNMP land, things are limited >> >> >> > to 255 ASCII characters (octets). This description would limit things >> >> >> > to 255 UTF-8 encoded characters, that can be very well more than 255 >> >> >> > octets. >> >> >> > >> >> >> >> >> >> How is that any different than the current text: >> >> >> >> >> >> leaf name { >> >> >> type string { >> >> >> length "0 .. 255"; >> >> >> } >> >> >> } >> >> >> >> >> >> This is the same, except the "MAY support larger values" part. >> >> >> This says MUST NOT support larger values. >> >> > >> >> > In both cases, 255 UTF-8 code points is not the same as 255 ASCII >> >> > characters. >> >> >> >> But the YANG length-stmt is in units of characters, not octets. >> >> >> >> 9.4.4. The length Statement >> >> >> >> The "length" statement, which is an optional substatement to the >> >> "type" statement, takes as an argument a length expression string. >> >> It is used to restrict the built-in type "string", or types derived >> >> from "string". >> >> >> >> A "length" statement restricts the number of Unicode characters in >> >> the string. >> > >> > Exactly. 255 characters in YANG != 255 octets in SNMP DisplayStrings. >> > >> >> So. It's been that way from the first version. >> I removed the reference to the SNMP object. >> This isn't SNMP and the characters are not limited to DisplayString. >> I said 'characters', not 'octets'. > > So then we finally agree that this is a totally arbitrary limit. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From phil@juniper.net Thu Aug 9 16:26:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807B221F8644 for ; Thu, 9 Aug 2012 16:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj7wgR8Nkyu2 for ; Thu, 9 Aug 2012 16:26:13 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 20C5821F8628 for ; Thu, 9 Aug 2012 16:26:10 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUCRHEUU+x110mrlQjtvnL/vJgXs5ItFR@postini.com; Thu, 09 Aug 2012 16:26:13 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 9 Aug 2012 16:25: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 q79NPSh94616; Thu, 9 Aug 2012 16:25:28 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q79NOP8t042414; Thu, 9 Aug 2012 19:24:47 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208092324.q79NOP8t042414@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 9 Aug 2012 19:24:25 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:26:14 -0000 Andy Bierman writes: >This is the same, except the "MAY support larger values" part. >This says MUST NOT support larger values. Isn't supporting longer lengths just a deviation? Thanks, Phil From ietfc@btconnect.com Fri Aug 10 01:14:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DBF21F8628 for ; Fri, 10 Aug 2012 01:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.656 X-Spam-Level: X-Spam-Status: No, score=-3.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdWR3NXuK9Rm for ; Fri, 10 Aug 2012 01:14:07 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id DD12221F861E for ; Fri, 10 Aug 2012 01:14:02 -0700 (PDT) Received: from mail14-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 Aug 2012 08:13:58 +0000 Received: from mail14-co1 (localhost [127.0.0.1]) by mail14-co1-R.bigfish.com (Postfix) with ESMTP id 5C0D8860314; Fri, 10 Aug 2012 08:13:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT012.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(z37d5kz9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail14-co1 (localhost.localdomain [127.0.0.1]) by mail14-co1 (MessageSwitch) id 1344586435682082_10618; Fri, 10 Aug 2012 08:13:55 +0000 (UTC) Received: from CO1EHSMHS008.bigfish.com (unknown [10.243.78.251]) by mail14-co1.bigfish.com (Postfix) with ESMTP id A479A6C003F; Fri, 10 Aug 2012 08:13:55 +0000 (UTC) Received: from DB3PRD0702HT012.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS008.bigfish.com (10.243.66.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 Aug 2012 08:13:55 +0000 Received: from CH1PRD0310HT002.namprd03.prod.outlook.com (157.56.244.37) by pod51017.outlook.com (10.3.5.132) with Microsoft SMTP Server (TLS) id 14.15.108.4; Fri, 10 Aug 2012 08:13:34 +0000 Message-ID: <014c01cd76cf$68c71dc0$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , References: Date: Fri, 10 Aug 2012 09:08:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.244.37] X-OriginatorOrg: btconnect.com Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 08:14:09 -0000 ----- Original Message ----- From: "Andy Bierman" To: Sent: Thursday, August 09, 2012 7:09 PM > >> > >> Can we raise this hard-wired arbitrary limit to 1023? > > > > You probably want to start a separate thread as this has nothing to do > > with GPS coordinates. I assume the 255 is inherited from MIB > > world. That said, if we consider changing this limit, then we should > > remote it rather than replacing it by another arbitrary limit, perhaps > > adding text similar to .../interface/name. > > > We should not allow these admin strings to have structure, like > the interface name leaf. > > I thought of no limit, and let the server return a too-big error-tag > if it cannot hold the text: Maybe that would be best. e.,g.: > > [remove length-stmt and reference-stmt] I like having a limit, because of human behaviour when there isn't one. Cobol was the first I encountered and the absurd names that people came up with seriously impaired comprehension. The problem is that people want to encode everything including the kitchen sink into a label, instead of recognising that it is a label and should be chosen to provide a convenient index into more detailed information. So, for me, 255 characters - not octets - is excessive, 63 is almost always enough. Think of writing it, transcribing it, saying it over the phone to third level support ...... Tom Petch > leaf name { > type string; > description > "The administratively assigned system name. > The server MUST support values from 0 to 255 characters in length, > and MAY support larger values."; > } > > > > /js > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@yumaworks.com Fri Aug 10 02:27:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AF021F853F for ; Fri, 10 Aug 2012 02:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfKCPjfjJNU5 for ; Fri, 10 Aug 2012 02:27:36 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8647D21F8523 for ; Fri, 10 Aug 2012 02:27:35 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2441528pbb.31 for ; Fri, 10 Aug 2012 02:27:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=ZKC5t43hMNYdBygul0W+yWlIeVG6Pm5f5dfc0Nwu9xs=; b=jnhkAh1N8O15flDFnjYEfxaTP3voYccw0lwjfAdV/XAGNdE86DY+pS97CI06gXe5Vu KN2nxXyA5RgwJ7K16vASrJ6BbA4rCT5QamgcRe7Ynr/Dw6/cCEY+Ht7fny7/7YyaJHWO K7TJGF/Dq225lucXoUqi12byZ+kBcsDVjOGC6QXlUkqskzNRNpgng27ZSdmmjHrv1NFo v9MDK8hEkPhSv4QYVlD+Vm/phnYxOwNaMnlTluwa0LFtq04Xfu+lHslxTUkNQALg0DuV q8m95MLWpH23AdoLgobk1wSwV8PjXVakcw5lMFulNURDn+Z8Hdw0vDhBD6obQu0LO8wG 8Reg== Received: by 10.68.222.103 with SMTP id ql7mr11105624pbc.48.1344590855110; Fri, 10 Aug 2012 02:27:35 -0700 (PDT) Received: from [192.168.0.106] (cpe-75-84-168-164.socal.res.rr.com. [75.84.168.164]) by mx.google.com with ESMTPS id nv6sm3001777pbc.42.2012.08.10.02.27.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 02:27:34 -0700 (PDT) References: <014c01cd76cf$68c71dc0$4001a8c0@gateway.2wire.net> In-Reply-To: <014c01cd76cf$68c71dc0$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9277B093-1064-4CDF-A188-D2DA7FA758B3@yumaworks.com> X-Mailer: iPhone Mail (9B206) From: Andy Bierman Date: Fri, 10 Aug 2012 02:27:31 -0700 To: "t.petch" X-Gm-Message-State: ALoCoQnD6DpEZUutDql+sFmMNbSuXHJ+y1B6zf4P84btAgbyctZGqBQuQ8HBFQT9EINegrIuK3FV Cc: "" Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 09:27:36 -0000 Ok, so we will leave the current objects alone. I see no consensus to chang= e anything.=20 Andy Sent from my iPhone On Aug 10, 2012, at 1:08, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: > Sent: Thursday, August 09, 2012 7:09 PM >>>>=20 >>>> Can we raise this hard-wired arbitrary limit to 1023? >>>=20 >>> You probably want to start a separate thread as this has nothing to > do >>> with GPS coordinates. I assume the 255 is inherited from MIB >>> world. That said, if we consider changing this limit, then we should >>> remote it rather than replacing it by another arbitrary limit, > perhaps >>> adding text similar to .../interface/name. >>>=20 >> We should not allow these admin strings to have structure, like >> the interface name leaf. >>=20 >> I thought of no limit, and let the server return a too-big error-tag >> if it cannot hold the text: Maybe that would be best. e.,g.: >>=20 >> [remove length-stmt and reference-stmt] >=20 > I like having a limit, because of human behaviour when there isn't one. > Cobol was the first I encountered and the absurd names that people came > up with seriously impaired comprehension. The problem is that people > want to encode everything including the kitchen sink into a label, > instead of recognising that it is a label and should be chosen to > provide a convenient index into more detailed information. >=20 > So, for me, 255 characters - not octets - is excessive, 63 is almost > always enough. Think of writing it, transcribing it, saying it over the > phone to third level support ...... >=20 > Tom Petch >=20 >> leaf name { >> type string; >> description >> "The administratively assigned system name. >> The server MUST support values from 0 to 255 characters in > length, >> and MAY support larger values."; >> } >>=20 >>=20 >>> /js >>=20 >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 From j.schoenwaelder@jacobs-university.de Fri Aug 10 03:45:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CD821F8610 for ; Fri, 10 Aug 2012 03:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GvwjpJPmO5b for ; Fri, 10 Aug 2012 03:45:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9874821F861E for ; Fri, 10 Aug 2012 03:45:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C770F20C02; Fri, 10 Aug 2012 12:45:04 +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 KfG_HZb_MXrV; Fri, 10 Aug 2012 12:45:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E38D20BE3; Fri, 10 Aug 2012 12:45:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AEDF22114788; Fri, 10 Aug 2012 12:45:03 +0200 (CEST) Date: Fri, 10 Aug 2012 12:45:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120810104501.GA3122@elstar.local> Mail-Followup-To: Andy Bierman , "t.petch" , "" References: <014c01cd76cf$68c71dc0$4001a8c0@gateway.2wire.net> <9277B093-1064-4CDF-A188-D2DA7FA758B3@yumaworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9277B093-1064-4CDF-A188-D2DA7FA758B3@yumaworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "" Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 10:45:06 -0000 On Fri, Aug 10, 2012 at 02:27:31AM -0700, Andy Bierman wrote: > Ok, so we will leave the current objects alone. I see no consensus > to change anything. I think we were talking about these three objects: leaf contact { type string { length "0..255"; } description "The administrator contact information for the system."; reference "RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) SNMPv2-MIB.sysContact"; } leaf name { type string { length "0..255"; } description "The administratively assigned system name."; reference "RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) SNMPv2-MIB.sysName"; } leaf location { type string { length "0..255"; } description "The system location"; reference "RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) SNMPv2-MIB.sysLocation"; } My point remains that this definition is potentially misleading since sysContact, sysName, and sysLocation have a different character set and a different length restriction. I think it is useful to be explicit about such differences. In the interfaces YANG model, Martin wrote text such as (replace XXXX with sysContact, sysName, or sysLocation): This leaf MAY be mapped to XXXX by an implementation. Such an implementation MAY restrict the allowed values for this leaf so that it matches the restrictions of XXXX. If a NETCONF server that implements this restriction is sent a value that doesn't match the restriction, it MUST reply with an rpc-error with the error-tag 'invalid-value'. And in the interface model, Martin dropped the length restrictions altogether. I think we should be consistent with this. I also note that we do not impose length restrictions in other data models, e.g. the NETCONF access control model (see user-name-type or group-name-type). /js (as contributor) PS: If we would have explicit conformance statements, we could define a minimum length that implementations must support as part of the conformance definition instead of hardwiring this in the data model. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Fri Aug 10 10:39:44 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2057921F866D for ; Fri, 10 Aug 2012 10:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+8ocea+cjT3 for ; Fri, 10 Aug 2012 10:39:43 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2A121F865F for ; Fri, 10 Aug 2012 10:39:41 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUCVHXacFVHfcuNnmFjy4mIfXdI+1+nhH@postini.com; Fri, 10 Aug 2012 10:39:43 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 10 Aug 2012 10:38:00 -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 q7AHbxh44372; Fri, 10 Aug 2012 10:37:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7AHambn047358; Fri, 10 Aug 2012 13:37:18 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208101737.q7AHambn047358@idle.juniper.net> To: t.petch In-Reply-To: <014c01cd76cf$68c71dc0$4001a8c0@gateway.2wire.net> Date: Fri, 10 Aug 2012 13:36:48 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:39:44 -0000 "t.petch" writes: >I like having a limit, because of human behaviour when there isn't one. Yup, customers stuff all sorts of vital information into our description strings. With no limit, I can see someone expecting to use this as backing store for their OSS system. >So, for me, 255 characters - not octets - is excessive, 63 is almost >always enough. Think of writing it, transcribing it, saying it over the >phone to third level support ...... 63 is likely too small, given the above comment. I've seen customers using descriptions with >128 bytes in the wild. Thanks, Phil From xiangli@seguesoft.com Fri Aug 10 11:15:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FE421F8757 for ; Fri, 10 Aug 2012 11:15:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VQ3FMe+hoj0 for ; Fri, 10 Aug 2012 11:15:31 -0700 (PDT) Received: from m1plsmtpa01-04.prod.mesa1.secureserver.net (m1plsmtpa01-04.prod.mesa1.secureserver.net [64.202.165.6]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8B21F8645 for ; Fri, 10 Aug 2012 11:15:31 -0700 (PDT) Received: from [192.168.2.10] ([98.212.151.151]) by m1plsmtpa01-04.prod.mesa1.secureserver.net with id l6FV1j00C3GEayi016FWfT; Fri, 10 Aug 2012 11:15:30 -0700 Message-ID: <50254FC3.4040707@seguesoft.com> Date: Fri, 10 Aug 2012 13:15:31 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netmod@ietf.org References: <014c01cd76cf$68c71dc0$4001a8c0@gateway.2wire.net> In-Reply-To: <014c01cd76cf$68c71dc0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:15:32 -0000 > I like having a limit, because of human behaviour when there isn't one. > Cobol was the first I encountered and the absurd names that people came > up with seriously impaired comprehension. The problem is that people > want to encode everything including the kitchen sink into a label, > instead of recognising that it is a label and should be chosen to > provide a convenient index into more detailed information. For a standard model, I also prefer to having a limit, be it 255 or some other appropriate length. I feel it might defeat the purpose for a standard model if we let each server implementation to determine the length to support. I think it may be misused if there is no limit and is arguably "harder" to implement. --Xiang Li > > So, for me, 255 characters - not octets - is excessive, 63 is almost > always enough. Think of writing it, transcribing it, saying it over the > phone to third level support ...... > Tom Petch > >> leaf name { >> type string; >> description >> "The administratively assigned system name. >> The server MUST support values from 0 to 255 characters in > length, >> and MAY support larger values."; >> } >> >> >>> /js >> 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 andy@yumaworks.com Fri Aug 10 11:34:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FF421F8712 for ; Fri, 10 Aug 2012 11:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sXtW5sL1nNe for ; Fri, 10 Aug 2012 11:34:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1106F21F8713 for ; Fri, 10 Aug 2012 11:34:05 -0700 (PDT) Received: by qcac10 with SMTP id c10so1261340qca.31 for ; Fri, 10 Aug 2012 11:34:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=g4VOHYcgPE8sZ1cw3CiuLrlYThIM/WELjCiDKZAsM5o=; b=Ux/MlKx65dKRxlSkdyCIhidOoUmMkm4gg2q55kyLPwYH5TPdt0skXBzpeY8ymw0Z08 VIhGM/81pdPRMod4N1HGqJk9eDzk2pDabjODVEFN0jQSv6mkNFRWjBqDgOgz5Na4MYBz 8yRmNdEqm4gPODd1rYJaU2J4LgjeoQGlK0iHpZFBeEc9xezzQUIcXIMEd98zbzqeiOq6 cixsYcOV/b/sBFRoYLzlG0CYph8AJPT/u2j9t5DbLnEAJXJjD5G4c9hHGa/d0xWYzeft xy7Uix0zHo4fmqdS/nqV2cfloCvdh7aM8sfGfMYIkVHR425oQp1AVQI+44FtWY1LuYm6 4fqQ== MIME-Version: 1.0 Received: by 10.229.136.135 with SMTP id r7mr1809073qct.133.1344623645451; Fri, 10 Aug 2012 11:34:05 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Fri, 10 Aug 2012 11:34:05 -0700 (PDT) In-Reply-To: <50254FC3.4040707@seguesoft.com> References: <014c01cd76cf$68c71dc0$4001a8c0@gateway.2wire.net> <50254FC3.4040707@seguesoft.com> Date: Fri, 10 Aug 2012 11:34:05 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlYsn2lN6sedtQffDr94zDPR+OfqEjrBO2kX5OCdKJhq0RqxCKjaXHPgtc9TPliqb2EGpZO Cc: netmod@ietf.org Subject: Re: [netmod] length limits on system/name,contact,location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:34:09 -0000 On Fri, Aug 10, 2012 at 11:15 AM, Xiang Li wrote: >> I like having a limit, because of human behaviour when there isn't one. >> Cobol was the first I encountered and the absurd names that people came >> up with seriously impaired comprehension. The problem is that people >> want to encode everything including the kitchen sink into a label, >> instead of recognising that it is a label and should be chosen to >> provide a convenient index into more detailed information. > > > > For a standard model, I also prefer to having a limit, be it 255 or some > other > appropriate length. I feel it might defeat the purpose for a standard model > if we > let each server implementation to determine the length to support. > > I think it may be misused if there is no limit and is arguably "harder" to > implement. > This is what I proposed: leaf name { type string; description "The administratively assigned system name. The server MUST support values from 0 to 255 characters in length, and MAY support larger values."; } Apparently YANG writers skip the description-stmts and they don't seem to count as normative behavior. The length-stmt says the "the server MUST support this range of value lengths and only this range". The above text requires the same range of value lengths be supported, but allowed larger strings without the server deviating from the standard. The proper way to deal with conformance issues is with a real conformance model. NETCONF/YANG has a simplistic conformance model, so we have no concept of this, or machine-readable stmts to deal with "server MUST support this minimum functionality, and MAY support more functionality." We should never be defining any administrative fields with arbitrary upper limits built into the definition. > --Xiang Li > Andy > >> >> So, for me, 255 characters - not octets - is excessive, 63 is almost >> always enough. Think of writing it, transcribing it, saying it over the >> phone to third level support ...... > > > > > > > > > > > > > > > > > > >> Tom Petch >> >>> leaf name { >>> type string; >>> description >>> "The administratively assigned system name. >>> The server MUST support values from 0 to 255 characters in >> >> length, >>> >>> and MAY support larger values."; >>> } >>> >>> >>>> /js >>> >>> 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 > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Sat Aug 11 07:41:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B487921F8554 for ; Sat, 11 Aug 2012 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsYSTJcOHd+h for ; Sat, 11 Aug 2012 07:41:10 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 17C9421F850B for ; Sat, 11 Aug 2012 07:41:09 -0700 (PDT) Received: by qadz3 with SMTP id z3so183943qad.10 for ; Sat, 11 Aug 2012 07:41:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=HHOpjPRjnc605navjnvwosB3AnN5rkYvxQfE2xkGsfM=; b=a1E4AQIA9RtjaNs/ik/FhV7ZxFS3a9SjFMmDQuTpUDeEW8hSd4bZnEBdPmKJvDUQKJ OUpG7tmoopOBJshVtoxevSnBarFcETbKCftD8ILMqyHqRrjc81KjIekSrcaUyyz8oF4j oUzXmxBTpb7tnWmcJSyqeKk2WF3zgAmlD8mohL4bEim0oVsU3JHZbNzM8zgpiEbvRgUL a72d3twCveGitvMs5lkid64LrhmIo+6gnLx5Vy2D6/T1U6nZKbzm1G/gcdL77zQZdDNl acRUerT9vcjKax5yYa44D8yigsPCsRlSwul26b46WD8UIHgaaxeGQ96cRvcJhULEpYXo NRFg== MIME-Version: 1.0 Received: by 10.229.102.155 with SMTP id g27mr3089161qco.109.1344696069258; Sat, 11 Aug 2012 07:41:09 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sat, 11 Aug 2012 07:41:09 -0700 (PDT) In-Reply-To: <20120806.221755.449072128.mbj@tail-f.com> References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> Date: Sat, 11 Aug 2012 07:41:09 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkNGSqddIobMcG+OVNSzkskbextWQJ9lFqq4uhiBZIpxlVjfYkiKWKGGktgovg1IvHGyvc6 Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 14:41:10 -0000 Hi, I think the scope of offline validation should be limited to YANG rpc input parameters. All of the parameters in ietf-netconf.yang are declared as 'anyxml'. From the rpc-statement validation POV, anyxml is treated as a leaf. There are no YANG child nodes specified, so therefore there are no constraints on child nodes of the anyxml node. The internal processing of the anyxml child nodes is part of the datastore editing behavior for the edit-config or copy-config implementation. It is not part of the input parameter validation. Andy On Mon, Aug 6, 2012 at 1:17 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> On Aug 5, 2012, at 9:38 PM, Martin Bjorklund wrote: >> >> > Hi, >> > >> > I agree fully with Andy on this issue. The main problem seems to be >> > that the DSDL mapping cannot handle "when" properly when it is >> > combined with mandatory true. But this is a not a problem with 6020. >> >> Sorry, I cannot agree. Sec. 7.19.5 defines the context node for 'when' XPath >> expression as follows: >> >> o If the "when" statement is a child of any other data definition >> statement, the context node is the data definition's node in the >> data tree. >> >> It doesn't say what happens if "data definition's node" is absent in the data >> tree. And without a context node, the XPath expression is not well-defined. >> >> >> > >> > The evaluation mechanism is (conceptually) as follows. If a node with >> > a when stmt exists, the when expression is evaluated with the node as >> > context node. If the expression evaluates to false, the node is >> > deleted. If a node with a when expression is about to be created, it >> > is added to the tree (I think this is what Andy refers to as the dummy >> > node), and the when expression is evaluated with the node as context >> > node. If the expression is evaluated to false, the error specified in >> > 8.3.1 is returned. >> >> OK, but what about this: >> >> leaf enable-foo { >> type boolean; >> } >> container foo { >> when "../enable-foo = 'true'"; >> leaf bar { >> type uint8; >> mandatory true; >> } >> } >> >> Now, consider an instance document containing false >> but not , i.e. the XPath context node is missing. Simple question: is >> this a valid document? If your answer is yes, could you explain how the >> validity follows from 6020? >> >> I think this is where Andy needs to temporarily insert as his dummy >> element, which is however not "about to be created" as you write, at least not >> as a result of client's action. This has no support in 6020, the alone XPath. > > Ok, I see your point. But this doesn't seem to be related to the > original issue in this thread - that "when" somehow modifies the > *schema tree*. > > > /martin From lhotka@nic.cz Sat Aug 11 10:26:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5DB21F85ED for ; Sat, 11 Aug 2012 10:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu3w+l15bRQu for ; Sat, 11 Aug 2012 10:26:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 05B7621F85C3 for ; Sat, 11 Aug 2012 10:26:54 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.21]) by mail.nic.cz (Postfix) with ESMTPSA id 52BA41408DA; Sat, 11 Aug 2012 19:26:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344706012; bh=V67eFHSUjHXhAPgwBcw6gH3fkFHL+Jm+OBmQ4oRpdd4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pz+BmyZMPYpo2CzAcjY1QoHBbnfQ+vmrF1X+/nIeX3JDMBLQLkt+7fMW0jd6a04ef HiSHKPwt5pCvZt3PX8hWw9F4lomz6DqqBmwB9jgjuJLfaBVGbSaXZ+cpNJmxEd+gE2 up3U18p6KlXEDi+YeNIsDNQK4xPLZYTabKMjNKbQ= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Sat, 11 Aug 2012 19:26:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F60BB79-B200-4988-9C49-4C09576F968F@nic.cz> References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> <1611C3F1-68E3-4ECB-80AA-2E531B3BEADA@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:26:56 -0000 On Aug 9, 2012, at 3:56 PM, Andy Bierman wrote: > Hi, >=20 > Why are we debating an implementation detail? I have never mentioned any implementation in this thread. =20 > There are lots of combinations where the when-stmt > needs to be conceptually evaluated on a missing node > to determine if that node is triggering an error or not. > So what? We have the same situation with conceptual > NP containers that contain default leafs: >=20 > leaf if-foobar { > when "../foobar"; > type string; > } >=20 > container foobar { > leaf def { > type int32; > default 42; > } > } >=20 > The when-stmt is always true, whether the server > has a /foobar node or not. It is an implementation > detail. This case is not interesting because sec. 7.19.5 in RFC 6020 makes it = very clear that the accessible tree for 'when' evaluation contains all = leafs with default values. Defaults interact with 'when' in another problematic way though: leaf enable-foo { type boolean; } leaf foo { when "../enable-foo =3D 'true'"; type uint8; default 42; } Consider this scenario: 1. Client A sets "enable-foo" to "false". 2. Server deletes the leaf "foo". 3. Client B issues a , asking for "foo". 4. The response will contain no data. Now, can client B assume that "foo" effectively contains the default = value (42)? If not, why? The datastore schema is an important part of the contract between the = server and client. If it was so, as you wrote, that the current schema = can only be determined on the server, the client couldn't sometimes = correctly interpret data obtained from the server. Therefore, I think = that after finishing exchange *both* the server and client = should be able to construct the schema and it should be identical on = both sides of the connection. So it is not about offline validation but rather about the contract and = its interpretation. I don't know why the client couldn't validate the = contents of a reply to or . Lada =20 >=20 >=20 > Andy >=20 >=20 > On Wed, Aug 8, 2012 at 9:49 PM, Ladislav Lhotka wrote: >>=20 >> On Aug 9, 2012, at 12:49 AM, Jernej Tuljak wrote: >>=20 >>> Are you sure that you used the correct example? Because it does not = seem consistent with what you are saying. Container foo is not = mandatory.. And there's nothing wrong with an instance of enable-foo = being present in a datastore without an instance of foo. There's no such = constraint on the enable-foo leaf. It's just a plain old leaf. >>=20 >> Container "foo" is mandatory due to Sec. 3.1 in RFC 6020 (third = bullet). >>=20 >> Lada >>=20 >>>=20 >>> What you claim would hold if mandatory-stmt and when-stmt were used = on the same leaf. A server would delete such a leaf instance if it's = when evaluated to false..but doing so would be deleting a mandatory data = node - leaving the datastore in an invalid state. Is this what you are = saying? >>>=20 >>> Jernej >>>=20 >>> Dne 8. avg. 2012 22:04 je "Ladislav Lhotka" = napisal/-a: >>>=20 >>> On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote: >>>=20 >>>> ..... >>>>>>>> OK, but what about this: >>>>>>>>=20 >>>>>>>> leaf enable-foo { >>>>>>>> type boolean; >>>>>>>> } >>>>>>>> container foo { >>>>>>>> when "../enable-foo =3D 'true'"; >>>>>>>> leaf bar { >>>>>>>> type uint8; >>>>>>>> mandatory true; >>>>>>>> } >>>>>>>> } >>>>>>>>=20 >>>>>>>> Now, consider an instance document containing = false >>>>>>>> but not , i.e. the XPath context node is missing. Simple = question: is >>>>>>>> this a valid document? If your answer is yes, could you explain = how the >>>>>>>> validity follows from 6020? >>>>>>>>=20 >>>>=20 >>>> I assume these are the contents of the node in an = edit-config >>>=20 >>> To keep things simple, it could be the content of a . >>>=20 >>>> operation. The edit-config operation and the when statement are = very clear >>>> about when-stmts that are applied to the context node vs. >>>> those which are applied to a conceptual datastore + state document. >>>>=20 >>>> In your example, setting enable-foo=3Dfalse or deleting it will = cause the >>>> /foo container to be deleted by the server. The YANG statements >>>> like when/must apply to conceptual datastores, not to NETCONF >>>> messages. >>>=20 >>> If the server does this, the resulting datastore content is invalid = because from sec. 3.1 in 6020 it follows that the "foo" container is = mandatory. The 'when' statement cannot change this because its XPath = expression has no context node and is therefore undefined. >>>=20 >>>=20 >>> Lada >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>>>> I think this is where Andy needs to temporarily insert as = his dummy >>>>>>>> element, which is however not "about to be created" as you = write, at least not >>>>>>>> as a result of client's action. This has no support in 6020, = the alone XPath. >>>>>>>=20 >>>>>>> Ok, I see your point. But this doesn't seem to be related to = the >>>>>>> original issue in this thread - that "when" somehow modifies the >>>>>>> *schema tree*. >>>>>>=20 >>>>>> Not schema tree but schema, with which one can check the = structure of an XML document without looking into element values of the = validated document (think of a RELAX NG or XSD schema). >>>>>>=20 >>>>=20 >>>> A static off-line validation tool is limited in its inherent = capabilities. >>>> The protocol clearly defines the operations in terms of the >>>> behavior on the server and the target datastore. An offline tool >>>> cannot provide datastore validation without knowing what is in it. >>>>=20 >>>> .... >>>>>> Lada >>>>>>=20 >>>>>=20 >>>>=20 >>>> Andy >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sat Aug 11 12:51:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459FC21F8582 for ; Sat, 11 Aug 2012 12:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8qpumLBbHdM for ; Sat, 11 Aug 2012 12:51:58 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68A7E21F853B for ; Sat, 11 Aug 2012 12:51:58 -0700 (PDT) Received: by qadb17 with SMTP id b17so554572qad.10 for ; Sat, 11 Aug 2012 12:51:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=DLFPlvle3Pow0uaFOEjdeNfhYykocsPQG/jV94K0M8M=; b=mAN5gTA9MwxBncga921MXrc6VnkkM7xz5K0mHB1DBzDRLnfTnwiQ5Io+t2QIpr9OkX xjjX21aM7dE3lr1psir7fesQdS4G36/Mfysa5IUESaZFj4o2OKczMktKWF9CjwYPmsvp Rbg3RowA8qXtecjjeFnH6UqUEStt9zpzJCSAKdW75K6r94DI3TBRrw3AaniTQOuitoCM Tk6QFJIvWDzEgizKukXz3ye0KX18gasYLe8XiMa1X9wMKwoAsCxMGLSsdpljZnQzWAXu 7ncSo2jDA1P+3qkwplm0gT0QVRCVXOsICRt7p5vxXD3xTb9aNn/EWOAUVeJAABfreGpQ YGiw== MIME-Version: 1.0 Received: by 10.224.58.142 with SMTP id g14mr14934054qah.96.1344714717454; Sat, 11 Aug 2012 12:51:57 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Sat, 11 Aug 2012 12:51:57 -0700 (PDT) In-Reply-To: <4F60BB79-B200-4988-9C49-4C09576F968F@nic.cz> References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> <1611C3F1-68E3-4ECB-80AA-2E531B3BEADA@nic.cz> <4F60BB79-B200-4988-9C49-4C09576F968F@nic.cz> Date: Sat, 11 Aug 2012 12:51:57 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm9u28B9TbGMbqCnGUtdLGqhI/ZAC0FOxq8wDpXRgcjXUkT60U2XIylQvxt59HNqwRe7wc1 Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 19:51:59 -0000 The element is also defined in YANG as anyxml. Offline validation applies to input parameters. Those can always be validated offline because the instance document for the when-stmt evaluation is the request message. You are trying to apply the RPC input validation beyond what YANG defines. The NETCONF protocol operations require the input parameters to be conceptually applied to the current target datastore. The DSDL mapping works for detecting errors in RPC input and output. It does not work for validating the entire server operation if the current state of the target datastore needs to be known to support that operation. Andy On Sat, Aug 11, 2012 at 10:26 AM, Ladislav Lhotka wrote: > > On Aug 9, 2012, at 3:56 PM, Andy Bierman wrote: > >> Hi, >> >> Why are we debating an implementation detail? > > I have never mentioned any implementation in this thread. > >> There are lots of combinations where the when-stmt >> needs to be conceptually evaluated on a missing node >> to determine if that node is triggering an error or not. >> So what? We have the same situation with conceptual >> NP containers that contain default leafs: >> >> leaf if-foobar { >> when "../foobar"; >> type string; >> } >> >> container foobar { >> leaf def { >> type int32; >> default 42; >> } >> } >> >> The when-stmt is always true, whether the server >> has a /foobar node or not. It is an implementation >> detail. > > This case is not interesting because sec. 7.19.5 in RFC 6020 makes it ver= y clear that the accessible tree for 'when' evaluation contains all leafs w= ith default values. > > Defaults interact with 'when' in another problematic way though: > > leaf enable-foo { > type boolean; > } > leaf foo { > when "../enable-foo =3D 'true'"; > type uint8; > default 42; > } > > Consider this scenario: > > 1. Client A sets "enable-foo" to "false". > 2. Server deletes the leaf "foo". > 3. Client B issues a , asking for "foo". > 4. The response will contain no data. > > Now, can client B assume that "foo" effectively contains the default valu= e (42)? If not, why? > > The datastore schema is an important part of the contract between the ser= ver and client. If it was so, as you wrote, that the current schema can onl= y be determined on the server, the client couldn't sometimes correctly inte= rpret data obtained from the server. Therefore, I think that after finishin= g exchange *both* the server and client should be able to construct= the schema and it should be identical on both sides of the connection. > > So it is not about offline validation but rather about the contract and i= ts interpretation. I don't know why the client couldn't validate the conten= ts of a reply to or . > > Lada > >> >> >> Andy >> >> >> On Wed, Aug 8, 2012 at 9:49 PM, Ladislav Lhotka wrote: >>> >>> On Aug 9, 2012, at 12:49 AM, Jernej Tuljak wrote: >>> >>>> Are you sure that you used the correct example? Because it does not se= em consistent with what you are saying. Container foo is not mandatory.. An= d there's nothing wrong with an instance of enable-foo being present in a d= atastore without an instance of foo. There's no such constraint on the enab= le-foo leaf. It's just a plain old leaf. >>> >>> Container "foo" is mandatory due to Sec. 3.1 in RFC 6020 (third bullet)= . >>> >>> Lada >>> >>>> >>>> What you claim would hold if mandatory-stmt and when-stmt were used on= the same leaf. A server would delete such a leaf instance if it's when eva= luated to false..but doing so would be deleting a mandatory data node - lea= ving the datastore in an invalid state. Is this what you are saying? >>>> >>>> Jernej >>>> >>>> Dne 8. avg. 2012 22:04 je "Ladislav Lhotka" napisal/-a= : >>>> >>>> On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote: >>>> >>>>> ..... >>>>>>>>> OK, but what about this: >>>>>>>>> >>>>>>>>> leaf enable-foo { >>>>>>>>> type boolean; >>>>>>>>> } >>>>>>>>> container foo { >>>>>>>>> when "../enable-foo =3D 'true'"; >>>>>>>>> leaf bar { >>>>>>>>> type uint8; >>>>>>>>> mandatory true; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> Now, consider an instance document containing false >>>>>>>>> but not , i.e. the XPath context node is missing. Simple que= stion: is >>>>>>>>> this a valid document? If your answer is yes, could you explain h= ow the >>>>>>>>> validity follows from 6020? >>>>>>>>> >>>>> >>>>> I assume these are the contents of the node in an edit-confi= g >>>> >>>> To keep things simple, it could be the content of a . >>>> >>>>> operation. The edit-config operation and the when statement are very= clear >>>>> about when-stmts that are applied to the context node vs. >>>>> those which are applied to a conceptual datastore + state document. >>>>> >>>>> In your example, setting enable-foo=3Dfalse or deleting it will cause= the >>>>> /foo container to be deleted by the server. The YANG statements >>>>> like when/must apply to conceptual datastores, not to NETCONF >>>>> messages. >>>> >>>> If the server does this, the resulting datastore content is invalid be= cause from sec. 3.1 in 6020 it follows that the "foo" container is mandator= y. The 'when' statement cannot change this because its XPath expression has= no context node and is therefore undefined. >>>> >>>> >>>> Lada >>>> >>>>> >>>>> >>>>> >>>>>>>>> I think this is where Andy needs to temporarily insert as h= is dummy >>>>>>>>> element, which is however not "about to be created" as you write,= at least not >>>>>>>>> as a result of client's action. This has no support in 6020, the = alone XPath. >>>>>>>> >>>>>>>> Ok, I see your point. But this doesn't seem to be related to the >>>>>>>> original issue in this thread - that "when" somehow modifies the >>>>>>>> *schema tree*. >>>>>>> >>>>>>> Not schema tree but schema, with which one can check the structure = of an XML document without looking into element values of the validated doc= ument (think of a RELAX NG or XSD schema). >>>>>>> >>>>> >>>>> A static off-line validation tool is limited in its inherent capabili= ties. >>>>> The protocol clearly defines the operations in terms of the >>>>> behavior on the server and the target datastore. An offline tool >>>>> cannot provide datastore validation without knowing what is in it. >>>>> >>>>> .... >>>>>>> Lada >>>>>>> >>>>>> >>>>> >>>>> Andy >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Mon Aug 13 01:10:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE4021F85F4 for ; Mon, 13 Aug 2012 01:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXQI5YR547+B for ; Mon, 13 Aug 2012 01:10:32 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C18B021F863F for ; Mon, 13 Aug 2012 01:10:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 82EA454038E for ; Mon, 13 Aug 2012 10:10:29 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDiumujFyZiy for ; Mon, 13 Aug 2012 10:10:24 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id A36FB540246 for ; Mon, 13 Aug 2012 10:10:24 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> <1611C3F1-68E3-4ECB-80AA-2E531B3BEADA@nic.cz> <4F60BB79-B200-4988-9C49-4C09576F968F@nic.cz> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 13 Aug 2012 10:10:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 08:10:33 -0000 Andy Bierman writes: > The element is also defined in YANG as anyxml. > Offline validation applies to input parameters. > Those can always be validated offline > because the instance document for the when-stmt > evaluation is the request message. > > You are trying to apply the RPC input validation beyond > what YANG defines. The NETCONF protocol operations > require the input parameters to be conceptually applied > to the current target datastore. > > The DSDL mapping works for detecting errors in RPC input and output. > It does not work for validating the entire server operation if > the current state of the target datastore needs to be known to > support that operation. > This discussion doesn't lead anywhere because you keep repeating this offline validation thing. RFC 6020 provides, for the most part, validation rules for datastore contents, and I am discussing these rules rather than DSDL or offline validation. Specifically, I am trying to point to gaps and inconsistencies in the definition of 'when'. Lada > > > Andy > > > On Sat, Aug 11, 2012 at 10:26 AM, Ladislav Lhotka wrote: >> >> On Aug 9, 2012, at 3:56 PM, Andy Bierman wrote: >> >>> Hi, >>> >>> Why are we debating an implementation detail? >> >> I have never mentioned any implementation in this thread. >> >>> There are lots of combinations where the when-stmt >>> needs to be conceptually evaluated on a missing node >>> to determine if that node is triggering an error or not. >>> So what? We have the same situation with conceptual >>> NP containers that contain default leafs: >>> >>> leaf if-foobar { >>> when "../foobar"; >>> type string; >>> } >>> >>> container foobar { >>> leaf def { >>> type int32; >>> default 42; >>> } >>> } >>> >>> The when-stmt is always true, whether the server >>> has a /foobar node or not. It is an implementation >>> detail. >> >> This case is not interesting because sec. 7.19.5 in RFC 6020 makes it very clear that the accessible tree for 'when' evaluation contains all leafs with default values. >> >> Defaults interact with 'when' in another problematic way though: >> >> leaf enable-foo { >> type boolean; >> } >> leaf foo { >> when "../enable-foo = 'true'"; >> type uint8; >> default 42; >> } >> >> Consider this scenario: >> >> 1. Client A sets "enable-foo" to "false". >> 2. Server deletes the leaf "foo". >> 3. Client B issues a , asking for "foo". >> 4. The response will contain no data. >> >> Now, can client B assume that "foo" effectively contains the default value (42)? If not, why? >> >> The datastore schema is an important part of the contract between the server and client. If it was so, as you wrote, that the current schema can only be determined on the server, the client couldn't sometimes correctly interpret data obtained from the server. Therefore, I think that after finishing exchange *both* the server and client should be able to construct the schema and it should be identical on both sides of the connection. >> >> So it is not about offline validation but rather about the contract and its interpretation. I don't know why the client couldn't validate the contents of a reply to or . >> >> Lada >> >>> >>> >>> Andy >>> >>> >>> On Wed, Aug 8, 2012 at 9:49 PM, Ladislav Lhotka wrote: >>>> >>>> On Aug 9, 2012, at 12:49 AM, Jernej Tuljak wrote: >>>> >>>>> Are you sure that you used the correct example? Because it does not seem consistent with what you are saying. Container foo is not mandatory.. And there's nothing wrong with an instance of enable-foo being present in a datastore without an instance of foo. There's no such constraint on the enable-foo leaf. It's just a plain old leaf. >>>> >>>> Container "foo" is mandatory due to Sec. 3.1 in RFC 6020 (third bullet). >>>> >>>> Lada >>>> >>>>> >>>>> What you claim would hold if mandatory-stmt and when-stmt were used on the same leaf. A server would delete such a leaf instance if it's when evaluated to false..but doing so would be deleting a mandatory data node - leaving the datastore in an invalid state. Is this what you are saying? >>>>> >>>>> Jernej >>>>> >>>>> Dne 8. avg. 2012 22:04 je "Ladislav Lhotka" napisal/-a: >>>>> >>>>> On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote: >>>>> >>>>>> ..... >>>>>>>>>> OK, but what about this: >>>>>>>>>> >>>>>>>>>> leaf enable-foo { >>>>>>>>>> type boolean; >>>>>>>>>> } >>>>>>>>>> container foo { >>>>>>>>>> when "../enable-foo = 'true'"; >>>>>>>>>> leaf bar { >>>>>>>>>> type uint8; >>>>>>>>>> mandatory true; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Now, consider an instance document containing false >>>>>>>>>> but not , i.e. the XPath context node is missing. Simple question: is >>>>>>>>>> this a valid document? If your answer is yes, could you explain how the >>>>>>>>>> validity follows from 6020? >>>>>>>>>> >>>>>> >>>>>> I assume these are the contents of the node in an edit-config >>>>> >>>>> To keep things simple, it could be the content of a . >>>>> >>>>>> operation. The edit-config operation and the when statement are very clear >>>>>> about when-stmts that are applied to the context node vs. >>>>>> those which are applied to a conceptual datastore + state document. >>>>>> >>>>>> In your example, setting enable-foo=false or deleting it will cause the >>>>>> /foo container to be deleted by the server. The YANG statements >>>>>> like when/must apply to conceptual datastores, not to NETCONF >>>>>> messages. >>>>> >>>>> If the server does this, the resulting datastore content is invalid because from sec. 3.1 in 6020 it follows that the "foo" container is mandatory. The 'when' statement cannot change this because its XPath expression has no context node and is therefore undefined. >>>>> >>>>> >>>>> Lada >>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>> I think this is where Andy needs to temporarily insert as his dummy >>>>>>>>>> element, which is however not "about to be created" as you write, at least not >>>>>>>>>> as a result of client's action. This has no support in 6020, the alone XPath. >>>>>>>>> >>>>>>>>> Ok, I see your point. But this doesn't seem to be related to the >>>>>>>>> original issue in this thread - that "when" somehow modifies the >>>>>>>>> *schema tree*. >>>>>>>> >>>>>>>> Not schema tree but schema, with which one can check the structure of an XML document without looking into element values of the validated document (think of a RELAX NG or XSD schema). >>>>>>>> >>>>>> >>>>>> A static off-line validation tool is limited in its inherent capabilities. >>>>>> The protocol clearly defines the operations in terms of the >>>>>> behavior on the server and the target datastore. An offline tool >>>>>> cannot provide datastore validation without knowing what is in it. >>>>>> >>>>>> .... >>>>>>>> Lada >>>>>>>> >>>>>>> >>>>>> >>>>>> Andy >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Aug 13 02:00:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2B521F874C for ; Mon, 13 Aug 2012 02:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fVItYslHPoN for ; Mon, 13 Aug 2012 02:00:13 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBF721F874A for ; Mon, 13 Aug 2012 02:00:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2574354038E; Mon, 13 Aug 2012 11:00:12 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XxWvkjqVb0F; Mon, 13 Aug 2012 11:00:04 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C39235401C8; Mon, 13 Aug 2012 11:00:03 +0200 (CEST) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" In-Reply-To: <77F4DCD4-D344-4DC3-B1D5-779E2E7E9F93@cisco.com> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> <006701cd70b7$4f0b9e60$4001a8c0@gateway.2wire.net> <005a01cd7185$0fce9bc0$4001a8c0@gateway.2wire.net> <77F4DCD4-D344-4DC3-B1D5-779E2E7E9F93@cisco.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "Yi Yang \(yiya\)" , netmod@ietf.org Date: Mon, 13 Aug 2012 11:00:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 09:00:14 -0000 "Yi Yang (yiya)" writes: > Hi Ladislav, > >> Hi Tom, >> >> thank you for a detailed explanation. The moral of the story for me is that it is probably better to avoid FIB/RIB and use "routing table" everywhere, although it may look "less sophisticated". >> >> As for the term "forwarding table", it is used in this sense in Junos documentation: >> >> http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/routing-protocols-routing-databases-overview.html > > Even on the Juniper's webpage, the forwarding table and routing table have different meanings. They are close but different. > > For IOS world, the webpage may help you understand the difference between routing table and forwarding table. > http://blog.ioshints.info/2010/09/ribs-and-fibs.html Hmm, these definitions of RIB and FIB are clearly at odds with those advocated by Tom Petch. Oh well ... Lada > > Yi > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 13 07:54:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9F021F85F4 for ; Mon, 13 Aug 2012 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4Ih7pLdIZ63 for ; Mon, 13 Aug 2012 07:54:20 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D78C21F853F for ; Mon, 13 Aug 2012 07:54:20 -0700 (PDT) Received: by weyu54 with SMTP id u54so2923268wey.31 for ; Mon, 13 Aug 2012 07:54:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=Gwx6j3+8WH0R2JuJKYmGHfT3UiO23UfViFex2pJs+Ig=; b=gtKk0Ng2qA1K3EKFzpNnfHvv8uBXyGQQw1NoS1TRZafyp2cxH4QGosikdqPjV63yh0 1T3g+XHL8cK2gfNALi6H3xpQ0vpPZSB/qsZCL8AcfFA2ge1Xg103GJztjAnfuRhqd5t6 an+G19sM6CRVd+Wzk8ELEq0tOENhB9bFCK7Yn8iAQ7ePr+XgB0nLMegazWHfbDftd2HT 8ts++ujRJzRZzITviR1E+xFG6ep24RPUc9nK6gtqpTlGWkrWbM5jN+71d8rvKm1W1Dyr rGHD2/JD2ixgSnV3u/mujtEqyYi0DIbT8bf/gU2n6OKFprXW0+tzIlbtpaR2PxqmHwtZ SIeA== MIME-Version: 1.0 Received: by 10.50.88.229 with SMTP id bj5mr2942581igb.21.1344869658560; Mon, 13 Aug 2012 07:54:18 -0700 (PDT) Received: by 10.50.23.2 with HTTP; Mon, 13 Aug 2012 07:54:18 -0700 (PDT) In-Reply-To: References: <20120805.213825.278234967.mbj@tail-f.com> <20120806.221755.449072128.mbj@tail-f.com> <1611C3F1-68E3-4ECB-80AA-2E531B3BEADA@nic.cz> <4F60BB79-B200-4988-9C49-4C09576F968F@nic.cz> Date: Mon, 13 Aug 2012 07:54:18 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmvEhjl3iG/hXfpWtA/E6S26qg6q7EqBjQDwfeQ/c7FOoRZdQT62KJ/ZaucHr30TqnoDq9X Subject: Re: [netmod] XPath errors in ietf-snmp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:54:21 -0000 On Mon, Aug 13, 2012 at 1:10 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> The element is also defined in YANG as anyxml. >> Offline validation applies to input parameters. >> Those can always be validated offline >> because the instance document for the when-stmt >> evaluation is the request message. >> >> You are trying to apply the RPC input validation beyond >> what YANG defines. The NETCONF protocol operations >> require the input parameters to be conceptually applied >> to the current target datastore. >> >> The DSDL mapping works for detecting errors in RPC input and output. >> It does not work for validating the entire server operation if >> the current state of the target datastore needs to be known to >> support that operation. >> > > This discussion doesn't lead anywhere because you keep repeating this off= line validation thing. > > RFC 6020 provides, for the most part, validation rules for datastore cont= ents, and I am discussing these rules rather than DSDL or offline validatio= n. > > Specifically, I am trying to point to gaps and inconsistencies in the def= inition of 'when'. > I think the RFCs are quite clear. If the when-stmt applies to RPC input parameters, then the complete instance document is used for validation. If the when-stmt applies to a data node within a NETCONF datastore, then the complete conceptual datastore (plus all state) is used for validat= ion. Any tool that has access to this information can implement NETCONF. Martin pointed out that even if descendant-or-self nodes are referenced in a when-stmt, the server knows there are no instances of them, so even these XPath expressions can be conceptually evaluated. Please define the gaps and why a NETCONF server cannot be implemented because of these gaps. > Lada > Andy >> >> >> Andy >> >> >> On Sat, Aug 11, 2012 at 10:26 AM, Ladislav Lhotka wrote: >>> >>> On Aug 9, 2012, at 3:56 PM, Andy Bierman wrote: >>> >>>> Hi, >>>> >>>> Why are we debating an implementation detail? >>> >>> I have never mentioned any implementation in this thread. >>> >>>> There are lots of combinations where the when-stmt >>>> needs to be conceptually evaluated on a missing node >>>> to determine if that node is triggering an error or not. >>>> So what? We have the same situation with conceptual >>>> NP containers that contain default leafs: >>>> >>>> leaf if-foobar { >>>> when "../foobar"; >>>> type string; >>>> } >>>> >>>> container foobar { >>>> leaf def { >>>> type int32; >>>> default 42; >>>> } >>>> } >>>> >>>> The when-stmt is always true, whether the server >>>> has a /foobar node or not. It is an implementation >>>> detail. >>> >>> This case is not interesting because sec. 7.19.5 in RFC 6020 makes it v= ery clear that the accessible tree for 'when' evaluation contains all leafs= with default values. >>> >>> Defaults interact with 'when' in another problematic way though: >>> >>> leaf enable-foo { >>> type boolean; >>> } >>> leaf foo { >>> when "../enable-foo =3D 'true'"; >>> type uint8; >>> default 42; >>> } >>> >>> Consider this scenario: >>> >>> 1. Client A sets "enable-foo" to "false". >>> 2. Server deletes the leaf "foo". >>> 3. Client B issues a , asking for "foo". >>> 4. The response will contain no data. >>> >>> Now, can client B assume that "foo" effectively contains the default va= lue (42)? If not, why? >>> >>> The datastore schema is an important part of the contract between the s= erver and client. If it was so, as you wrote, that the current schema can o= nly be determined on the server, the client couldn't sometimes correctly in= terpret data obtained from the server. Therefore, I think that after finish= ing exchange *both* the server and client should be able to constru= ct the schema and it should be identical on both sides of the connection. >>> >>> So it is not about offline validation but rather about the contract and= its interpretation. I don't know why the client couldn't validate the cont= ents of a reply to or . >>> >>> Lada >>> >>>> >>>> >>>> Andy >>>> >>>> >>>> On Wed, Aug 8, 2012 at 9:49 PM, Ladislav Lhotka wrote: >>>>> >>>>> On Aug 9, 2012, at 12:49 AM, Jernej Tuljak wrote: >>>>> >>>>>> Are you sure that you used the correct example? Because it does not = seem consistent with what you are saying. Container foo is not mandatory.. = And there's nothing wrong with an instance of enable-foo being present in a= datastore without an instance of foo. There's no such constraint on the en= able-foo leaf. It's just a plain old leaf. >>>>> >>>>> Container "foo" is mandatory due to Sec. 3.1 in RFC 6020 (third bulle= t). >>>>> >>>>> Lada >>>>> >>>>>> >>>>>> What you claim would hold if mandatory-stmt and when-stmt were used = on the same leaf. A server would delete such a leaf instance if it's when e= valuated to false..but doing so would be deleting a mandatory data node - l= eaving the datastore in an invalid state. Is this what you are saying? >>>>>> >>>>>> Jernej >>>>>> >>>>>> Dne 8. avg. 2012 22:04 je "Ladislav Lhotka" napisal/= -a: >>>>>> >>>>>> On Aug 8, 2012, at 7:47 PM, Andy Bierman wrote: >>>>>> >>>>>>> ..... >>>>>>>>>>> OK, but what about this: >>>>>>>>>>> >>>>>>>>>>> leaf enable-foo { >>>>>>>>>>> type boolean; >>>>>>>>>>> } >>>>>>>>>>> container foo { >>>>>>>>>>> when "../enable-foo =3D 'true'"; >>>>>>>>>>> leaf bar { >>>>>>>>>>> type uint8; >>>>>>>>>>> mandatory true; >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Now, consider an instance document containing false= >>>>>>>>>>> but not , i.e. the XPath context node is missing. Simple q= uestion: is >>>>>>>>>>> this a valid document? If your answer is yes, could you explain= how the >>>>>>>>>>> validity follows from 6020? >>>>>>>>>>> >>>>>>> >>>>>>> I assume these are the contents of the node in an edit-con= fig >>>>>> >>>>>> To keep things simple, it could be the content of a . >>>>>> >>>>>>> operation. The edit-config operation and the when statement are ve= ry clear >>>>>>> about when-stmts that are applied to the context node vs. >>>>>>> those which are applied to a conceptual datastore + state document. >>>>>>> >>>>>>> In your example, setting enable-foo=3Dfalse or deleting it will cau= se the >>>>>>> /foo container to be deleted by the server. The YANG statements >>>>>>> like when/must apply to conceptual datastores, not to NETCONF >>>>>>> messages. >>>>>> >>>>>> If the server does this, the resulting datastore content is invalid = because from sec. 3.1 in 6020 it follows that the "foo" container is mandat= ory. The 'when' statement cannot change this because its XPath expression h= as no context node and is therefore undefined. >>>>>> >>>>>> >>>>>> Lada >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> I think this is where Andy needs to temporarily insert as= his dummy >>>>>>>>>>> element, which is however not "about to be created" as you writ= e, at least not >>>>>>>>>>> as a result of client's action. This has no support in 6020, th= e alone XPath. >>>>>>>>>> >>>>>>>>>> Ok, I see your point. But this doesn't seem to be related to th= e >>>>>>>>>> original issue in this thread - that "when" somehow modifies the >>>>>>>>>> *schema tree*. >>>>>>>>> >>>>>>>>> Not schema tree but schema, with which one can check the structur= e of an XML document without looking into element values of the validated d= ocument (think of a RELAX NG or XSD schema). >>>>>>>>> >>>>>>> >>>>>>> A static off-line validation tool is limited in its inherent capabi= lities. >>>>>>> The protocol clearly defines the operations in terms of the >>>>>>> behavior on the server and the target datastore. An offline tool >>>>>>> cannot provide datastore validation without knowing what is in it. >>>>>>> >>>>>>> .... >>>>>>>>> Lada >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Andy >>>>>> >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From ietfc@btconnect.com Tue Aug 14 03:40:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFF321F8549 for ; Tue, 14 Aug 2012 03:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[AWL=1.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 242+axLR1V7q for ; Tue, 14 Aug 2012 03:40:55 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33D1D21F8548 for ; Tue, 14 Aug 2012 03:40:54 -0700 (PDT) Received: from mail168-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 10:40:54 +0000 Received: from mail168-tx2 (localhost [127.0.0.1]) by mail168-tx2-R.bigfish.com (Postfix) with ESMTP id 779AA12027E; Tue, 14 Aug 2012 10:40:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT009.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zz9371I542M1432I179dNzz1202hzz8275ch1033IL8275eh8275bh8275dha1495iz2dh2a8h5a9h668h839hd24hf0ah107ah1177h304l) Received: from mail168-tx2 (localhost.localdomain [127.0.0.1]) by mail168-tx2 (MessageSwitch) id 1344940852495680_27810; Tue, 14 Aug 2012 10:40:52 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.244]) by mail168-tx2.bigfish.com (Postfix) with ESMTP id 6C8E58042F; Tue, 14 Aug 2012 10:40:52 +0000 (UTC) Received: from DB3PRD0702HT009.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 10:40:51 +0000 Received: from SN2PRD0710HT001.namprd07.prod.outlook.com (157.56.234.149) by pod51017.outlook.com (10.3.4.174) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 14 Aug 2012 10:40:39 +0000 Message-ID: <02f601cd7a08$9b6dbe00$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , "Yi Yang (yiya)" References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com><1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com><5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com><006701cd70b7$4f0b9e60$4001a8c0@gateway.2wire.net><005a01cd7185$0fce9bc0$4001a8c0@gateway.2wire.net><77F4DCD4-D344-4DC3-B1D5-779E2E7E9F93@cisco.com> Date: Tue, 14 Aug 2012 11:35:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.234.149] X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 10:40:56 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Yi Yang (yiya)" Cc: Sent: Monday, August 13, 2012 10:00 AM > "Yi Yang (yiya)" writes: > > > Hi Ladislav, > > > >> Hi Tom, > >> > >> thank you for a detailed explanation. The moral of the story for me is that it is probably better to avoid FIB/RIB and use "routing table" everywhere, although it may look "less sophisticated". > >> > >> As for the term "forwarding table", it is used in this sense in Junos documentation: > >> > >> http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/routing-p rotocols-routing-databases-overview.html > > > > Even on the Juniper's webpage, the forwarding table and routing table have different meanings. They are close but different. > > > > For IOS world, the webpage may help you understand the difference between routing table and forwarding table. > > http://blog.ioshints.info/2010/09/ribs-and-fibs.html > > Hmm, these definitions of RIB and FIB are clearly at odds with those advocated by Tom Petch. Oh well ... Yes:-( My definitions come, as you can see, from RFC and from I-Ds I expect to become RFC, ie they are IETF consensus documents, whereas the references above are to manufacturer documentation, in support of the sale and implementation of a particular manufacturer's products. The relationship of a manufacturer with standards is complex, typically adopting them when it helps their business model, ignoring them when it has the opposite effect. A WG has to decide which road to go down, but to use different terminology to the rest of the IETF does require justification, IMO. It happens, particularly between the low level, of IP and Routing, and the high level, Applications, but I do not think it ever helpful to those who want to use our standards. In the source referenced above, Juniper says "The Junos OS maintains two databases for routing information: Routing table-Contains all the routing information learned by all routing protocols. Forwarding table-Contains the routes actually used to forward packets through the router. In addition, the interior gateway protocols (IGPs), IS-IS, and OSPF maintain link-state databases." which, to someone familiar with routing protocols, looks a little odd. The OSPF protocol is about link state, used to build the link state database. Every so often, the SPF algorithm is used to generate best routes. Does this constitute "routing information learned by all routing protocols"? Strictly no, so where does it go? Direct into the Forwarding table if it is better than a RIP route? I cannot tell from this. Likewise, Juniper is unclear where the BGP learnt data goes, what is widely referred to as a RIB. That does fit the definition of 'Routing table' but it is odd that BGP, the most important routing protocol for the Internet, and its RIB, do not get a mention here. It is as if the focus is on an entry level router, linking LAN to WAN, not a high powered Internet router. The other web site says "I'm asked about the difference between Routing Information Base (RIB), also known as IP Routing Table ..." but then has a diagram of BGP table -> BGP process -> IP Routing Table which is a contradiction of every RFC on BGP that the IETF has ever produced; the BGP table is the RIB. And so on and so forth. Sources like these are fine for Routing 101, especially for a manufacturer promoting their products, but a Standards body should aim higher and be precise and consistent in its choice and use of terms. Tom Petch > Lada > > > > > Yi From lhotka@nic.cz Tue Aug 14 05:48:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3447A21F86E1 for ; Tue, 14 Aug 2012 05:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLjsl9VxjkOx for ; Tue, 14 Aug 2012 05:48:40 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CC74C21F86C5 for ; Tue, 14 Aug 2012 05:48:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A685A540436 for ; Tue, 14 Aug 2012 14:48:37 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M43rm7l70J5a for ; Tue, 14 Aug 2012 14:48:31 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 05A5854038E for ; Tue, 14 Aug 2012 14:48:30 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120730.152629.378501941.mbj@tail-f.com> References: <20120730.152629.378501941.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 14 Aug 2012 14:48:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] mbj review of draft-ietf-netmod-routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 12:48:41 -0000 Hi Martin, thank you for the review, see my replies inline. Martin Bjorklund writes: > > o 4. bullet 1 (after Figure 2) > > o Along with the main routing table, which must always be present, > an additional routing table is configured. > > What does "must always be present mean"? This needs to be > clarified. In my world, it should not be necessary to configure > this, so I assume it means that it always exists operationally, even > if it is not explicitly configured. My idea is that an implementation will preconfigure the main table and will not allow the client to delete it. A cleaner solution - given the current state of affairs - would be to have routing tables in two places, as state data and as configuration. But that would sort of defeat the proposed approach for state data that we discussed in Vancouver. Any suggestion? > > > o 4.1. > > It would be useful with a paragraph that explains that an > implementation doesn't have to support more than a single router > (i.e., no logical routers). OK. BTW, I will probably drop the term "logical router" entirely and use only. > > It would also be useful to include the text you wrote in > http://www.ietf.org/mail-archive/web/netmod/current/msg06845.html. OK. > > > o 4.3. > > Why is the main routing table's name only a SHOULD? If it not a > MUST, how will a client know which table is main? Some implementations may not have one "main" table, and may therefore want to adjust the naming. > > > o 4.3. > > The naming scheme for additional routing tables, as well as > restrictions on the number and configurability of routing tables are > implementation-specific. > > What does "restrictions on configurability" mean? It means, for example, that an implementation may not accept user-configured tables at all, or may limit their number. > > > o 4.4 > > Each routing protocol instance is connected to exactly one routing > table for each address family that the routing protocol instance > supports. > > How do I know which address families a routing protocol instance > supports? This is protocol-specific. For instance, in the static protocol it is implicitly indicated by the presence of the list of static routes within the corresponding container ("ipv4" or "ipv6"). > > > o 4.4.1 > > OLD: > > Every router instance MUST contain exactly one instance of the > "direct" pseudo-protocol type. The name of this instance MUST > also be "direct". > > > NEW: > > Every router instance MUST contain exactly one "routing-protocol" > instance of the "direct" pseudo-protocol type. The name of this > instance MUST also be "direct". > > What does this MUST mean? Do I have to configure this > routing-protocol instance? What happens if I try to delete it? > I assume that the "direct" protocol will not have any configuration - direct routes are configured as a result of IP configuration on an interface. In fact, the only place where the direct protocol may explicitly appear is the "source-protocol" attribute of routes. > Why is the name important? It is not important but since there is always exactly one instance it would only be confusing if the name was arbitrary. > > Isn't it better to state that if no routing-protocol instance of > type "direct" is configured, then all routes are sent to the main > routing table. Such routes will have the "source-protocol" attribute set to "direct". > > > o 4.4.1 > > A pseudo-protocol of the type "static" allows for specifying routes > manually. It MAY be configured in zero or multiple instances, > although a typical implementation will have exactly one instance per > logical router. > > Do you mean "typical configuration"? Yes, I will change it. > > > o 4.5 > > The default value for the route > filter type is the identity "deny-all-route-filter". > > I still think this is confusing and not necessary. If I define a > filter and leave out the type, the filter will block everything. I > think the result will be much more clear if the type is mandatory. > I.e., when a filter is defined, the type must also be specified. OK. > > > o 4.6. > > I think we should stop using the semi-formal notation of specifying > new rpcs. The YANG definition is supposed to capture all this > information in a more strict way. This only leads to duplicate text > and the opportunity for errors. In fact, the text, but not the YANG > module, was updated with the "error-tag" fix. > > I suggest you remove 4.6.1 and 4.6.2, and just provide a short > descrioption of these operations in 4.6. (and fix the text in the > YANG module). OK, will do. > > You also use the term "FIB" here, but "forwarding table" earlier. > Also, the rpc active-route says that is reads the route from the > FIB, but earlier you wrote that the FIB was optional. So this > should probably be rephrased. The acronym FIB is meant more dynamically here. Every IP box must be able to do routing, i.e. to find the active route for a given destination. However, it needn't be a simple lookup in a forwarding table - Linux, for example, has the "fib_lookup" function for this purpose. In the mean time, we had an interesting discussion about the definition of RIB and FIB. It seems it will be wise to avoid them entirely. > > > o 5.2 identity direct > > Move text from 4.4.1 to the description. Same for "static". OK. > > > o 5.2 identity deny-all-route-filter > > Should it be called "deny-all-routes"? > I don't know, but for an identity name I subjectively prefer "deny-all-route-filter". > > o 5.2. grouping afn-safi > > leaf address-family { > type ianaaf:address-family; > default "ipv4"; > > Is this default really appropriate? Isn't it better w/ no default? The advantage of having a default is that this info needn't be present in the configuration. It is not a big deal but I think it will prove practical though maybe not politically correct. > > > o 5.2. > > There are some single-qouted strings in descriptions that should be > changed to double-quoted strings (in all three modules). Why and where? I used single quotes for all quoting purposes in descriptions (which are enclosed in double quotes). > > > o 5.2. > > leaf name { > type string; > description > "The unique router name."; > } > > NEW: > > "An arbitrary name of the router instance."; OK. > > > o 5.2 > > leaf name { > type string; > description > "The name of the routing protocol instance."; > } > > NEW: > > "An arbitrary name of the routing protocol instance."; > OK. > OR: state that an implementation MAY restrict the allowed values of > this name (if this is what you meant). Not really, it's supposed to be an arbitrary name. > > > o 5.2. > > Currently you have: > > +--rw connected-routing-tables > | +--rw routing-table [name] > > Should the latter list be called "connected-routing-table" for > consistency with the rest of the model? IMO this way it also conveys the information that it is a reference to an existing routing table (leafref). > > The impressive "must" expression in this list uses a "rt:" prefix on > some nodes, but not all. I suggest you remove it from all nodes for > consistency. OK. > > > o 5.2. > > container static-routes { > must "../type='rt:static'" { > > This should be "when", not "must". See also 4.4.2 bullet 4! Apart from my reservations towards 'when', in this case I don't really see any benefit of doing so. The 'must' expression guarantees that "static-routes" are only configured for a "static" protocol. Why would somebody ever want to change the protocol type to something else than "static" and let the server delete the container? IMO this could only happen by mistake and therefore is not desirable. Am I missing something? Following Yi Yang's suggestion, I will add the "enabled" switch under "routing-protocol", so disabling a protocol instance can be easily done by setting this switch to "false". Regarding the fourth bullet in 4.4.2, it talks about an augment, so 'when' is the only option. > > > o 5.2. > > list routing-table { > key "name"; > description > "Each entry represents a routing table identified by the > 'name' key. All routes in a routing table must have the > same AFN and SAFI."; > > The last sentence has a "must" that doesn't make much sense, since > a route doesn't "uses afn-safi". The address family is implicit in every route - it follows from the address format. This description means that e.g. IPv4 and IPv6 routes cannot appear in the same table. > > NEW: > > 'name' key. All routes in a routing table have the > same AFN and SAFI."; OK, this is possible. > > > o 5.2 > > list route { > description > "A routing table entry. This data node must augmented > > s/must augmented/must be augmented/ OK. > > > o 5.2. > > leaf source-protocol { > type leafref { > path "/routing/router/routing-protocols/" > + "routing-protocol/name"; > } > > I think the leafref should be relative - otherwise you can point to > protocols in other logical routers. It was relative in a previous revision but now router instances needn't be isolated, so the possibility of a "foreign" source protocol is indeed open. Hmm, but we have no guarantee that the names of protocol instances are unique accross router instances - I have to think about it. > > The text says: > > This routing protocol must > be configured (automatically or manually) in the > device." > > so what happens if the routing protocol instance is removed? Will > all its routes be removed? Good question. I have to check the existing implementations but I think the routes should also be removed if their source disappears. > > > o 5.2 > > list recipient-routing-table { > ... > leaf name { > type leafref { > path "/routing/router/routing-tables/" > + "routing-table/name"; > } > > This should also be a relative path. It is the same as with "source-protocol". > > > o 7 > > Every implementation must preconfigure a routing table with the > name 'main-ipv4-unicast', which is the main routing table for > IPv4 unicast. > > This contraditcs the SHOULD on page 12. Right, the description has to say the same thing. > > > o 7 > > list route { > ... > leaf id { > type uint32 { > range "1..max"; > } > > Why do you have a numeric id if it is arbitrary? Why not a string? Why is a string better? > > > o 8 > > NOTE: Parameter 'is-router' is not included, it is expected > that it will be implemented by the 'ietf-ip' module. > > Remove this sentence, or rephrase. OK. > > > o 8 > > leaf min-rtr-adv-interval { > ... > description > "The minimum time allowed between sending unsolicited > multicast Router Advertisements from the interface. > > Must be no greater than 0.75 * max-rtr-adv-interval. > > > Make a "must" statement out if this constraint. OK. > > > o 8 > > leaf cur-hop-limit { > default "64"; > description > ... > The default should be set to the value specified in IANA > Assigned Numbers that was in effect at the time of > implementation. > > Either remove the default statement, or change the text. I would keep the default, the "Internet diameter" doesn't change that often. > > > o 8 > > leaf default-lifetime { > ... > The default value is dynamic and should be set to 3 * > max-rtr-adv-interval. > > I prefer to not use the term "dynamic default". I suggest this: > > If this leaf is not configured, the server uses the value > 3 * max-rtr-adv-interval. OK. Lada > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From xiangli@seguesoft.com Wed Aug 15 16:43:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F3911E8098 for ; Wed, 15 Aug 2012 16:43:40 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8EsocVan45s for ; Wed, 15 Aug 2012 16:43:39 -0700 (PDT) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by ietfa.amsl.com (Postfix) with SMTP id D13B911E808A for ; Wed, 15 Aug 2012 16:43:36 -0700 (PDT) Received: (qmail 27479 invoked from network); 15 Aug 2012 23:43:35 -0000 Received: from unknown (98.212.151.151) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 15 Aug 2012 23:43:35 -0000 Message-ID: <502C3427.4010501@seguesoft.com> Date: Wed, 15 Aug 2012 18:43:35 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netmod@ietf.org References: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> <20120614.095835.401067499.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC88ABD@xmb-sjc-239.amer.cisco.com> In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC88ABD@xmb-sjc-239.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Data model structure notation conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 23:43:40 -0000 Hi, These notation conventions are concise and work great but I think it may not be clear to someone who does not need to use pyang, but just need to read YANG modules. I think these notation need to be explained somewhere. Perhaps in the core system module? Then all other modules such as interface, routing etc. can simply refer to the definition there? Without this piece of information documented somewhere I don't think these draft yang module documents can be considered "complete". --Xiang Li On 6/14/2012 4:28 PM, Alexander Clemm (alex) wrote: > Thanks, Martin, for the explanation. > --- Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, June 14, 2012 12:59 AM > To: Alexander Clemm (alex) > Cc: netmod@ietf.org > Subject: Re: [netmod] Data model structure notation conventions > > Hi Alex, > > "Alexander Clemm (alex)" wrote: >> I have a question regarding the notation conventions with which the >> Internet Drafts provide an overview of the structure of YANG modules. >> (Example, section 3 in draft-ietf-netmod-interfaces-cfg-04) I really >> like that aspect of the Drafts a lot as it provides a very simple way > to >> visualize what is going on and look at the forest, not the trees. > Glad you like it; I use it all the time when I get (large) data models > to review and also during data model design. > >> I notice that "?" is used to indicate that a leaf is optional. What I > am >> wondering is why it was not instead decided to use "!" to indicate > that >> a leaf is mandatory. "Mandatory" was chosen as a substatement/keyword >> in YANG, not "optional", presumably because a much larger number of >> leaves would turn out to be optional than mandatory and hence a more >> compact specification would result. However, the same is true for the >> structure summary, where instead of appending most nodes with a "?", >> much fewer nodes could be appended with a "!" (and the connection with >> the corresponding YANG keywords would be more direct, not inversely >> direct, providing for slightly improved continuity). >> >> On similar lines, I am wondering whether it was considered to use a >> prefix when "config = false", instead of prepending every node with > "rw" >> or "ro" (the "r" itself looking redundant)? > Good points! The reson for this is that I really liked the -f tree > output from smidump, so I implemented -f tree in pyang, and I more or > less used the same notation as smidump. The '?' and '*' was used > simply b/c those are common symbols known to many people (from > regexps), as are rw/ro. > > > The complete syntax is: > > > > is one of: > + for current > x for deprecated > o for obsolete > > is one of: > rw for configuration data > ro for non-configuration data > -x for rpcs > -n for notifications > > is the name of the node > () means that the node is a choice node > :() means that the node is a case node > > If the node is augmented into the tree from another module, its > name is printed as :. > > is one of: > ? for an optional leaf or presence container > * for a leaf-list > [] for a list's keys > > is the name of the type for leafs and leaf-lists > > > > So this tree output is typically generated using pyang, and then > copied into the documents. > > > > pyang also has support for generating UML, javascript trees, and > hyperbolic trees from YANG modules. See > http://code.google.com/p/pyang/wiki/UMLOutput and > http://code.google.com/p/pyang/wiki/JSTreeandHyperTree for > screenshots. > > > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- --Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 Mobile: 1 (217) 472-4108 From mbj@tail-f.com Thu Aug 16 00:47:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A521921F8605 for ; Thu, 16 Aug 2012 00:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CpWT-dMLFtZ for ; Thu, 16 Aug 2012 00:47:36 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A43A321F858F for ; Thu, 16 Aug 2012 00:47:35 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A5D9C1200D40; Thu, 16 Aug 2012 09:47:33 +0200 (CEST) Date: Thu, 16 Aug 2012 09:47:33 +0200 (CEST) Message-Id: <20120816.094733.56975140704571591.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120730.152629.378501941.mbj@tail-f.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 07:47:36 -0000 Ladislav Lhotka wrote: > Hi Martin, > > thank you for the review, see my replies inline. > > Martin Bjorklund writes: > > > > > o 4. bullet 1 (after Figure 2) > > > > o Along with the main routing table, which must always be present, > > an additional routing table is configured. > > > > What does "must always be present mean"? This needs to be > > clarified. In my world, it should not be necessary to configure > > this, so I assume it means that it always exists operationally, even > > if it is not explicitly configured. > > My idea is that an implementation will preconfigure the main table and > will not allow the client to delete it. > > A cleaner solution - given the current state of affairs - would be to > have routing tables in two places, as state data and as > configuration. But that would sort of defeat the proposed approach for > state data that we discussed in Vancouver. Any suggestion? I think the data model should not be duplicated, and it should not be necessary to configure the main routing table. If it is not explicitly configured, it operationally exists within the system. Once configured, it can be referenced in leafrefs etc. > > o 4.3. > > > > The naming scheme for additional routing tables, as well as > > restrictions on the number and configurability of routing tables are > > implementation-specific. > > > > What does "restrictions on configurability" mean? > > It means, for example, that an implementation may not accept > user-configured tables at all, or may limit their number. This should be clarified. > > o 4.4.1 > > > > OLD: > > > > Every router instance MUST contain exactly one instance of the > > "direct" pseudo-protocol type. The name of this instance MUST > > also be "direct". > > > > > > NEW: > > > > Every router instance MUST contain exactly one "routing-protocol" > > instance of the "direct" pseudo-protocol type. The name of this > > instance MUST also be "direct". > > > > What does this MUST mean? Do I have to configure this > > routing-protocol instance? What happens if I try to delete it? > > > > I assume that the "direct" protocol will not have any configuration - > direct routes are configured as a result of IP configuration on an > interface. In fact, the only place where the direct protocol may > explicitly appear is the "source-protocol" attribute of routes. If it doesn't have any configuration, why is it a MUST to configure it? > > Why is the name important? > > It is not important but since there is always exactly one instance it > would only be confusing if the name was arbitrary. Ok, but this seems to be a CLR... > > Isn't it better to state that if no routing-protocol instance of > > type "direct" is configured, then all routes are sent to the main > > routing table. > > Such routes will have the "source-protocol" attribute set to "direct". Ok, so you mean that since source-protocol is a leafref it must be configured? Hmm - this might work better with the introduction of "operational state"... > > o 5.2. grouping afn-safi > > > > leaf address-family { > > type ianaaf:address-family; > > default "ipv4"; > > > > Is this default really appropriate? Isn't it better w/ no default? > > The advantage of having a default is that this info needn't be present > in the configuration. Sure, but it is not configured in "many" places, and w/o a default the config is more explict. Also, if you don't look at the data model, it is not obvious if the default is ipv4 or ipv6. > > o 5.2. > > > > There are some single-qouted strings in descriptions that should be > > changed to double-quoted strings (in all three modules). > > Why and where? I used single quotes for all quoting purposes in > descriptions (which are enclosed in double quotes). [grep "';" *.yang] /routing/router/description: description 'Each list entry is a container for configuration and ipv4/route/id description 'Numeric identifier of the route. ipv6/route/id description 'Numeric identifier of the route. > > o 5.2. > > > > container static-routes { > > must "../type='rt:static'" { > > > > This should be "when", not "must". See also 4.4.2 bullet 4! > > Apart from my reservations towards 'when', in this case I don't really > see any benefit of doing so. The 'must' expression guarantees that > "static-routes" are only configured for a "static" protocol. Why would > somebody ever want to change the protocol type to something else than > "static" This is why "when" is better. The container is valid only when the type is static. So if the type is not static, it should not even be possible to configure static routes. Imagine a client application with drop-down menus for these additional per-type containers. With "when" statements, the client application can adjust the available choices to what makes sense for the specific type. > Regarding the fourth bullet in 4.4.2, it talks about an augment, so > 'when' is the only option. You have chosen to inline the definition of static routes, but it could as well have been done in a separate module, and if so, you would have used "when" - so it makes sense to use "when" even though you inline the definition. > > o 5.2. > > > > leaf source-protocol { > > type leafref { > > path "/routing/router/routing-protocols/" > > + "routing-protocol/name"; > > } > > > > I think the leafref should be relative - otherwise you can point to > > protocols in other logical routers. > > It was relative in a previous revision but now router instances > needn't be isolated, so the possibility of a "foreign" source protocol > is indeed open. Hmm, but we have no guarantee that the names of > protocol instances are unique accross router instances Exactly. So you would have to have a second leafref to the router name as well. > > o 7 > > > > list route { > > ... > > leaf id { > > type uint32 { > > range "1..max"; > > } > > > > Why do you have a numeric id if it is arbitrary? Why not a string? > > Why is a string better? It gives the user more flexibility in finding a unique and maybe descriptive name. /martin From lhotka@nic.cz Thu Aug 16 09:34:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424BA21F854A for ; Thu, 16 Aug 2012 09:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlVUooj1a4wn for ; Thu, 16 Aug 2012 09:34:34 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7521F84FB for ; Thu, 16 Aug 2012 09:34:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 781625402F9 for ; Thu, 16 Aug 2012 18:34:32 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnqFyUFcRneJ for ; Thu, 16 Aug 2012 18:34:24 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E43E0540246 for ; Thu, 16 Aug 2012 18:34:23 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120816.094733.56975140704571591.mbj@tail-f.com> References: <20120730.152629.378501941.mbj@tail-f.com> <20120816.094733.56975140704571591.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Thu, 16 Aug 2012 18:34:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] mbj review of draft-ietf-netmod-routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:34:35 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Hi Martin, >> >> thank you for the review, see my replies inline. >> >> Martin Bjorklund writes: >> >> > >> > o 4. bullet 1 (after Figure 2) >> > >> > o Along with the main routing table, which must always be present, >> > an additional routing table is configured. >> > >> > What does "must always be present mean"? This needs to be >> > clarified. In my world, it should not be necessary to configure >> > this, so I assume it means that it always exists operationally, even >> > if it is not explicitly configured. >> >> My idea is that an implementation will preconfigure the main table and >> will not allow the client to delete it. >> >> A cleaner solution - given the current state of affairs - would be to >> have routing tables in two places, as state data and as >> configuration. But that would sort of defeat the proposed approach for >> state data that we discussed in Vancouver. Any suggestion? > > I think the data model should not be duplicated, and it should not be > necessary to configure the main routing table. If it is not > explicitly configured, it operationally exists within the system. > Once configured, it can be referenced in leafrefs etc. Do you mean the draft should state that the main table always exists as operational state data but these state data are not present in the data model? It would be actually more logical to let the leafrefs point to tables within state data because routing protocols are connected to routing tables, not to their configuration. > >> > o 4.3. >> > >> > The naming scheme for additional routing tables, as well as >> > restrictions on the number and configurability of routing tables are >> > implementation-specific. >> > >> > What does "restrictions on configurability" mean? >> >> It means, for example, that an implementation may not accept >> user-configured tables at all, or may limit their number. > > This should be clarified. OK, will try. > >> > o 4.4.1 >> > >> > OLD: >> > >> > Every router instance MUST contain exactly one instance of the >> > "direct" pseudo-protocol type. The name of this instance MUST >> > also be "direct". >> > >> > >> > NEW: >> > >> > Every router instance MUST contain exactly one "routing-protocol" >> > instance of the "direct" pseudo-protocol type. The name of this >> > instance MUST also be "direct". >> > >> > What does this MUST mean? Do I have to configure this >> > routing-protocol instance? What happens if I try to delete it? >> > >> >> I assume that the "direct" protocol will not have any configuration - >> direct routes are configured as a result of IP configuration on an >> interface. In fact, the only place where the direct protocol may >> explicitly appear is the "source-protocol" attribute of routes. > > If it doesn't have any configuration, why is it a MUST to configure > it? The text doesn't say that it MUST be configured (by a client) but rather that it MUST exist - it is the same as with the main routing table. We badly need a better model for the dual character of such objects that essentially exist as operational state data but may also be configured. > >> > Why is the name important? >> >> It is not important but since there is always exactly one instance it >> would only be confusing if the name was arbitrary. > > Ok, but this seems to be a CLR... Well, I think it is better to be able to immediately identify direct routes in routing tables by the value of "source-protocol" (= "direct"). I see no sane reason why an implementor might want another name. > >> > Isn't it better to state that if no routing-protocol instance of >> > type "direct" is configured, then all routes are sent to the main >> > routing table. >> >> Such routes will have the "source-protocol" attribute set to "direct". > > Ok, so you mean that since source-protocol is a leafref it must be > configured? Hmm - this might work better with the introduction of > "operational state"... Exactly, the same story again. > > >> > o 5.2. grouping afn-safi >> > >> > leaf address-family { >> > type ianaaf:address-family; >> > default "ipv4"; >> > >> > Is this default really appropriate? Isn't it better w/ no default? >> >> The advantage of having a default is that this info needn't be present >> in the configuration. > > Sure, but it is not configured in "many" places, and w/o a default the > config is more explict. Also, if you don't look at the data model, it > is not obvious if the default is ipv4 or ipv6. It will usually be quite obvious, e.g. from the format of addresses. But I have no strong opinion on this, so I'd like to hear other voices, if somebody else has read this far. :-) > >> > o 5.2. >> > >> > There are some single-qouted strings in descriptions that should be >> > changed to double-quoted strings (in all three modules). >> >> Why and where? I used single quotes for all quoting purposes in >> descriptions (which are enclosed in double quotes). > > [grep "';" *.yang] > > > /routing/router/description: > > description > 'Each list entry is a container for configuration and > > > ipv4/route/id > > description > 'Numeric identifier of the route. > > ipv6/route/id > > description > 'Numeric identifier of the route. > OK, I thought you meant single-quoted strings *inside* descriptions. I will fix it. >> > o 5.2. >> > >> > container static-routes { >> > must "../type='rt:static'" { >> > >> > This should be "when", not "must". See also 4.4.2 bullet 4! >> >> Apart from my reservations towards 'when', in this case I don't really >> see any benefit of doing so. The 'must' expression guarantees that >> "static-routes" are only configured for a "static" protocol. Why would >> somebody ever want to change the protocol type to something else than >> "static" > > This is why "when" is better. The container is valid only when the > type is static. So if the type is not static, it should not even be > possible to configure static routes. Imagine a client application It won't be possible with "must" either. > with drop-down menus for these additional per-type containers. With > "when" statements, the client application can adjust the available > choices to what makes sense for the specific type. But it can do so even with "must", can't it? As far as I can tell, the real difference between "must" and "when" is in the server behaviour if a client tries to change the value of "../type" from "static" to something else (which IMO could only happen by mistake). With "must", the server will reject this change, whereas with "when" it will accept it and, as a side effect, also delete the "static-routes" container with all its contents. I don't like the latter scenario at all, however improbable it may be. Randy Presuhn advocated "when" as a means for enabling hot-swap or hot-insertion of components and subsystems, but I don't think it can really be used for this: A hot-inserted component may induce some changes in operational state data which are however not accessible for "when" statements within the config=true tree. Moreover, I don't think it is generally desirable to remove *configuration* of a component that has been removed. It is OK to remove operational state data owned by that component, but not necessarily configuration. So I guess we are back to the issue of operational state data versus configuration, surprise, surprise ... > >> Regarding the fourth bullet in 4.4.2, it talks about an augment, so >> 'when' is the only option. > > You have chosen to inline the definition of static routes, but it > could as well have been done in a separate module, and if so, you > would have used "when" - so it makes sense to use "when" even though > you inline the definition. For me it makes sense to take advantage of the fact that it is inline and completely eliminate the auto-deletion scenario. > >> > o 5.2. >> > >> > leaf source-protocol { >> > type leafref { >> > path "/routing/router/routing-protocols/" >> > + "routing-protocol/name"; >> > } >> > >> > I think the leafref should be relative - otherwise you can point to >> > protocols in other logical routers. >> >> It was relative in a previous revision but now router instances >> needn't be isolated, so the possibility of a "foreign" source protocol >> is indeed open. Hmm, but we have no guarantee that the names of >> protocol instances are unique accross router instances > > Exactly. So you would have to have a second leafref to the router > name as well. Or I could re-introduce my esoteric "unique" statement that stirred such a lively discussion few months ago. :-) > >> > o 7 >> > >> > list route { >> > ... >> > leaf id { >> > type uint32 { >> > range "1..max"; >> > } >> > >> > Why do you have a numeric id if it is arbitrary? Why not a string? >> >> Why is a string better? > > It gives the user more flexibility in finding a unique and maybe > descriptive name. Hmm, imagine you have a list of a few thousand routes - finding a fresh key might be a challenge, no matter what the datatype. It would be neat if we could leave the assigment of such keys to the server. Lada > > > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From wjhns1@hardakers.net Mon Aug 20 14:21:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A3F11E8091 for ; Mon, 20 Aug 2012 14:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtWN6yDj0mVS for ; Mon, 20 Aug 2012 14:21:16 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0748211E808D for ; Mon, 20 Aug 2012 14:21:14 -0700 (PDT) Received: from localhost (wjhw.hardakers.net [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id 44DE94A6 for ; Mon, 20 Aug 2012 14:21:14 -0700 (PDT) From: Wes Hardaker To: netmod@ietf.org Date: Mon, 20 Aug 2012 14:21:13 -0700 Message-ID: <0lwr0tdzue.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 21:21:18 -0000 I've reviewed the non-yang-module sections of the routing-cfg file. I think I'd really need another read to fully absorb it all. But in the mean time, I have the following concerns/questions/suggestions: 1) section 4.1, this text is really not needed: Apart from the key, each entry of the "rt:interface" list MAY contain other configuration or operational state data related to the corresponding router interface. That's really the whole point of netconf/netmod in the first place: nearly anything may contain more data. If you're stating that future sections will conditionally add more data to this section, then I'd suggest being more explicit about that. 2) section 4.2 should probably include RPKI status, as should another of other references to it (eg, the active-route RPC). At a minimum, I'd suggest listing 3 RPKI result status types: "unknown", "valid" and "invalid". 3) for 4.3, I had the same question previously discussed: why wouldn't "main-ipv4-unicast" and "main-ipv6-unicast" naming be a MUST. I'm trying to envision writing a manager that can take the config and do something like draw a pretty diagram based on what I pull in, and without a starting point I have to make educated guesses about what a vendor might have intended by a random label such as "myroutes", and these guesses will most likely be incorrect. Interoperability, IMHO, will fail if we don't have a standard starting container name. It doesn't prevent you from having others, if implementations need more than one. 4) section 4.3 says that additional routing tables are implementation-specific. I'd add "and/or configuration-specific". 5) 4.4.1: I'd also argue that "a typical implementation will have exactly one instance per logical router" should be "a typical configuration..." 6) 4.4.1: ' "rt:route" inside "rt:routing-table" ' would be better expressed as simply a full path. 7) 4.4.2: the 'tag' is a uint16, and I think it should be a uint32. Although current RIP defines a uint16, it doesn't make sense to limit the data model to uint16 if a future version may rev the protocol to allow for uint32 tag space. See the discussion surrounding the configuration of SNMP data lengths recently discussed here :-) 8) Similar for the range 10..60 for the update-interval. I actually wonder if vendors have allowed for shorter/longer update intervals in their implementations in places. I don't know, so I'll defer to your judgment, of course, but I thought I'd mention it for consideration. 9) 5.1: so if if:enabled is changed to 'false', then all configuration is dropped? Disabled? vendor-specific-decision? The way the text is now, I'd argue it's vendor-specific but clarity might be a good thing. 10) 5.2: The way I read the final paragraph, it means that if I have a manually configured change to the routing configuration such that I've modified a direct route in the main routing table to redirect it, then the instant the interface's netmask, for example, is reduced then it'll reset my original configuration change to the default outgoing interface output? Or is the direct route in the main routing table read-only and the only way to modify it would be to inject a manual static route that would take precedence? -- Wes Hardaker SPARTA, Inc. From lhotka@nic.cz Tue Aug 21 08:59:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5CC21F8799 for ; Tue, 21 Aug 2012 08:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X37bFKWp0iuQ for ; Tue, 21 Aug 2012 08:59:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 990A721F879B for ; Tue, 21 Aug 2012 08:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9E4CB540436 for ; Tue, 21 Aug 2012 17:58:54 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G80wNmYaOGo3 for ; Tue, 21 Aug 2012 17:58:50 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 426CF54004E for ; Tue, 21 Aug 2012 17:58:49 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <0lwr0tdzue.fsf@wjh.hardakers.net> References: <0lwr0tdzue.fsf@wjh.hardakers.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 21 Aug 2012 17:58:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:59:00 -0000 Hi Wes, thanks for the review, my responses are inline. Wes Hardaker writes: > I've reviewed the non-yang-module sections of the routing-cfg file. I > think I'd really need another read to fully absorb it all. But in the > mean time, I have the following concerns/questions/suggestions: > > 1) section 4.1, this text is really not needed: > > Apart from the key, each entry of the "rt:interface" list MAY contain > other configuration or operational state data related to the > corresponding router interface. > > That's really the whole point of netconf/netmod in the first place: > nearly anything may contain more data. If you're stating that future > sections will conditionally add more data to this section, then I'd > suggest being more explicit about that. You are right. Actually, the point to explain here is that "rt:interface" is modelled as a list rather than a leaf-list in order to allow for augmenting the entries with other stuff. > > 2) section 4.2 should probably include RPKI status, as should another of > other references to it (eg, the active-route RPC). At a minimum, > I'd suggest listing 3 RPKI result status types: "unknown", "valid" > and "invalid". I think this attribute should be augmented in from a separate RPKI module (remember the DHCP discussion in Vancouver). We only have static routes so far and for them RPKI makes no sense. > > 3) for 4.3, I had the same question previously discussed: why wouldn't > "main-ipv4-unicast" and "main-ipv6-unicast" naming be a MUST. I'm > trying to envision writing a manager that can take the config and do > something like draw a pretty diagram based on what I pull in, and > without a starting point I have to make educated guesses about what a > vendor might have intended by a random label such as "myroutes", and > these guesses will most likely be incorrect. Interoperability, IMHO, > will fail if we don't have a standard starting container name. It > doesn't prevent you from having others, if implementations need more > than one. OK, if there are no objections, I will make it a MUST. > > 4) section 4.3 says that additional routing tables are > implementation-specific. I'd add "and/or configuration-specific". Martin asked about that paragraph in his review. It is intended to say that implementations may decide (i) to add other "system" routing tables that cannot be deleted, and (ii) to provide (or not) the option of user-configured tables. I will clarify the text. > > 5) 4.4.1: I'd also argue that "a typical implementation will have > exactly one instance per logical router" should be "a typical > configuration..." Yes, Martin also had this comment. > > 6) 4.4.1: ' "rt:route" inside "rt:routing-table" ' would be better > expressed as simply a full path. OK, it still fits the line length limit: /rt:routing/rt:router/rt:routing-tables/rt:routing-table/rt:route > > 7) 4.4.2: the 'tag' is a uint16, and I think it should be a uint32. > Although current RIP defines a uint16, it doesn't make sense to limit > the data model to uint16 if a future version may rev the protocol to > allow for uint32 tag space. See the discussion surrounding the > configuration of SNMP data lengths recently discussed here :-) Appendix E says that the "example-rip" module is intended only as an illustration rather than a real definition of a data model for the RIP routing protocol. So I think this doesn't really matter. > > 8) Similar for the range 10..60 for the update-interval. I actually > wonder if vendors have allowed for shorter/longer update intervals in > their implementations in places. I don't know, so I'll defer to your > judgment, of course, but I thought I'd mention it for consideration. Ditto. > > 9) 5.1: so if if:enabled is changed to 'false', then all configuration > is dropped? Disabled? vendor-specific-decision? The way the text > is now, I'd argue it's vendor-specific but clarity might be a good > thing. The text says: If this switch is set to "false" for a given network layer interface, the device MUST behave exactly as if that interface was not assigned to any logical router at all. Nothing about dropping any configuration (there is no "when" statement based on "if:enabled"). > > 10) 5.2: The way I read the final paragraph, it means that if I have a > manually configured change to the routing configuration such that > I've modified a direct route in the main routing table to redirect > it, then the instant the interface's netmask, for example, is > reduced then it'll reset my original configuration change to the > default outgoing interface output? Or is the direct route in the > main routing table read-only and the only way to modify it would be > to inject a manual static route that would take precedence? It is the latter. Direct routes are operational state resulting from IP configuration on interfaces. Within the routing module, the only configurable part is that the "direct" pseudo-protocol may be reconnected to a "non-main" routing table. Lada > > -- > Wes Hardaker > SPARTA, Inc. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 21 09:08:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650C621F86C3 for ; Tue, 21 Aug 2012 09:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhbSslq9tKdx for ; Tue, 21 Aug 2012 09:08:58 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB0D721F86AF for ; Tue, 21 Aug 2012 09:08:55 -0700 (PDT) Received: by qcac10 with SMTP id c10so5890796qca.31 for ; Tue, 21 Aug 2012 09:08:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=19U83J8Jw7Si3DmabqAm+0jJSM631ld4jEKzIozMpT0=; b=eVroePEq02kaZ0Cr4Sbqj9tY/Pdw5Fyv3/MO1urOuNx5iF6d7PCLatYdroVL/cfByh jrtShHSNmu0tmH3JctWtgTqDon+p60wdQaG7gTwnCwPdHXt/Ul0CWjN52GRwZBEkXsJG wPbtkcaH5Vma63QJxpatMyqGhE9m1ldC5ai20Z5efzp+OXoAT9OgnXr3zIysRv7XP33g pH3bGiT4ba+n6CdYRIDX5KPLioXUm/Vup3Jkg1SCTcUn+Q/v8RKmtERYGQ+Nqx2HO2t5 S1Mh9aoVsLqrtYiOJWQ7v8gzpn3KaHOErWcVxx2mY0BEUyEeYLfTZW0UW4SaO5HV7WvB xdTQ== MIME-Version: 1.0 Received: by 10.224.44.202 with SMTP id b10mr5076897qaf.2.1345565335186; Tue, 21 Aug 2012 09:08:55 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Tue, 21 Aug 2012 09:08:55 -0700 (PDT) In-Reply-To: References: <0lwr0tdzue.fsf@wjh.hardakers.net> Date: Tue, 21 Aug 2012 09:08:55 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmMELkncgjMESFU2T8jUzjDlOUbYnwvI9NaG6yWMkjkriZTQGvlrIODqNkLOR3gd8gAdb0c Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:08:58 -0000 On Tue, Aug 21, 2012 at 8:58 AM, Ladislav Lhotka wrote: > Hi Wes, > .... >> >> 3) for 4.3, I had the same question previously discussed: why wouldn't >> "main-ipv4-unicast" and "main-ipv6-unicast" naming be a MUST. I'm >> trying to envision writing a manager that can take the config and do >> something like draw a pretty diagram based on what I pull in, and >> without a starting point I have to make educated guesses about what a >> vendor might have intended by a random label such as "myroutes", and >> these guesses will most likely be incorrect. Interoperability, IMHO, >> will fail if we don't have a standard starting container name. It >> doesn't prevent you from having others, if implementations need more >> than one. > > OK, if there are no objections, I will make it a MUST. It appears you are introducing a "YANG identifier CLR". IMO this is a really bad idea. Introducing any sort of structure into identifier strings is a bad idea, let alone a SHOULD or MUST requirement. If this issue is something else then ignore this comment ;-) > >> > Lada > Andy From lhotka@nic.cz Tue Aug 21 11:07:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8142F21F86AD for ; Tue, 21 Aug 2012 11:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dHpb+AxjWNx for ; Tue, 21 Aug 2012 11:07:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 94C9521F8688 for ; Tue, 21 Aug 2012 11:07:31 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7433D13F682; Tue, 21 Aug 2012 20:07:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1345572450; bh=0DTPtt3qYGZKdoNas0xRjYAkPutUeohfQblfgANvGcU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Jt8rYDidZYzff+vsb0g4JgJva/PwYfU7W3jFyY4g4t9twQJN6XvBEGF+gM1mpKyIl hw1xZkW0cFHnfQT9w1MbUxe1I/G62Cjdd6gr+CN9MoDsPMAOUiJ7O0hYzh1t+9X15Q N2xKuR1Fi/rn+60+2/sMNkDMVIfCxVgkhBYtWRGE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 21 Aug 2012 20:07:29 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <0lwr0tdzue.fsf@wjh.hardakers.net> To: Andy Bierman X-Mailer: Apple Mail (2.1485) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 18:07:32 -0000 On Aug 21, 2012, at 6:08 PM, Andy Bierman wrote: > On Tue, Aug 21, 2012 at 8:58 AM, Ladislav Lhotka wrote: >> Hi Wes, >> > .... >>> >>> 3) for 4.3, I had the same question previously discussed: why wouldn't >>> "main-ipv4-unicast" and "main-ipv6-unicast" naming be a MUST. I'm >>> trying to envision writing a manager that can take the config and do >>> something like draw a pretty diagram based on what I pull in, and >>> without a starting point I have to make educated guesses about what a >>> vendor might have intended by a random label such as "myroutes", and >>> these guesses will most likely be incorrect. Interoperability, IMHO, >>> will fail if we don't have a standard starting container name. It >>> doesn't prevent you from having others, if implementations need more >>> than one. >> >> OK, if there are no objections, I will make it a MUST. > > It appears you are introducing a "YANG identifier CLR". > IMO this is a really bad idea. Introducing any sort of > structure into identifier strings is a bad idea, let alone > a SHOULD or MUST requirement. So what do you suggest? Lada > > If this issue is something else then ignore this comment ;-) > > >> >>> >> Lada >> > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 21 11:29:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4954521F86C3 for ; Tue, 21 Aug 2012 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC5RGZh+ZBhD for ; Tue, 21 Aug 2012 11:29:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6364221F86DE for ; Tue, 21 Aug 2012 11:29:34 -0700 (PDT) Received: by qcac10 with SMTP id c10so91263qca.31 for ; Tue, 21 Aug 2012 11:29:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=n8dEslg41iTdj3yS8YhMmqXOirhnLLnX1wAdyhRLomc=; b=hEI8bhvT5n7oPefR7DRX0xb+Dn/W3RbRs2PXJmANayDag81gIbkzJaIUGd0/mURKli l7guNiZPiv6RRKLWeptogsz9mzotbYTFG7pSKcynQDI0ku72SaXNhiL6wII64W+BYDvb iTuhm1YIZ6kt/Vs7CfDEuBx+5XTWuOkrDTQw9RI89OvoZSAKdqIRivVKTSjeaGFVdAB6 wJ85gw/EsfEqjKzTX3+DtVcWu8IggCtE+r47A+n2BcC071tZTcV3fGy8qvoCesiiGG1D 5ZAmBuz/3589sFVKohN01fU8f6KP59Hp8K4nUKvwUgGVleV8neMGaq1H8kxiTwsSU0jb hW9A== MIME-Version: 1.0 Received: by 10.229.137.18 with SMTP id u18mr15273360qct.22.1345573773584; Tue, 21 Aug 2012 11:29:33 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Tue, 21 Aug 2012 11:29:33 -0700 (PDT) In-Reply-To: References: <0lwr0tdzue.fsf@wjh.hardakers.net> Date: Tue, 21 Aug 2012 11:29:33 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm+UfTGurGxZnhvpCdC9w6tO3QaxD2vxOalKV2epuzG3wpUXrhH3BMPJezy+MLShDoQGXYf Cc: netmod@ietf.org Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 18:29:35 -0000 On Tue, Aug 21, 2012 at 11:07 AM, Ladislav Lhotka wrote: > > On Aug 21, 2012, at 6:08 PM, Andy Bierman wrote: > >> On Tue, Aug 21, 2012 at 8:58 AM, Ladislav Lhotka wrote: >>> Hi Wes, >>> >> .... >>>> >>>> 3) for 4.3, I had the same question previously discussed: why wouldn't >>>> "main-ipv4-unicast" and "main-ipv6-unicast" naming be a MUST. I'm >>>> trying to envision writing a manager that can take the config and do >>>> something like draw a pretty diagram based on what I pull in, and >>>> without a starting point I have to make educated guesses about what a >>>> vendor might have intended by a random label such as "myroutes", and >>>> these guesses will most likely be incorrect. Interoperability, IMHO, >>>> will fail if we don't have a standard starting container name. It >>>> doesn't prevent you from having others, if implementations need more >>>> than one. >>> >>> OK, if there are no objections, I will make it a MUST. >> >> It appears you are introducing a "YANG identifier CLR". >> IMO this is a really bad idea. Introducing any sort of >> structure into identifier strings is a bad idea, let alone >> a SHOULD or MUST requirement. > > So what do you suggest? > I assume this is the text in question: One routing table MUST be present for each router instance and each address family supported by that router instance. It is the so- called main routing table to which all routing protocol instances supporting the given address family SHOULD be connected by default. For the two address families that are part of the core routing data model, the names of the main routing tables SHOULD be as follows: o "main-ipv4-unicast" for IPv4 unicast, o "main-ipv6-unicast" for IPv6 unicast. If it is so important to identity each 'main routing table' then add an schema-identifier leaf (config=false) that the server will set, pointing to it. We don't need YANG node naming CLRs. We did that with SNMP requiring "the plural form" of the counter name in all cases. IMO, a waste of time and just adds historical baggage. > Lada Andy > >> >> If this issue is something else then ignore this comment ;-) >> >> >>> >>>> >>> Lada >>> >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Wed Aug 22 01:51:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3447821F8570 for ; Wed, 22 Aug 2012 01:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFtWbDKyXAHZ for ; Wed, 22 Aug 2012 01:51:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E00AD21F851E for ; Wed, 22 Aug 2012 01:51:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7B87554020A for ; Wed, 22 Aug 2012 10:51:43 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFJ1sy7InEcA for ; Wed, 22 Aug 2012 10:51:37 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 275AF540106 for ; Wed, 22 Aug 2012 10:51:36 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <0lwr0tdzue.fsf@wjh.hardakers.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 22 Aug 2012 10:51:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 08:51:52 -0000 Andy Bierman writes: > On Tue, Aug 21, 2012 at 11:07 AM, Ladislav Lhotka wrote: >> >> On Aug 21, 2012, at 6:08 PM, Andy Bierman wrote: >> >>> On Tue, Aug 21, 2012 at 8:58 AM, Ladislav Lhotka wrote: >>>> Hi Wes, >>>> >>> .... >>>>> >>>>> 3) for 4.3, I had the same question previously discussed: why wouldn't >>>>> "main-ipv4-unicast" and "main-ipv6-unicast" naming be a MUST. I'm >>>>> trying to envision writing a manager that can take the config and do >>>>> something like draw a pretty diagram based on what I pull in, and >>>>> without a starting point I have to make educated guesses about what a >>>>> vendor might have intended by a random label such as "myroutes", and >>>>> these guesses will most likely be incorrect. Interoperability, IMHO, >>>>> will fail if we don't have a standard starting container name. It >>>>> doesn't prevent you from having others, if implementations need more >>>>> than one. >>>> >>>> OK, if there are no objections, I will make it a MUST. >>> >>> It appears you are introducing a "YANG identifier CLR". >>> IMO this is a really bad idea. Introducing any sort of >>> structure into identifier strings is a bad idea, let alone >>> a SHOULD or MUST requirement. >> >> So what do you suggest? >> > > I assume this is the text in question: > > One routing table MUST be present for each router instance and each > address family supported by that router instance. It is the so- > called main routing table to which all routing protocol instances > supporting the given address family SHOULD be connected by default. > For the two address families that are part of the core routing data > model, the names of the main routing tables SHOULD be as follows: > > o "main-ipv4-unicast" for IPv4 unicast, > o "main-ipv6-unicast" for IPv6 unicast. > > If it is so important to identity each 'main routing table' then add > an schema-identifier leaf (config=false) that the server > will set, pointing to it. > > We don't need YANG node naming CLRs. > We did that with SNMP requiring "the plural form" > of the counter name in all cases. IMO, a waste of time > and just adds historical baggage. An alternative is to add a new leaf representing routing table type, and require that exactly one routing table of the type "main" be present for each address family. Lada > > >> Lada > > Andy > >> >>> >>> If this issue is something else then ignore this comment ;-) >>> >>> >>>> >>>>> >>>> Lada >>>> >>> >>> Andy >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From wjhns1@hardakers.net Wed Aug 22 09:28:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA2C21F8600 for ; Wed, 22 Aug 2012 09:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14FJBx8Am0Oh for ; Wed, 22 Aug 2012 09:28:49 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFC521F8594 for ; Wed, 22 Aug 2012 09:28:48 -0700 (PDT) Received: from localhost (wjhw.hardakers.net [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id 0322B13C for ; Wed, 22 Aug 2012 09:28:47 -0700 (PDT) From: Wes Hardaker To: netmod@ietf.org References: <0lwr0tdzue.fsf@wjh.hardakers.net> Date: Wed, 22 Aug 2012 09:28:46 -0700 In-Reply-To: (Ladislav Lhotka's message of "Tue, 21 Aug 2012 17:58:49 +0200") Message-ID: <0lpq6izy9t.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:28:50 -0000 Ladislav Lhotka writes: > Appendix E says that the "example-rip" module is intended only as an > illustration rather than a real definition of a data model for the RIP > routing protocol. So I think this doesn't really matter. People use examples far too often as normative, or cut-and-paste them into the "reals" later. IMHO, a fix now prevents that and doesn't hurt the now. -- Wes Hardaker SPARTA, Inc. From wjhns1@hardakers.net Wed Aug 22 09:32:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E6421F8610 for ; Wed, 22 Aug 2012 09:32:13 -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.234, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi38hU6i6pHB for ; Wed, 22 Aug 2012 09:32:12 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id A079921F860B for ; Wed, 22 Aug 2012 09:32:12 -0700 (PDT) Received: from localhost (wjhw.hardakers.net [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id D727E13C; Wed, 22 Aug 2012 09:32:10 -0700 (PDT) From: Wes Hardaker To: Andy Bierman References: <0lwr0tdzue.fsf@wjh.hardakers.net> Date: Wed, 22 Aug 2012 09:32:09 -0700 In-Reply-To: (Andy Bierman's message of "Tue, 21 Aug 2012 11:29:33 -0700") Message-ID: <0llih6zy46.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:32:13 -0000 Andy Bierman writes: > We don't need YANG node naming CLRs. > We did that with SNMP requiring "the plural form" > of the counter name in all cases. IMO, a waste of time > and just adds historical baggage. The issue is how a manager, unfamiliar with a device, would know where in the data routing tree to take as the "top" table to which everything else is connected. If you don't have something labelled as "main-ipv4-unicast" then a manager has no hope of achieving interoperable configuration settings across multiple routers when one implementation chooses "four-forever" and another "routes" and another "main-ipv4-unicast". There is no way a manager can know the possible starting names of all the route tables unless there is commonality between the implementations (or you end up with managers that have to know of every implementation and their hacks). -- Wes Hardaker SPARTA, Inc. From andy@yumaworks.com Wed Aug 22 09:46:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7E721F862B for ; Wed, 22 Aug 2012 09:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gth8-avBBFME for ; Wed, 22 Aug 2012 09:46:38 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8D79721F8606 for ; Wed, 22 Aug 2012 09:46:38 -0700 (PDT) Received: by qadz3 with SMTP id z3so936255qad.10 for ; Wed, 22 Aug 2012 09:46:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ObVy4mpsjcPTvjvUDYFQTNo/MDzmM9eJw5w6hPK4/v0=; b=O9zRkB8KMobqpAbtdOedtnRGJsdOCZoOdwXzBEYsMMO8FVRioPuq1QhV992YT5weOa GXrps9q79iFO4U9abwrUqWX7pya5Zlizc2QCY4i39BfrD08UxaGLq1zYbJ7siHjLxAfT Mb8pHDXDvMi+x3vALCPR5EtmMIo2jmxyxdFaVxTsK4TzJlynL71fri8nJaxOkpQdY8la qakFRlBlqqscoASb/AGdViRzuy3yWzUSES2c6UASlKamFmyJ78XPhT2hMBFDRfLg3Ra1 f0pjy+oDl7beuMKJdRfZ5Z585EOuMVQDdAuabzOkc4KcRKcNfqtoDR1jq/B/hRJ/9ZSp G27w== MIME-Version: 1.0 Received: by 10.224.203.197 with SMTP id fj5mr16153663qab.98.1345653997928; Wed, 22 Aug 2012 09:46:37 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Wed, 22 Aug 2012 09:46:37 -0700 (PDT) In-Reply-To: <0llih6zy46.fsf@wjh.hardakers.net> References: <0lwr0tdzue.fsf@wjh.hardakers.net> <0llih6zy46.fsf@wjh.hardakers.net> Date: Wed, 22 Aug 2012 09:46:37 -0700 Message-ID: From: Andy Bierman To: Wes Hardaker Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlMEnzuSH0eeui/szw8VdAIpUSCeUG+Xpr8G2NliNagz+Kmr4gtAtB2o4aHk8M75vLX79G0 Cc: netmod@ietf.org Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:46:39 -0000 On Wed, Aug 22, 2012 at 9:32 AM, Wes Hardaker wrote: > Andy Bierman writes: > >> We don't need YANG node naming CLRs. >> We did that with SNMP requiring "the plural form" >> of the counter name in all cases. IMO, a waste of time >> and just adds historical baggage. > > The issue is how a manager, unfamiliar with a device, would know where > in the data routing tree to take as the "top" table to which everything > else is connected. If you don't have something labelled as > "main-ipv4-unicast" then a manager has no hope of achieving > interoperable configuration settings across multiple routers when one > implementation chooses "four-forever" and another "routes" and another > "main-ipv4-unicast". There is no way a manager can know the possible > starting names of all the route tables unless there is commonality > between the implementations (or you end up with managers that have to > know of every implementation and their hacks). IMO a leaf pointer identifying the top routing table is a much better solution. Unfortunately, the node-instance-identifier data type is in ietf-netconf-acm.yang: http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#node-instance-identifier.167 leaf main-ipv4-unicast-ptr { type acm:node-instance-identifier; description "Identifies the object node of the main IPv4 unicast routing table."; } Hard-wiring YANG node names seems wrong to me. You want to encode semantics into the node identifier. The only semantics should be "the local-name that uniquely identifies this node among its sibling nodes.". > -- > Wes Hardaker Andy From wjhns1@hardakers.net Wed Aug 22 12:43:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9955921F8665 for ; Wed, 22 Aug 2012 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC7gnWTURs4x for ; Wed, 22 Aug 2012 12:43:50 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD6C21F8625 for ; Wed, 22 Aug 2012 12:43:49 -0700 (PDT) Received: from localhost (wjhw.hardakers.net [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id D5AF45D7; Wed, 22 Aug 2012 12:43:47 -0700 (PDT) From: Wes Hardaker To: Andy Bierman References: <0lwr0tdzue.fsf@wjh.hardakers.net> <0llih6zy46.fsf@wjh.hardakers.net> Date: Wed, 22 Aug 2012 12:43:46 -0700 In-Reply-To: (Andy Bierman's message of "Wed, 22 Aug 2012 09:46:37 -0700") Message-ID: <0lk3wqyaod.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] half-review of routing-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:43:50 -0000 Andy Bierman writes: > IMO a leaf pointer identifying the top routing table is a much > better solution. That's fine too, IMHO, as long as there is a starting point. Nuking it entirely leaves none. [note you need multiple lookups though, not just one leaf... you need one per routing starting point, eg ipv4 and ipv6] -- Wes Hardaker SPARTA, Inc. From lhotka@nic.cz Thu Aug 23 07:41:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79B421F858A for ; Thu, 23 Aug 2012 07:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4LhdHGc4VMY for ; Thu, 23 Aug 2012 07:41:37 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6315B21F847A for ; Thu, 23 Aug 2012 07:41:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 40B14540297 for ; Thu, 23 Aug 2012 16:41:35 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SN8r-EzLzi5 for ; Thu, 23 Aug 2012 16:41:31 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E50C75401C6 for ; Thu, 23 Aug 2012 16:41:30 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Thu, 23 Aug 2012 16:41:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netmod] XML->JSON translation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 14:41:38 -0000 Hi, I wrote a plugin for pyang ("jsonxsl" output format) that does the XML -> JSON translation according to draft-lhotka-yang-json-01. It takes one or more YANG modules as input and generates an XSLT 1.0 stylesheet that can be used with any XSLT processor (e.g. xsltproc) for performing the translation for any XML instance document conforming to the data model. Two limitations I am aware of: - "union" type is always rendered as string in JSON, - values of "instance-identifier" type are not transformed. If will fix both later (at least partly). For those who are interested, please checkout the current pyang revision from SVN, test the plugin and let me know if you discover any problems. Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Aug 23 12:43:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4C721F86A2 for ; Thu, 23 Aug 2012 12:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3qUP9v35DUn for ; Thu, 23 Aug 2012 12:43:46 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5D221F869C for ; Thu, 23 Aug 2012 12:43:46 -0700 (PDT) Received: by qadz3 with SMTP id z3so37258qad.10 for ; Thu, 23 Aug 2012 12:43:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=kfbATXZDSt1yzTkQVtUwSCNlb/K4uLkQ+PSdd7wmHf0=; b=jpZxmxeWG02kC4lkIsEeq1rVrjMnx2J8WMGoA/WW7GrOzDqIBHuVEdjmHJUm2s+8sp mlrVjiW/lGvNx5OGnPRdx7knuXwaTCT7ObUBw9xHORxC5Y9zxQne6QVY+OVhTo1nCaWi VLSflO4V0b943Wv9cXOX4Vyhj8D4ZCpvKHHJxx2dlrNvpDImzgMrnH9PZri5mv6f+TfS SdxrTLzuP3CQrKnkgBi1CFHFShozFhnn0HBXewDal+OangRmfHZkOIMX9FA0SApqNYTw dxYHyPageCJ+LlOeGhC4fQZZE5ZVoECNH1bTNsqGfsbfFVnRleK5Xr1fpFi6RlrEOHPI SX8A== MIME-Version: 1.0 Received: by 10.229.137.18 with SMTP id u18mr1283635qct.22.1345751025697; Thu, 23 Aug 2012 12:43:45 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Thu, 23 Aug 2012 12:43:45 -0700 (PDT) Date: Thu, 23 Aug 2012 12:43:45 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkjsRKc2buhzVotiIqQaKsmc0F0cluIwDNzEsShbP90LCbn3ahZIUhnhFcQE0ROKjmgtkJQ Subject: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:43:47 -0000 Hi, The WG is not very interested in this topic, but I strongly suggest that all NETMOD WG modules in progress be split into 2 modules if there are any reusable typedefs, groupings, extensions, features, and/or identities. These should go in a separate YANG module so a server and YANG designer can reuse this meta-data without advertising the 'main' module with mandatory objects, rpcs, and notifications. This simple workaround should cover most use-cases and may prove to be better organization in the long-run. It has proven to be effective in SMIv2-land. Andy From mbj@tail-f.com Fri Aug 24 06:59:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0021F86C4 for ; Fri, 24 Aug 2012 06:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO1WcQxILbQe for ; Fri, 24 Aug 2012 06:59:34 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CA47721F86C2 for ; Fri, 24 Aug 2012 06:59:33 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E2F6C1200D10; Fri, 24 Aug 2012 15:59:31 +0200 (CEST) Date: Fri, 24 Aug 2012 15:59:31 +0200 (CEST) Message-Id: <20120824.155931.389305767.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120802233724.GB87351@elstar.local> References: <20120802.160015.289535832.mbj@tail-f.com> <20120802233724.GB87351@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 13:59:34 -0000 Hi, I have one open issue on the ip config draft: Juergen Schoenwaelder wrote: > On Thu, Aug 02, 2012 at 04:00:15PM -0700, Martin Bjorklund wrote: > > ps> container ipv4 and ipv6 should be presence containers, since > > ps> otherwise both ipv4 and ipv6 are enabled by default. > > > > This is an important point. The question to the WG is if > > these address families should be enabled by default or not. I think > > this was discussed at some point, but I cannot find this in the > > archives now. > > Now that we are sunsetting ipv4... ;-) I think there are enabled leafs > so I think the question boils down to whether the default is true or > false and not whether we need presence containers. That said, I assume > either both true or both false are the options we really have. What is > the concern with the both true defaults? So, currently we have: container ipv4 { // ditto for ipv6 leaf enabled { default "true"; ... } } The proposal is to change this into: container ipv4 { // ditto for ipv6 presence "..."; leaf enabled { default "true"; ... } } Without the presence statement, both ipv4 and ipv6 are enabled by default. Explicit config is needed to disable it. With the proposal to add presence statement, ipv4 & ipv6 are disabled by default. Explicit creation of the "ipv4" or "ipv6" container is needed in order to enable ipv4 and ipv6. Comments? /martin From phil@juniper.net Fri Aug 24 09:10:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A6C21F86B1 for ; Fri, 24 Aug 2012 09:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewaDApliH2TG for ; Fri, 24 Aug 2012 09:10:58 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 740A221F8686 for ; Fri, 24 Aug 2012 09:10:54 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUDenjqLWn40dO0s3aHcysP/e4/EuUhKv@postini.com; Fri, 24 Aug 2012 09:10:58 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Aug 2012 09:07:42 -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 q7OFKNh56611; Fri, 24 Aug 2012 08:20:28 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7OFJKDr074149; Fri, 24 Aug 2012 11:19:42 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208241519.q7OFJKDr074149@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20120824.155931.389305767.mbj@tail-f.com> Date: Fri, 24 Aug 2012 11:19:19 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:10:59 -0000 Martin Bjorklund writes: >The proposal is to change this into: > > container ipv4 { // ditto for ipv6 > presence "..."; > leaf enabled { > default "true"; > ... > } > } > > >Without the presence statement, both ipv4 and ipv6 are enabled by >default. Explicit config is needed to disable it. > >With the proposal to add presence statement, ipv4 & ipv6 are disabled >by default. Explicit creation of the "ipv4" or "ipv6" container is >needed in order to enable ipv4 and ipv6. +1. Because: - Nothing should be enabled by default. - Most interfaces will run one of [46] or the other, and having to explicitly disable one is tacky/noisy. - If you really believe that v4 is sunsetting, then making it require explicit unconfiguring is a "forever" requirement. - It's a bad precedent for other protocols (mpls, etc). - Since addressing information is needed anyway, adding the presence container is automatic and natural. Thanks, Phil From andy@yumaworks.com Fri Aug 24 09:43:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0BF21F86B7 for ; Fri, 24 Aug 2012 09:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKI1prDMEUKE for ; Fri, 24 Aug 2012 09:43:50 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB6E821F86B0 for ; Fri, 24 Aug 2012 09:43:49 -0700 (PDT) Received: by qcac10 with SMTP id c10so1528738qca.31 for ; Fri, 24 Aug 2012 09:43:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=dBPz/bf0cxGj593xyY66xJiOhZIcOc57n9NagB7imXA=; b=OWfF+xAXmRl7PiMsevHfO4MRT4ZSg4OJ+c1Wu7uHjnWtrjy91aLa2fXZSD552aRPCh +pefIGHWnk9k/kXiZgVkRZPrkxgpCeSfz5LG4pvAhwznc/CCvTX6++PHMJY75eQEZfK7 G/egeCuK+EytYW1oIbBntT7JdgiAX3tQ/WFD+FAobpSI3657qdlx9jnNzYREUhsdzr1i SONDPdDlZjHwtHXJOTXH0tLo7S4gg1Q2ugA7xY9b2BSVtqqM7WMdfYMCJd0ZAHlvRuV+ /0gbtba6dOvdauQccMsyLrptjl2J5E1O/x/qGeNLSLrOua4gHeysmovJ0RoNGhirHHmv jtVw== MIME-Version: 1.0 Received: by 10.224.59.212 with SMTP id m20mr9851933qah.14.1345826629368; Fri, 24 Aug 2012 09:43:49 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Fri, 24 Aug 2012 09:43:49 -0700 (PDT) In-Reply-To: <201208241519.q7OFJKDr074149@idle.juniper.net> References: <20120824.155931.389305767.mbj@tail-f.com> <201208241519.q7OFJKDr074149@idle.juniper.net> Date: Fri, 24 Aug 2012 09:43:49 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQltpqWd2xVOp+SB4loCi4g19SsGMTQg+9mrcK93uX96O39dvYaraWK/Wo7WOkqWGfHwVS+7 Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:43:50 -0000 On Fri, Aug 24, 2012 at 8:19 AM, Phil Shafer wrote: > Martin Bjorklund writes: >>The proposal is to change this into: >> >> container ipv4 { // ditto for ipv6 >> presence "..."; >> leaf enabled { >> default "true"; >> ... >> } >> } >> >> >>Without the presence statement, both ipv4 and ipv6 are enabled by >>default. Explicit config is needed to disable it. >> >>With the proposal to add presence statement, ipv4 & ipv6 are disabled >>by default. Explicit creation of the "ipv4" or "ipv6" container is >>needed in order to enable ipv4 and ipv6. > > +1. Because: > > - Nothing should be enabled by default. > - Most interfaces will run one of [46] or the other, and having to > explicitly disable one is tacky/noisy. > - If you really believe that v4 is sunsetting, then making it require > explicit unconfiguring is a "forever" requirement. > - It's a bad precedent for other protocols (mpls, etc). > - Since addressing information is needed anyway, adding the > presence container is automatic and natural. > All very fine, but come up with a better presence statement than "...". If an empty ipv4 container means that IPv4 is enabled, then what does this mean: false It means the config sub-tree is a place-holder and IPv4 is not really enabled. The text has to clarify the 2 'enable' mechanisms. > Thanks, > Phil Andy From spakes@snmp.com Fri Aug 24 10:02:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D64C21F8598 for ; Fri, 24 Aug 2012 10:02:01 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvoR75aOvzQ8 for ; Fri, 24 Aug 2012 10:02:00 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF2621F84FB for ; Fri, 24 Aug 2012 10:01:59 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA12071; Fri, 24 Aug 2012 13:01:57 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA07659; Fri, 24 Aug 2012 13:01:56 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 24 Aug 2012 13:01:55 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: Message-ID: References: <20120824.155931.389305767.mbj@tail-f.com> <201208241519.q7OFJKDr074149@idle.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:02:01 -0000 On Fri, 24 Aug 2012, Andy Bierman wrote: > On Fri, Aug 24, 2012 at 8:19 AM, Phil Shafer wrote: > > Martin Bjorklund writes: > >>The proposal is to change this into: > >> > >> container ipv4 { // ditto for ipv6 > >> presence "..."; > >> leaf enabled { > >> default "true"; > >> ... > >> } > >> } > >> > >> > >>Without the presence statement, both ipv4 and ipv6 are enabled by > >>default. Explicit config is needed to disable it. > >> > >>With the proposal to add presence statement, ipv4 & ipv6 are disabled > >>by default. Explicit creation of the "ipv4" or "ipv6" container is > >>needed in order to enable ipv4 and ipv6. > > > > +1. Because: > > > > - Nothing should be enabled by default. > > - Most interfaces will run one of [46] or the other, and having to > > explicitly disable one is tacky/noisy. > > - If you really believe that v4 is sunsetting, then making it require > > explicit unconfiguring is a "forever" requirement. > > - It's a bad precedent for other protocols (mpls, etc). > > - Since addressing information is needed anyway, adding the > > presence container is automatic and natural. > > > > All very fine, but come up with a better presence > statement than "...". If an empty ipv4 container > means that IPv4 is enabled, then what does this mean: > > > false > > > It means the config sub-tree is a place-holder and IPv4 > is not really enabled. The text has to clarify the 2 'enable' > mechanisms. Having two mechanisms makes perfect sense to me, but possibly with a different semantic than what has been proposed. - A computer system may or may not have an IPv4 stack (presence). - If the IPv4 stack is present, then it may be enabled or disabled (leaf enabled with possible values true and false). Hence, if this is returned in response to a get-config, false it means that the system does possess an IPv4 stack and it is currently disabled. If the response to a get-config does not include a section for , then it means that there is no IPv4 stack present in the computer system. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From andy@yumaworks.com Fri Aug 24 10:24:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B5B21F8686 for ; Fri, 24 Aug 2012 10:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SgtE1NypQVs for ; Fri, 24 Aug 2012 10:24:52 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 313D921F858E for ; Fri, 24 Aug 2012 10:24:52 -0700 (PDT) Received: by qan41 with SMTP id 41so457265qan.10 for ; Fri, 24 Aug 2012 10:24:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=My6xHCgNXcNnCDd+XsgDuOKPWzKdLefPjfsBx1/U2FY=; b=PD1h0bP0BI7Uky7Lifaa6ySvOa6VTMLex8urbbmSC/6mIQ7hh8uCCdrZnOjOuHppt1 e6f8GhdnOLRE20pwHnMAffY/8tFdLtCeqo5ul7MhtowqXkAKPn0oekCF69fM4OVSiQxJ TMER9zASFy+9RN5/uA4KJxgCaLtr4uwygZdQZW2QXwmcmA+xz9ucCiY1tGv/3Z66MJh9 hPzjl5YTK83cvl81DbJgI56rWgpeP56+1U/2M2+4IqoMJ/8E1wO9TMazwAz6Dx0MVu/W sSpVkF+/JWeJM3Fckhhu98McV3XbHIAkrrGRNljRHvth93/cdpH+U0iiZ5UTBOC62Pzq MYJA== MIME-Version: 1.0 Received: by 10.229.135.206 with SMTP id o14mr2856432qct.91.1345829091577; Fri, 24 Aug 2012 10:24:51 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Fri, 24 Aug 2012 10:24:51 -0700 (PDT) In-Reply-To: References: <20120824.155931.389305767.mbj@tail-f.com> <201208241519.q7OFJKDr074149@idle.juniper.net> Date: Fri, 24 Aug 2012 10:24:51 -0700 Message-ID: From: Andy Bierman To: David Spakes Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnJ4YAt+dBo8PTr5wt0YYpeWLYAhSHZHqb5YkTpu3WGHmQhSA3FKzSdaKazUFO4c8oPNgnE Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:24:53 -0000 On Fri, Aug 24, 2012 at 10:01 AM, David Spakes wrote: > On Fri, 24 Aug 2012, Andy Bierman wrote: > >> On Fri, Aug 24, 2012 at 8:19 AM, Phil Shafer wrote: >> > Martin Bjorklund writes: >> >>The proposal is to change this into: >> >> >> >> container ipv4 { // ditto for ipv6 >> >> presence "..."; >> >> leaf enabled { >> >> default "true"; >> >> ... >> >> } >> >> } >> >> >> >> >> >>Without the presence statement, both ipv4 and ipv6 are enabled by >> >>default. Explicit config is needed to disable it. >> >> >> >>With the proposal to add presence statement, ipv4 & ipv6 are disabled >> >>by default. Explicit creation of the "ipv4" or "ipv6" container is >> >>needed in order to enable ipv4 and ipv6. >> > >> > +1. Because: >> > >> > - Nothing should be enabled by default. >> > - Most interfaces will run one of [46] or the other, and having to >> > explicitly disable one is tacky/noisy. >> > - If you really believe that v4 is sunsetting, then making it require >> > explicit unconfiguring is a "forever" requirement. >> > - It's a bad precedent for other protocols (mpls, etc). >> > - Since addressing information is needed anyway, adding the >> > presence container is automatic and natural. >> > >> >> All very fine, but come up with a better presence >> statement than "...". If an empty ipv4 container >> means that IPv4 is enabled, then what does this mean: >> >> >> false >> >> >> It means the config sub-tree is a place-holder and IPv4 >> is not really enabled. The text has to clarify the 2 'enable' >> mechanisms. > > > Having two mechanisms makes perfect sense to me, but possibly with a > different semantic than what has been proposed. > > - A computer system may or may not have an IPv4 stack (presence). > > - If the IPv4 stack is present, then it may be enabled or disabled > (leaf enabled with possible values true and false). > > Hence, if this is returned in response to a get-config, > > > false > > > it means that the system does possess an IPv4 stack and it is currently > disabled. > > If the response to a get-config does not include a section for , > then it means that there is no IPv4 stack present in the computer system. > The client creates the P-container, not the server. Perhaps on some systems creating this container will cause the IPv4 code to be loaded into the system, but on most systems the code will be there, just disabled. If not supported the server will reject the create request on the ipv4 container. > > -dss > Andy From mbj@tail-f.com Fri Aug 24 12:38:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA821F85A2 for ; Fri, 24 Aug 2012 12:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4M5KnUrV8N5 for ; Fri, 24 Aug 2012 12:38:29 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D39C321F8596 for ; Fri, 24 Aug 2012 12:38:28 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A384C1200050; Fri, 24 Aug 2012 21:38:27 +0200 (CEST) Date: Fri, 24 Aug 2012 21:38:27 +0200 (CEST) Message-Id: <20120824.213827.520095880.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201208241519.q7OFJKDr074149@idle.juniper.net> References: <20120824.155931.389305767.mbj@tail-f.com> <201208241519.q7OFJKDr074149@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:38:30 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >The proposal is to change this into: > > > > container ipv4 { // ditto for ipv6 > > presence "..."; > > leaf enabled { > > default "true"; > > ... > > } > > } > > > > > >Without the presence statement, both ipv4 and ipv6 are enabled by > >default. Explicit config is needed to disable it. > > > >With the proposal to add presence statement, ipv4 & ipv6 are disabled > >by default. Explicit creation of the "ipv4" or "ipv6" container is > >needed in order to enable ipv4 and ipv6. > > +1. Because: > > - Nothing should be enabled by default. > - Most interfaces will run one of [46] or the other, and having to > explicitly disable one is tacky/noisy. > - If you really believe that v4 is sunsetting, then making it require > explicit unconfiguring is a "forever" requirement. > - It's a bad precedent for other protocols (mpls, etc). > - Since addressing information is needed anyway, adding the > presence container is automatic and natural. An alternative is to simply make the "enabled" leaf have "false" as default value. With "ipv4" being a P-container, what exactly is the meaning of its presence? /martin From andy@yumaworks.com Fri Aug 24 13:05:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B885D21F85C3 for ; Fri, 24 Aug 2012 13:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Rbu0oPPfUDP for ; Fri, 24 Aug 2012 13:05:55 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F27721F8594 for ; Fri, 24 Aug 2012 13:05:54 -0700 (PDT) Received: by qcac10 with SMTP id c10so1662483qca.31 for ; Fri, 24 Aug 2012 13:05:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8mW9GJfjkkXV9ZCakGtHf0Xz2eWZ9/9H0u77LpZ6oDI=; b=pk4tRM3emttZEy04LOIlI/H3LTRqvYvR+Lp5MQxcw6aaX3/sBv0oXoFCPKPfrcxqUL AFE2AOfPPO+iPQEi0VB4AwGEnvjninnAN5jAvWiQCBkzcFx6HOhJyhXXkqNpxHTtZEbO VVhHd4svXAhrLKFIICqWScEi5fIEqQDCSzbs6URaJWqO1FI/tfXFo9m5F284Vd2WCddz tjgXwwoMkJiDNg/gfmm959MGg7PkQMNjCGn7U3pCeFnl30KPVeWEkaZc7E7B+ltpKJXb /F+sCVcvyqI++slGkV2JYu24L7xyNKPqrD25xJTjhW647BN4eQ5IhEunv1HQnHmlBtfG btnQ== MIME-Version: 1.0 Received: by 10.224.199.201 with SMTP id et9mr10696426qab.59.1345838754412; Fri, 24 Aug 2012 13:05:54 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Fri, 24 Aug 2012 13:05:54 -0700 (PDT) In-Reply-To: <20120824.213827.520095880.mbj@tail-f.com> References: <20120824.155931.389305767.mbj@tail-f.com> <201208241519.q7OFJKDr074149@idle.juniper.net> <20120824.213827.520095880.mbj@tail-f.com> Date: Fri, 24 Aug 2012 13:05:54 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl/TUqZOYe55VdxIaH29MdDBoWa+ECicKuNpJMcgomUAU63KHu9xdpmWSDjZCKNq47VCUNT Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 20:05:55 -0000 On Fri, Aug 24, 2012 at 12:38 PM, Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >> >The proposal is to change this into: >> > >> > container ipv4 { // ditto for ipv6 >> > presence "..."; >> > leaf enabled { >> > default "true"; >> > ... >> > } >> > } >> > >> > >> >Without the presence statement, both ipv4 and ipv6 are enabled by >> >default. Explicit config is needed to disable it. >> > >> >With the proposal to add presence statement, ipv4 & ipv6 are disabled >> >by default. Explicit creation of the "ipv4" or "ipv6" container is >> >needed in order to enable ipv4 and ipv6. >> >> +1. Because: >> >> - Nothing should be enabled by default. >> - Most interfaces will run one of [46] or the other, and having to >> explicitly disable one is tacky/noisy. >> - If you really believe that v4 is sunsetting, then making it require >> explicit unconfiguring is a "forever" requirement. >> - It's a bad precedent for other protocols (mpls, etc). >> - Since addressing information is needed anyway, adding the >> presence container is automatic and natural. > > An alternative is to simply make the "enabled" leaf have "false" as > default value. With "ipv4" being a P-container, what exactly is the > meaning of its presence? > duh! +1 > > /martin Andy From lhotka@nic.cz Sat Aug 25 03:22:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E4721F8471 for ; Sat, 25 Aug 2012 03:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh8ZNC8P9zdE for ; Sat, 25 Aug 2012 03:22:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB321F846D for ; Sat, 25 Aug 2012 03:22:58 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8E6A713F9D0; Sat, 25 Aug 2012 12:22:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1345890177; bh=XVSznl5I8CwH2HOv54+JsQ4qJ2Ux/co4TEc+evAkaU0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=R8aG4IRf/WFi8WCe7jjbDP1Tlgd7H96dyy2G/VaFUuIvR/xKuhIOp1vIQD+g3Oycu giVhhGRkPiGichem6FPWVDkcFPCuv9hYDgnaMoqUJs9OqXkUGGPgrx6waJDe7tWCxT eNRzGL17k6VKnJSMzdJeAlzzzT5ZNIqXpCBZQvbg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ladislav Lhotka In-Reply-To: <20120824.213827.520095880.mbj@tail-f.com> Date: Sat, 25 Aug 2012 12:22:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28FA0CCA-A61E-4139-8F5B-FD17A4856228@nic.cz> References: <20120824.155931.389305767.mbj@tail-f.com> <201208241519.q7OFJKDr074149@idle.juniper.net> <20120824.213827.520095880.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1485) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 10:23:00 -0000 On Aug 24, 2012, at 9:38 PM, Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> The proposal is to change this into: >>>=20 >>> container ipv4 { // ditto for ipv6 >>> presence "..."; >>> leaf enabled { >>> default "true"; >>> ... >>> } >>> } >>>=20 >>>=20 >>> Without the presence statement, both ipv4 and ipv6 are enabled by >>> default. Explicit config is needed to disable it. >>>=20 >>> With the proposal to add presence statement, ipv4 & ipv6 are = disabled >>> by default. Explicit creation of the "ipv4" or "ipv6" container is >>> needed in order to enable ipv4 and ipv6. >>=20 >> +1. Because: >>=20 >> - Nothing should be enabled by default. >> - Most interfaces will run one of [46] or the other, and having to >> explicitly disable one is tacky/noisy. >> - If you really believe that v4 is sunsetting, then making it require >> explicit unconfiguring is a "forever" requirement. >> - It's a bad precedent for other protocols (mpls, etc). >> - Since addressing information is needed anyway, adding the >> presence container is automatic and natural. >=20 > An alternative is to simply make the "enabled" leaf have "false" as > default value. With "ipv4" being a P-container, what exactly is the > meaning of its presence? Its *absence* means that no configuration within that container is ever = seen, no matter what the with-defaults mode. If is a non-presence = container and defaults to "false", then a client with no = interest in IPv6 would still get the following data for every interface = in the "report-all" mode: false false 1 true false 604800 86400 So I am in favour of making and P-containers, and making = the same in other places in the core models where appropriate. Lada >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sat Aug 25 07:42:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D1721F845F for ; Sat, 25 Aug 2012 07:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yb8doSHQ8QG for ; Sat, 25 Aug 2012 07:42:40 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id DEEF021F845D for ; Sat, 25 Aug 2012 07:42:39 -0700 (PDT) Received: by qadz3 with SMTP id z3so1042744qad.10 for ; Sat, 25 Aug 2012 07:42:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ljxJybs+9kzEIHDWKILgbGZteE+OTsnmnQcesJnRH10=; b=fd6cg9pi2IRFpAiaWMdvLfuiLckdXzA4qPsOUuznnpjHhwMBEoA5lm3HPydU+/cw6T Y1jF2ka7kN9haPWwyekbAE2JeCsNYyx3qZAz5KcKK9iEhI2ND5H10LlM2phVXQluQIbi E1AKj8OA2r04AGZEYyHb7kFOROV2KllTeql8d2no6KdEawAz6lE3WnjVrBN2ws44xlXT Q6tgPsTj+ksLCyxxAzELgTzDYLKrB+enhMf5bDS7DhtV+Uy2XbTrZ6/gOqlfdAy8xy63 PQg/uUdy+GXJH8JG9/0JcI0/jwL0WxdLKjdIPPpARGeLasmYIQ47YtJh6ucsnqDVUnrh oJ0w== MIME-Version: 1.0 Received: by 10.224.213.198 with SMTP id gx6mr14560818qab.9.1345905759398; Sat, 25 Aug 2012 07:42:39 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Sat, 25 Aug 2012 07:42:39 -0700 (PDT) In-Reply-To: <28FA0CCA-A61E-4139-8F5B-FD17A4856228@nic.cz> References: <20120824.155931.389305767.mbj@tail-f.com> <201208241519.q7OFJKDr074149@idle.juniper.net> <20120824.213827.520095880.mbj@tail-f.com> <28FA0CCA-A61E-4139-8F5B-FD17A4856228@nic.cz> Date: Sat, 25 Aug 2012 07:42:39 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkAHw6cOyr4aUIMsPCvuWNzun9VoQc/I16Jb7tObCzcXLMM/avKLkYiD/eKOXSgUpmB7bEy Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 14:42:40 -0000 On Sat, Aug 25, 2012 at 3:22 AM, Ladislav Lhotka wrote: > > On Aug 24, 2012, at 9:38 PM, Martin Bjorklund wrote: > >> Phil Shafer wrote: >>> Martin Bjorklund writes: >>>> The proposal is to change this into: >>>> >>>> container ipv4 { // ditto for ipv6 >>>> presence "..."; >>>> leaf enabled { >>>> default "true"; >>>> ... >>>> } >>>> } >>>> >>>> >>>> Without the presence statement, both ipv4 and ipv6 are enabled by >>>> default. Explicit config is needed to disable it. >>>> >>>> With the proposal to add presence statement, ipv4 & ipv6 are disabled >>>> by default. Explicit creation of the "ipv4" or "ipv6" container is >>>> needed in order to enable ipv4 and ipv6. >>> >>> +1. Because: >>> >>> - Nothing should be enabled by default. >>> - Most interfaces will run one of [46] or the other, and having to >>> explicitly disable one is tacky/noisy. >>> - If you really believe that v4 is sunsetting, then making it require >>> explicit unconfiguring is a "forever" requirement. >>> - It's a bad precedent for other protocols (mpls, etc). >>> - Since addressing information is needed anyway, adding the >>> presence container is automatic and natural. >> >> An alternative is to simply make the "enabled" leaf have "false" as >> default value. With "ipv4" being a P-container, what exactly is the >> meaning of its presence? > > Its *absence* means that no configuration within that container is ever s= een, no matter what the with-defaults mode. If is a non-presence con= tainer and defaults to "false", then a client with no interest in= IPv6 would still get the following data for every interface in the "report= -all" mode: > The difference between an NP container and a P container is that an empty P container has some semantic meaning within the data model and an NP container does not. So what does an empty ipv4 container mean? > > false > false > 1 > > true > false > 604800 > 86400 > > > This is no big deal -- the client has to explicitly request with-defaults, and getting back 6 default leafs in this case is the intended behavior. > So I am in favour of making and P-containers, and making th= e same in other places in the core models where appropriate. But what is the meaning of an empty P container in each case? "protocol enabled"? There is an 'enabled' leaf for that. "code is present"? The client creates a P container, not the server > > Lada > Andy >> >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Sat Aug 25 09:29:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157BF21F84A1 for ; Sat, 25 Aug 2012 09:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQNIcgkQHIdc for ; Sat, 25 Aug 2012 09:29:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEEF21F849D for ; Sat, 25 Aug 2012 09:29:46 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4750713F70A; Sat, 25 Aug 2012 18:29:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1345912185; bh=+Xcs2eie5w04O3eSWFpUcTDkaJBfhp4dFjsHab3Hioo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ia1pY/VjixfxHWi3YoGQifYkCX/npEwZjfXJRIRZgoagxoP3gQHL0CRls1nGXHpKS S8bFsxFwTONEXmIz7waVwjW+pPXPVM8pWaNXCdik4h+YGN34w9RoSpFt1O1yWeewG+ /xSZDVCyxl5JNjuaAlhbIr8nzSyxMODvgF9Ardp0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 25 Aug 2012 18:29:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120824.155931.389305767.mbj@tail-f.com> <201208241519.q7OFJKDr074149@idle.juniper.net> <20120824.213827.520095880.mbj@tail-f.com> <28FA0CCA-A61E-4139-8F5B-FD17A4856228@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1485) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 16:29:48 -0000 On Aug 25, 2012, at 4:42 PM, Andy Bierman wrote: > On Sat, Aug 25, 2012 at 3:22 AM, Ladislav Lhotka = wrote: >>=20 >> On Aug 24, 2012, at 9:38 PM, Martin Bjorklund wrote: >>=20 >>> Phil Shafer wrote: >>>> Martin Bjorklund writes: >>>>> The proposal is to change this into: >>>>>=20 >>>>> container ipv4 { // ditto for ipv6 >>>>> presence "..."; >>>>> leaf enabled { >>>>> default "true"; >>>>> ... >>>>> } >>>>> } >>>>>=20 >>>>>=20 >>>>> Without the presence statement, both ipv4 and ipv6 are enabled by >>>>> default. Explicit config is needed to disable it. >>>>>=20 >>>>> With the proposal to add presence statement, ipv4 & ipv6 are = disabled >>>>> by default. Explicit creation of the "ipv4" or "ipv6" container = is >>>>> needed in order to enable ipv4 and ipv6. >>>>=20 >>>> +1. Because: >>>>=20 >>>> - Nothing should be enabled by default. >>>> - Most interfaces will run one of [46] or the other, and having to >>>> explicitly disable one is tacky/noisy. >>>> - If you really believe that v4 is sunsetting, then making it = require >>>> explicit unconfiguring is a "forever" requirement. >>>> - It's a bad precedent for other protocols (mpls, etc). >>>> - Since addressing information is needed anyway, adding the >>>> presence container is automatic and natural. >>>=20 >>> An alternative is to simply make the "enabled" leaf have "false" as >>> default value. With "ipv4" being a P-container, what exactly is the >>> meaning of its presence? >>=20 >> Its *absence* means that no configuration within that container is = ever seen, no matter what the with-defaults mode. If is a = non-presence container and defaults to "false", then a client = with no interest in IPv6 would still get the following data for every = interface in the "report-all" mode: >>=20 >=20 > The difference between an NP container and a P container is that > an empty P container has some semantic meaning within the > data model and an NP container does not. So what does an > empty ipv4 container mean? It means that the default contents defined under are present. >=20 >> >> false >> false >> 1 >> >> true >> false >> 604800 >> 86400 >> >> >>=20 >=20 > This is no big deal -- the client has to explicitly request = with-defaults, > and getting back 6 default leafs in this case is the intended = behaviour. Yes, but for each interface. The presence of defaults may also affect = XPath expressions.=20 >=20 >> So I am in favour of making and P-containers, and = making the same in other places in the core models where appropriate. >=20 > But what is the meaning of an empty P container in each case? >=20 > "protocol enabled"? There is an 'enabled' leaf for that. This depends on the default value for "enabled". > "code is present"? The client creates a P container, not the server Sure. Lada >=20 >>=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>>=20 >>> /martin >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From dromasca@avaya.com Sat Aug 25 22:37:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F9621F84D9 for ; Sat, 25 Aug 2012 22:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdP8b+RNl94y for ; Sat, 25 Aug 2012 22:37:16 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6F521F84F7 for ; Sat, 25 Aug 2012 22:37:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIO1OVDGmAcF/2dsb2JhbABFummBB4IgAQEBAQMBAQEPHgo0FwQCAQgNBAQBAQsGDAsBBgEmHwkIAQEEARIIGodrC58+nB8EiwiGMWADm1OKF4Jl X-IronPort-AV: E=Sophos;i="4.77,829,1336363200"; d="scan'208";a="363855016" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Aug 2012 01:31:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Aug 2012 01:30:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Aug 2012 07:36:34 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] followup on YANG conformance Thread-Index: Ac2BZ6ZhRsMMVrrUTPu87hI87SumaAB5KR7g References: From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 05:37:17 -0000 Hi Andy, Can you give an example of what you are proposing using one of the YANG modules currently in progress? I am not sure that I understand exactly what you are proposing, in SMIv2 we (try to) separate the reusable TCs, we do not separate conformance clauses.=20 Thanks and Regards, Dan > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Andy Bierman > Sent: Thursday, August 23, 2012 10:44 PM > To: netmod@ietf.org > Subject: [netmod] followup on YANG conformance >=20 > Hi, >=20 > The WG is not very interested in this topic, but I strongly suggest that > all NETMOD WG modules in progress be split into > 2 modules if there are any reusable typedefs, groupings, extensions, > features, and/or identities. These should go in a separate YANG module > so a server and YANG designer can reuse this meta-data without > advertising the 'main' module with mandatory objects, rpcs, and > notifications. >=20 > This simple workaround should cover most use-cases and may prove to be > better organization in the long-run. It has proven to be effective in > SMIv2-land. >=20 >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Sun Aug 26 08:20:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C59821F854A for ; Sun, 26 Aug 2012 08:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK0RkdFdHiwG for ; Sun, 26 Aug 2012 08:20:56 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A39C021F8540 for ; Sun, 26 Aug 2012 08:20:56 -0700 (PDT) Received: by qcac10 with SMTP id c10so2442743qca.31 for ; Sun, 26 Aug 2012 08:20:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=iqoaWyj7KefXewplSM3tel3erolGRJ7RQQxG3yOD/eo=; b=CzUoUfHPvjjODijWdXG/ln6pH8XxZ0Le+4UYfFWtDN/oViQCNXe2+DS01hkZAr9Qt6 cffs2IbF/sM7WFoNYyEQQAWiewBjcGkbE25W2vYZY/2lmGhNE7woGMGdruvUnK1BWHSp M6aNHggFJWt1nShKxoGjqkOALZMbJTzr/F3qGKMbuYPpVFA5uWcxShXyTI7++GvJsb2k NoTtWYDfibCSpGSYmD1MGL5yxrKXNeM2tBLE3KU0J/d7QfZNEjYtVgKexX8SQs8cnsQz SlJKrXPPtxe/vSDCV8gBYLS9kHTs69go8mgzCa4MA6jarWqrbKsPrcdxDS7wjSRXZV9y t4Jg== MIME-Version: 1.0 Received: by 10.229.136.14 with SMTP id p14mr5559825qct.93.1345994456020; Sun, 26 Aug 2012 08:20:56 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Sun, 26 Aug 2012 08:20:55 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Aug 2012 08:20:55 -0700 Message-ID: From: Andy Bierman To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmIcT0HlWwS1jwIGYjiQ8aA+kOH+aEoFN4MQWtZfwkECQCfrzMp08RRIhtvhKYAfTjccAsq Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 15:20:57 -0000 On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) wrote: > Hi Andy, > > Can you give an example of what you are proposing using one of the YANG > modules currently in progress? I am not sure that I understand exactly > what you are proposing, in SMIv2 we (try to) separate the reusable TCs, > we do not separate conformance clauses. > We have no explicit module conformance mechanisms in NETCONF/YANG, other than the YANG module capability in the message. So if I want to use the 'crypt-hash' typedef in 1 of my modules (or another IETF module), then I have to import ietf-system. In order to tell the client which 'ietf-system' (remember YANG module names are not even intended to be unique) I have to advertise ietf-system in the server . The client will think I implement the /system container, which is not correct. So if the crypt-hash typedef was in the ietf-system-types module instead, I would not have to import ietf-system -- I could import ietf-system-types. That way the client will not see ietf-system advertised unless the server really implements the /system container. > Thanks and Regards, > > Dan > Andy > > >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf >> Of Andy Bierman >> Sent: Thursday, August 23, 2012 10:44 PM >> To: netmod@ietf.org >> Subject: [netmod] followup on YANG conformance >> >> Hi, >> >> The WG is not very interested in this topic, but I strongly suggest > that >> all NETMOD WG modules in progress be split into >> 2 modules if there are any reusable typedefs, groupings, extensions, >> features, and/or identities. These should go in a separate YANG > module >> so a server and YANG designer can reuse this meta-data without >> advertising the 'main' module with mandatory objects, rpcs, and >> notifications. >> >> This simple workaround should cover most use-cases and may prove to be >> better organization in the long-run. It has proven to be effective in >> SMIv2-land. >> >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Sun Aug 26 08:51:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D104321F8487 for ; Sun, 26 Aug 2012 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDblJUSuHcvs for ; Sun, 26 Aug 2012 08:51:10 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 476C721F851C for ; Sun, 26 Aug 2012 08:51:08 -0700 (PDT) Received: by qadz3 with SMTP id z3so1346761qad.10 for ; Sun, 26 Aug 2012 08:51:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=uYILyGCC3lo2jhbT5Gx+F3xR5eohlaK57ImQtnTL3aY=; b=Q8TwjBRVCxhRGMVp7EY0iCSIYcMrlLO81gs8TyU75LJokkIpY75M/VWc7+usfrTmJt 2S6Yr38U/89yufQf4bCsGnIEoRuw6nyc85BW66sQ72QTWjhDgn9SYrb+0qzbGeF6Wcct +g3Y8HAgQ91b0Hb9i2QYcHOUvxuMFIn88mR/uFmZNSR7D6VaBZapcJE8jLrb3XPeHqbH 84tC3gIL5F/avJNrtJMCWW+fhw6OztU/0ZrTWft0KWo8u+adnYWnE/BQxgDSOnFGMUsI KCzJdxY9RQp/PpyOkBEl2ndQzT40N8poaoYpvPLwMiPzH5SSjYf1hjkMmf1G/zVGQEpO yTdQ== MIME-Version: 1.0 Received: by 10.224.42.17 with SMTP id q17mr4122802qae.11.1345996267512; Sun, 26 Aug 2012 08:51:07 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Sun, 26 Aug 2012 08:51:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Aug 2012 08:51:07 -0700 Message-ID: From: Andy Bierman To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnw8f+1oKCITgbfk+VqJBvISIsW500K+28DwYTYOLXL1G857F8XxAy9E4ygyXXtXCAGxltn Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 15:51:10 -0000 On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) wrote: > Hi Andy, > > Can you give an example of what you are proposing using one of the YANG > modules currently in progress? I am not sure that I understand exactly > what you are proposing, in SMIv2 we (try to) separate the reusable TCs, > we do not separate conformance clauses. > I picked the simplest example -- typedefs. If you consider top-level groupings, then YANG conformance gets really murky. Where is the conformance applied? In module A which defines the grouping but does not use it anywhere, or in module B which imports the grouping and uses it? Or in module B, which imports and uses it with refinements? Seems to me that meta-data in YANG (features, typedefs, extensions, identities, groupings) have no conformance requirements whatsoever until they are used in a data-def-stmt. Even if module B imports a data-def-stmt from module A in order to augment it, it is not clear that module B inherits all the conformance requirements for all of module A. There is a perception that the NETCONF tells the client all it needs to know about the server schema inventory and conformance levels, but this far from accurate. > Thanks and Regards, > > Dan Andy > > > >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf >> Of Andy Bierman >> Sent: Thursday, August 23, 2012 10:44 PM >> To: netmod@ietf.org >> Subject: [netmod] followup on YANG conformance >> >> Hi, >> >> The WG is not very interested in this topic, but I strongly suggest > that >> all NETMOD WG modules in progress be split into >> 2 modules if there are any reusable typedefs, groupings, extensions, >> features, and/or identities. These should go in a separate YANG > module >> so a server and YANG designer can reuse this meta-data without >> advertising the 'main' module with mandatory objects, rpcs, and >> notifications. >> >> This simple workaround should cover most use-cases and may prove to be >> better organization in the long-run. It has proven to be effective in >> SMIv2-land. >> >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From dromasca@avaya.com Mon Aug 27 01:27:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D7021F8526 for ; Mon, 27 Aug 2012 01:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.436 X-Spam-Level: X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDl4NVTsgXc3 for ; Mon, 27 Aug 2012 01:27:22 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5E421F8581 for ; Mon, 27 Aug 2012 01:27:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPguO1CHCzI1/2dsb2JhbABFhgOzfHOBB4IgAQEBAQIBAQEBDxENBDoLDAQCAQgNBAQBAQECAgYGDAsBAgICAQElHwkIAQEEEwgTB4dlBgudD4odkkUEgSGJZ4V/MmADm1OKF4Jl X-IronPort-AV: E=Sophos;i="4.77,834,1336363200"; d="scan'208";a="363999504" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Aug 2012 04:22:39 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Aug 2012 04:05:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 27 Aug 2012 10:26:15 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] followup on YANG conformance Thread-Index: Ac2DoqU1wdInmkz8RRiuzUDwwXl5YgAipiow References: From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:27:22 -0000 U28gdGhlIHNvbHV0aW9uIHRoYXQgeW91IGFyZSBwcm9wb3NpbmcgaXMgdG8gYnJlYWsgYXdheSB0 eXBlZGVmcyBpbiBzZXBhcmF0ZSBZQU5HIG1vZHVsZXMgZm9yIGVhY2ggc3RhbmRhcmQgbW9kdWxl PyANCg0KRGFuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmR5 IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo+IFNlbnQ6IFN1bmRheSwgQXVn dXN0IDI2LCAyMDEyIDY6NTEgUE0NCj4gVG86IFJvbWFzY2FudSwgRGFuIChEYW4pDQo+IENjOiBu ZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGZvbGxvd3VwIG9uIFlBTkcg Y29uZm9ybWFuY2UNCj4gDQo+IE9uIFNhdCwgQXVnIDI1LCAyMDEyIGF0IDEwOjM2IFBNLCBSb21h c2NhbnUsIERhbiAoRGFuKQ0KPiA8ZHJvbWFzY2FAYXZheWEuY29tPiB3cm90ZToNCj4gPiBIaSBB bmR5LA0KPiA+DQo+ID4gQ2FuIHlvdSBnaXZlIGFuIGV4YW1wbGUgb2Ygd2hhdCB5b3UgYXJlIHBy b3Bvc2luZyB1c2luZyBvbmUgb2YgdGhlDQo+ID4gWUFORyBtb2R1bGVzIGN1cnJlbnRseSBpbiBw cm9ncmVzcz8gSSBhbSBub3Qgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZA0KPiA+IGV4YWN0bHkgd2hh dCB5b3UgYXJlIHByb3Bvc2luZywgaW4gU01JdjIgd2UgKHRyeSB0bykgc2VwYXJhdGUgdGhlDQo+ ID4gcmV1c2FibGUgVENzLCB3ZSBkbyBub3Qgc2VwYXJhdGUgY29uZm9ybWFuY2UgY2xhdXNlcy4N Cj4gPg0KPiANCj4gSSBwaWNrZWQgdGhlIHNpbXBsZXN0IGV4YW1wbGUgLS0gdHlwZWRlZnMuDQo+ IA0KPiBJZiB5b3UgY29uc2lkZXIgdG9wLWxldmVsIGdyb3VwaW5ncywgdGhlbiBZQU5HIGNvbmZv cm1hbmNlIGdldHMgcmVhbGx5DQo+IG11cmt5Lg0KPiBXaGVyZSBpcyB0aGUgY29uZm9ybWFuY2Ug YXBwbGllZD8gIEluIG1vZHVsZSBBIHdoaWNoIGRlZmluZXMgdGhlDQo+IGdyb3VwaW5nIGJ1dCBk b2VzIG5vdCB1c2UgaXQgYW55d2hlcmUsIG9yIGluIG1vZHVsZSBCIHdoaWNoIGltcG9ydHMgdGhl DQo+IGdyb3VwaW5nIGFuZCB1c2VzIGl0PyAgT3IgaW4gbW9kdWxlIEIsIHdoaWNoIGltcG9ydHMg YW5kIHVzZXMgaXQgd2l0aA0KPiByZWZpbmVtZW50cz8NCj4gDQo+IFNlZW1zIHRvIG1lIHRoYXQg bWV0YS1kYXRhIGluIFlBTkcgKGZlYXR1cmVzLCB0eXBlZGVmcywgZXh0ZW5zaW9ucywNCj4gaWRl bnRpdGllcywgZ3JvdXBpbmdzKSBoYXZlIG5vIGNvbmZvcm1hbmNlIHJlcXVpcmVtZW50cyB3aGF0 c29ldmVyIHVudGlsDQo+IHRoZXkgYXJlIHVzZWQgaW4gYSBkYXRhLWRlZi1zdG10Lg0KPiANCj4g RXZlbiBpZiBtb2R1bGUgQiBpbXBvcnRzIGEgZGF0YS1kZWYtc3RtdCBmcm9tIG1vZHVsZSBBIGlu IG9yZGVyIHRvDQo+IGF1Z21lbnQgaXQsIGl0IGlzIG5vdCBjbGVhciB0aGF0IG1vZHVsZSBCIGlu aGVyaXRzIGFsbCB0aGUgY29uZm9ybWFuY2UNCj4gcmVxdWlyZW1lbnRzIGZvciBhbGwgb2YgbW9k dWxlIEEuDQo+IA0KPiBUaGVyZSBpcyBhIHBlcmNlcHRpb24gdGhhdCB0aGUgTkVUQ09ORiA8aGVs bG8+IHRlbGxzIHRoZSBjbGllbnQgYWxsIGl0DQo+IG5lZWRzIHRvIGtub3cgYWJvdXQgdGhlIHNl cnZlciBzY2hlbWEgaW52ZW50b3J5IGFuZCBjb25mb3JtYW5jZSBsZXZlbHMsDQo+IGJ1dCB0aGlz IGZhciBmcm9tIGFjY3VyYXRlLg0KPiANCj4gDQo+ID4gVGhhbmtzIGFuZCBSZWdhcmRzLA0KPiA+ DQo+ID4gRGFuDQo+IA0KPiBBbmR5DQo+IA0KPiA+DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+IEJlaGFsZg0KPiA+PiBPZiBBbmR5 IEJpZXJtYW4NCj4gPj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMywgMjAxMiAxMDo0NCBQTQ0K PiA+PiBUbzogbmV0bW9kQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFtuZXRtb2RdIGZvbGxvd3Vw IG9uIFlBTkcgY29uZm9ybWFuY2UNCj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+IFRoZSBXRyBp cyBub3QgdmVyeSBpbnRlcmVzdGVkIGluIHRoaXMgdG9waWMsIGJ1dCBJIHN0cm9uZ2x5IHN1Z2dl c3QNCj4gPiB0aGF0DQo+ID4+IGFsbCBORVRNT0QgV0cgbW9kdWxlcyBpbiBwcm9ncmVzcyBiZSBz cGxpdCBpbnRvDQo+ID4+IDIgbW9kdWxlcyBpZiB0aGVyZSBhcmUgYW55IHJldXNhYmxlIHR5cGVk ZWZzLCBncm91cGluZ3MsIGV4dGVuc2lvbnMsDQo+ID4+IGZlYXR1cmVzLCBhbmQvb3IgaWRlbnRp dGllcy4gIFRoZXNlIHNob3VsZCBnbyBpbiBhIHNlcGFyYXRlIFlBTkcNCj4gPiBtb2R1bGUNCj4g Pj4gc28gYSBzZXJ2ZXIgYW5kIFlBTkcgZGVzaWduZXIgY2FuIHJldXNlIHRoaXMgbWV0YS1kYXRh IHdpdGhvdXQNCj4gPj4gYWR2ZXJ0aXNpbmcgdGhlICdtYWluJyBtb2R1bGUgd2l0aCBtYW5kYXRv cnkgb2JqZWN0cywgcnBjcywgYW5kDQo+ID4+IG5vdGlmaWNhdGlvbnMuDQo+ID4+DQo+ID4+IFRo aXMgc2ltcGxlIHdvcmthcm91bmQgc2hvdWxkIGNvdmVyIG1vc3QgdXNlLWNhc2VzIGFuZCBtYXkg cHJvdmUgdG8NCj4gPj4gYmUgYmV0dGVyIG9yZ2FuaXphdGlvbiBpbiB0aGUgbG9uZy1ydW4uICBJ dCBoYXMgcHJvdmVuIHRvIGJlDQo+ID4+IGVmZmVjdGl2ZSBpbiBTTUl2Mi1sYW5kLg0KPiA+Pg0K PiA+Pg0KPiA+PiBBbmR5DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPj4gbmV0bW9kQGlldGYu b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From lhotka@nic.cz Mon Aug 27 02:10:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9907E21F85F4 for ; Mon, 27 Aug 2012 02:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuF3O99jC2Rs for ; Mon, 27 Aug 2012 02:10:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A548E21F8581 for ; Mon, 27 Aug 2012 02:10:00 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id F247D1410A9; Mon, 27 Aug 2012 11:09:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1346058599; bh=cWaVU6mSliYPAeASam3FNfahdprZ5kpmWeguwlNuCHI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Hcj2ooXqRqAhEqnTFGG0jAkO9qo4EZSq0om1hP9FkpZj4wG8gmDTUZKQ5U4roUowq J8VHeCQ67Bq3PQe0avY6yke7VfY9xBNVcINZqOSQBYpT+DrMSFxryl/F9Fk7rdFxVr 7IsU/MJ9YfpZcCLbP5qunsZkwQ49dIuocMqTvVYo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 27 Aug 2012 11:09:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A5B91B4-0D16-4EB8-AA2C-463CD369FB3D@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1485) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:10:01 -0000 On Aug 26, 2012, at 5:20 PM, Andy Bierman wrote: > On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) > wrote: >> Hi Andy, >>=20 >> Can you give an example of what you are proposing using one of the = YANG >> modules currently in progress? I am not sure that I understand = exactly >> what you are proposing, in SMIv2 we (try to) separate the reusable = TCs, >> we do not separate conformance clauses. >>=20 >=20 > We have no explicit module conformance mechanisms in NETCONF/YANG, > other than the YANG module capability in the message. >=20 > So if I want to use the 'crypt-hash' typedef in 1 of my modules (or > another IETF module), then I have to import ietf-system. > In order to tell the client which 'ietf-system' (remember YANG module = names > are not even intended to be unique) I have to advertise ietf-system in > the server . I think in this case ietf-system is not advertized and the client should = be able to find out which version of ietf-system was imported from the = importing module (which is advertised). >=20 > The client will think I implement the /system container, which is not = correct. >=20 > So if the crypt-hash typedef was in the ietf-system-types module = instead, > I would not have to import ietf-system -- I could import = ietf-system-types. > That way the client will not see ietf-system advertised unless the > server really implements the /system container. So how would the client determine which version of ietf-system-types was = imported? I don't see any difference. Lada >=20 >=20 >> Thanks and Regards, >>=20 >> Dan >>=20 >=20 > Andy >=20 >>=20 >>=20 >>> -----Original Message----- >>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >> Behalf >>> Of Andy Bierman >>> Sent: Thursday, August 23, 2012 10:44 PM >>> To: netmod@ietf.org >>> Subject: [netmod] followup on YANG conformance >>>=20 >>> Hi, >>>=20 >>> The WG is not very interested in this topic, but I strongly suggest >> that >>> all NETMOD WG modules in progress be split into >>> 2 modules if there are any reusable typedefs, groupings, extensions, >>> features, and/or identities. These should go in a separate YANG >> module >>> so a server and YANG designer can reuse this meta-data without >>> advertising the 'main' module with mandatory objects, rpcs, and >>> notifications. >>>=20 >>> This simple workaround should cover most use-cases and may prove to = be >>> better organization in the long-run. It has proven to be effective = in >>> SMIv2-land. >>>=20 >>>=20 >>> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Aug 27 02:20:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BC621F8606 for ; Mon, 27 Aug 2012 02:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX0hyz5OZDfR for ; Mon, 27 Aug 2012 02:20:13 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1293C21F851B for ; Mon, 27 Aug 2012 02:20:12 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C37651200AEC; Mon, 27 Aug 2012 11:20:10 +0200 (CEST) Date: Mon, 27 Aug 2012 11:20:10 +0200 (CEST) Message-Id: <20120827.112010.231213491159244583.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <3A5B91B4-0D16-4EB8-AA2C-463CD369FB3D@nic.cz> References: <3A5B91B4-0D16-4EB8-AA2C-463CD369FB3D@nic.cz> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:20:13 -0000 Ladislav Lhotka wrote: > > On Aug 26, 2012, at 5:20 PM, Andy Bierman wrote: > > > On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) > > wrote: > >> Hi Andy, > >> > >> Can you give an example of what you are proposing using one of the > >> YANG > >> modules currently in progress? I am not sure that I understand exactly > >> what you are proposing, in SMIv2 we (try to) separate the reusable > >> TCs, > >> we do not separate conformance clauses. > >> > > > > We have no explicit module conformance mechanisms in NETCONF/YANG, > > other than the YANG module capability in the message. > > > > So if I want to use the 'crypt-hash' typedef in 1 of my modules (or > > another IETF module), then I have to import ietf-system. > > In order to tell the client which 'ietf-system' (remember YANG module > > names > > are not even intended to be unique) I have to advertise ietf-system in > > the server . > > I think in this case ietf-system is not advertized and the client > should be able to find out which version of ietf-system was imported > from the importing module (which is advertised). But if the importing module did not use import by revision, the client does not know which version the server used. This can be solved by checking the /netconf-state/schema/schema list. This works for typedefs, groupings, extensions, but not identities. In order for a server/client to be able to recognize an identity, the module where the identity is defined must be advertised. > > The client will think I implement the /system container, which is not > > correct. > > > > So if the crypt-hash typedef was in the ietf-system-types module > > instead, > > I would not have to import ietf-system -- I could import > > ietf-system-types. > > That way the client will not see ietf-system advertised unless the > > server really implements the /system container. > > So how would the client determine which version of ietf-system-types > was imported? > I don't see any difference. B/c the ietf-system-types module would be advertised, together with its revision. /martin From jernej.tuljak@mg-soft.si Mon Aug 27 02:55:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E167921F8615 for ; Mon, 27 Aug 2012 02:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF8uW7UMbt1q for ; Mon, 27 Aug 2012 02:55:37 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 08F3321F8471 for ; Mon, 27 Aug 2012 02:55:36 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q7R9tYdf031361; Mon, 27 Aug 2012 11:55:35 +0200 Message-ID: <503B4415.7030705@mg-soft.com> Date: Mon, 27 Aug 2012 11:55:33 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <3A5B91B4-0D16-4EB8-AA2C-463CD369FB3D@nic.cz> In-Reply-To: <3A5B91B4-0D16-4EB8-AA2C-463CD369FB3D@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:55:38 -0000 Dne 27.8.2012 11:09, piše Ladislav Lhotka: > On Aug 26, 2012, at 5:20 PM, Andy Bierman wrote: > >> On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) >> wrote: >>> Hi Andy, >>> >>> Can you give an example of what you are proposing using one of the YANG >>> modules currently in progress? I am not sure that I understand exactly >>> what you are proposing, in SMIv2 we (try to) separate the reusable TCs, >>> we do not separate conformance clauses. >>> >> We have no explicit module conformance mechanisms in NETCONF/YANG, >> other than the YANG module capability in the message. >> >> So if I want to use the 'crypt-hash' typedef in 1 of my modules (or >> another IETF module), then I have to import ietf-system. >> In order to tell the client which 'ietf-system' (remember YANG module names >> are not even intended to be unique) I have to advertise ietf-system in >> the server. > I think in this case ietf-system is not advertized and the client should be able to find out which version of ietf-system was imported from the importing module (which is advertised). I disagree. A server MUST advertise all revisions of all modules it implements (RFC6020 5.6.4.1). When you import a module into another module as a modeler, you are currently creating a union of them, automatically saying that an implementer must implement both of them entirely, unless the imported module makes smart use of features. "Partial advertising" cannot be done. Jernej > >> The client will think I implement the /system container, which is not correct. >> >> So if the crypt-hash typedef was in the ietf-system-types module instead, >> I would not have to import ietf-system -- I could import ietf-system-types. >> That way the client will not see ietf-system advertised unless the >> server really implements the /system container. > So how would the client determine which version of ietf-system-types was imported? > I don't see any difference. > > Lada > >> >>> Thanks and Regards, >>> >>> Dan >>> >> Andy >> >>> >>>> -----Original Message----- >>>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >>> Behalf >>>> Of Andy Bierman >>>> Sent: Thursday, August 23, 2012 10:44 PM >>>> To: netmod@ietf.org >>>> Subject: [netmod] followup on YANG conformance >>>> >>>> Hi, >>>> >>>> The WG is not very interested in this topic, but I strongly suggest >>> that >>>> all NETMOD WG modules in progress be split into >>>> 2 modules if there are any reusable typedefs, groupings, extensions, >>>> features, and/or identities. These should go in a separate YANG >>> module >>>> so a server and YANG designer can reuse this meta-data without >>>> advertising the 'main' module with mandatory objects, rpcs, and >>>> notifications. >>>> >>>> This simple workaround should cover most use-cases and may prove to be >>>> better organization in the long-run. It has proven to be effective in >>>> SMIv2-land. >>>> >>>> >>>> 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 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From jernej.tuljak@mg-soft.si Mon Aug 27 02:58:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B02321F8518 for ; Mon, 27 Aug 2012 02:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smor1r5IXIUx for ; Mon, 27 Aug 2012 02:58:15 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB121F8462 for ; Mon, 27 Aug 2012 02:58:14 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q7R9wCjJ031420; Mon, 27 Aug 2012 11:58:12 +0200 Message-ID: <503B44B4.4000803@mg-soft.com> Date: Mon, 27 Aug 2012 11:58:12 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:58:15 -0000 Dne 23.8.2012 21:43, piše Andy Bierman: > Hi, > > The WG is not very interested in this topic, but I strongly suggest > that all NETMOD WG modules in progress be split into > 2 modules if there are any reusable typedefs, groupings, extensions, > features, and/or identities. These should go in a separate YANG module > so a server and YANG designer can reuse this meta-data without > advertising the 'main' module with mandatory objects, rpcs, and notifications. > > This simple workaround should cover most use-cases and may > prove to be better organization in the long-run. It has proven > to be effective in SMIv2-land. An alternative to making a "header" and an "implementation" version of each standard module would be to put a feature in them which would enable or disable a module's data tree. It would be clear whether a module is just being used for definitions or for it's data tree when advertised in the hello message. This would be a pure YANG solution. With feature implementation; the following http://example.com/some-module?module=some-module&revision=2008-04-01&feature=implementation would indicate that the entire module is implemented on server, and the following http://example.com/some-module?module=some-module&revision=2008-04-01 would mean that some other module just imports this module for it's definitions. I believe this would be a far more elegant solution that having a module split into two. Not sure if this is backwards compatible for existing modules though. Also it could be problematic to impose such a requirement on each top-level data definition statement. Jernej > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Mon Aug 27 05:04:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03D21F8616 for ; Mon, 27 Aug 2012 05:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K99uTfUqxymt for ; Mon, 27 Aug 2012 05:04:17 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A134F21F8610 for ; Mon, 27 Aug 2012 05:04:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A265454029C for ; Mon, 27 Aug 2012 14:04:14 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4Ceu2styOZM for ; Mon, 27 Aug 2012 14:04:10 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 802295401DB for ; Mon, 27 Aug 2012 14:04:10 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <503B4415.7030705@mg-soft.com> References: <3A5B91B4-0D16-4EB8-AA2C-463CD369FB3D@nic.cz> <503B4415.7030705@mg-soft.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 27 Aug 2012 14:04:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:04:17 -0000 Jernej Tuljak writes: > Dne 27.8.2012 11:09, pi=C5=A1e Ladislav Lhotka: >> On Aug 26, 2012, at 5:20 PM, Andy Bierman wrote: >> >>> On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) >>> wrote: >>>> Hi Andy, >>>> >>>> Can you give an example of what you are proposing using one of the YANG >>>> modules currently in progress? I am not sure that I understand exactly >>>> what you are proposing, in SMIv2 we (try to) separate the reusable TCs, >>>> we do not separate conformance clauses. >>>> >>> We have no explicit module conformance mechanisms in NETCONF/YANG, >>> other than the YANG module capability in the message. >>> >>> So if I want to use the 'crypt-hash' typedef in 1 of my modules (or >>> another IETF module), then I have to import ietf-system. >>> In order to tell the client which 'ietf-system' (remember YANG module n= ames >>> are not even intended to be unique) I have to advertise ietf-system in >>> the server. >> I think in this case ietf-system is not advertized and the client should= be able to find out which version of ietf-system was imported from the imp= orting module (which is advertised). > > I disagree. A server MUST advertise all revisions of all modules it=20 > implements (RFC6020 5.6.4.1). > > When you import a module into another module as a modeler, you are=20 > currently creating a union of them, automatically saying that an=20 > implementer must implement both of them entirely, unless the imported=20 > module makes smart use of features. "Partial advertising" cannot be done. No. This is pretty counter-intuitive, but see http://www.ietf.org/mail-archive/web/yang/current/msg00455.html Lada > > Jernej > >> >>> The client will think I implement the /system container, which is not c= orrect. >>> >>> So if the crypt-hash typedef was in the ietf-system-types module instea= d, >>> I would not have to import ietf-system -- I could import ietf-system-ty= pes. >>> That way the client will not see ietf-system advertised unless the >>> server really implements the /system container. >> So how would the client determine which version of ietf-system-types was= imported? >> I don't see any difference. >> >> Lada >> >>> >>>> Thanks and Regards, >>>> >>>> Dan >>>> >>> Andy >>> >>>> >>>>> -----Original Message----- >>>>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >>>> Behalf >>>>> Of Andy Bierman >>>>> Sent: Thursday, August 23, 2012 10:44 PM >>>>> To: netmod@ietf.org >>>>> Subject: [netmod] followup on YANG conformance >>>>> >>>>> Hi, >>>>> >>>>> The WG is not very interested in this topic, but I str --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Aug 27 06:57:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEC921F86AB for ; Mon, 27 Aug 2012 06:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajswLi7EYoGY for ; Mon, 27 Aug 2012 06:57:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BA65E21F8671 for ; Mon, 27 Aug 2012 06:56:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1E0E854029C for ; Mon, 27 Aug 2012 15:56:58 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtKwBbHl5IvJ for ; Mon, 27 Aug 2012 15:56:54 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 52FFD5401C0 for ; Mon, 27 Aug 2012 15:56:53 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120827.112010.231213491159244583.mbj@tail-f.com> References: <3A5B91B4-0D16-4EB8-AA2C-463CD369FB3D@nic.cz> <20120827.112010.231213491159244583.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 27 Aug 2012 15:56:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:57:01 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> >> On Aug 26, 2012, at 5:20 PM, Andy Bierman wrote: >> >> > On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) >> > wrote: >> >> Hi Andy, >> >> >> >> Can you give an example of what you are proposing using one of the >> >> YANG >> >> modules currently in progress? I am not sure that I understand exactly >> >> what you are proposing, in SMIv2 we (try to) separate the reusable >> >> TCs, >> >> we do not separate conformance clauses. >> >> >> > >> > We have no explicit module conformance mechanisms in NETCONF/YANG, >> > other than the YANG module capability in the message. >> > >> > So if I want to use the 'crypt-hash' typedef in 1 of my modules (or >> > another IETF module), then I have to import ietf-system. >> > In order to tell the client which 'ietf-system' (remember YANG module >> > names >> > are not even intended to be unique) I have to advertise ietf-system in >> > the server . >> >> I think in this case ietf-system is not advertized and the client >> should be able to find out which version of ietf-system was imported >> from the importing module (which is advertised). > > But if the importing module did not use import by revision, the client > does not know which version the server used. This can be solved by Yes, but the same problem is with include - and submodules cannot be advertised in . > checking the /netconf-state/schema/schema list. Right, perhaps this "RESTful" approach is best - each client can decide which conformance info has to be checked. > > This works for typedefs, groupings, extensions, but not identities. > In order for a server/client to be able to recognize an identity, the > module where the identity is defined must be advertised. > >> > The client will think I implement the /system container, which is not >> > correct. >> > >> > So if the crypt-hash typedef was in the ietf-system-types module >> > instead, >> > I would not have to import ietf-system -- I could import >> > ietf-system-types. >> > That way the client will not see ietf-system advertised unless the >> > server really implements the /system container. >> >> So how would the client determine which version of ietf-system-types >> was imported? >> I don't see any difference. > > B/c the ietf-system-types module would be advertised, together with > its revision. But then the import statement seems redundant, perhaps useful only as a way for declaring an abbreviation (prefix) for a module name within the importing module. I think Andy has a point, but I am not sure that splitting the modules is the right solution - for one, it would double the number of modules, namespaces and prefixes. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 27 07:10:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3AF21F8648 for ; Mon, 27 Aug 2012 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjTBseboPE64 for ; Mon, 27 Aug 2012 07:10:39 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D889221F865B for ; Mon, 27 Aug 2012 07:10:38 -0700 (PDT) Received: by qan41 with SMTP id 41so1604873qan.10 for ; Mon, 27 Aug 2012 07:10:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=40SI2s3SzfYbbgl0KZAvD8V1wLtV+AH5UVvaAWuTEpA=; b=pEV9ulANBdyo55MxDu4jpjRIiknS7Rw4idsPPGgXeuWhdtzkZAMGrP/hU1I3jF3Um8 sJ+cXNUZuuNSwi9flVux4H5FMSCO7a+vmGJ8gsO2AGQxQckMhOoigbkZBiFVBv3DhwnS bINEek9xNKQJwN/1RnUsnpPcabCuO8wdVUfSPYDnBNskQCKV2/qc3wiPug+x/gwrd62t ebtMi+wx9ew+WJlkiE9RuAmTrKb3OrJjaHkv9YXRmhanMdbQSLixDUAb7Cfg7Dbc0x4J hacpYQSqHXDbGQHMSOLHKbuQdHzP/cs2ya2GhrFRiGAcvrDA2nZo7+ldQBISsRhBd3T2 Ya4A== MIME-Version: 1.0 Received: by 10.224.42.17 with SMTP id q17mr8731273qae.11.1346076638240; Mon, 27 Aug 2012 07:10:38 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 27 Aug 2012 07:10:38 -0700 (PDT) In-Reply-To: <503B44B4.4000803@mg-soft.com> References: <503B44B4.4000803@mg-soft.com> Date: Mon, 27 Aug 2012 07:10:38 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn5y01Ex/cDgnudVA80Mr15NyIpCV5t2vIS8GKZeZB7Y8i/w1z4nzVneSCFYzPgc0mgNCOg Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:10:39 -0000 On Mon, Aug 27, 2012 at 2:58 AM, Jernej Tuljak w= rote: > Dne 23.8.2012 21:43, pi=C5=A1e Andy Bierman: >> >> Hi, >> >> The WG is not very interested in this topic, but I strongly suggest >> that all NETMOD WG modules in progress be split into >> 2 modules if there are any reusable typedefs, groupings, extensions, >> features, and/or identities. These should go in a separate YANG module >> so a server and YANG designer can reuse this meta-data without >> advertising the 'main' module with mandatory objects, rpcs, and >> notifications. >> >> This simple workaround should cover most use-cases and may >> prove to be better organization in the long-run. It has proven >> to be effective in SMIv2-land. > > > An alternative to making a "header" and an "implementation" version of ea= ch > standard module would be to put a feature in them which would enable or > disable a module's data tree. It would be clear whether a module is just > being used for definitions or for it's data tree when advertised in the > hello message. This would be a pure YANG solution. > This would make all YANG objects optional-to-implement as well. A YANG feature is advertised at the whim of the server developer. YANG conformance needs something more like the when-stmt for conformance, not an arbitrary AND-expr. The "expressiveness" of YANG conformance is already extremely limited. I would not want to make that even worse. Import/include by revision is mostly broken, and if you don't understand why, just use it in your own YANG modules for awhile. Every time you update the imported YANG module, you have to go change all the import-stmts to the new date. Otherwise you end up using and advertising multiple revisions of the same YANG module= , instead of just the latest revision. There are corner-cases where you might want multiple revisions, but they are rare -- almost always you want just the latest revision supported by the server. Andy > With > > feature implementation; > > the following > > http://example.com/some-module?module=3Dsome-module&revision=3D2008-04-01= &feature=3Dimplementation > > would indicate that the entire module is implemented on server, and the > following > > http://example.com/some-module?module=3Dsome-module&revision=3D2008-04-01 > > would mean that some other module just imports this module for it's > definitions. I believe this would be a far more elegant solution that hav= ing > a module split into two. Not sure if this is backwards compatible for > existing modules though. Also it could be problematic to impose such a > requirement on each top-level data definition statement. > > Jernej > >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > From phil@juniper.net Mon Aug 27 07:16:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CBE21F86BB for ; Mon, 27 Aug 2012 07:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwRCpimKea4A for ; Mon, 27 Aug 2012 07:16:17 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7135521F86B9 for ; Mon, 27 Aug 2012 07:16:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUDuBJ1HCntnWCPmWq6OyEyKD+PQx2bSq@postini.com; Mon, 27 Aug 2012 07:16:17 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Aug 2012 07:13: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 q7REDRh00568; Mon, 27 Aug 2012 07:13:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7RECQWk003640; Mon, 27 Aug 2012 10:12:46 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208271412.q7RECQWk003640@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20120824.213827.520095880.mbj@tail-f.com> Date: Mon, 27 Aug 2012 10:12:25 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:16:18 -0000 Martin Bjorklund writes: >An alternative is to simply make the "enabled" leaf have "false" as >default value. With "ipv4" being a P-container, what exactly is the >meaning of its presence? Giving a box an IP address turns on ip by default. This seems like a natural fit. One can disable it if needed, but the normal case is trivial. Thanks, Phil From andy@yumaworks.com Mon Aug 27 07:45:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1224121F86BA for ; Mon, 27 Aug 2012 07:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqoEPBvGrZeA for ; Mon, 27 Aug 2012 07:45:28 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6BB21F8456 for ; Mon, 27 Aug 2012 07:45:28 -0700 (PDT) Received: by qcac10 with SMTP id c10so3054762qca.31 for ; Mon, 27 Aug 2012 07:45:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=++IW3rCobbXEOLc8oIRK4X2asear6s6OAMcbp8UwIRM=; b=Ru4pWVb11tFkEZCfaQkLdKfwamCJEKkuNUHkwzMHQIByuVBddfL5arM4d2j7oQrOBX 6VHtchcn0mTV2agyGAhmPTpcdorxypTt1b32faYyBuVvAguxRheVgN9Wbqu0jqdjv6Q0 M4+wvfQ/sYZOwPhteXyYd7bQhjtUBKYjsdF51i0C2vKznhKmJDoGeJRN+1fBBojoEhoM HP5IulXLW1GeIKicGl19HrtKWE84wHqaEOfQOCtcw/9Wt4zLKG71OEeFD52UyaZgRM0Q 6n7IE5zjtF4w/RNFJPUzIevi10BqZY1rJCN6oHibczVQ3a0t9L1H294GKHGRPzYIJSfN O7ww== MIME-Version: 1.0 Received: by 10.224.199.201 with SMTP id et9mr23966493qab.59.1346078727957; Mon, 27 Aug 2012 07:45:27 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 27 Aug 2012 07:45:27 -0700 (PDT) In-Reply-To: <201208271412.q7RECQWk003640@idle.juniper.net> References: <20120824.213827.520095880.mbj@tail-f.com> <201208271412.q7RECQWk003640@idle.juniper.net> Date: Mon, 27 Aug 2012 07:45:27 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkqyoxQc5wqA4Gm05FIsa5b7uHi/kPjVa++kU4fy6CCqNMyq1WYpyqGZOmAWbh1rBxYqKFt Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:45:29 -0000 On Mon, Aug 27, 2012 at 7:12 AM, Phil Shafer wrote: > Martin Bjorklund writes: >>An alternative is to simply make the "enabled" leaf have "false" as >>default value. With "ipv4" being a P-container, what exactly is the >>meaning of its presence? > > Giving a box an IP address turns on ip by default. This seems > like a natural fit. One can disable it if needed, but the > normal case is trivial. > Is this universal, or just Junos? So should the 'enabled' leaf be removed? What needs to change in the YANG modules? IMO, we need a generic mechanism for disabling config, not a bunch of 'enabled' leafs all over the place. > Thanks, > Phil Andy From xiangli@seguesoft.com Mon Aug 27 07:45:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9113121F86C5 for ; Mon, 27 Aug 2012 07:45: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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdlDq3PLB+Fh for ; Mon, 27 Aug 2012 07:45:32 -0700 (PDT) Received: from m1plsmtpa01-04.prod.mesa1.secureserver.net (m1plsmtpa01-04.prod.mesa1.secureserver.net [64.202.165.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E43321F86C4 for ; Mon, 27 Aug 2012 07:45:32 -0700 (PDT) Received: from [192.168.2.10] ([98.212.151.151]) by m1plsmtpa01-04.prod.mesa1.secureserver.net with id rqlW1j0043GEayi01qlX20; Mon, 27 Aug 2012 07:45:31 -0700 Message-ID: <503B880B.7000301@seguesoft.com> Date: Mon, 27 Aug 2012 09:45:31 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070608050508050400070905" Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:45:33 -0000 This is a multi-part message in MIME format. --------------070608050508050400070905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/26/2012 10:20 AM, Andy Bierman wrote: > On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) > wrote: >> Hi Andy, >> >> Can you give an example of what you are proposing using one of the YANG >> modules currently in progress? I am not sure that I understand exactly >> what you are proposing, in SMIv2 we (try to) separate the reusable TCs, >> we do not separate conformance clauses. >> > We have no explicit module conformance mechanisms in NETCONF/YANG, > other than the YANG module capability in the message. > > So if I want to use the 'crypt-hash' typedef in 1 of my modules (or > another IETF module), then I have to import ietf-system. > In order to tell the client which 'ietf-system' (remember YANG module names > are not even intended to be unique) I have to advertise ietf-system in > the server . > > The client will think I implement the /system container, which is not correct. Can this be solved by adding an additional attribute to the advertised hello. RFC6020 5.6.4 . Announcing Conformance Information in the Messag The namespace URI MUST be advertised as a capability in the NETCONF message to indicate support for the YANG module by a NETCONF server. The capability URI advertised MUST be of the form: capability-string = namespace-uri [ parameter-list ] parameter-list = "?" parameter *( "&" parameter ) parameter = revision-parameter / module-parameter / feature-parameter / deviation-parameter / implementation-parameter ==>Add this flag? For example, if you are just using the typedefs in foo-module, instead of advertising: http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01 Can we do http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01&implementation=false This way, the client knows foo-module is only needed and advertised for name access? --Xiang > > So if the crypt-hash typedef was in the ietf-system-types module instead, > I would not have to import ietf-system -- I could import ietf-system-types. > That way the client will not see ietf-system advertised unless the > server really implements the /system container. > > >> Thanks and Regards, >> >> Dan >> > Andy > >> >>> -----Original Message----- >>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >> Behalf >>> Of Andy Bierman >>> Sent: Thursday, August 23, 2012 10:44 PM >>> To: netmod@ietf.org >>> Subject: [netmod] followup on YANG conformance >>> >>> Hi, >>> >>> The WG is not very interested in this topic, but I strongly suggest >> that >>> all NETMOD WG modules in progress be split into >>> 2 modules if there are any reusable typedefs, groupings, extensions, >>> features, and/or identities. These should go in a separate YANG >> module >>> so a server and YANG designer can reuse this meta-data without >>> advertising the 'main' module with mandatory objects, rpcs, and >>> notifications. >>> >>> This simple workaround should cover most use-cases and may prove to be >>> better organization in the long-run. It has proven to be effective in >>> SMIv2-land. >>> >>> >>> 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 -- --Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 Mobile: 1 (217) 472-4108 --------------070608050508050400070905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/26/2012 10:20 AM, Andy Bierman wrote:
On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan)
<dromasca@avaya.com> wrote:

Hi Andy,

Can you give an example of what you are proposing using one of the YANG
modules currently in progress? I am not sure that I understand exactly
what you are proposing, in SMIv2 we (try to) separate the reusable TCs,
we do not separate conformance clauses.


We have no explicit module conformance mechanisms in NETCONF/YANG,
other than the YANG module capability in the <hello> message.

So if I want to use the 'crypt-hash' typedef in 1 of my modules (or
another IETF module), then I have to import ietf-system.
In order to tell the client which 'ietf-system' (remember YANG module names
are not even intended to be unique) I have to advertise ietf-system in
the server <hello>.

The client will think I implement the /system container, which is not correct.

Can this be solved by adding an additional attribute to the  advertised hello.

RFC6020
5.6.4.  Announcing Conformance Information in the <hello> Messag


   The namespace URI MUST be advertised as a capability in the NETCONF
   <hello> message to indicate support for the YANG module by a NETCONF
   server.  The capability URI advertised MUST be of the form:

     capability-string   = namespace-uri [ parameter-list ]
     parameter-list      = "?" parameter *( "&" parameter )
     parameter           = revision-parameter /
                           module-parameter /
                           feature-parameter /
                           deviation-parameter /
                           implementation-parameter  ==>Add this flag?


For example,  if you are just using the typedefs in foo-module,
instead of advertising:


http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01

Can we do
http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01&implementation=false

This way, the client knows foo-module is only needed and advertised for name access?


--Xiang




So if the crypt-hash typedef was in the ietf-system-types module instead,
I would not have to import ietf-system -- I could import ietf-system-types.
That way the client will not see ietf-system advertised unless the
server really implements the /system container.



Thanks and Regards,

Dan


Andy




-----Original Message-----
From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On

Behalf

Of Andy Bierman
Sent: Thursday, August 23, 2012 10:44 PM
To: netmod@ietf.org
Subject: [netmod] followup on YANG conformance

Hi,

The WG is not very interested in this topic, but I strongly suggest

that

all NETMOD WG modules in progress be split into
2 modules if there are any reusable typedefs, groupings, extensions,
features, and/or identities.  These should go in a separate YANG

module

so a server and YANG designer can reuse this meta-data without
advertising the 'main' module with mandatory objects, rpcs, and
notifications.

This simple workaround should cover most use-cases and may prove to be
better organization in the long-run.  It has proven to be effective in
SMIv2-land.


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


-- 
--Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610 
Mobile: 1 (217) 472-4108
--------------070608050508050400070905-- From andy@yumaworks.com Mon Aug 27 07:59:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D713A21F866B for ; Mon, 27 Aug 2012 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48bxtHqRS20k for ; Mon, 27 Aug 2012 07:59:12 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8E9A21F8646 for ; Mon, 27 Aug 2012 07:59:11 -0700 (PDT) Received: by qcac10 with SMTP id c10so3066277qca.31 for ; Mon, 27 Aug 2012 07:59:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=u3GKwSnApwkd3E/8gdTZLI/R2z1nGCVf43vu2OlzvmY=; b=FJZSq7gIaPyGtNFX+Xag4LQLaPxhuIlrZkrjr5YhTafVye7lgMAZ+lMyhB35eQoleQ 6z9RpLz1Dv7wANQBrs0VGCsDiOhXtYvuWgVRhuClnL3urC8WYfFoXsAOiPSJ1Zw0a5GF io+yK7Xf7NeEx1zgX99O93MGx7Re2hv8zlUtU5vLaV87MmIOxas/BOcBJ6Is/Z8slB9P HgdGTNJ4sI47bUhukgsL8DKLU8NJgmCIeXU2/s6nrwUJEc9C55b6F32VAGvUyArxFyOu JPI5E76pwwloH8ef/4Q78ucPekDHpN/2eM3xgX44n6b1PqRzxN2Dz0dfdlcLl+j4S92o 0BHg== MIME-Version: 1.0 Received: by 10.229.135.76 with SMTP id m12mr7221074qct.68.1346079551112; Mon, 27 Aug 2012 07:59:11 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 27 Aug 2012 07:59:10 -0700 (PDT) In-Reply-To: <503B880B.7000301@seguesoft.com> References: <503B880B.7000301@seguesoft.com> Date: Mon, 27 Aug 2012 07:59:10 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlkR2i+V5QoyttmvynOkluzzPS4VU+2f3U+ANn2V4NYJP4kYarsHBkYfQr1+IqgEopFD/mZ Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:59:13 -0000 On Mon, Aug 27, 2012 at 7:45 AM, Xiang Li wrote: > > On 8/26/2012 10:20 AM, Andy Bierman wrote: > > On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) > wrote: > > Hi Andy, > > Can you give an example of what you are proposing using one of the YANG > modules currently in progress? I am not sure that I understand exactly > what you are proposing, in SMIv2 we (try to) separate the reusable TCs, > we do not separate conformance clauses. > > We have no explicit module conformance mechanisms in NETCONF/YANG, > other than the YANG module capability in the message. > > So if I want to use the 'crypt-hash' typedef in 1 of my modules (or > another IETF module), then I have to import ietf-system. > In order to tell the client which 'ietf-system' (remember YANG module names > are not even intended to be unique) I have to advertise ietf-system in > the server . > > The client will think I implement the /system container, which is not > correct. > > > Can this be solved by adding an additional attribute to the advertised > hello. You mean like "conform=true|false"? Perhaps you saw my slides that we did not have time for in Vancouver? This is 1 option I proposed in my slides. Since the default is 'true' you would really only see conform=false added to module capabilities that are advertised for imports identification only. The leaf could also be added to the ietf-netconf-monitoring module /netconf-state/schemas/schema list. Adding the leaf is easy. Changing the module capability URI format is not, so when YANG 2.0 gets done someday, it will be on the wish-list. I don't want to change YANG for this (or any other proposed tweaks so far). Andy > > RFC6020 > > 5.6.4. Announcing Conformance Information in the Messag > > The namespace URI MUST be advertised as a capability in the NETCONF > message to indicate support for the YANG module by a NETCONF > server. The capability URI advertised MUST be of the form: > > capability-string = namespace-uri [ parameter-list ] > parameter-list = "?" parameter *( "&" parameter ) > parameter = revision-parameter / > module-parameter / > feature-parameter / > deviation-parameter / > implementation-parameter ==>Add this flag? > > > > For example, if you are just using the typedefs in foo-module, > instead of advertising: > > > http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01 > > Can we do > http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01&implementation=false > > This way, the client knows foo-module is only needed and advertised for name > access? > > > --Xiang > > > > > So if the crypt-hash typedef was in the ietf-system-types module instead, > I would not have to import ietf-system -- I could import ietf-system-types. > That way the client will not see ietf-system advertised unless the > server really implements the /system container. > > > Thanks and Regards, > > Dan > > Andy > > > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > Behalf > > Of Andy Bierman > Sent: Thursday, August 23, 2012 10:44 PM > To: netmod@ietf.org > Subject: [netmod] followup on YANG conformance > > Hi, > > The WG is not very interested in this topic, but I strongly suggest > > that > > all NETMOD WG modules in progress be split into > 2 modules if there are any reusable typedefs, groupings, extensions, > features, and/or identities. These should go in a separate YANG > > module > > so a server and YANG designer can reuse this meta-data without > advertising the 'main' module with mandatory objects, rpcs, and > notifications. > > This simple workaround should cover most use-cases and may prove to be > better organization in the long-run. It has proven to be effective in > SMIv2-land. > > > 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 > > > -- > --Xiang Li > Web: www.seguesoft.com > Voice: 1 (872) 216-2610 > Mobile: 1 (217) 472-4108 > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Mon Aug 27 08:07:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013F521F86CA for ; Mon, 27 Aug 2012 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u6EjYVDQzgt for ; Mon, 27 Aug 2012 08:07:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E3FF921F8646 for ; Mon, 27 Aug 2012 08:07:09 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1866020C80; Mon, 27 Aug 2012 17:07:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bujcxioxcVwP; Mon, 27 Aug 2012 17:07:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2B0F20C7B; Mon, 27 Aug 2012 17:07:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 380E821407B1; Mon, 27 Aug 2012 17:07:03 +0200 (CEST) Date: Mon, 27 Aug 2012 17:07:03 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120827150703.GB268@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , netmod@ietf.org References: <20120824.213827.520095880.mbj@tail-f.com> <201208271412.q7RECQWk003640@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:07:11 -0000 On Mon, Aug 27, 2012 at 07:45:27AM -0700, Andy Bierman wrote: > On Mon, Aug 27, 2012 at 7:12 AM, Phil Shafer wrote: > > Martin Bjorklund writes: > >>An alternative is to simply make the "enabled" leaf have "false" as > >>default value. With "ipv4" being a P-container, what exactly is the > >>meaning of its presence? > > > > Giving a box an IP address turns on ip by default. This seems > > like a natural fit. One can disable it if needed, but the > > normal case is trivial. > > > > Is this universal, or just Junos? > So should the 'enabled' leaf be removed? > What needs to change in the YANG modules? It find it kind of useful to disable some function leaving the config in place. Having to remove all config to disable something means more work to enable it again. The presence container would be complementary for those situations where there is a function I really do not care at all about. It would make any noise related to it disappear. > IMO, we need a generic mechanism for disabling config, > not a bunch of 'enabled' leafs all over the place. These enabled leafs is what we have today and there is value in getting implementable data models out at some hopefully close point in time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Aug 27 08:07:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3192B21F86D4 for ; Mon, 27 Aug 2012 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPadf8TGjKVw for ; Mon, 27 Aug 2012 08:07:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 72FDD21F8646 for ; Mon, 27 Aug 2012 08:07:24 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id A03281410A9; Mon, 27 Aug 2012 17:07:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1346080043; bh=31fqZ2jX5UxSsMjHgHBR/e1Lx+yYxMkJrcnqTbN61Ac=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QoTVi4dxlt5q4otNwsa0u+faxTzCfCintZ0JrsgLyFOky0RBtU3DXk7wGoAaBN5Wk ptkEF4OJCkG1NTxtr28zhxMMCx6KeOh2/AZ2qQ5greigCP11USvQGVnI7WFfpjR9h+ 1KIfSYi9GtfTOdxxjCwDBltWj5pIERFU8kUswEvk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 27 Aug 2012 17:07:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <267AB6A4-B16E-424E-B596-CBB723F8848C@nic.cz> References: <20120824.213827.520095880.mbj@tail-f.com> <201208271412.q7RECQWk003640@idle.juniper.net> To: Andy Bierman X-Mailer: Apple Mail (2.1485) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:07:26 -0000 On Aug 27, 2012, at 4:45 PM, Andy Bierman wrote: > On Mon, Aug 27, 2012 at 7:12 AM, Phil Shafer wrote: >> Martin Bjorklund writes: >>> An alternative is to simply make the "enabled" leaf have "false" as >>> default value. With "ipv4" being a P-container, what exactly is the >>> meaning of its presence? >>=20 >> Giving a box an IP address turns on ip by default. This seems >> like a natural fit. One can disable it if needed, but the >> normal case is trivial. >>=20 >=20 > Is this universal, or just Junos? > So should the 'enabled' leaf be removed? > What needs to change in the YANG modules? I think it should suffice to add "presence" to the container definition = and keep the "true" default for "enabled". Then: 1. The protocol is disabled and no configuration data are present unless = the client creates the corresponding container (descendant defaults are = inactive). 2. If the container is created, the protocol becomes enabled and all the = defaults are activated. 3. The client can disable the protocol but keep the configuration by = setting "enabled" to "false". >=20 > IMO, we need a generic mechanism for disabling config, > not a bunch of 'enabled' leafs all over the place. A universal XML attribute, such as would fit this purpose quite nicely. Lada >=20 >> Thanks, >> Phil >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Mon Aug 27 08:08:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DF421F8450 for ; Mon, 27 Aug 2012 08:08:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gskpPNgtY-H7 for ; Mon, 27 Aug 2012 08:08:13 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id A537B21F8514 for ; Mon, 27 Aug 2012 08:08:11 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUDuNWwB52tNPoX71QrSazgi7EQprhG2Y@postini.com; Mon, 27 Aug 2012 08:08:13 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Aug 2012 08:05:23 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q7RF5Kh39550; Mon, 27 Aug 2012 08:05:21 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7RF4EWI003994; Mon, 27 Aug 2012 11:04:38 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208271504.q7RF4EWI003994@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Mon, 27 Aug 2012 11:04:13 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:08:14 -0000 Andy Bierman writes: >> Giving a box an IP address turns on ip by default. This seems >> like a natural fit. One can disable it if needed, but the >> normal case is trivial. >Is this universal, or just Junos? This is how JUNOS works. There's a "disable" leaf but we work hard to avoid "noise" in the configuration data, so we avoid having an explicit "enable". You just assign an address and the protocol is turned on ("set interface fe-0/0/0.0 family inet address 10.1.2.3/24"). >So should the 'enabled' leaf be removed? We "hide" it in JUNOS (from the CLI user), but still have it since it may be needed for overriding our inheritance model (where you can disable some interfaces in a config group and then explicitly enable them in the main config). None of which is interesting to netmod, but gives some background into our choices in JUNOS. >IMO, we need a generic mechanism for disabling config, >not a bunch of 'enabled' leafs all over the place. In JUNOS, we made this happen as a generic attribute of configuration data. If you mark a node as "inactive" is remains in the config data, but is ignored, essentially commenting it out while retaining it in place. In the CLI, this is rendered with an "inactive:" tag. See below..... Thanks, Phil ----------- In this example, the interface has multiple addresses, one of which has been deactivated: [edit] phil@dent# show ## Last changed: 2012-08-27 12:12:02 EDT interfaces { fe-0/0/0 { unit 0 { family inet { address 10.1.2.3/24; inactive: address 10.4.5.6/24; address 10.7.8.9/24; } } } } [edit] phil@dent# show | display xml fe-0/0/0 0
10.1.2.3/24
10.4.5.6/24
10.7.8.9/24
[edit] phil@dent# From xiangli@seguesoft.com Mon Aug 27 08:26:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFAF21F8534 for ; Mon, 27 Aug 2012 08:26:03 -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_75=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do+NcCUeHjsM for ; Mon, 27 Aug 2012 08:26:02 -0700 (PDT) Received: from m1plsmtpa01-05.prod.mesa1.secureserver.net (m1plsmtpa01-05.prod.mesa1.secureserver.net [64.202.165.10]) by ietfa.amsl.com (Postfix) with ESMTP id 58A9E21F8503 for ; Mon, 27 Aug 2012 08:26:02 -0700 (PDT) Received: from [192.168.2.10] ([98.212.151.151]) by m1plsmtpa01-05.prod.mesa1.secureserver.net with id rrS01j0083GEayi01rS0QX; Mon, 27 Aug 2012 08:26:01 -0700 Message-ID: <503B918A.4000201@seguesoft.com> Date: Mon, 27 Aug 2012 10:26:02 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Andy Bierman References: <503B880B.7000301@seguesoft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] followup on YANG conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:26:03 -0000 On 8/27/2012 9:59 AM, Andy Bierman wrote: > On Mon, Aug 27, 2012 at 7:45 AM, Xiang Li wrote: >> On 8/26/2012 10:20 AM, Andy Bierman wrote: >> >> On Sat, Aug 25, 2012 at 10:36 PM, Romascanu, Dan (Dan) >> wrote: >> >> Hi Andy, >> >> Can you give an example of what you are proposing using one of the YANG >> modules currently in progress? I am not sure that I understand exactly >> what you are proposing, in SMIv2 we (try to) separate the reusable TCs, >> we do not separate conformance clauses. >> >> We have no explicit module conformance mechanisms in NETCONF/YANG, >> other than the YANG module capability in the message. >> >> So if I want to use the 'crypt-hash' typedef in 1 of my modules (or >> another IETF module), then I have to import ietf-system. >> In order to tell the client which 'ietf-system' (remember YANG module names >> are not even intended to be unique) I have to advertise ietf-system in >> the server . >> >> The client will think I implement the /system container, which is not >> correct. >> >> >> Can this be solved by adding an additional attribute to the advertised >> hello. > You mean like "conform=true|false"? I did not read the slides you mentioned. I think "implementation=true/false" or "implemented=true/false" is not exactly same as "conform=true/false". But it could be just be different naming as "conform=true|false". "implementation=true/false" or "implemented=true/false" just tells if the device implements the module or it is advertised only for name access. I think if it is "conform=false" one could interpret it as "the device does implement this module, but is not 100% conformant to the contract ". But that could just be me. > Perhaps you saw my slides that we did not have time for in Vancouver? > This is 1 option I proposed in my slides. > > Since the default is 'true' you would really only see conform=false added > to module capabilities that are advertised for imports identification only. > > The leaf could also be added to the ietf-netconf-monitoring > module /netconf-state/schemas/schema list. Adding the leaf is easy. Yes if ietf-netconf-monitoring is mandatory for every implementation, I think this should also work. We however need to make sure /netconf-state/schemas/schema won't become another "sysORTable", where different implementations implement it differently (if it gets implemented). --Xiang > Changing the module capability URI format is not, so when YANG 2.0 > gets done someday, it will be on the wish-list. I don't want to change > YANG for this (or any other proposed tweaks so far). > Ok. --Xiang > Andy > >> RFC6020 >> >> 5.6.4. Announcing Conformance Information in the Messag >> >> The namespace URI MUST be advertised as a capability in the NETCONF >> message to indicate support for the YANG module by a NETCONF >> server. The capability URI advertised MUST be of the form: >> >> capability-string = namespace-uri [ parameter-list ] >> parameter-list = "?" parameter *( "&" parameter ) >> parameter = revision-parameter / >> module-parameter / >> feature-parameter / >> deviation-parameter / >> implementation-parameter ==>Add this flag? >> >> >> >> For example, if you are just using the typedefs in foo-module, >> instead of advertising: >> >> >> http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01 >> >> Can we do >> http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01&implementation=false >> >> This way, the client knows foo-module is only needed and advertised for name >> access? >> >> >> --Xiang >> >> >> >> >> So if the crypt-hash typedef was in the ietf-system-types module instead, >> I would not have to import ietf-system -- I could import ietf-system-types. >> That way the client will not see ietf-system advertised unless the >> server really implements the /system container. >> >> >> Thanks and Regards, >> >> Dan >> >> Andy >> >> >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >> >> Behalf >> >> Of Andy Bierman >> Sent: Thursday, August 23, 2012 10:44 PM >> To: netmod@ietf.org >> Subject: [netmod] followup on YANG conformance >> >> Hi, >> >> The WG is not very interested in this topic, but I strongly suggest >> >> that >> >> all NETMOD WG modules in progress be split into >> 2 modules if there are any reusable typedefs, groupings, extensions, >> features, and/or identities. These should go in a separate YANG >> >> module >> >> so a server and YANG designer can reuse this meta-data without >> advertising the 'main' module with mandatory objects, rpcs, and >> notifications. >> >> This simple workaround should cover most use-cases and may prove to be >> better organization in the long-run. It has proven to be effective in >> SMIv2-land. >> >> >> 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 >> >> >> -- >> --Xiang Li >> Web: www.seguesoft.com >> Voice: 1 (872) 216-2610 >> Mobile: 1 (217) 472-4108 >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- --Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 Mobile: 1 (217) 472-4108 From david.kessens@nsn.com Mon Aug 27 12:44:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEE021F84E1 for ; Mon, 27 Aug 2012 12:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdUD+t-Ty3jN for ; Mon, 27 Aug 2012 12:44:46 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF7C21F8459 for ; Mon, 27 Aug 2012 12:44:46 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7RJigqQ019999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Aug 2012 21:44:42 +0200 Received: from localhost.localdomain ([10.138.53.248]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7RJicOb012410; Mon, 27 Aug 2012 21:44:39 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id q7RJicG6006856; Mon, 27 Aug 2012 12:44:38 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id q7RJiYS5006854; Mon, 27 Aug 2012 12:44:34 -0700 Date: Mon, 27 Aug 2012 12:44:34 -0700 From: David Kessens To: Phil Shafer Message-ID: <20120827194434.GT5818@nsn.com> References: <20120824.213827.520095880.mbj@tail-f.com> <201208271412.q7RECQWk003640@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208271412.q7RECQWk003640@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 579 X-purgate-ID: 151667::1346096682-00006F5F-8B9B46B3/0-0/0-0 Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:44:47 -0000 Phil, On Mon, Aug 27, 2012 at 10:12:25AM -0400, Phil Shafer wrote: > Martin Bjorklund writes: > >An alternative is to simply make the "enabled" leaf have "false" as > >default value. With "ipv4" being a P-container, what exactly is the > >meaning of its presence? > > Giving a box an IP address turns on ip by default. This seems > like a natural fit. One can disable it if needed, but the > normal case is trivial. How about not configuring an IP address but enabling accepting route advertisements ? How about link local addresses ? David Kessens --- From mbj@tail-f.com Mon Aug 27 14:07:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD021F8527 for ; Mon, 27 Aug 2012 14:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydpjawszunlq for ; Mon, 27 Aug 2012 14:07:23 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EC58721F851E for ; Mon, 27 Aug 2012 14:07:22 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A56E51200043; Mon, 27 Aug 2012 23:07:19 +0200 (CEST) Date: Mon, 27 Aug 2012 23:07:18 +0200 (CEST) Message-Id: <20120827.230718.466353401.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201208271504.q7RF4EWI003994@idle.juniper.net> References: <201208271504.q7RF4EWI003994@idle.juniper.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:07:23 -0000 Phil Shafer wrote: > Andy Bierman writes: > >IMO, we need a generic mechanism for disabling config, > >not a bunch of 'enabled' leafs all over the place. > > In JUNOS, we made this happen as a generic attribute of configuration > data. If you mark a node as "inactive" is remains in the config > data, but is ignored, essentially commenting it out while retaining > it in place. This is a great feature, and we have something similar. We also have user-defined comments as such meta-data. This makes it possible for users to disable and comment any part of the config, without the data model designer adding leafs such as "enabled" and "comment" or "description". Unfortunately, as long as this is not part of the standard "meta model", we have to add such leafs in our data models... /martin From phil@juniper.net Mon Aug 27 14:59:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960A911E8097 for ; Mon, 27 Aug 2012 14:59:16 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-UvPmsCnaLe for ; Mon, 27 Aug 2012 14:59:16 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7B11E808A for ; Mon, 27 Aug 2012 14:59:12 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUDvtr7pqQ/4s+Xx/lqTZLpyrONgBH9fr@postini.com; Mon, 27 Aug 2012 14:59:16 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Aug 2012 14:58:59 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q7RLwwh43326; Mon, 27 Aug 2012 14:58:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7RLvqDK006228; Mon, 27 Aug 2012 17:58:16 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208272158.q7RLvqDK006228@idle.juniper.net> To: David Kessens In-Reply-To: <20120827194434.GT5818@nsn.com> Date: Mon, 27 Aug 2012 17:57:52 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:59:16 -0000 David Kessens writes: >How about not configuring an IP address but enabling accepting route >advertisements ? How about link local addresses ? We require at address for the former and the latter requires other interface-related config, so the v4 or v6 container would have to exist. Thanks, Phil From david.kessens@nsn.com Mon Aug 27 16:20:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C803221F847F for ; Mon, 27 Aug 2012 16:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8FbN1HTrul0 for ; Mon, 27 Aug 2012 16:20:45 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F22B421F847D for ; Mon, 27 Aug 2012 16:20:43 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7RNKeE8004680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Aug 2012 01:20:40 +0200 Received: from localhost.localdomain ([10.138.53.248]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7RNKaV5020586; Tue, 28 Aug 2012 01:20:37 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id q7RNKa2E007426; Mon, 27 Aug 2012 16:20:36 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id q7RNKXd4007424; Mon, 27 Aug 2012 16:20:33 -0700 Date: Mon, 27 Aug 2012 16:20:33 -0700 From: David Kessens To: Phil Shafer Message-ID: <20120827232033.GW5818@nsn.com> References: <20120827194434.GT5818@nsn.com> <201208272158.q7RLvqDK006228@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208272158.q7RLvqDK006228@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 531 X-purgate-ID: 151667::1346109640-00003184-7B2DB987/0-0/0-0 Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 23:20:47 -0000 Phil, On Mon, Aug 27, 2012 at 05:57:52PM -0400, Phil Shafer wrote: > David Kessens writes: > >How about not configuring an IP address but enabling accepting route > >advertisements ? How about link local addresses ? > > We require at address for the former and the latter requires > other interface-related config, so the v4 or v6 container > would have to exist. Can you be more specific for the latter: I thought the "other interface-related config" was enabling ipv6 on the interface. David Kessens --- From phil@juniper.net Mon Aug 27 20:17:44 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B203B21F8445 for ; Mon, 27 Aug 2012 20:17:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0KEurLWhsj7 for ; Mon, 27 Aug 2012 20:17:44 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id EF19E21F8319 for ; Mon, 27 Aug 2012 20:17:40 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUDw4VGOeVls+RNR8POHP/j+t2+sI8RW7@postini.com; Mon, 27 Aug 2012 20:17:44 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Aug 2012 20:17: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 q7S3HUh50399; Mon, 27 Aug 2012 20:17:30 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7S3GP6G007483; Mon, 27 Aug 2012 23:16:49 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208280316.q7S3GP6G007483@idle.juniper.net> To: David Kessens In-Reply-To: <20120827232033.GW5818@nsn.com> Date: Mon, 27 Aug 2012 23:16:24 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of ip draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 03:17:44 -0000 David Kessens writes: > >Phil, > >On Mon, Aug 27, 2012 at 05:57:52PM -0400, Phil Shafer wrote: >> David Kessens writes: >> >How about not configuring an IP address but enabling accepting route >> >advertisements ? How about link local addresses ? >> >> We require at address for the former and the latter requires >> other interface-related config, so the v4 or v6 container >> would have to exist. > >Can you be more specific for the latter: > >I thought the "other interface-related config" was enabling ipv6 on the >interface. My bad. Just turning on v6 ("set interfaces xxx family inet6") is sufficient to enable v6 and link local addresses. I was thinking that it was a flag on the address, but it's not. So for JUNOS, inet6 is already a P container. Strictly speaking, so is v4 ("family inet"), but I don't think anything interesting happens without either an address or the "unnumbered-interface" flag. Thanks, Phil From calle@tail-f.com Tue Aug 28 00:49:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECE811E80A3 for ; Tue, 28 Aug 2012 00:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKMm5btK7RZH for ; Tue, 28 Aug 2012 00:49:45 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACCE11E808D for ; Tue, 28 Aug 2012 00:49:45 -0700 (PDT) Received: from calle-macbook.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D1FE212008D2 for ; Tue, 28 Aug 2012 09:49:42 +0200 (CEST) From: Carl Moberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <454AE524-CCD3-4F84-9D0D-59CFC6B8BB73@tail-f.com> Date: Tue, 28 Aug 2012 09:49:44 +0200 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [netmod] Metro Ethernet Forum publishes YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 07:49:46 -0000 All, FYI, the MEF has recently published the following specifications: - MEF 38 "Service OAM Fault Management YANG Modules" [1] - MEF 39 "Service OAM Performance Monitoring YANG Module" [2] Theses documents provide YANG modules corresponding to the scope of the = following specifications: - MEF SOAM TC/FM and PM MIBs - ITU-T Y.1731, IEEE 802.1Q 1. = http://www.metroethernetforum.org/PDF_Documents/technical-specifications/M= EF_38.pdf 2. = http://www.metroethernetforum.org/PDF_Documents/technical-specifications/M= EF_39.pdf Regards, -- Carl Moberg mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From j.schoenwaelder@jacobs-university.de Tue Aug 28 01:05:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A8211E80E6 for ; Tue, 28 Aug 2012 01:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYBWgC1gH3Il for ; Tue, 28 Aug 2012 01:05:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 934C111E80A3 for ; Tue, 28 Aug 2012 01:05:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E494A20C6C; Tue, 28 Aug 2012 10:05:31 +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 cAHN2lMH4u6G; Tue, 28 Aug 2012 10:05:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AE7B20C57; Tue, 28 Aug 2012 10:05:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB9DB21484DD; Tue, 28 Aug 2012 10:05:25 +0200 (CEST) Date: Tue, 28 Aug 2012 10:05:25 +0200 From: Juergen Schoenwaelder To: Carl Moberg Message-ID: <20120828080525.GA1668@elstar.local> Mail-Followup-To: Carl Moberg , netmod@ietf.org References: <454AE524-CCD3-4F84-9D0D-59CFC6B8BB73@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <454AE524-CCD3-4F84-9D0D-59CFC6B8BB73@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Metro Ethernet Forum publishes YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:05:35 -0000 On Tue, Aug 28, 2012 at 09:49:44AM +0200, Carl Moberg wrote: > All, > > FYI, the MEF has recently published the following specifications: > - MEF 38 "Service OAM Fault Management YANG Modules" [1] > - MEF 39 "Service OAM Performance Monitoring YANG Module" [2] > > Theses documents provide YANG modules corresponding to the scope of the following specifications: > - MEF SOAM TC/FM and PM MIBs > - ITU-T Y.1731, IEEE 802.1Q > > 1. http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_38.pdf > 2. http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_39.pdf > Thanks for letting is know. Its good to see usage of our work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From alex@cisco.com Fri Aug 31 16:03:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E26411E80BF for ; Fri, 31 Aug 2012 16:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRYkEkJtUfAb for ; Fri, 31 Aug 2012 16:03:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEC811E80BA for ; Fri, 31 Aug 2012 16:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=4383; q=dns/txt; s=iport; t=1346454205; x=1347663805; h=from:to:cc:subject:date:message-id:mime-version; bh=EqBRXEwaddvjiOqH2lvV3TRyBd/+ljZ1FZ+fef7Ufqk=; b=hlpFZSBi3g4QRlySWmGWjoBr7gyXfDhRrAeDszhdfxJ7XeePXl25N/+F 2svFXa3DGpEuyp5WBVE3SyowVj+40NmNTxptvHXgZRr8th4dmSjES5ixE wUrUa52AY7bgE8IuHCuJh6jz3ZDoCPX2ckCRSCIXZf7vK8YFT6loIAUEd o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAB9CQVCtJXHB/2dsb2JhbABFgkq4V4EHgiIBBBIBGkwSASpWJgEEDg0BGYdrC5pboBCRKmADpAuBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,349,1344211200"; d="scan'208,217";a="117128519" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 31 Aug 2012 23:03:25 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7VN3OXi006713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Aug 2012 23:03:24 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Fri, 31 Aug 2012 18:03:24 -0500 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjw== Date: Fri, 31 Aug 2012 23:03:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.187] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19154.001 x-tm-as-result: No--39.922200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B570F4C5783xmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: [netmod] YANG module for ACL configuration X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 23:03:26 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B570F4C5783xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, we have just posted an Internet Draft of a YANG model for ACL configuration= : http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt This document defines a YANG data model for Access Control Lists (ACLs) on = a device. An ACL is an ordered set of rules that is used to filter traffic = on a networking device. In the draft you will find details of how the model= is designed and the corresponding YANG modules. We are hoping that this model is of interest to this group. Please take a = look and let us know your thoughts and comments. Thanks, Alex & Lisa --_000_DBC595ED2346914F9F81D17DD5C32B570F4C5783xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

we have just posted an Internet Draft of a YANG m= odel for ACL configuration:

http://www.ietf.org/internet-drafts/draft-huan= g-netmod-acl-00.txt

 

This document defines a YANG data model for Acces= s Control Lists (ACLs) on a device. An ACL is an ordered set of rules that = is used to filter traffic on a networking device. In the draft you will fin= d details of how the model is designed and the corresponding YANG modules. 

 

We are hoping that this model is of interest to t= his group.  Please take a look and let us know your thoughts and comme= nts. 

 

Thanks,

 

Alex & Lisa

 

 

--_000_DBC595ED2346914F9F81D17DD5C32B570F4C5783xmbrcdx05ciscoc_--