From dromasca@avaya.com Sun Nov 1 02:30:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511ED3A6403 for ; Sun, 1 Nov 2009 02:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNHgQJWlnknQ for ; Sun, 1 Nov 2009 02:30:21 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 981B63A67E5 for ; Sun, 1 Nov 2009 02:30:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,661,1249272000"; d="scan'208";a="178820397" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Nov 2009 05:30:34 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Nov 2009 05:30:34 -0500 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, 1 Nov 2009 11:30:17 +0100 Message-ID: In-Reply-To: <4AECB2B8.6030609@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] operational knobs Thread-Index: AcpadUqsbXNlWs/kR0mNQxomMpoXTwAaOlhg References: <4AEC94B0.6050703@netconfcentral.com><4AECA0B6.2010708@joelhalpern.com> <4AECB2B8.6030609@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Joel M. Halpern" Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 10:30:23 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Saturday, October 31, 2009 11:57 PM > To: Joel M. Halpern > Cc: NETMOD Working Group > Subject: Re: [netmod] operational knobs >=20 > Joel M. Halpern wrote: > > While I do not know what the right answer is for YANG,=20 > let's not get=20 > > too distracted by the SNMP answer. The mechanism used for=20 > this sort=20 > > of thing by SNMP is a kludge designed to work around the limitaiton=20 > > where the only operations were get and set. > >=20 >=20 > Agreed -- but I view the IETF SNMP experience as more than a=20 > distraction. We are theoretically asking IETF WGs to stop=20 > using SMIv2 and start using YANG to design data models. > I think the differences, and guidelines wrt/ those=20 > differences, are relevant to a significant portion of the=20 > IETF community. >=20 I agree. Is not this something that netmod-arch should deal with?=20 Dan From phil@juniper.net Sun Nov 1 08:15:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5B93A690C for ; Sun, 1 Nov 2009 08:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q3UsKqPt3H1 for ; Sun, 1 Nov 2009 08:15:47 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id DA1693A68D6 for ; Sun, 1 Nov 2009 08:15:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSu20QgyOdiYFH+45c9JZECHNE4IrapLc@postini.com; Sun, 01 Nov 2009 08:16:04 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 1 Nov 2009 08:14:10 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 08:14:10 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 08:14:10 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 08:14:09 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA1GE8j39710; Sun, 1 Nov 2009 08:14:08 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA1G12oL015680; Sun, 1 Nov 2009 16:01:02 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911011601.nA1G12oL015680@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4AECA0B6.2010708@joelhalpern.com> Date: Sun, 1 Nov 2009 11:01:01 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Nov 2009 16:14:09.0611 (UTC) FILETIME=[57EA19B0:01CA5B0E] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 16:15:48 -0000 "Joel M. Halpern" writes: >While I do not know what the right answer is for YANG, let's not get too >distracted by the SNMP answer. The mechanism used for this sort of >thing by SNMP is a kludge designed to work around the limitaiton where >the only operations were get and set. [Clearly an aside, but as a non-snmp dude.....] I've always been curious why new verbs weren't added to SNMP instead of this kludge. Poking bytes into control registers clearly wasn't the example to follow and the distaste for it seems universal, but I've never grok'd why verbs like CREATE, DELETE, LOCK, CHANGE, PRE-CREATE, DISABLE, &etc weren't made. Thanks, Phil From jmh@joelhalpern.com Sun Nov 1 08:22:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE4D3A6864 for ; Sun, 1 Nov 2009 08:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhqTqFawv7Gh for ; Sun, 1 Nov 2009 08:22:11 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 838C03A67E9 for ; Sun, 1 Nov 2009 08:22:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CD60932318D1; Sun, 1 Nov 2009 08:22:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-240.clppva.btas.verizon.net [71.161.50.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 2161432318CF; Sun, 1 Nov 2009 08:22:30 -0800 (PST) Message-ID: <4AEDB5C8.8080408@joelhalpern.com> Date: Sun, 01 Nov 2009 11:22:32 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4AEC94B0.6050703@netconfcentral.com><4AECA0B6.2010708@joelhalpern.com> <4AECB2B8.6030609@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 16:22:12 -0000 That would indeed seem an appropriate place to deal with the topic. Joel Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Saturday, October 31, 2009 11:57 PM >> To: Joel M. Halpern >> Cc: NETMOD Working Group >> Subject: Re: [netmod] operational knobs >> >> Joel M. Halpern wrote: >>> While I do not know what the right answer is for YANG, >> let's not get >>> too distracted by the SNMP answer. The mechanism used for >> this sort >>> of thing by SNMP is a kludge designed to work around the limitaiton >>> where the only operations were get and set. >>> >> Agreed -- but I view the IETF SNMP experience as more than a >> distraction. We are theoretically asking IETF WGs to stop >> using SMIv2 and start using YANG to design data models. >> I think the differences, and guidelines wrt/ those >> differences, are relevant to a significant portion of the >> IETF community. >> > > I agree. Is not this something that netmod-arch should deal with? > > Dan > From randy_presuhn@mindspring.com Sun Nov 1 09:01:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86C73A6896 for ; Sun, 1 Nov 2009 09:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSzvkjdoIcc8 for ; Sun, 1 Nov 2009 09:01:46 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id CF48E3A6831 for ; Sun, 1 Nov 2009 09:01:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WFauFYFz3CQ/qp731sOj4fkEu1p8q/baD1Lc0HSDiTUr4ceWOJDbyiClkAkBol3z; 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.35.227.153] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N4doY-0005zo-EX for netmod@ietf.org; Sun, 01 Nov 2009 12:02:02 -0500 Message-ID: <002801ca5b0c$a89a4c60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <200911011601.nA1G12oL015680@idle.juniper.net> Date: Sun, 1 Nov 2009 09:02:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9600260ce6a50216a090b731475ca3259350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.227.153 Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 17:01:46 -0000 Hi - > From: "Phil Shafer" > To: "Joel M. Halpern" > Cc: "NETMOD Working Group" > Sent: Sunday, November 01, 2009 9:01 AM > Subject: Re: [netmod] operational knobs ... > I've always been curious why new verbs weren't added to SNMP > instead of this kludge. Poking bytes into control registers > clearly wasn't the example to follow and the distaste for it > seems universal, but I've never grok'd why verbs like CREATE, > DELETE, LOCK, CHANGE, PRE-CREATE, DISABLE, &etc weren't made. ... Adding them would have been a change to the protocol's grammar, which would have been a non-starter for several reasons: - re-starting the clock at "Proposed Standard" each time one of these was added would have been politically unpalatable (CMIP was a full IS, and, since it already had verbs for Create, Delete, etc., adding these to SNMP would also have been seen as an admission of inadequacy) - changing the grammar would have adversely affected the deployed base of management systems and agents, as well as the various vendors' development tools, and would have invalidated the interoperability suites, bake-offs, and test events. The ability to work with generic "dumb" MIB browsers was demanded by users. - by the time SMP, Secure SNMP, SNMPv2, SNMPv2*, etc, started appearing, access control models were being formulated in terms of object identifiers. If an "Action" facility were to be added, we'd have had to formulate the policies in ways similar to how VACM processes notifications, which would severly constrain how people could formulate actions. (Not that that would have been a bad thing) FWIW the CMIP experience, while it did establish that having distinct verbs for Create and Delete was a Good Thing, and had provisions for synchronization built into the object model and the protocol, also demonstrated that a generic Action facility, while useful, needed to be used *Very* carefully. Like netconf RPCs, it provided the ability to shovel around rather arbitrary syntax. Mating this with fine-grained access control expressed in terms of the object model is hard. Later discussions of "we wish we had" in CMIP-land supported limiting the payload to things that would look like variable bindings, rather than arbitrary ASN.1, to ease matching up the bits and pieces of actions with the objects' data models. Randy From dromasca@avaya.com Sun Nov 1 09:03:27 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F5B3A6896 for ; Sun, 1 Nov 2009 09:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpAfwWK9Elon for ; Sun, 1 Nov 2009 09:03:26 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A27393A6831 for ; Sun, 1 Nov 2009 09:03:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,662,1249272000"; d="scan'208,217";a="178832108" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Nov 2009 12:03:44 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Nov 2009 12:03:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5B15.387D7429" Date: Sun, 1 Nov 2009 18:01:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] operational knobs Thread-Index: AcpbDqrc+MoA2lySTVOZz69rDRunuwABk6XE References: <200911011601.nA1G12oL015680@idle.juniper.net> From: "Romascanu, Dan (Dan)" To: "Phil Shafer" , "Joel M. Halpern" Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 17:03:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5B15.387D7429 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: netmod-bounces@ietf.org on behalf of Phil Shafer Sent: Sun 11/1/2009 6:01 PM To: Joel M. Halpern Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs =20 "Joel M. Halpern" writes: >While I do not know what the right answer is for YANG, let's not get = too=20 >distracted by the SNMP answer. The mechanism used for this sort of=20 >thing by SNMP is a kludge designed to work around the limitaiton where=20 >the only operations were get and set. [Clearly an aside, but as a non-snmp dude.....] I've always been curious why new verbs weren't added to SNMP instead of this kludge. Poking bytes into control registers clearly wasn't the example to follow and the distaste for it seems universal, but I've never grok'd why verbs like CREATE, DELETE, LOCK, CHANGE, PRE-CREATE, DISABLE, &etc weren't made. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod The short answer is that SNMP was designed to be the light (and = temporary!) alternative to CMIP which had 11 'verbs' (if I remember = well) including some of the ones you mentioned.=20 The long answer requires a few beers :-) Dan ------_=_NextPart_001_01CA5B15.387D7429 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [netmod] operational knobs


-----Original Message-----
From: netmod-bounces@ietf.org on behalf of Phil Shafer
Sent: Sun 11/1/2009 6:01 PM
To: Joel M. Halpern
Cc: NETMOD Working Group
Subject: Re: [netmod] operational knobs

"Joel M. Halpern" writes:
>While I do not know what the right answer is for YANG, let's not get = too
>distracted by the SNMP answer.  The mechanism used for this = sort of
>thing by SNMP is a kludge designed to work around the limitaiton = where
>the only operations were get and set.

[Clearly an aside, but as a non-snmp dude.....]

I've always been curious why new verbs weren't added to SNMP
instead of this kludge.  Poking bytes into control registers
clearly wasn't the example to follow and the distaste for it
seems universal, but I've never grok'd why verbs like CREATE,
DELETE, LOCK, CHANGE, PRE-CREATE, DISABLE, &etc weren't made.

Thanks,
 Phil
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod

The short answer is that SNMP was designed to be the light (and = temporary!) alternative to CMIP which had 11 'verbs' (if I remember = well) including some of the ones you mentioned.

The long answer requires a few beers :-)

Dan

------_=_NextPart_001_01CA5B15.387D7429-- From saperia@jdscons.com Sun Nov 1 09:07:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DF83A68C7 for ; Sun, 1 Nov 2009 09:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCkegda25O6N for ; Sun, 1 Nov 2009 09:07:34 -0800 (PST) Received: from rs40.luxsci.com (rs40.luxsci.com [65.61.166.82]) by core3.amsl.com (Postfix) with ESMTP id 973023A6896 for ; Sun, 1 Nov 2009 09:07:34 -0800 (PST) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id nA1H7oPk001679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 1 Nov 2009 11:07:50 -0600 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Jon Saperia X-Priority: 3 In-Reply-To: <002801ca5b0c$a89a4c60$6801a8c0@oemcomputer> Date: Sun, 1 Nov 2009 12:07:49 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1C4EA86C-B572-4E53-9D50-25BCB9ACB7D2@jdscons.com> References: <200911011601.nA1G12oL015680@idle.juniper.net> <002801ca5b0c$a89a4c60$6801a8c0@oemcomputer> To: Randy Presuhn X-Mailer: Apple Mail (2.1076) Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 17:07:35 -0000 Randy, Good points. In the context of the current conversation, this history argues for getting as much of NETCONF/YANG correct the first time. I mean not only for the immediate application to which the protocol and language will be put, but also, where people want it to go. To the degree NETCONF/YANG are successful, it will be difficult to change them to make adjustments/corrections that the WG chooses to punt now. /jon On Nov 1, 2009, at 11:02 AM, Randy Presuhn wrote: > Hi - > >> From: "Phil Shafer" >> To: "Joel M. Halpern" >> Cc: "NETMOD Working Group" >> Sent: Sunday, November 01, 2009 9:01 AM >> Subject: Re: [netmod] operational knobs > ... >> I've always been curious why new verbs weren't added to SNMP >> instead of this kludge. Poking bytes into control registers >> clearly wasn't the example to follow and the distaste for it >> seems universal, but I've never grok'd why verbs like CREATE, >> DELETE, LOCK, CHANGE, PRE-CREATE, DISABLE, &etc weren't made. > ... > > Adding them would have been a change to the protocol's grammar, > which would have been a non-starter for several reasons: > > - re-starting the clock at "Proposed Standard" each time one of > these was added would have been politically unpalatable (CMIP > was a full IS, and, since it already had verbs for Create, > Delete, etc., > adding these to SNMP would also have been seen as an admission > of inadequacy) > > - changing the grammar would have adversely affected the deployed > base > of management systems and agents, as well as the various vendors' > development tools, and would have invalidated the > interoperability suites, > bake-offs, and test events. The ability to work with generic > "dumb" MIB > browsers was demanded by users. > > - by the time SMP, Secure SNMP, SNMPv2, SNMPv2*, etc, started > appearing, > access control models were being formulated in terms of object > identifiers. > If an "Action" facility were to be added, we'd have had to > formulate the policies > in ways similar to how VACM processes notifications, which > would severly > constrain how people could formulate actions. (Not that that > would have been > a bad thing) > > FWIW the CMIP experience, while it did establish that having > distinct verbs for > Create and Delete was a Good Thing, and had provisions for > synchronization > built into the object model and the protocol, also demonstrated that > a generic > Action facility, while useful, needed to be used *Very* carefully. > Like netconf RPCs, > it provided the ability to shovel around rather arbitrary syntax. > Mating this with > fine-grained access control expressed in terms of the object model is > hard. Later discussions of "we wish we had" in CMIP-land supported > limiting > the payload to things that would look like variable bindings, rather > than arbitrary > ASN.1, to ease matching up the bits and pieces of actions with the > objects' > data models. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Sun Nov 1 11:34:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BFA3A67DF for ; Sun, 1 Nov 2009 11:34:40 -0800 (PST) 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.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcm1Mzhji33Y for ; Sun, 1 Nov 2009 11:34:39 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 514823A6782 for ; Sun, 1 Nov 2009 11:34:39 -0800 (PST) Received: (qmail 66851 invoked from network); 1 Nov 2009 19:34:55 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 01 Nov 2009 11:34:54 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: wLl2YdsVM1l8gsyUOse1xX5Vvjd1Dfe8wCsrwRMIVxL4jDGM7Sa7Kdh7tT6SwKE3FTl5mDDh_DznaPwD2j6v5aiIiUO3p1bJWzSSMH4QOecMHWQRkl_tr15LD2eGnqGZbZ5F7A9LLR05P8iThxELv8l0lCG7rqIz7L7slzYklHAQEwzhOaa5z.8hz3Y0aNiGMvkzl.f5vjc13aDgwFkNIpiFm42xqE_W8YoF1s5l.e7_ZmIf3Nz4crRIMUgXdB0O33A0JHdR4_qlCK49zCRUg0ODAr9rqyjhwy9UpD2PzvTh67e89b_R X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AEDE315.6030100@netconfcentral.com> Date: Sun, 01 Nov 2009 11:35:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jon Saperia References: <200911011601.nA1G12oL015680@idle.juniper.net> <002801ca5b0c$a89a4c60$6801a8c0@oemcomputer> <1C4EA86C-B572-4E53-9D50-25BCB9ACB7D2@jdscons.com> In-Reply-To: <1C4EA86C-B572-4E53-9D50-25BCB9ACB7D2@jdscons.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 19:34:40 -0000 Jon Saperia wrote: > Randy, > > Good points. > > In the context of the current conversation, this history argues for > getting as much of NETCONF/YANG correct the first time. I mean not only > for the immediate application to which the protocol and language will be > put, but also, where people want it to go. > I disagree. We have a lot of theory, but not 1 config=true object in any I-D or RFC. We have a description-stmt for a reason. It is much easier for a WG to reach consensus on advanced features if there is common experience based on well-known data models in use. There also needs to be a YANG Doctors eventually, like MIB Doctors, so sufficient review resources are available throughout the IETF YANG data modeling experience. This is a far more effective process than working forever on YANG 1.0, because we know it is not perfect. > To the degree NETCONF/YANG are successful, it will be difficult to > change them to make adjustments/corrections that the WG chooses to punt > now. But now we have capabilities and a message. Incremental additions are part of the plan. > > /jon Andy > On Nov 1, 2009, at 11:02 AM, Randy Presuhn wrote: > >> Hi - >> >>> From: "Phil Shafer" >>> To: "Joel M. Halpern" >>> Cc: "NETMOD Working Group" >>> Sent: Sunday, November 01, 2009 9:01 AM >>> Subject: Re: [netmod] operational knobs >> ... >>> I've always been curious why new verbs weren't added to SNMP >>> instead of this kludge. Poking bytes into control registers >>> clearly wasn't the example to follow and the distaste for it >>> seems universal, but I've never grok'd why verbs like CREATE, >>> DELETE, LOCK, CHANGE, PRE-CREATE, DISABLE, &etc weren't made. >> ... >> >> Adding them would have been a change to the protocol's grammar, >> which would have been a non-starter for several reasons: >> >> - re-starting the clock at "Proposed Standard" each time one of >> these was added would have been politically unpalatable (CMIP >> was a full IS, and, since it already had verbs for Create, >> Delete, etc., >> adding these to SNMP would also have been seen as an admission >> of inadequacy) >> >> - changing the grammar would have adversely affected the deployed base >> of management systems and agents, as well as the various vendors' >> development tools, and would have invalidated the >> interoperability suites, >> bake-offs, and test events. The ability to work with generic >> "dumb" MIB >> browsers was demanded by users. >> >> - by the time SMP, Secure SNMP, SNMPv2, SNMPv2*, etc, started >> appearing, >> access control models were being formulated in terms of object >> identifiers. >> If an "Action" facility were to be added, we'd have had to >> formulate the policies >> in ways similar to how VACM processes notifications, which would >> severly >> constrain how people could formulate actions. (Not that that >> would have been >> a bad thing) >> >> FWIW the CMIP experience, while it did establish that having distinct >> verbs for >> Create and Delete was a Good Thing, and had provisions for >> synchronization >> built into the object model and the protocol, also demonstrated that a >> generic >> Action facility, while useful, needed to be used *Very* carefully. >> Like netconf RPCs, >> it provided the ability to shovel around rather arbitrary syntax. >> Mating this with >> fine-grained access control expressed in terms of the object model is >> hard. Later discussions of "we wish we had" in CMIP-land supported >> limiting >> the payload to things that would look like variable bindings, rather >> than arbitrary >> ASN.1, to ease matching up the bits and pieces of actions with the >> objects' >> data models. >> >> Randy >> >> _______________________________________________ >> 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 saperia@jdscons.com Sun Nov 1 12:18:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0168828C111 for ; Sun, 1 Nov 2009 12:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZQWqbwFKt4K for ; Sun, 1 Nov 2009 12:18:58 -0800 (PST) Received: from rs40.luxsci.com (rs40.luxsci.com [65.61.166.82]) by core3.amsl.com (Postfix) with ESMTP id EF0AD28C113 for ; Sun, 1 Nov 2009 12:18:57 -0800 (PST) Received: from [10.0.1.4] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id nA1KJEEV009007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 1 Nov 2009 14:19:15 -0600 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Jon Saperia In-Reply-To: <4AEDE315.6030100@netconfcentral.com> Date: Sun, 1 Nov 2009 15:19:14 -0500 Content-Transfer-Encoding: 7bit Message-Id: <7F50FFF5-14B3-41CA-82BF-14296A6C2557@jdscons.com> References: <200911011601.nA1G12oL015680@idle.juniper.net> <002801ca5b0c$a89a4c60$6801a8c0@oemcomputer> <1C4EA86C-B572-4E53-9D50-25BCB9ACB7D2@jdscons.com> <4AEDE315.6030100@netconfcentral.com> To: Andy Bierman X-Mailer: Apple Mail (2.1076) Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 20:18:59 -0000 On Nov 1, 2009, at 2:35 PM, Andy Bierman wrote: > Jon Saperia wrote: >> Randy, >> >> Good points. >> >> In the context of the current conversation, this history argues for >> getting as much of NETCONF/YANG correct the first time. I mean not >> only >> for the immediate application to which the protocol and language >> will be >> put, but also, where people want it to go. >> > > I disagree. > We have a lot of theory, but not 1 config=true > object in any I-D or RFC. We have a description-stmt > for a reason. > > It is much easier for a WG to reach consensus > on advanced features if there is common experience > based on well-known data models in use. I was not suggesting chrome polishing or advanced features. Yesterday you asked about operational knobs and said current drafts do not support them. My point is that, if as you suggest this is to be a requirement, that there is consensus that it can be addressed incrementally, if not right now. jon > > There also needs to be a YANG Doctors eventually, like MIB Doctors, > so sufficient review resources are available throughout the > IETF YANG data modeling experience. This is a far more effective > process than working forever on YANG 1.0, because we know it > is not perfect. > > >> To the degree NETCONF/YANG are successful, it will be difficult to >> change them to make adjustments/corrections that the WG chooses to >> punt >> now. > > But now we have capabilities and a message. > Incremental additions are part of the plan. > > >> >> /jon > > Andy > >> On Nov 1, 2009, at 11:02 AM, Randy Presuhn wrote: >> >>> Hi - >>> >>>> From: "Phil Shafer" >>>> To: "Joel M. Halpern" >>>> Cc: "NETMOD Working Group" >>>> Sent: Sunday, November 01, 2009 9:01 AM >>>> Subject: Re: [netmod] operational knobs >>> ... >>>> I've always been curious why new verbs weren't added to SNMP >>>> instead of this kludge. Poking bytes into control registers >>>> clearly wasn't the example to follow and the distaste for it >>>> seems universal, but I've never grok'd why verbs like CREATE, >>>> DELETE, LOCK, CHANGE, PRE-CREATE, DISABLE, &etc weren't made. >>> ... >>> >>> Adding them would have been a change to the protocol's grammar, >>> which would have been a non-starter for several reasons: >>> >>> - re-starting the clock at "Proposed Standard" each time one of >>> these was added would have been politically unpalatable (CMIP >>> was a full IS, and, since it already had verbs for Create, >>> Delete, etc., >>> adding these to SNMP would also have been seen as an admission >>> of inadequacy) >>> >>> - changing the grammar would have adversely affected the deployed >>> base >>> of management systems and agents, as well as the various >>> vendors' >>> development tools, and would have invalidated the >>> interoperability suites, >>> bake-offs, and test events. The ability to work with generic >>> "dumb" MIB >>> browsers was demanded by users. >>> >>> - by the time SMP, Secure SNMP, SNMPv2, SNMPv2*, etc, started >>> appearing, >>> access control models were being formulated in terms of object >>> identifiers. >>> If an "Action" facility were to be added, we'd have had to >>> formulate the policies >>> in ways similar to how VACM processes notifications, which would >>> severly >>> constrain how people could formulate actions. (Not that that >>> would have been >>> a bad thing) >>> >>> FWIW the CMIP experience, while it did establish that having >>> distinct >>> verbs for >>> Create and Delete was a Good Thing, and had provisions for >>> synchronization >>> built into the object model and the protocol, also demonstrated >>> that a >>> generic >>> Action facility, while useful, needed to be used *Very* carefully. >>> Like netconf RPCs, >>> it provided the ability to shovel around rather arbitrary syntax. >>> Mating this with >>> fine-grained access control expressed in terms of the object model >>> is >>> hard. Later discussions of "we wish we had" in CMIP-land supported >>> limiting >>> the payload to things that would look like variable bindings, rather >>> than arbitrary >>> ASN.1, to ease matching up the bits and pieces of actions with the >>> objects' >>> data models. >>> >>> Randy >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From andy@netconfcentral.com Sun Nov 1 13:29:47 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6174F3A6869 for ; Sun, 1 Nov 2009 13:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DD8nmuz-kuo for ; Sun, 1 Nov 2009 13:29:46 -0800 (PST) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id 4B1823A6822 for ; Sun, 1 Nov 2009 13:29:41 -0800 (PST) Received: (qmail 20892 invoked from network); 1 Nov 2009 21:29:58 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 01 Nov 2009 13:29:57 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 4Vhj1EMVM1lZnsnIzjwyOkIljnXVXDnFBCdjpNXCttt8L3vbBfuLNh8yh8YJtIE275NE.t0MjUM9PK_tW6iX5od4DQfilSuruzyXfHTbqm5JRB7XLqmQTHXgAz6qTFynMOwMCsrB.n6gTnhPYdcXLgauN99_B28RYz6Na3hT1NNRx5U.ElcAGPeyCiJyXqJxKeYRY7tX81cUXfSLY1YeRK4Ib97mArRUYsoetnEf2LC5qsJiwKATvDM5V0brlxG0rZObWInMOsPpVAutuyc22G7fOqHqbvxJzh357SgNVvCVx4NJFoZHJVFIO6apjaagwiB7oHD8xTIUYoQ9qyugqjV4z6I42B4JcJB0CYUOqMz2LQiP6dNW992Cajk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AEDFD94.7020904@netconfcentral.com> Date: Sun, 01 Nov 2009 13:28:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jon Saperia References: <200911011601.nA1G12oL015680@idle.juniper.net> <002801ca5b0c$a89a4c60$6801a8c0@oemcomputer> <1C4EA86C-B572-4E53-9D50-25BCB9ACB7D2@jdscons.com> <4AEDE315.6030100@netconfcentral.com> <7F50FFF5-14B3-41CA-82BF-14296A6C2557@jdscons.com> In-Reply-To: <7F50FFF5-14B3-41CA-82BF-14296A6C2557@jdscons.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 21:29:47 -0000 Jon Saperia wrote: > > On Nov 1, 2009, at 2:35 PM, Andy Bierman wrote: > >> Jon Saperia wrote: >>> Randy, >>> >>> Good points. >>> >>> In the context of the current conversation, this history argues for >>> getting as much of NETCONF/YANG correct the first time. I mean not only >>> for the immediate application to which the protocol and language will be >>> put, but also, where people want it to go. >>> >> >> I disagree. >> We have a lot of theory, but not 1 config=true >> object in any I-D or RFC. We have a description-stmt >> for a reason. >> >> It is much easier for a WG to reach consensus >> on advanced features if there is common experience >> based on well-known data models in use. > > I was not suggesting chrome polishing or advanced features. Yesterday > you asked about operational knobs and said current drafts do not support > them. My point is that, if as you suggest this is to be a requirement, > that there is consensus that it can be addressed incrementally, if not > right now. The consensus seems to be that 'action' (rpc-stmt) is the correct choice, not a config=true leaf. One question that keeps coming up: 'what is config?' There seems to be consensus that config is not a leaf that the server changes, once the client has set it. > jon Andy From phil@juniper.net Sun Nov 1 14:20:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F406E3A67CF for ; Sun, 1 Nov 2009 14:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n55fTXoSrlId for ; Sun, 1 Nov 2009 14:20:47 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 614613A6778 for ; Sun, 1 Nov 2009 14:20:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSu4J0FvAnnyAW251tTTl8XDu2uAUlA8I@postini.com; Sun, 01 Nov 2009 14:21:06 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 1 Nov 2009 14:20:05 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:20:06 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:20:05 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:20:04 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA1MK2j48804; Sun, 1 Nov 2009 14:20:03 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA1M6u1K018346; Sun, 1 Nov 2009 22:06:56 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911012206.nA1M6u1K018346@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AEDFD94.7020904@netconfcentral.com> Date: Sun, 1 Nov 2009 17:06:55 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Nov 2009 22:20:04.0856 (UTC) FILETIME=[76429F80:01CA5B41] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 22:20:48 -0000 Andy Bierman writes: >The consensus seems to be that 'action' (rpc-stmt) is >the correct choice, not a config=true leaf. "actions" were already discussed and the concensus was not to add them: http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00221 Thanks, Phil From phil@juniper.net Sun Nov 1 14:22:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCEF3A67CF for ; Sun, 1 Nov 2009 14:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ip136+iGuof for ; Sun, 1 Nov 2009 14:22:45 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 304093A6778 for ; Sun, 1 Nov 2009 14:22:45 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSu4KRn3uP/atVls4T9bSVGO869Y2o4MQ@postini.com; Sun, 01 Nov 2009 14:23:04 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 1 Nov 2009 14:22:00 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:22:00 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:22:00 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:21:59 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA1MLwj49141; Sun, 1 Nov 2009 14:21:58 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA1M8pd8018374; Sun, 1 Nov 2009 22:08:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911012208.nA1M8pd8018374@idle.juniper.net> To: Jon Saperia In-Reply-To: <1C4EA86C-B572-4E53-9D50-25BCB9ACB7D2@jdscons.com> Date: Sun, 1 Nov 2009 17:08:51 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Nov 2009 22:21:59.0382 (UTC) FILETIME=[BA85E760:01CA5B41] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 22:22:46 -0000 Jon Saperia writes: >To the degree NETCONF/YANG are successful, it will be difficult to >change them to make adjustments/corrections that the WG chooses to >punt now. I think our choice is more open, saying that the world changes and that we want to be more flexible and open in both NETCONF and YANG. Both have extension mechanisms that are meant to make the technologies more correctable, adjustable, and future proof. Thanks, Phil From phil@juniper.net Sun Nov 1 14:25:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032F33A6823 for ; Sun, 1 Nov 2009 14:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgRxIqevgrPo for ; Sun, 1 Nov 2009 14:25:31 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 1D4173A67F1 for ; Sun, 1 Nov 2009 14:25:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSu4K7VQsR7nfCFOrRilRNULZSDnJH234@postini.com; Sun, 01 Nov 2009 14:25:50 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 1 Nov 2009 14:24:44 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:24:44 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:24:44 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 14:24:43 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA1MOgj49839; Sun, 1 Nov 2009 14:24:42 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA1MBa9q018437; Sun, 1 Nov 2009 22:11:36 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911012211.nA1MBa9q018437@idle.juniper.net> To: "Randy Presuhn" In-Reply-To: <002801ca5b0c$a89a4c60$6801a8c0@oemcomputer> Date: Sun, 1 Nov 2009 17:11:35 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Nov 2009 22:24:43.0225 (UTC) FILETIME=[1C2E5C90:01CA5B42] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 22:25:32 -0000 "Randy Presuhn" writes: >Adding them would have been a change to the protocol's grammar, >which would have been a non-starter for several reasons: Adding new verbs would not have been so destructive. A MIB variables listing known verbs would have allowed a device to advertise to the application the verbs it supported, and verb-less clients would simply have ignored the advanced options available on enlghtened devices. Thanks, Phil From jmh@joelhalpern.com Sun Nov 1 14:28:47 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAF73A6823 for ; Sun, 1 Nov 2009 14:28:47 -0800 (PST) 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.097, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLEHxB6vB5lw for ; Sun, 1 Nov 2009 14:28:47 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 1FC983A67F1 for ; Sun, 1 Nov 2009 14:28:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 97912322D11B; Sun, 1 Nov 2009 14:29:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-240.clppva.btas.verizon.net [71.161.50.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id E2AA9322C5BE; Sun, 1 Nov 2009 14:29:04 -0800 (PST) Message-ID: <4AEE0BB3.30308@joelhalpern.com> Date: Sun, 01 Nov 2009 17:29:07 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200911012206.nA1M6u1K018346@idle.juniper.net> In-Reply-To: <200911012206.nA1M6u1K018346@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 22:28:47 -0000 To be specific, it was to "not add them now." I believe Andy said that he does not want to add them before YANG 1.0. His point, which I think is well taken, is that we will need to figure out what variation on action / rpc definition we want to use, and define it. Text pointing in the right direction should go somewhere (the arch draft seems sensible) so that folks do not simply re-implement the SNMP mechanism. Also note, the question you pointed to was actually much narrower, as it was about defining actions in lists, which introduces many powerful and complicated issues. Yours, Joel Phil Shafer wrote: > Andy Bierman writes: >> The consensus seems to be that 'action' (rpc-stmt) is >> the correct choice, not a config=true leaf. > > "actions" were already discussed and the concensus was not to add them: > > http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00221 > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From randy_presuhn@mindspring.com Sun Nov 1 16:50:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE0C3A687E for ; Sun, 1 Nov 2009 16:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0krs+hbTQoY for ; Sun, 1 Nov 2009 16:50:04 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 392003A6862 for ; Sun, 1 Nov 2009 16:50:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FzHN+juEwVBLomF3MYKMOgzMMvJajvXAac1AqO/XXM6nMErpyJ45GJDU1/ROwtSc; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.55.135] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N4l7m-0003G1-Te for netmod@ietf.org; Sun, 01 Nov 2009 19:50:23 -0500 Message-ID: <001e01ca5b4e$15dd93e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <200911012211.nA1MBa9q018437@idle.juniper.net> Date: Sun, 1 Nov 2009 16:50:24 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9587f8c5297ec3769de2e13bb26ef7cce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.55.135 Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 00:50:05 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: "NETMOD Working Group" > Sent: Sunday, November 01, 2009 3:11 PM > Subject: Re: [netmod] operational knobs > > "Randy Presuhn" writes: > >Adding them would have been a change to the protocol's grammar, > >which would have been a non-starter for several reasons: > > Adding new verbs would not have been so destructive. A MIB variables > listing known verbs would have allowed a device to advertise to the > application the verbs it supported, and verb-less clients would > simply have ignored the advanced options available on enlghtened > devices. I disagree. The *grammar* of the SNMP protocol has no provision for this kind of extensibility. There simply is no way to add a new verb without changing the grammar of the protocol. I am certain this limitation was deliberate; CMIP, developed during the same period, made extensive use of ASN.1's extinsibility mechanisms (ANY DEFINED BY). Randy From j.schoenwaelder@jacobs-university.de Sun Nov 1 21:36:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1361528C0E3 for ; Sun, 1 Nov 2009 21:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCAe70F2WUkj for ; Sun, 1 Nov 2009 21:36:04 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D7A9928C0D8 for ; Sun, 1 Nov 2009 21:36:03 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F27ABC000C; Mon, 2 Nov 2009 06:36:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZbpEZcThVKMB; Mon, 2 Nov 2009 06:36:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F841C0009; Mon, 2 Nov 2009 06:36:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1BDE9D60534; Mon, 2 Nov 2009 06:36:19 +0100 (CET) Date: Mon, 2 Nov 2009 06:36:19 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20091102053619.GA23203@elstar.local> Mail-Followup-To: Randy Presuhn , NETMOD Working Group References: <200911012211.nA1MBa9q018437@idle.juniper.net> <001e01ca5b4e$15dd93e0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001e01ca5b4e$15dd93e0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 05:36:05 -0000 On Mon, Nov 02, 2009 at 12:50:24AM +0100, Randy Presuhn wrote: > Hi - > > > From: "Phil Shafer" > > To: "Randy Presuhn" > > Cc: "NETMOD Working Group" > > Sent: Sunday, November 01, 2009 3:11 PM > > Subject: Re: [netmod] operational knobs > > > > "Randy Presuhn" writes: > > >Adding them would have been a change to the protocol's grammar, > > >which would have been a non-starter for several reasons: > > > > Adding new verbs would not have been so destructive. A MIB variables > > listing known verbs would have allowed a device to advertise to the > > application the verbs it supported, and verb-less clients would > > simply have ignored the advanced options available on enlghtened > > devices. > > I disagree. The *grammar* of the SNMP protocol has no provision for this > kind of extensibility. There simply is no way to add a new verb without > changing the grammar of the protocol. I am certain this limitation was > deliberate; CMIP, developed during the same period, made extensive > use of ASN.1's extinsibility mechanisms (ANY DEFINED BY). This is really off topic, but RFC 1157, RFC 1901, and RFC 3412 all use "ANY -- e.g., PDUs". Yes, it is not ANY DEFINED BY but if people would have wanted to add create/delete operations, the grammar would not have been the show stopper. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Sun Nov 1 22:50:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE343A68BA for ; Sun, 1 Nov 2009 22:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3V8F0z9KT6Y for ; Sun, 1 Nov 2009 22:50:14 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id C07703A6359 for ; Sun, 1 Nov 2009 22:50:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qg0jG96KTXSb9XOJdwa/jpYsMYzs7NJpebnEcTC1Q9UHCLoCysagHqSI5J5Jm5K0; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.54.88] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N4qkL-0003qk-Vz for netmod@ietf.org; Mon, 02 Nov 2009 01:50:34 -0500 Message-ID: <000a01ca5b80$619cfbe0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <200911012211.nA1MBa9q018437@idle.juniper.net> <001e01ca5b4e$15dd93e0$6801a8c0@oemcomputer> <20091102053619.GA23203@elstar.local> Date: Sun, 1 Nov 2009 22:50:26 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f99a87296bf493428f8b38d2550bd88f0b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.88 Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 06:50:15 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: "NETMOD Working Group" > Sent: Sunday, November 01, 2009 10:36 PM > Subject: Re: [netmod] operational knobs ... > This is really off topic, but RFC 1157, RFC 1901, and RFC 3412 all use > "ANY -- e.g., PDUs". Yes, it is not ANY DEFINED BY but if people would > have wanted to add create/delete operations, the grammar would not > have been the show stopper. The "ANY" in the envelope was just a hack to allow an encrypted payload. The elements of procedure require it to be treated as a parse error if it doesn't match the grammar for "PDUs". Putting anything else there would still require it to be treated as a new protocol version. Randy From j.schoenwaelder@jacobs-university.de Mon Nov 2 00:52:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07ED23A67F5 for ; Mon, 2 Nov 2009 00:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQHHv7fNFsCd for ; Mon, 2 Nov 2009 00:51:59 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 13BBB3A67B8 for ; Mon, 2 Nov 2009 00:51:58 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94D48C001A; Mon, 2 Nov 2009 09:52:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bmQnfnGJxwrr; Mon, 2 Nov 2009 09:52:14 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9D18C0007; Mon, 2 Nov 2009 09:52:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0306BD62BB5; Mon, 2 Nov 2009 09:52:13 +0100 (CET) Date: Mon, 2 Nov 2009 09:52:13 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20091102085213.GA23298@elstar.local> Mail-Followup-To: Randy Presuhn , NETMOD Working Group References: <200911012211.nA1MBa9q018437@idle.juniper.net> <001e01ca5b4e$15dd93e0$6801a8c0@oemcomputer> <20091102053619.GA23203@elstar.local> <000a01ca5b80$619cfbe0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000a01ca5b80$619cfbe0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 08:52:00 -0000 On Mon, Nov 02, 2009 at 06:50:26AM +0100, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: "NETMOD Working Group" > > Sent: Sunday, November 01, 2009 10:36 PM > > Subject: Re: [netmod] operational knobs > ... > > This is really off topic, but RFC 1157, RFC 1901, and RFC 3412 all use > > "ANY -- e.g., PDUs". Yes, it is not ANY DEFINED BY but if people would > > have wanted to add create/delete operations, the grammar would not > > have been the show stopper. > > The "ANY" in the envelope was just a hack to allow an encrypted payload. > The elements of procedure require it to be treated as a parse error if it > doesn't match the grammar for "PDUs". Putting anything else there > would still require it to be treated as a new protocol version. Yes, because the WG did choose to forbit this sort of extension and this was a political decision, not a grammar problem. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Mon Nov 2 03:51:25 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4D23A682C for ; Mon, 2 Nov 2009 03:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk+paW6sM6S6 for ; Mon, 2 Nov 2009 03:51:24 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D50A33A6819 for ; Mon, 2 Nov 2009 03:51:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,666,1249272000"; d="scan'208";a="162007299" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Nov 2009 06:51:41 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Nov 2009 06:51:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 12:51:31 +0100 Message-ID: In-Reply-To: <4AEDE315.6030100@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] operational knobs Thread-Index: AcpbKmhtG3K5EwCYT1qSSww8Kg7RDgAiBy+A References: <200911011601.nA1G12oL015680@idle.juniper.net> <002801ca5b0c$a89a4c60$6801a8c0@oemcomputer><1C4EA86C-B572-4E53-9D50-25BCB9ACB7D2@jdscons.com> <4AEDE315.6030100@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Jon Saperia" Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 11:51:25 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >=20 > There also needs to be a YANG Doctors eventually, like MIB=20 > Doctors, so sufficient review resources are available=20 > throughout the IETF YANG data modeling experience. =20 Yes. This team will need the YANG Usage Guidelines document at hand as a reference as soon as possible. I have seen to little attention being paid to it, which is maybe normal until we send the core YANG document to the IESG, but then we need to start focusing on making it happen.=20 Dan From dromasca@avaya.com Mon Nov 2 03:56:36 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938DC28C212 for ; Mon, 2 Nov 2009 03:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D34-+0blo12e for ; Mon, 2 Nov 2009 03:56:35 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5AEE028C1DE for ; Mon, 2 Nov 2009 03:56:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,666,1249272000"; d="scan'208";a="162007626" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Nov 2009 06:56:53 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Nov 2009 06:56:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 12:56:51 +0100 Message-ID: In-Reply-To: <20091102085213.GA23298@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] operational knobs Thread-Index: AcpbmcrMwYad0bkrQdqt6bx709LaWwAGaiGQ References: <200911012211.nA1MBa9q018437@idle.juniper.net><001e01ca5b4e$15dd93e0$6801a8c0@oemcomputer><20091102053619.GA23203@elstar.local><000a01ca5b80$619cfbe0$6801a8c0@oemcomputer> <20091102085213.GA23298@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Randy Presuhn" Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 11:56:36 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Monday, November 02, 2009 10:52 AM > To: Randy Presuhn > Cc: NETMOD Working Group > Subject: Re: [netmod] operational knobs >=20 > On Mon, Nov 02, 2009 at 06:50:26AM +0100, Randy Presuhn wrote: > > Hi - > >=20 > > > From: "Juergen Schoenwaelder"=20 > > > > To: "Randy Presuhn" > > > Cc: "NETMOD Working Group" > > > Sent: Sunday, November 01, 2009 10:36 PM > > > Subject: Re: [netmod] operational knobs > > ... > > > This is really off topic, but RFC 1157, RFC 1901, and RFC=20 > 3412 all=20 > > > use "ANY -- e.g., PDUs". Yes, it is not ANY DEFINED BY=20 > but if people=20 > > > would have wanted to add create/delete operations, the=20 > grammar would=20 > > > not have been the show stopper. > >=20 > > The "ANY" in the envelope was just a hack to allow an=20 > encrypted payload. > > The elements of procedure require it to be treated as a=20 > parse error if=20 > > it doesn't match the grammar for "PDUs". Putting anything=20 > else there=20 > > would still require it to be treated as a new protocol version. >=20 > Yes, because the WG did choose to forbit this sort of=20 > extension and this was a political decision, not a grammar problem. >=20 > /js >=20 It was a political decision which resulted in parsing errors :-)=20 Dan From phil@juniper.net Mon Nov 2 06:59:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA2328C12C for ; Mon, 2 Nov 2009 06:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBHo9RIK27aP for ; Mon, 2 Nov 2009 06:59:23 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 5D8B83A657C for ; Mon, 2 Nov 2009 06:59:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSu7z2mevnEu1aCcCMGhKi3tEg8d4yPzx@postini.com; Mon, 02 Nov 2009 06:59:43 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 2 Nov 2009 06:55:11 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 06:55:12 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 06:55:11 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 06:55:10 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA2EtAj28588; Mon, 2 Nov 2009 06:55:10 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA2Eg2KH037978; Mon, 2 Nov 2009 14:42:02 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911021442.nA2Eg2KH037978@idle.juniper.net> To: "Romascanu, Dan (Dan)" In-Reply-To: Date: Mon, 2 Nov 2009 09:42:02 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Nov 2009 14:55:10.0674 (UTC) FILETIME=[79B37320:01CA5BCC] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:59:24 -0000 "Romascanu, Dan (Dan)" writes: >It was a political decision which resulted in parsing errors :-) But couldn't the political decision have been reversed when the tide of "not so simple variables" began to flow in? Thanks, Phil From dromasca@avaya.com Mon Nov 2 07:53:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4403A6963 for ; Mon, 2 Nov 2009 07:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBfs2cF9u10O for ; Mon, 2 Nov 2009 07:53:58 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 42E1A3A68F0 for ; Mon, 2 Nov 2009 07:53:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,667,1249272000"; d="scan'208";a="162034419" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Nov 2009 10:54:15 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Nov 2009 10:54:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 16:53:56 +0100 Message-ID: In-Reply-To: <200911021442.nA2Eg2KH037978@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] operational knobs Thread-Index: AcpbzR0U5GT2FwesQ1KI+88wX/XOMQABrSQg References: <200911021442.nA2Eg2KH037978@idle.juniper.net> From: "Romascanu, Dan (Dan)" To: "Phil Shafer" Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:53:59 -0000 =20 > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net]=20 > Sent: Monday, November 02, 2009 4:42 PM > To: Romascanu, Dan (Dan) > Cc: Juergen Schoenwaelder; Randy Presuhn; NETMOD Working Group > Subject: Re: [netmod] operational knobs=20 >=20 > "Romascanu, Dan (Dan)" writes: > >It was a political decision which resulted in parsing errors :-) >=20 > But couldn't the political decision have been reversed when=20 > the tide of "not so simple variables" began to flow in? >=20 > Thanks, > Phil >=20 It was not that easy, and the success of the protocol was part of the reason. It took a few years to realize that CMIP / CMOT will never happen. By that time SNMP was working at least for some applications the IETF needed, with security being the principal flaw the whole community was told to focus for another few good years. You can consider SNMCONF and SMIng as tentative to finesse the issue without rocking the boat of the protocol. And then somebody said X-M-L !! Dan (apologizing for historical soapboxes) From andy@netconfcentral.com Mon Nov 2 08:52:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52EA28C18D for ; Mon, 2 Nov 2009 08:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frmLKwH4DoW2 for ; Mon, 2 Nov 2009 08:52:00 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id 1185628C18C for ; Mon, 2 Nov 2009 08:52:00 -0800 (PST) Received: (qmail 45625 invoked from network); 2 Nov 2009 16:52:20 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 02 Nov 2009 08:52:19 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6Sr0pecVM1lRQN4A6HS_KpRZ6X53XxC905ykIxgeJNV9RTaP5DqqPgNCHVjmBxNUVJEgSyITRRyUgqP.ibGlBju3h.I1U6zntDgTodHsY2Nih2jqQszT8bs07mM2WR0.3zd2_qhLLMwzjRVZ8xsm5UoZugMSWVIygeUx9CR8FYmknQ7Zr6_IaQBX8.jirkEUw0BICkklngWxmKNhstEbqwV2idI9TONkHKrKv0DeSx6ApODURvkpsL_kmZ2i6NhSyDDK7xaInsOk.oES_9_AKm3GYU8h0l.EvOdObaLzzoDvds1bn_oG0_EwnWeqygJUwdmkhpzIeIjALE9fitwxFxCkw422BxoM4xtE.N84fjBvuLunGTJ3.1cO_yZ33uO5DBa_AOHRFAyXxsBvZKA7KOBn20QX8x0U X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AEF0E80.40107@netconfcentral.com> Date: Mon, 02 Nov 2009 08:53:20 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: <200911021442.nA2Eg2KH037978@idle.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:52:01 -0000 Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: Phil Shafer [mailto:phil@juniper.net] >> Sent: Monday, November 02, 2009 4:42 PM >> To: Romascanu, Dan (Dan) >> Cc: Juergen Schoenwaelder; Randy Presuhn; NETMOD Working Group >> Subject: Re: [netmod] operational knobs >> >> "Romascanu, Dan (Dan)" writes: >>> It was a political decision which resulted in parsing errors :-) >> But couldn't the political decision have been reversed when >> the tide of "not so simple variables" began to flow in? >> >> Thanks, >> Phil >> > > It was not that easy, and the success of the protocol was part of the > reason. It took a few years to realize that CMIP / CMOT will never > happen. By that time SNMP was working at least for some applications the > IETF needed, with security being the principal flaw the whole community > was told to focus for another few good years. You can consider SNMCONF > and SMIng as tentative to finesse the issue without rocking the boat of > the protocol. And then somebody said X-M-L !! > There were some of us that were tried to get SNMP to change so that SNMP Set would be relatively implementable. The 'gumball machine effect' in SNMP, and the lack of complex data structures in SMIv2, made distributed control tables a nightmare to code in the agent. CLI accepts 1 command at a time. SNMP accepts an arbitrary number of leafs from an arbitrary number of commands, and reconstructs commands as they arrive in Set PDUs. Something as dirt-simple in NETCONF as is a nest of kludges in SNMP. For awhile, many OPS people did not really believe operators when they said they liked CLI because they could read it. Think OID. Then go as far in the opposite direction as possible. Some of the many benefits of XML -- it can be read, cut-and-pasted, and emailed. But we don't need to replay the XMLCONF discussions that led to the formation of the NETCONF WG. SMIv2 action knob --> NETCONF . End of problem (for now). > Dan > (apologizing for historical soapboxes) me too! Andy From randy_presuhn@mindspring.com Mon Nov 2 10:19:41 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFB83A63EB for ; Mon, 2 Nov 2009 10:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8eQPP4Nnb4D for ; Mon, 2 Nov 2009 10:19:41 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id AA5613A63D3 for ; Mon, 2 Nov 2009 10:19:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WSf5HyFnicLpgkgVIq6eroXHe6LKZAgaw6Mp5AMS6oey+Gy1/Co0qIQBCzlTzxrJ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.54.88] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N51VW-0002P1-AN for netmod@ietf.org; Mon, 02 Nov 2009 13:19:58 -0500 Message-ID: <002901ca5be0$b87110e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <200911021442.nA2Eg2KH037978@idle.juniper.net> <4AEF0E80.40107@netconfcentral.com> Date: Mon, 2 Nov 2009 10:20:04 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9e144a38567fa9df14f5753a07d0ee407350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.88 Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 18:19:41 -0000 Hi - > From: "Andy Bierman" > To: "Romascanu, Dan (Dan)" > Cc: "NETMOD Working Group" > Sent: Monday, November 02, 2009 9:53 AM > Subject: Re: [netmod] operational knobs ... > But we don't need to replay the XMLCONF discussions that led to > the formation of the NETCONF WG. SMIv2 action knob --> NETCONF . > End of problem (for now). ... That's what we though we had accomplished with CMIP's "Action". :-( There are serious lessons to be learned from the failures there, especially with regard to access control, how one constructs information models, and formalizing the description of side-effects, at least to the point where action X can be said to interoperably accomplish "the same thing" on both implementations Y and Z. But you're right - this group has already set its direction, and a Cassandra- like rehash isn't helpful. Randy From andy@netconfcentral.com Tue Nov 3 09:24:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF253A6A40 for ; Tue, 3 Nov 2009 09:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCr1j2grIjaL for ; Tue, 3 Nov 2009 09:24:36 -0800 (PST) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 24DB73A6A3D for ; Tue, 3 Nov 2009 09:24:36 -0800 (PST) Received: from [209.191.108.97] by n18.bullet.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 17:24:55 -0000 Received: from [68.142.201.248] by t4.bullet.mud.yahoo.com with NNFMP; 03 Nov 2009 17:24:55 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 17:24:55 -0000 X-Yahoo-Newman-Id: 475834.71991.bm@omp409.mail.mud.yahoo.com Received: (qmail 95240 invoked from network); 3 Nov 2009 17:24:54 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 3 Nov 2009 17:24:54 -0000 X-YMail-OSG: 9BEd5W0VM1kJ1DcuaV6T1FNJ7neRoVXvEhDffiO8Tq64OOh.nIYjT_pr9mrIIptfnEKOy0or39XVxeVJDze_.CXZnRxNV4ST.xKFsZbyoInSnUK1.DTDSTAN37BRxG7CxQ_sZF69h_4KFdCrSF1Zzo22jfBVbzwSxG8VozNH2QQXQmjnNzicB7wUicNWVWwAI4uVWWuEfHn8OR.WqVasboRbYJw4saNe283aOaapoesU1tZtcthrg2ECoY1x3TCP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF067A8.5020304@netconfcentral.com> Date: Tue, 03 Nov 2009 09:26:00 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200911021442.nA2Eg2KH037978@idle.juniper.net> In-Reply-To: <200911021442.nA2Eg2KH037978@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:24:37 -0000 Phil Shafer wrote: > "Romascanu, Dan (Dan)" writes: >> It was a political decision which resulted in parsing errors :-) > > But couldn't the political decision have been reversed when the > tide of "not so simple variables" began to flow in? > Bad decisions can still benefit from Newton's first law of motion :-) At 10,000 feet, SNMP was succeeding at monitoring. But on the ground, it was obvious (SNMPCONF, DIFFSERV-MIB, APM-MIB, TPM-MIB) that we had reached the upper bound of SMIv2/SNMP utility. IMO, new verbs and nested data structures in notifications are the best parts of YANG. The config database may turn out to be a 'legacy' concept, and complex verbs may replace get/set operations on an XML tree someday. > Thanks, > Phil Andy From randy_presuhn@mindspring.com Tue Nov 3 09:37:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387D93A6A48 for ; Tue, 3 Nov 2009 09:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e63gfBJljty for ; Tue, 3 Nov 2009 09:37:58 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 53C143A68E0 for ; Tue, 3 Nov 2009 09:37:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=n3OTPrKV8mHrn0SgizUPnxLTHNyByidF3zYUnIZ6GDqFomN11oELb+++DHmts2IG; 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.25] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N5NKk-0007ER-SM for netmod@ietf.org; Tue, 03 Nov 2009 12:38:19 -0500 Message-ID: <001801ca5ca4$1226b900$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <200911021442.nA2Eg2KH037978@idle.juniper.net> <4AF067A8.5020304@netconfcentral.com> Date: Tue, 3 Nov 2009 09:38:26 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f96eeef2503be693bc52af6cdf1c45e40b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.25 Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:37:59 -0000 Hi - > From: "Andy Bierman" > To: "Phil Shafer" > Cc: "NETMOD Working Group" > Sent: Tuesday, November 03, 2009 10:26 AM > Subject: Re: [netmod] operational knobs ... > IMO, new verbs and nested data structures in notifications > are the best parts of YANG. Initially, we thought the same thing about these capabilities in CMIP. Implementation and deployment experience demonstrated that they came at a high cost, though in areas that netconf hasn't really started to dig into. > The config database may > turn out to be a 'legacy' concept, and complex verbs may > replace get/set operations on an XML tree someday. If that's the case, then you may as well discard the whole notion that configuration management is about bringing a system to a reasonably known state. Randy From dromasca@avaya.com Tue Nov 3 09:44:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030A33A6A58 for ; Tue, 3 Nov 2009 09:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ecwizIBxGr3 for ; Tue, 3 Nov 2009 09:43:59 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 09F783A6A4D for ; Tue, 3 Nov 2009 09:43:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,675,1249272000"; d="scan'208";a="189045852" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Nov 2009 12:44:18 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Nov 2009 12:44:18 -0500 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: Tue, 3 Nov 2009 18:43:46 +0100 Message-ID: In-Reply-To: <001801ca5ca4$1226b900$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] operational knobs Thread-Index: AcpcrHKOQW9suQ6rTIOCleivAxEKmgAADFmg References: <200911021442.nA2Eg2KH037978@idle.juniper.net><4AF067A8.5020304@netconfcentral.com> <001801ca5ca4$1226b900$6801a8c0@oemcomputer> From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "NETMOD Working Group" Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:44:00 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Tuesday, November 03, 2009 6:38 PM > To: NETMOD Working Group > Subject: Re: [netmod] operational knobs >=20 > Hi - >=20 > > From: "Andy Bierman" > > To: "Phil Shafer" > > Cc: "NETMOD Working Group" > > Sent: Tuesday, November 03, 2009 10:26 AM > > Subject: Re: [netmod] operational knobs > ... > > IMO, new verbs and nested data structures in notifications are the=20 > > best parts of YANG. >=20 > Initially, we thought the same thing about these capabilities in CMIP. > Implementation and deployment experience demonstrated that=20 > they came at a high cost, though in areas that netconf hasn't=20 > really started to dig into. >=20 What changed in the two decades dramatically is the cost of the resources needed for implementation on a network device. As an implementer at that time I can bare direct witness that the principal reason we adopted SNMP at that point in time was simply that it was implementable in network devices (hubs, bridges, routers) while CMIP was not.=20 > > The config database may > > turn out to be a 'legacy' concept, and complex verbs may replace=20 > > get/set operations on an XML tree someday. >=20 > If that's the case, then you may as well discard the whole=20 > notion that configuration management is about bringing a=20 > system to a reasonably known state. I would agree. I do not see yet how interoperable management is possible without a config database shared between different vendors of devices and applications but maybe it's just that I am not imaginative enough.=20 Dan >=20 > Randy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From randy_presuhn@mindspring.com Tue Nov 3 10:06:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1FE28C145 for ; Tue, 3 Nov 2009 10:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkHB4iGVyobE for ; Tue, 3 Nov 2009 10:06:36 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 3AEFF28C139 for ; Tue, 3 Nov 2009 10:06:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jomfe+ulNdZLD7NQvsDTJG8VhLSizU4OstlEzO5B3Xie1g8BN3z0t0F8ZtNVVQE3; 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.25] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N5NmS-0007Yx-FH for netmod@ietf.org; Tue, 03 Nov 2009 13:06:57 -0500 Message-ID: <002a01ca5ca8$128ef3e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <200911021442.nA2Eg2KH037978@idle.juniper.net><4AF067A8.5020304@netconfcentral.com> <001801ca5ca4$1226b900$6801a8c0@oemcomputer> Date: Tue, 3 Nov 2009 10:07:05 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9e17f33bffb6952da3f6206624b91506d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.25 Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:06:37 -0000 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "NETMOD Working Group" > Sent: Tuesday, November 03, 2009 10:43 AM > Subject: RE: [netmod] operational knobs ... > What changed in the two decades dramatically is the cost of the > resources needed for implementation on a network device. As an > implementer at that time I can bare direct witness that the principal > reason we adopted SNMP at that point in time was simply that it was > implementable in network devices (hubs, bridges, routers) while CMIP was > not. That depends on the implementation approach. Yes, at that time there was a freely-available implementation which was spectacularly inefficient in terms of code size, memory use, and processing time. I think that implementation did more to kill CMIP than anything else. We implemented it from scratch, and found it could be implemented compactly and efficiently, working quite well in 68000/68302-based network gear. Randy From andy@netconfcentral.com Tue Nov 3 12:11:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BF03A6896 for ; Tue, 3 Nov 2009 12:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM-qPXENXCab for ; Tue, 3 Nov 2009 12:11:58 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 65B8B3A6878 for ; Tue, 3 Nov 2009 12:11:58 -0800 (PST) Received: (qmail 42501 invoked from network); 3 Nov 2009 20:12:18 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 03 Nov 2009 12:12:17 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: W48FI0kVM1l.nJEQLQw982ORUhjEfzELobdKQxGwwvlnbmpPAKsp_jznfrlYZdGXqguGpi5P3TZtjyPLHcr.avZr.hslybaW9IZDZTmu8cOr8T8paO7VDRcOoHmhJbJaeSkl7UJAcDpeP86ZJW1gy6rFG1tbfOh79Yqji6w_bm7elECPVjWUy1uORF2CaxGsKyfTZt.Mbv.pZC299sqyi8Yfch989csubmvWn9tSdA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF08E6A.6060002@netconfcentral.com> Date: Tue, 03 Nov 2009 12:11:22 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: <200911021442.nA2Eg2KH037978@idle.juniper.net><4AF067A8.5020304@netconfcentral.com> <001801ca5ca4$1226b900$6801a8c0@oemcomputer> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:11:59 -0000 Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Randy Presuhn >> Sent: Tuesday, November 03, 2009 6:38 PM >> To: NETMOD Working Group >> Subject: Re: [netmod] operational knobs >> >> Hi - >> >>> From: "Andy Bierman" >>> To: "Phil Shafer" >>> Cc: "NETMOD Working Group" >>> Sent: Tuesday, November 03, 2009 10:26 AM >>> Subject: Re: [netmod] operational knobs >> ... >>> IMO, new verbs and nested data structures in notifications are the >>> best parts of YANG. >> Initially, we thought the same thing about these capabilities in CMIP. >> Implementation and deployment experience demonstrated that >> they came at a high cost, though in areas that netconf hasn't >> really started to dig into. >> > > What changed in the two decades dramatically is the cost of the > resources needed for implementation on a network device. As an > implementer at that time I can bare direct witness that the principal > reason we adopted SNMP at that point in time was simply that it was > implementable in network devices (hubs, bridges, routers) while CMIP was > not. > >>> The config database may >>> turn out to be a 'legacy' concept, and complex verbs may replace >>> get/set operations on an XML tree someday. >> If that's the case, then you may as well discard the whole >> notion that configuration management is about bringing a >> system to a reasonably known state. > > I would agree. I do not see yet how interoperable management is possible > without a config database shared between different vendors of devices > and applications but maybe it's just that I am not imaginative enough. > I'm not saying the technology is in place to allow a command-oriented approach to completely replace the data-oriented approach, but... The problem with pure data structures is that the high-level procedures built on top of the data structures are not uniform, and usually not even formally defined. It may not make sense to adjust knobs arbitrarily once a network service has been created from the XML representation of the desired state. This was often the case with MIBs, and there are many DESCRIPTION clauses that say "This object may not be modified if the associated RowStatus is equal to 'active'". There are high implementation, interoperability, and training costs due to the data-approach that are not immediately obvious. Operators like to think in terms of sending commands to the device. Translating between YANG data structures and high-level commands is ad-hoc and usually non-trivial. IMO, we would reach faster, better interoperability by standardizing basic operations, and not mandating complete adoption of complex data structures. For example, an operation to start a DHCP service instead of a complex data structure: start-dhcp (start-address=192.168.1.10, end-address=192.168.1.100, ...) There are no internal data structures that can be altered in arbitrary ways with edit-config and copy-config. There is no parameter changing on the fly to support. Obviously DHCP config would be way more complicated than this, but my point is that RPC operations allow the WG to standardize procedures, which can be a subset of all possible protocol behavior. This allows some forward progress, in highly directed and interoperable steps. I am not convinced that the forklift data-model (ala ipfix-psamp.yang) has much chance of widespread deployment. > Dan > >> Randy Andy From phil@juniper.net Tue Nov 3 13:00:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC263A681B for ; Tue, 3 Nov 2009 13:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpqAS9zqA9Xb for ; Tue, 3 Nov 2009 13:00:50 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 2C86B3A6802 for ; Tue, 3 Nov 2009 13:00:49 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSvCaFGJe7jdSiEf88rwaFnXrcqCpM7Yg@postini.com; Tue, 03 Nov 2009 13:01:11 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 3 Nov 2009 12:54:24 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 12:54:24 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 12:54:24 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 12:54:23 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA3KsNj80038; Tue, 3 Nov 2009 12:54:23 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA3KfEmK070263; Tue, 3 Nov 2009 20:41:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911032041.nA3KfEmK070263@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AF08E6A.6060002@netconfcentral.com> Date: Tue, 3 Nov 2009 15:41:14 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Nov 2009 20:54:23.0857 (UTC) FILETIME=[D2CFEE10:01CA5CC7] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:00:51 -0000 Andy Bierman writes: > start-dhcp (start-address=192.168.1.10, end-address=192.168.1.100, ...) This is fine if the customer doesn't care about any of the details of how dhcp is deployed, or it your RPC contains all the parameters they need. But each customer is different; beware of underestimating the diversity of the marketplace. IMHO the world's just not that simple. Eventually, you'll need access to other config data (interfaces) and datastore-wide constraint checking. The good news is that YANG handle do all this. >I am not >convinced that the forklift data-model (ala ipfix-psamp.yang) >has much chance of widespread deployment. My hope is that I can define simple transformations between IETF models and JUNOS models. I think it's unlikely that JUNOS will adopt the DHCP module directly, but if we can generate data that is ietf-dhcp.yang with junos augmentations. Thanks, Phil From andy@netconfcentral.com Tue Nov 3 14:13:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CC53A6808 for ; Tue, 3 Nov 2009 14:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQm9H2UjG0kM for ; Tue, 3 Nov 2009 14:13:28 -0800 (PST) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id F22A03A67A2 for ; Tue, 3 Nov 2009 14:13:27 -0800 (PST) Received: from [68.142.200.224] by n17.bullet.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 22:13:47 -0000 Received: from [68.142.201.69] by t5.bullet.mud.yahoo.com with NNFMP; 03 Nov 2009 22:13:47 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 22:13:47 -0000 X-Yahoo-Newman-Id: 126729.39438.bm@omp421.mail.mud.yahoo.com Received: (qmail 25009 invoked from network); 3 Nov 2009 22:13:46 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 03 Nov 2009 14:13:46 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Qo32iTMVM1kJLTxRX9jtdutMBAjIv.e_MaBryrDRocg4OpB6cZPO1tYE8oByDs08Kwcw4pGPacZJfcOgOekhYNE2RUreEPcI27TWqGqWMmGLj6MnvEFHGm.c3HHNlRLpXukdYfG9VLrgEBYDu4hWILknWNH3R1U0OPRzEmFF2fyagC2TTP70fS7glNHYa9c7Gm6uWQ.Ezn8so1tbKZI3mzUacx5nfGdTxJaNlycRxkRqQ5xZjXFg2ODCWhe25cF7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF0AB5D.2060101@netconfcentral.com> Date: Tue, 03 Nov 2009 14:14:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200911032041.nA3KfEmK070263@idle.juniper.net> In-Reply-To: <200911032041.nA3KfEmK070263@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:13:29 -0000 Phil Shafer wrote: > Andy Bierman writes: >> start-dhcp (start-address=192.168.1.10, end-address=192.168.1.100, ...) > > This is fine if the customer doesn't care about any of the details > of how dhcp is deployed, or it your RPC contains all the parameters > they need. But each customer is different; beware of underestimating > the diversity of the marketplace. > > IMHO the world's just not that simple. Eventually, you'll need > access to other config data (interfaces) and datastore-wide constraint > checking. The good news is that YANG handle do all this. > Maybe it's a better-than-nothing approach, but nothing is what we have now wrt/ standard configuration. For 20 years, vendors have been claiming they cannot agree on every detail of any sort of config. YANG has some formal clauses, bit no new optionality features that have not existed before, so I do not think 'if-feature' will be enough to facilitate standard data models. It is a total myth that there is any sort of procedural interoperability with NETCONF. When it comes to applying arbitrary explicit and implicit nc:operation attributes throughout the conceptual config tree -- especially for copy-config and commit, it is very implementation-dependent. What constitutes an edit? Is it just the data that changed? What about applying defaults? For 'explicit default' servers, a 'client-replacing-server-default' is an edit, but it is not an edit anywhere else. Do non-edits get saved to NV-storage? Does confirmed-commit still proceed for NO-OP edits? What about nested nc:operation attributes? Which combinations does the server allow? Does the server support alteration of every parameter for an existing list entry? >> I am not >> convinced that the forklift data-model (ala ipfix-psamp.yang) >> has much chance of widespread deployment. > > My hope is that I can define simple transformations between IETF > models and JUNOS models. I think it's unlikely that JUNOS will > adopt the DHCP module directly, but if we can generate data that > is ietf-dhcp.yang with junos augmentations. > An analogy from another industry is General MIDI. Even though a fancy keyboard has 1000 details to create an instrument, not everybody wants to spend 5 years studying the manual before they could just make the thing sound like a piano, organ, trombone, etc. So all the keyboards support a standard set of instruments, which can be used as-is, or edited like the 'from-scratch' instruments. It is understood that the Classical Piano from 2 different vendors may not sound exactly the same, and certainly will not be configured the same. So back to Junos -- in this analogy, you would support the general IETF RPC operations that do limited things, and these RPCs would map directly to your vendor data structure(s), for experts to use. Summary: ietf-start-dhcp(P1, P2, P3) [server implementation] ---> Junos 'dhcp' container; P1 --> Junos(P1), etc. Your expert customers will just use the complex vendor config data, but if they do not care about the details, they may use ietf-start-dhcp. IMO, the current IETF processes have produced no positive results, so maybe the all-or-nothing, giant data-model or bust approach is the reason why. > Thanks, > Phil > Andy From phil@juniper.net Tue Nov 3 18:34:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E942F28C13C for ; Tue, 3 Nov 2009 18:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFlH2lO1sXKc for ; Tue, 3 Nov 2009 18:34:02 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 26E3128C137 for ; Tue, 3 Nov 2009 18:34:01 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSvDoK0zBbs18y9t8i4nTqTGswbX3ahGo@postini.com; Tue, 03 Nov 2009 18:34:23 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 3 Nov 2009 18:31:16 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 18:31:16 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 18:31:16 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 18:31:16 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA42VFj08795; Tue, 3 Nov 2009 18:31:15 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA42I63g081016; Wed, 4 Nov 2009 02:18:06 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911040218.nA42I63g081016@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AF0AB5D.2060101@netconfcentral.com> Date: Tue, 3 Nov 2009 21:18:06 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Nov 2009 02:31:16.0203 (UTC) FILETIME=[E24F2BB0:01CA5CF6] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 02:34:03 -0000 Andy Bierman writes: > ietf-start-dhcp(P1, P2, P3) > > [server implementation] > ---> Junos 'dhcp' container; P1 --> Junos(P1), etc. > >Your expert customers will just use the complex vendor config data, >but if they do not care about the details, they may use ietf-start-dhcp. I'd rather see: v1 v2 v3 Then the incremental cost is adding a new parameter (vendor specific or not) is just adding the appropriate element under . v1 v2 v3 10g very 18-25 In the end, you'll build your content and make a call to your netconf library to say "add this chunk of xml to this device's configuration", and the library will hide all the netconf-layer stuff, like :candidate, :distinct-startup, :confirmed-commit, etc. So the upper-level call will be "add this config", which is close enough to your "command-oriented interface". Thanks, Phil From david.kessens@nsn.com Tue Nov 3 20:42:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FF728C1A4 for ; Tue, 3 Nov 2009 20:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ijb5x07CEjzE for ; Tue, 3 Nov 2009 20:42:27 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id A7FA228C13E for ; Tue, 3 Nov 2009 20:42:26 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA44gjgw003339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Nov 2009 05:42:45 +0100 Received: from localhost.localdomain ([10.138.50.140]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA44ghEk019427 for ; Wed, 4 Nov 2009 05:42:44 +0100 Received: from localhost.localdomain (david [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id nA44ghtg025450 for ; Tue, 3 Nov 2009 20:42:43 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id nA44ghHg025448 for netmod@ietf.org; Tue, 3 Nov 2009 20:42:43 -0800 Date: Tue, 3 Nov 2009 20:42:43 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20091104044242.GH16316@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] Draft agenda for netmod session in Hiroshima (v1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 04:42:28 -0000 Hi, Please see below for a first draft (v1) of the agenda for our session next week. As this is a draft, we still expect to make quite a few changes. Also, please let us know about other issues and topics that need discussion. Thanks and see you all in Hiroshima, David Kessens & David Partain --- Agenda: NETMOD WG Meeting: IETF 76 Location: ANA Crowne Plaza Hiroshima Hotel, Hiroshima, Japan WG Chairs: David Kessens (david.kessens@nsn.com) David Partain (david.partain@ericsson.com) Jabber: xmpp:netmod@jabber.ietf.org WG URL: http://tools.ietf.org/wg/netmod/ WebEx: will be available TUESDAY, November 10, 2009 0900-1130 Cattleya East 1) Administrivia [chairs][ 5 min ] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing 2) Status Update [chairs][ 5 min ] - How we're doing against the charter 3) Active Drafts For each draft: current status, delta from previous draft, open issues, and discussion. 3.1 NETMOD Architecture http://tools.ietf.org/html/draft-ietf-netmod-arch-02 3.2 Common YANG Data Types http://tools.ietf.org/html/draft-ietf-netmod-yang-types-04 3.3 YANG - A data modeling language for NETCONF http://tools.ietf.org/html/draft-ietf-netmod-yang-08 3.4 Mapping of YANG to DSDL http://tools.ietf.org/html/draft-ietf-netmod-dsdl-map-04 3.5 YANG Usage Guidelines http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02 4) Other (non WG) Internet-Drafts, for feedback and discussion [chairs, we will only spend time on these items if we have time] 4.1 draft-linowski-netmod-yang-abstract-00.txt (time allowing) Bernd Linowski/Mehmet Ersue 4.2 draft-schoenw-netmod-smi-yang-00 (time allowing) 5) I/O with other WGs (NETCONF/IPFIX/others ?), activities this week [chairs] 6) Plans post IETF76 WGLC for NETMOD Architecture? WGLC on YANG / YANG Data Types? 7) A.O.B. and open mike [N.N.] {please identify issues in advance} ---- From andy@netconfcentral.com Wed Nov 4 10:56:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E8C3A6914 for ; Wed, 4 Nov 2009 10:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_20=-0.74, J_CHICKENPOX_29=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bx7jTGdmOKZ for ; Wed, 4 Nov 2009 10:56:41 -0800 (PST) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 4BB833A6809 for ; Wed, 4 Nov 2009 10:56:41 -0800 (PST) Received: from [68.142.194.243] by n18.bullet.mail.mud.yahoo.com with NNFMP; 04 Nov 2009 18:57:01 -0000 Received: from [68.142.201.242] by t1.bullet.mud.yahoo.com with NNFMP; 04 Nov 2009 18:57:01 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 04 Nov 2009 18:57:01 -0000 X-Yahoo-Newman-Id: 620032.76492.bm@omp403.mail.mud.yahoo.com Received: (qmail 59743 invoked from network); 4 Nov 2009 18:57:01 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 04 Nov 2009 10:57:00 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: xRLlwsoVM1mmx4E4chuiXrnAqDeLECT7Lj5FG81DAl1Tt2u8bE9fK94l7B7riwDE0HD5RaHmcbHXAJ5jS6mAMv6OWxiGOIUl8TsrK_5ddywloyis4u4KNn3g.Ah0epR.l7fa9xJH4XyLxdBlf8r0nd.g8MHBjisaniCJGYFCKL3rMx4aw4kgBxLD2yUdAhYd_V9DYp.iQMvCLVLuem53lZTGqBrZDRnvpMF.uVL06OdcheSQb_mobe9toFfxZXQp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF1CEC4.9030909@netconfcentral.com> Date: Wed, 04 Nov 2009 10:58:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] nested insert operations (yang-08, 7.7.7 and 7.8.6) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:56:42 -0000 Hi, I am not sure the text in these sections wrt/ nested nc:operation attributes is very clear, or nested insert operations are explained at all. The higher level operation (closer to root) has precedence over the nested operation. There are lots of implementation details omitted, but essentially, a 'replace' operation takes affect the first descendant-or-self node that actually changed. So any insert operations nested within the 'replace' operation do not have any existing list or leaf-list, as explained in the draft: 7.7.7, para 6: In a , or an with a "replace" operation which covers the entire leaf-list, the leaf-list order is the same as the order of the XML elements in the request. An insert nested within a nc:operation=replace is really ignored, and should probably be flagged as an error. (The request PDU order is used instead.) ================================= 7.7.7, para 4: If no "insert" attribute is present in the "create" operation, it defaults to "last". Doesn't this default apply to 'merge' as well? Isn't the order required (key or value attributes) if the operation is 'replace'? Or is it just a NO-OP, and the server leaves the list or leaf-list in the same place? Andy From andy@netconfcentral.com Thu Nov 5 09:52:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E60D28C0D8 for ; Thu, 5 Nov 2009 09:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GddCR4p0dxbE for ; Thu, 5 Nov 2009 09:52:17 -0800 (PST) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id AF3F828C0EF for ; Thu, 5 Nov 2009 09:52:17 -0800 (PST) Received: from [68.142.200.225] by n14.bullet.mail.mud.yahoo.com with NNFMP; 05 Nov 2009 17:52:38 -0000 Received: from [68.142.201.249] by t6.bullet.mud.yahoo.com with NNFMP; 05 Nov 2009 17:52:38 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 05 Nov 2009 17:52:38 -0000 X-Yahoo-Newman-Id: 577291.82769.bm@omp410.mail.mud.yahoo.com Received: (qmail 57797 invoked from network); 5 Nov 2009 17:52:38 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 05 Nov 2009 09:52:38 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: IrJXN_oVM1kLCUN5j6WFR_tAHqFoULjf7lXzjUDko3ubcEP0Hc8pNiACX_zfDQxpI52gC47EPAgaPN_ZKbsDdw3mYkWO07qk9i6h7ncZOn.kl6hWK0BY6_kcfESZr9h7FlmoyFIEyATCGGMq7qJOVk9y9GA0r5nj8YypRXMnpkddxVS4UjDfSMGtWBp5hgaLMKeba_KvmQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF31133.6080207@netconfcentral.com> Date: Thu, 05 Nov 2009 09:53:55 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] with-defaults definition of 'explicit mode' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:52:18 -0000 Hi, I don't think this definition of explicit defaults matches what the NETMOD WG agreed to on the mailing list. o Explicitly set default data: Is default data that is set by a NETCONF client or other external management application/user by the way of an actual management operation to the value specified as its default in the data model schema. Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. Data, that is set to a value other then its default value, is not default data, so its handling is outside the scope of this document. IMO, this definition is too loose for the standard. The NETMOD WG agreed that explicitly set means: o Explicitly set data: - any value set by the client - any value (other than the schema default) set by the server The leaf definition needs to match the 'explicit' retrieval mode. The 'schema default' concepts are not exactly the same as the 'explicitly set' concepts. A system-created leaf is visible in all retrieval modes. It MUST NOT be filtered out of an 'explicit' retrieval. It would never be filtered by a 'trim' retrieval, because s-c-stmt and default-stmt are incompatible. There must not be any 'unclassified' data, Every server MUST implement the 'explicit' mode the same way. This goes for 'basic' behavior, not just the leaf. Andy From mbj@tail-f.com Thu Nov 5 12:43:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A1A28C0FF for ; Thu, 5 Nov 2009 12:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEy8RTYH+lsu for ; Thu, 5 Nov 2009 12:43:01 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 887C428C0F5 for ; Thu, 5 Nov 2009 12:43:01 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EB6F576C5B7; Thu, 5 Nov 2009 21:43:22 +0100 (CET) Date: Thu, 05 Nov 2009 21:43:22 +0100 (CET) Message-Id: <20091105.214322.199198682.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091023143024.GB10059@elstar.local> References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> <20091023143024.GB10059@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:43:02 -0000 Juergen Schoenwaelder wrote: > On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote: > > > Ok, so an alternative could be this: > > > > A "default" statement can be added to a leaf that does not have a > > default value (either directly or indirectly through its type). > > > > Do we agree that a default cannot be modified? > > Can someone remind me what the rationale is? Adding a default > statement causes an implementation that happens not to use the default > value to be non-compliant. We get the same effect if someone changes a > default value. When a client creates say a list entry, it may choose to not give values for leafs with defaults for the following reasons: 1. it doesn't care about the leaf; it trusts the server to use a good default value. 2. the default specified in the data model is the value it wants, so there is no need to send it. If we just want to support case 1, but not 2, then we can allow any changes to defaults. If we want to support 2, we have threea options: a. do not allow addition or change of default b. do not allow changes to default, but allow addition c. require revision on all modules and submodules, and also require import and include by revision. I think we have already discussed (c) and decided that it won't work. (a) is what is in -08, but is probably too restrictive, and (b) is the proposed text above. /martin From mbj@tail-f.com Thu Nov 5 13:07:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BD83A677E for ; Thu, 5 Nov 2009 13:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHN+gDmbZ1oM for ; Thu, 5 Nov 2009 13:07:17 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 37D933A682E for ; Thu, 5 Nov 2009 13:07:17 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C71D76C5B7; Thu, 5 Nov 2009 22:07:39 +0100 (CET) Date: Thu, 05 Nov 2009 22:07:39 +0100 (CET) Message-Id: <20091105.220739.136479979.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AF1CEC4.9030909@netconfcentral.com> References: <4AF1CEC4.9030909@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] nested insert operations (yang-08, 7.7.7 and 7.8.6) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:07:18 -0000 Hi, Andy Bierman wrote: > Hi, > > I am not sure the text in these sections wrt/ > nested nc:operation attributes is very clear, > or nested insert operations are explained at all. > > The higher level operation (closer to root) has precedence > over the nested operation. There are lots of implementation > details omitted, but essentially, a 'replace' operation > takes affect the first descendant-or-self node that actually changed. > So any insert operations nested within the 'replace' operation > do not have any existing list or leaf-list, as explained in > the draft: > > 7.7.7, para 6: > In a , or an with a "replace" operation > which covers the entire leaf-list, the leaf-list order is the same as > the order of the XML elements in the request. > > An insert nested within a nc:operation=replace is really ignored, > and should probably be flagged as an error. (The request PDU order > is used instead.) Actually, we can simplify the quoted text above a bit into: In a the leaf-list order is the same as the order of the XML elements in the request. and since elements are processed in order in an edit-config, if there are no insert attributes, each element will be placed at the end of the list, and we will end up with the same order as in the request. In this case, we don't need to reject insert within a create or replace; they will be processed in order as in any other case. > ================================= > > 7.7.7, para 4: > If no "insert" attribute is present in the "create" operation, it > defaults to "last". > > Doesn't this default apply to 'merge' as well? Yes, if the entry does not exists. Maybe change the quoted text to: If no "insert" attribute is present when the entry is created, it defaults to "last". > Isn't the order required (key or value attributes) > if the operation is 'replace'? Or is it just a NO-OP, > and the server leaves the list or leaf-list in the same place? It leaves it in the same place. This is not useful for a leaf-list, but it makes sense for a list entry. How about adding: If no "insert" attribute is present in a "replace" operation, the list entry does not change its position in the list. /martin From j.schoenwaelder@jacobs-university.de Thu Nov 5 13:08:36 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789C83A6AE5 for ; Thu, 5 Nov 2009 13:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh6RhGfwlkmm for ; Thu, 5 Nov 2009 13:08:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 387513A6AD2 for ; Thu, 5 Nov 2009 13:08:35 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2B04C003F; Thu, 5 Nov 2009 22:08:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NlMW4v8gPK7j; Thu, 5 Nov 2009 22:08:56 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E31FC0032; Thu, 5 Nov 2009 22:08:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3B422DA397D; Thu, 5 Nov 2009 22:08:55 +0100 (CET) Date: Thu, 5 Nov 2009 22:08:55 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091105210855.GA10642@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091105.214322.199198682.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:08:36 -0000 On Thu, Nov 05, 2009 at 09:43:22PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote: > > > > > Ok, so an alternative could be this: > > > > > > A "default" statement can be added to a leaf that does not have a > > > default value (either directly or indirectly through its type). > > > > > > Do we agree that a default cannot be modified? > > > > Can someone remind me what the rationale is? Adding a default > > statement causes an implementation that happens not to use the default > > value to be non-compliant. We get the same effect if someone changes a > > default value. > > When a client creates say a list entry, it may choose to not give > values for leafs with defaults for the following reasons: > > 1. it doesn't care about the leaf; it trusts the server to use a > good default value. > 2. the default specified in the data model is the value it wants, so > there is no need to send it. > > If we just want to support case 1, but not 2, then we can allow any > changes to defaults. If we want to support 2, we have threea options: > > a. do not allow addition or change of default > b. do not allow changes to default, but allow addition > c. require revision on all modules and submodules, and also require > import and include by revision. > > I think we have already discussed (c) and decided that it won't work. > (a) is what is in -08, but is probably too restrictive, and (b) is > the proposed text above. So the argument is that adding a default is OK since there was none before and fielded client applications thus can't rely on a specific value. But even then, if a new client is written for the module version that includes the default and it talks to an old server predating the module revision with the default, things might break. You will likely response that a client must be aware of the different versions of a data model. >From a practical perspective, I am concerned that we will see objects that have a default that turns out to be a bad choice after a few years and there is no way to fix this. And I also fear that we will have clients that won't track all changes of data model revisions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Nov 5 13:15:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC8E3A68F1 for ; Thu, 5 Nov 2009 13:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Rnm7FIobZmR for ; Thu, 5 Nov 2009 13:15:15 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2D7FC3A67DF for ; Thu, 5 Nov 2009 13:15:14 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AC77C76C5B7; Thu, 5 Nov 2009 22:15:36 +0100 (CET) Date: Thu, 05 Nov 2009 22:15:36 +0100 (CET) Message-Id: <20091105.221536.255430208.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091105210855.GA10642@elstar.local> References: <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> <20091105210855.GA10642@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:15:16 -0000 Juergen Schoenwaelder wrote: > On Thu, Nov 05, 2009 at 09:43:22PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote: > > > > > > > Ok, so an alternative could be this: > > > > > > > > A "default" statement can be added to a leaf that does not have a > > > > default value (either directly or indirectly through its type). > > > > > > > > Do we agree that a default cannot be modified? > > > > > > Can someone remind me what the rationale is? Adding a default > > > statement causes an implementation that happens not to use the default > > > value to be non-compliant. We get the same effect if someone changes a > > > default value. > > > > When a client creates say a list entry, it may choose to not give > > values for leafs with defaults for the following reasons: > > > > 1. it doesn't care about the leaf; it trusts the server to use a > > good default value. > > 2. the default specified in the data model is the value it wants, so > > there is no need to send it. > > > > If we just want to support case 1, but not 2, then we can allow any > > changes to defaults. If we want to support 2, we have threea options: > > > > a. do not allow addition or change of default > > b. do not allow changes to default, but allow addition > > c. require revision on all modules and submodules, and also require > > import and include by revision. > > > > I think we have already discussed (c) and decided that it won't work. > > (a) is what is in -08, but is probably too restrictive, and (b) is > > the proposed text above. > > So the argument is that adding a default is OK since there was none > before and fielded client applications thus can't rely on a specific > value. But even then, if a new client is written for the module > version that includes the default and it talks to an old server > predating the module revision with the default, things might break. > You will likely response that a client must be aware of the different > versions of a data model. This was never a use case we tried to handle. If the client only knows about the new data model, it might try to set leafs which don't even exist on the server (since you are allowed to add leafs and other nodes), (and more...) > From a practical perspective, I am concerned that we will see objects > that have a default that turns out to be a bad choice after a few > years and there is no way to fix this. To solve this, it seems we need to require revisions, and import/include by revision, but then... > And I also fear that we will > have clients that won't track all changes of data model revisions. ... clients that don't track revisions won't work well. So what is your suggestion? /martin From j.schoenwaelder@jacobs-university.de Thu Nov 5 14:18:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DFA3A68E9 for ; Thu, 5 Nov 2009 14:18:32 -0800 (PST) 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.345, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUKxQaMHjzqY for ; Thu, 5 Nov 2009 14:18:31 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9607A28C118 for ; Thu, 5 Nov 2009 14:18:31 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46F1CC003F; Thu, 5 Nov 2009 23:18:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hMnCWzs9FS3A; Thu, 5 Nov 2009 23:18:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43AEDC0016; Thu, 5 Nov 2009 23:18:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A144EDA3B45; Thu, 5 Nov 2009 23:18:52 +0100 (CET) Date: Thu, 5 Nov 2009 23:18:52 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091105221852.GA10764@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> <20091105210855.GA10642@elstar.local> <20091105.221536.255430208.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091105.221536.255430208.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 22:18:32 -0000 On Thu, Nov 05, 2009 at 10:15:36PM +0100, Martin Bjorklund wrote: > > > > So the argument is that adding a default is OK since there was none > > before and fielded client applications thus can't rely on a specific > > value. But even then, if a new client is written for the module > > version that includes the default and it talks to an old server > > predating the module revision with the default, things might break. > > You will likely response that a client must be aware of the different > > versions of a data model. > > This was never a use case we tried to handle. If the client only > knows about the new data model, it might try to set leafs which don't > even exist on the server (since you are allowed to add leafs and other > nodes), (and more...) OK, I admit to be undecided. But then, an attempt to create a leaf that is not supported results in an error. Assuming a default that is not known by the server causes surprises, and surprises are bad. > > From a practical perspective, I am concerned that we will see objects > > that have a default that turns out to be a bad choice after a few > > years and there is no way to fix this. > > To solve this, it seems we need to require revisions, and > import/include by revision, but then... > > > And I also fear that we will > > have clients that won't track all changes of data model revisions. > > ... clients that don't track revisions won't work well. > > So what is your suggestion? I have no good answer. Perhaps all we can do are explicit warnings that relying on defaults that get added after the publication of an initial revision of a YANG module requires to do proper version checking and if an application is not able to do that, to not rely on the default being present. And perhaps guidelines^Hwarnings to data model designer as well that defaults are final, you won't be able to change them ever since applications are allowed to rely on it. The only alternative would be to go back to the SMIv2 semantics where defaults are not binding - which means you better set them expicitely unless you trust the device to pick something reasonable (means I do not care what is picked). /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 Fri Nov 6 08:14:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2C33A67EB for ; Fri, 6 Nov 2009 08:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPU1kNFl7oq1 for ; Fri, 6 Nov 2009 08:14:37 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 053203A67A7 for ; Fri, 6 Nov 2009 08:14:37 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A6D5C000F; Fri, 6 Nov 2009 17:15:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NY3YL3pFsBYq; Fri, 6 Nov 2009 17:14:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CF66C0004; Fri, 6 Nov 2009 17:14:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0C6CCDA53E2; Fri, 6 Nov 2009 17:14:57 +0100 (CET) Date: Fri, 6 Nov 2009 17:14:56 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20091106161456.GA13153@elstar.local> Mail-Followup-To: David Spakes , "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.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal (fwd) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:14:38 -0000 On Mon, Oct 26, 2009 at 03:27:34PM +0100, David Spakes wrote: > Between March 11 and June 9, there was a lengthy discussion on this > list that resulted in a proposal to add a derived type called 'real' > to draft-ietf-netmod-yang-types-04. The proposal was submitted in > its final form (below) before WGLC for draft-ietf-netmod-yang-types-03 > ended on June 10. > > The draft-ietf-netmod-yang-types-04 document is out now and I see that the > new derived type was not included. Juergen's alternative proposal to make > decimal64's fraction-digits substatement be optional (15-May) is not > reflected in draft-ietf-netmod-yang-08 either. > > Was this omission done intentionally, and if so, why? Thanks for bringing this up again. Reviewing the mailing list discussion thread "float vs. decimal", it is difficult for me to determine a concensus position. What I saw were opinions to a) add the proposed 'real' typedef b) make fraction-digits optional, more closely following the XSD approach c) leave things as they are (not clear the 'real' is needed urgently enough to add it now) d) remove a bunch of other builtin types from YANG and make them typedefs instead So the omission was done intentionally to the extend that I as the editor do not understand the edits the WG agrees to (but the truth is that this issue slipped through). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Fri Nov 6 08:26:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304C23A68AF for ; Fri, 6 Nov 2009 08:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7Z9aliuAAQd for ; Fri, 6 Nov 2009 08:26:23 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 09FFF3A682D for ; Fri, 6 Nov 2009 08:26:23 -0800 (PST) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id E6973D800D1; Fri, 6 Nov 2009 17:26:45 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091105221852.GA10764@elstar.local> References: <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> <20091105210855.GA10642@elstar.local> <20091105.221536.255430208.mbj@tail-f.com> <20091105221852.GA10764@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 06 Nov 2009 17:26:45 +0100 Message-Id: <1257524805.3963.0.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:26:24 -0000 Juergen Schoenwaelder píše v ÄŒt 05. 11. 2009 v 23:18 +0100: > On Thu, Nov 05, 2009 at 10:15:36PM +0100, Martin Bjorklund wrote: > > > > > > So the argument is that adding a default is OK since there was none > > > before and fielded client applications thus can't rely on a specific > > > value. But even then, if a new client is written for the module > > > version that includes the default and it talks to an old server > > > predating the module revision with the default, things might break. > > > You will likely response that a client must be aware of the different > > > versions of a data model. > > > > This was never a use case we tried to handle. If the client only > > knows about the new data model, it might try to set leafs which don't > > even exist on the server (since you are allowed to add leafs and other > > nodes), (and more...) > > OK, I admit to be undecided. But then, an attempt to create a leaf > that is not supported results in an error. Assuming a default that is > not known by the server causes surprises, and surprises are bad. > But the fact that there was no default in the old version can mean three things: 1. The leaf was mandatory in the old version, so an error will be reported if the client doesn't set the value. 2. The value is not used at all by the old server version, so it doesn't matter what the client does to it. 3. The value is system-created by the old server version. Only this case can lead to an undetected mismatch between the server and client. IMO the only scenario for a reliable module evolution is 1. The questions that have to be asked when the data model is being designed are (i) whether the given parameter is operational or configuration, and (ii) whether it is needed for server operation or not. If the answer to either of these questions changes, it is not the same data model anymore. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Nov 6 08:43:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C955F3A6968 for ; Fri, 6 Nov 2009 08:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1xDNuCl6JS4 for ; Fri, 6 Nov 2009 08:43:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 85BF43A691F for ; Fri, 6 Nov 2009 08:43:09 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E689DC000F; Fri, 6 Nov 2009 17:43:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ugjIcWvi+p5U; Fri, 6 Nov 2009 17:43:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF1F1C0004; Fri, 6 Nov 2009 17:43:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 75B8EDA55C1; Fri, 6 Nov 2009 17:43:31 +0100 (CET) Date: Fri, 6 Nov 2009 17:43:31 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091106164331.GA13386@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> <20091105210855.GA10642@elstar.local> <20091105.221536.255430208.mbj@tail-f.com> <20091105221852.GA10764@elstar.local> <1257524805.3963.0.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1257524805.3963.0.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:43:10 -0000 On Fri, Nov 06, 2009 at 05:26:45PM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v ??t 05. 11. 2009 v 23:18 +0100: > > On Thu, Nov 05, 2009 at 10:15:36PM +0100, Martin Bjorklund wrote: > > > > > > > > So the argument is that adding a default is OK since there was none > > > > before and fielded client applications thus can't rely on a specific > > > > value. But even then, if a new client is written for the module > > > > version that includes the default and it talks to an old server > > > > predating the module revision with the default, things might break. > > > > You will likely response that a client must be aware of the different > > > > versions of a data model. > > > > > > This was never a use case we tried to handle. If the client only > > > knows about the new data model, it might try to set leafs which don't > > > even exist on the server (since you are allowed to add leafs and other > > > nodes), (and more...) > > > > OK, I admit to be undecided. But then, an attempt to create a leaf > > that is not supported results in an error. Assuming a default that is > > not known by the server causes surprises, and surprises are bad. > > > > But the fact that there was no default in the old version can mean three > things: > > 1. The leaf was mandatory in the old version, so an error will be > reported if the client doesn't set the value. > > 2. The value is not used at all by the old server version, so it doesn't > matter what the client does to it. > > 3. The value is system-created by the old server version. Only this case > can lead to an undetected mismatch between the server and client. > > IMO the only scenario for a reliable module evolution is 1. The > questions that have to be asked when the data model is being designed > are (i) whether the given parameter is operational or configuration, and > (ii) whether it is needed for server operation or not. If the answer to > either of these questions changes, it is not the same data model > anymore. But we are not discussing config true/false here - I think I do not understand your answer. A default on config false has little value, except for those who like to filter default values from config false objects, which is not my concern. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Fri Nov 6 09:05:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F97B28C0ED for ; Fri, 6 Nov 2009 09:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VglGwT7rAsAr for ; Fri, 6 Nov 2009 09:05:31 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6DB643A68FA for ; Fri, 6 Nov 2009 09:05:31 -0800 (PST) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 96120D800D1; Fri, 6 Nov 2009 18:05:54 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091106164331.GA13386@elstar.local> References: <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> <20091105210855.GA10642@elstar.local> <20091105.221536.255430208.mbj@tail-f.com> <20091105221852.GA10764@elstar.local> <1257524805.3963.0.camel@missotis> <20091106164331.GA13386@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 06 Nov 2009 18:05:53 +0100 Message-Id: <1257527153.3963.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:05:32 -0000 Juergen Schoenwaelder píše v Pá 06. 11. 2009 v 17:43 +0100: > On Fri, Nov 06, 2009 at 05:26:45PM +0100, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v ??t 05. 11. 2009 v 23:18 +0100: > > > On Thu, Nov 05, 2009 at 10:15:36PM +0100, Martin Bjorklund wrote: > > > > > > > > > > So the argument is that adding a default is OK since there was none > > > > > before and fielded client applications thus can't rely on a specific > > > > > value. But even then, if a new client is written for the module > > > > > version that includes the default and it talks to an old server > > > > > predating the module revision with the default, things might break. > > > > > You will likely response that a client must be aware of the different > > > > > versions of a data model. > > > > > > > > This was never a use case we tried to handle. If the client only > > > > knows about the new data model, it might try to set leafs which don't > > > > even exist on the server (since you are allowed to add leafs and other > > > > nodes), (and more...) > > > > > > OK, I admit to be undecided. But then, an attempt to create a leaf > > > that is not supported results in an error. Assuming a default that is > > > not known by the server causes surprises, and surprises are bad. > > > > > > > But the fact that there was no default in the old version can mean three > > things: > > > > 1. The leaf was mandatory in the old version, so an error will be > > reported if the client doesn't set the value. > > > > 2. The value is not used at all by the old server version, so it doesn't > > matter what the client does to it. > > > > 3. The value is system-created by the old server version. Only this case > > can lead to an undetected mismatch between the server and client. > > > > IMO the only scenario for a reliable module evolution is 1. The > > questions that have to be asked when the data model is being designed > > are (i) whether the given parameter is operational or configuration, and > > (ii) whether it is needed for server operation or not. If the answer to > > either of these questions changes, it is not the same data model > > anymore. > > But we are not discussing config true/false here - I think I do not > understand your answer. A default on config false has little value, > except for those who like to filter default values from config false > objects, which is not my concern. I am just trying to understand what the acceptable (and likely) paths are for module evolution, perhaps without the need for giving an exact revision number. The change of a leaf definition from mandatory=true to (mandatory=false & new default definition) seems a natural way for establishing a data model default based on operational experience, and it shouldn't cause any serious interoperability problems. The change of the existing default value is a different story though. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Nov 6 09:14:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009623A67D4 for ; Fri, 6 Nov 2009 09:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nZtzqeD4zdP for ; Fri, 6 Nov 2009 09:14:37 -0800 (PST) Received: from n12a.bullet.mail.mud.yahoo.com (n12a.bullet.mail.mud.yahoo.com [209.191.125.177]) by core3.amsl.com (Postfix) with SMTP id F2F593A68E4 for ; Fri, 6 Nov 2009 09:14:18 -0800 (PST) Received: from [68.142.194.244] by n12.bullet.mail.mud.yahoo.com with NNFMP; 06 Nov 2009 17:14:41 -0000 Received: from [68.142.201.249] by t2.bullet.mud.yahoo.com with NNFMP; 06 Nov 2009 17:14:41 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 06 Nov 2009 17:14:41 -0000 X-Yahoo-Newman-Id: 60639.40539.bm@omp410.mail.mud.yahoo.com Received: (qmail 94056 invoked from network); 6 Nov 2009 17:14:40 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 06 Nov 2009 09:14:40 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: dDNrWsQVM1mhbspYrRINteRsaBdrAxGit0LsQaKU.5W8KGnSl5Rd7yqSyVdWinhxaWQ2NFyH0ioLoVHrJbkICxtFt9h7LuKVHff5LDMoE24nJ4LRWaleNwbQNWqvBdfCsNAdvUMB0hkouLKjCSDvmTsd0exah2W.0N96XRF.E4tEcJ4vUd6FWmJx5P5vNr5CLXu3HBz2na9YxkJxFVg.Lh4jRGJeB170yLxHkixBg5Y2KwYYDsAMVGfp6CR4cKKU X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF459D3.5090208@netconfcentral.com> Date: Fri, 06 Nov 2009 09:16:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> <20091105210855.GA10642@elstar.local> <20091105.221536.255430208.mbj@tail-f.com> <20091105221852.GA10764@elstar.local> <1257524805.3963.0.camel@missotis> In-Reply-To: <1257524805.3963.0.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:14:39 -0000 Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v ÄŒt 05. 11. 2009 v 23:18 +0100: >> On Thu, Nov 05, 2009 at 10:15:36PM +0100, Martin Bjorklund wrote: >>>> So the argument is that adding a default is OK since there was none >>>> before and fielded client applications thus can't rely on a specific >>>> value. But even then, if a new client is written for the module >>>> version that includes the default and it talks to an old server >>>> predating the module revision with the default, things might break. >>>> You will likely response that a client must be aware of the different >>>> versions of a data model. >>> This was never a use case we tried to handle. If the client only >>> knows about the new data model, it might try to set leafs which don't >>> even exist on the server (since you are allowed to add leafs and other >>> nodes), (and more...) >> OK, I admit to be undecided. But then, an attempt to create a leaf >> that is not supported results in an error. Assuming a default that is >> not known by the server causes surprises, and surprises are bad. >> > > But the fact that there was no default in the old version can mean three > things: > > 1. The leaf was mandatory in the old version, so an error will be > reported if the client doesn't set the value. > > 2. The value is not used at all by the old server version, so it doesn't > matter what the client does to it. > > 3. The value is system-created by the old server version. Only this case > can lead to an undetected mismatch between the server and client. > > IMO the only scenario for a reliable module evolution is 1. The > questions that have to be asked when the data model is being designed > are (i) whether the given parameter is operational or configuration, and > (ii) whether it is needed for server operation or not. If the answer to > either of these questions changes, it is not the same data model > anymore. > The server most likely knows 1 revision of the module. It will enforce the rules in that module. If the leaf is mandatory in the supported version, that is all that matters. SMIv2-like CLRs to preserve backward compatibility don't work very well in YANG. IMO, a better implementation strategy for the client is to construct the server's view of the schema tree from the and avoid any heuristics based on the CLRs in Sec. 10. If the client supports deviations, then the change-control rules are totally irrelevant, since deviations don't follow any rules. (It would help if revisions were mandatory to use. The CLRs do not help at all for revision-less modules. Nothing does.) I prefer new option (d): c. require revision on all modules and submodules, and also require import and include by revision. d. require revision on all modules and submodules, and think about import-by-revision very carefully. The WG should understand how it will function within the IETF wrt/ all processes. After there are specific recommendations for module reuse practices, then rules for import-by-revision may be appropriate. > Lada > Andy From spakes@snmp.com Fri Nov 6 09:19:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B433A6851 for ; Fri, 6 Nov 2009 09:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bMPlX4TaBLa for ; Fri, 6 Nov 2009 09:19:02 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id E87EA3A68E4 for ; Fri, 6 Nov 2009 09:19:01 -0800 (PST) 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 MAA03137; Fri, 6 Nov 2009 12:19:24 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA19615; Fri, 6 Nov 2009 12:19:24 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 6 Nov 2009 12:19:24 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20091106161456.GA13153@elstar.local> Message-ID: References: <20091106161456.GA13153@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal (fwd) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: netmod@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:19:03 -0000 Don't forget that decimal64 wasn't the original proposal...! In February/March of this year, a big part of my day was spent implementing the float32 and float64 types that were described in an earlier draft. We had that code working reasonably well when decimal64 came along, and afterwards a lot had to be jettisoned. :-) Back then, there seemed to be several voices on the mailing list expressing concern that by moving from float32/float64 to decimal64, YANG was losing the ability to express infinitely large and infinitely small numbers. I was not one of those voices. My concern about decimal64 then and now is that the document writer must specify a fixed decimal position when defining a leaf. So from my viewpoint, there was never a complete concensus on the proposal for having the decimal64 built-in type in YANG in the first place. Both 'a' and 'b' were proposed as compromise positions to allow the working group to come to concensus on the acceptance of decimal64. Some members of the list objected to 'b' because it was important to their concerns to keep the fraction-ditits statement as a required substatment. The value of the compromise proposal 'a' is that the decimal64 type remains defined exactly as it is today. The 'real' typedef is a union of many forms of decimal64, and that is something any document writer can do today without the typedef. My argument for adding the typedef is that it encourages all document writers who need a floating decimal point to define the leaf in exactly the same way. There were no substantial arguments against the 'real' typedef that I can recall. I took the absence of meaningful counterargument against the 'real' typedef as a vote for compromise and concensus. I expected to find the new typedef in draft-ietf-netmod-yang-08 and was surprised when it wasn't there. -dss On Fri, 6 Nov 2009, Juergen Schoenwaelder wrote: > On Mon, Oct 26, 2009 at 03:27:34PM +0100, David Spakes wrote: > > > Between March 11 and June 9, there was a lengthy discussion on this > > list that resulted in a proposal to add a derived type called 'real' > > to draft-ietf-netmod-yang-types-04. The proposal was submitted in > > its final form (below) before WGLC for draft-ietf-netmod-yang-types-03 > > ended on June 10. > > > > The draft-ietf-netmod-yang-types-04 document is out now and I see that the > > new derived type was not included. Juergen's alternative proposal to make > > decimal64's fraction-digits substatement be optional (15-May) is not > > reflected in draft-ietf-netmod-yang-08 either. > > > > Was this omission done intentionally, and if so, why? > > Thanks for bringing this up again. Reviewing the mailing list > discussion thread "float vs. decimal", it is difficult for me to > determine a concensus position. What I saw were opinions to > > a) add the proposed 'real' typedef > b) make fraction-digits optional, more closely following the XSD approach > c) leave things as they are (not clear the 'real' is needed urgently > enough to add it now) > d) remove a bunch of other builtin types from YANG and make them typedefs > instead > > So the omission was done intentionally to the extend that I as the > editor do not understand the edits the WG agrees to (but the truth is > that this issue slipped through). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From andy@netconfcentral.com Fri Nov 6 09:38:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2873A6806 for ; Fri, 6 Nov 2009 09:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxI0Pm5P+tKH for ; Fri, 6 Nov 2009 09:38:36 -0800 (PST) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id 311E23A67EA for ; Fri, 6 Nov 2009 09:38:36 -0800 (PST) Received: (qmail 85876 invoked from network); 6 Nov 2009 17:38:57 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 06 Nov 2009 09:38:56 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: yXDbo4UVM1kbKcdmabW7Y53OeiO5Gu9iiXJoHb.uZ4yRGbn5n_skQRMd5QSr3p0gjPckC1HblzlDaKesRDSt.6bhOR13ANYPBHrkdMlBTpxBS4SAoeoXIHQcNzgnAP9vIzxqKwEP6OIUu9ghBhzMi8qLNH7q4TiT8HMbPq.iRO3sRRHH_8GKi_vXOzgX8SY7yc3m_ofeiTNBtx7C4JrjnSU5yGM6m2xpOMu2uVUPxjtxcDqzjYa5oUSfeH69EZErsU0wtz8d5IswzxD9XeRZF6FtqjUsPpzlEZhkwu2GrqzKbg7w3YvBnAnqmluT7imRq1bNrsrevRhv3eNmZVoiQYyYz1ooQm4VPPeldUmjm8dkIXDC6q3swKAV2gowbHsv28XY9WH_bhW6sX3hnI7VJ.pRqscq33KSvQQwNS8Y X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF45F83.5050100@netconfcentral.com> Date: Fri, 06 Nov 2009 09:40:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: netmod@ietf.org References: <20091106161456.GA13153@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal (fwd) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:38:37 -0000 David Spakes wrote: > Don't forget that decimal64 wasn't the original proposal...! > In February/March of this year, a big part of my day was spent > implementing the float32 and float64 types that were described in an > earlier draft. We had that code working reasonably well when decimal64 > came along, and afterwards a lot had to be jettisoned. :-) > > Back then, there seemed to be several voices on the mailing list > expressing concern that by moving from float32/float64 to decimal64, YANG > was losing the ability to express infinitely large and infinitely small > numbers. I was not one of those voices. My concern about decimal64 then > and now is that the document writer must specify a fixed decimal position > when defining a leaf. > > So from my viewpoint, there was never a complete concensus on the proposal > for having the decimal64 built-in type in YANG in the first place. > > Both 'a' and 'b' were proposed as compromise positions to allow the > working group to come to concensus on the acceptance of decimal64. Some > members of the list objected to 'b' because it was important to their > concerns to keep the fraction-ditits statement as a required substatment. > > The value of the compromise proposal 'a' is that the decimal64 type > remains defined exactly as it is today. The 'real' typedef is a union of > many forms of decimal64, and that is something any document writer can do > today without the typedef. My argument for adding the typedef is that it > encourages all document writers who need a floating decimal point to > define the leaf in exactly the same way. > > There were no substantial arguments against the 'real' typedef that I can > recall. I took the absence of meaningful counterargument against the > 'real' typedef as a vote for compromise and concensus. I expected to find > the new typedef in draft-ietf-netmod-yang-08 and was surprised when it > wasn't there. > It should not be surprising. Only changes that have WG consensus get added, especially after a WGLC has been done for the draft. Derived types are all the same to the client and server code. This is a higher-level data-modeling decision -- whether or not the 'real' typedef is something that WGs should reuse, or must build-their-own from decimal64. Data modeling decisions like typedefs are very subjective. I don't object to 'real' being added to yang-types, but it doesn't seem very important. The 'real' data type has not been needed in SMIv2, so why is it needed in YANG? We determined that decimal64 was more appropriate, based on use cases. I don't see why we need to emulate a 'real' data type in YANG. > -dss Andy From j.schoenwaelder@jacobs-university.de Fri Nov 6 11:05:26 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E131E3A683A for ; Fri, 6 Nov 2009 11:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEIN3v3aJUmK for ; Fri, 6 Nov 2009 11:05:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9AF903A6832 for ; Fri, 6 Nov 2009 11:05:25 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A0FCC0018; Fri, 6 Nov 2009 20:05:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BsFNqQraLd8O; Fri, 6 Nov 2009 20:05:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 231AAC0004; Fri, 6 Nov 2009 20:05:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D595BDA57D0; Fri, 6 Nov 2009 20:05:47 +0100 (CET) Date: Fri, 6 Nov 2009 20:05:47 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091106190547.GA13547@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> <20091105210855.GA10642@elstar.local> <20091105.221536.255430208.mbj@tail-f.com> <20091105221852.GA10764@elstar.local> <1257524805.3963.0.camel@missotis> <20091106164331.GA13386@elstar.local> <1257527153.3963.13.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1257527153.3963.13.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:05:27 -0000 On Fri, Nov 06, 2009 at 06:05:53PM +0100, Ladislav Lhotka wrote: > I am just trying to understand what the acceptable (and likely) paths > are for module evolution, perhaps without the need for giving an exact > revision number. > > The change of a leaf definition from mandatory=true to (mandatory=false > & new default definition) seems a natural way for establishing a data > model default based on operational experience, and it shouldn't cause > any serious interoperability problems. The change of the existing > default value is a different story though. There will be defaults created with the best intentions that will be wrong when the underlying protocol evolves. There will be must expressions created with the best intentions that will wrong when the underlying technology evolves. This is all fine and the answer to such situations is to obsolete definitions and to create new ones. The original question was why adding a default is OK while changing a default is not. Martin took the position that changing a default might break a contract between a client and a server. In the case where you add a default, you can't break a contract since there was no defined default. This is a reasonable position. Andy argues that clients have to know the exact version of the data model used by a given server (and its deviations) in order to do the right thing. And yes, this is also a defendable position - but it means that clients have to be pretty smart and be able to deal with many different revisions (even in a single vendor product line). This sets the bar of relying on defaults from the client side pretty high. So if my client happens to care of the value (means it needs a certain value - not that it is fine with whatever default value the server will pick), it better sets the value even if the data model promises the same default value in its data model. In other words, I would very likely not take any advantage of the knowledge of a default value on a client side since doing it correctly is way more effort that is the saving's gain. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Fri Nov 6 12:07:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A943A68A4 for ; Fri, 6 Nov 2009 12:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty53hzcmx8zN for ; Fri, 6 Nov 2009 12:07:55 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 348CD3A69EF for ; Fri, 6 Nov 2009 12:07:55 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSvSCLl37Kr+oDThiYB2NogL/XSkBy9nL@postini.com; Fri, 06 Nov 2009 12:08:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 6 Nov 2009 12:04:57 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 12:04:57 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 12:04:56 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 12:04:56 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA6K4tj70573; Fri, 6 Nov 2009 12:04:55 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nA6JpfxX068296; Fri, 6 Nov 2009 19:51:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911061951.nA6JpfxX068296@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091106190547.GA13547@elstar.local> Date: Fri, 6 Nov 2009 14:51:41 -0500 From: Phil Shafer X-OriginalArrivalTime: 06 Nov 2009 20:04:56.0140 (UTC) FILETIME=[692780C0:01CA5F1C] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 20:07:56 -0000 Juergen Schoenwaelder writes: >Martin took the position that changing a default might break a >contract between a client and a server. In the case where you add a >default, you can't break a contract since there was no defined >default. This is a reasonable position. > >Andy argues that clients have to know the exact version of the data >model used by a given server (and its deviations) in order to do the >right thing. And yes, this is also a defendable position - but it >means that clients have to be pretty smart and be able to deal with >many different revisions (even in a single vendor product line). This >sets the bar of relying on defaults from the client side pretty >high. So if my client happens to care of the value (means it needs a >certain value - not that it is fine with whatever default value the >server will pick), it better sets the value even if the data model >promises the same default value in its data model. In other words, I >would very likely not take any advantage of the knowledge of a default >value on a client side since doing it correctly is way more effort >that is the saving's gain. Both are reasonable goals. Is there a conflict? If the previous revision had no default, then the old client will always send a value if it needs/wants to. The default can move from unknown to known, but not from known to known. The primary issue with the "just make a new knob" is if the knob is mandatory or referenced by must or when expressions, then it must be set, even if ignored. Perhaps what is really needed is two levels of revisions, the compatible ones and the incompatible ones. If you change the default, the new revision is not compatible with the old one, and clients (and users) should be warned. Thanks, Phil From andy@netconfcentral.com Fri Nov 6 13:00:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E253A6823 for ; Fri, 6 Nov 2009 13:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QikWOqnWyelj for ; Fri, 6 Nov 2009 13:00:37 -0800 (PST) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 161D73A67E5 for ; Fri, 6 Nov 2009 13:00:37 -0800 (PST) Received: (qmail 84141 invoked from network); 6 Nov 2009 21:00:58 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 06 Nov 2009 13:00:58 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .owMjD4VM1l.oiyHResqWMcP.JoO03N3w0_b7.5K5azs.oRJelViWbEz1acJoXmO4jwzQG0Q.v5SvEHmKGGaPdfVyBCwjK55NFCfQKorcrjQMjNqHrNYm.0TJ6YgTLzWk6DWsl_nkrq0.II_0ktXXNBgnJvluNdXFlrVIKKFcmXmA_txGVAiYrnAc1iEoCIVp71DzLUbiUY6Pq0ZieOGxxoA4UKuMvOZYerMfVAEzrcORbq9EGI9XZfrtBlXGZRx X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF48EDD.6030703@netconfcentral.com> Date: Fri, 06 Nov 2009 13:02:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <20091023143024.GB10059@elstar.local> <20091105.214322.199198682.mbj@tail-f.com> <20091105210855.GA10642@elstar.local> <20091105.221536.255430208.mbj@tail-f.com> <20091105221852.GA10764@elstar.local> <1257524805.3963.0.camel@missotis> <20091106164331.GA13386@elstar.local> <1257527153.3963.13.camel@missotis> <20091106190547.GA13547@elstar.local> In-Reply-To: <20091106190547.GA13547@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 21:00:38 -0000 Juergen Schoenwaelder wrote: > On Fri, Nov 06, 2009 at 06:05:53PM +0100, Ladislav Lhotka wrote: > >> I am just trying to understand what the acceptable (and likely) paths >> are for module evolution, perhaps without the need for giving an exact >> revision number. >> >> The change of a leaf definition from mandatory=true to (mandatory=false >> & new default definition) seems a natural way for establishing a data >> model default based on operational experience, and it shouldn't cause >> any serious interoperability problems. The change of the existing >> default value is a different story though. > > There will be defaults created with the best intentions that will be > wrong when the underlying protocol evolves. There will be must > expressions created with the best intentions that will wrong when the > underlying technology evolves. This is all fine and the answer to such > situations is to obsolete definitions and to create new ones. > > The original question was why adding a default is OK while changing a > default is not. > > Martin took the position that changing a default might break a > contract between a client and a server. In the case where you add a > default, you can't break a contract since there was no defined > default. This is a reasonable position. > > Andy argues that clients have to know the exact version of the data > model used by a given server (and its deviations) in order to do the > right thing. And yes, this is also a defendable position - but it > means that clients have to be pretty smart and be able to deal with > many different revisions (even in a single vendor product line). This > sets the bar of relying on defaults from the client side pretty > high. So if my client happens to care of the value (means it needs a > certain value - not that it is fine with whatever default value the > server will pick), it better sets the value even if the data model > promises the same default value in its data model. In other words, I > would very likely not take any advantage of the knowledge of a default > value on a client side since doing it correctly is way more effort > that is the saving's gain. > I don't really care about this CLR, except... What about defaults in shared typedefs? It seems like these can never be added, because it will set the default for any leaf already using that typedef (if the leaf does not yet have one.) So even if the leaf is 'protected' by import-by-revision, a default cannot be added to the leaf without cut-and-pasting the 'old' typedef contents into the leaf, replacing the typedef usage. I want to discourage cut-and-paste reuse. The client will get confused if the shared typedef adds a default, and the client ignores the revisions advertised by the server. The client will get confused if the shared typedef adds a default, and the client ignores the import-revision-dates in the modules advertised by the server. Is there a CLR that says a default can never be added to a typedef? I don't think so. If not, then the CLR for the leaf-stmt seems pointless. > /js > Andy From mbj@tail-f.com Sat Nov 7 05:02:33 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1EF3A67AC for ; Sat, 7 Nov 2009 05:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vatanN5HQyLY for ; Sat, 7 Nov 2009 05:02:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B7C6F3A6778 for ; Sat, 7 Nov 2009 05:02:32 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 20A5C76C5B7; Sat, 7 Nov 2009 14:02:56 +0100 (CET) Date: Sat, 07 Nov 2009 14:02:55 +0100 (CET) Message-Id: <20091107.140255.70566824.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AF48EDD.6030703@netconfcentral.com> References: <1257527153.3963.13.camel@missotis> <20091106190547.GA13547@elstar.local> <4AF48EDD.6030703@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 13:02:33 -0000 Andy Bierman wrote: > What about defaults in shared typedefs? > It seems like these can never be added, Correct. This has never been allowed in the draft. > Is there a CLR that says a default can never be > added to a typedef? I don't think so. The section "Updating a Module" lists all allowed changes. Adding default to typedef is not listed. /martin From mbj@tail-f.com Mon Nov 9 01:06:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576333A6842; Mon, 9 Nov 2009 01:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihs+wptUqgA3; Mon, 9 Nov 2009 01:06:53 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 89C6A3A659B; Mon, 9 Nov 2009 01:06:53 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 46B8C616001; Mon, 9 Nov 2009 10:07:19 +0100 (CET) Date: Mon, 09 Nov 2009 10:07:16 +0100 (CET) Message-Id: <20091109.100716.96917148.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AF31133.6080207@netconfcentral.com> References: <4AF31133.6080207@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] with-defaults definition of 'explicit mode' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:06:54 -0000 Andy Bierman wrote: > Hi, > > I don't think this definition of explicit defaults matches what > the NETMOD WG agreed to on the mailing list. > > o Explicitly set default data: Is default data that is set by a > NETCONF client or other external management application/user by > the way of an actual management operation to the value specified > as its default in the data model schema. Some servers MAY treat > explicitly set default data as simple default data, as they may > not be able to differentiate between them. > Data, that is set to a value other then its default value, is not > default data, so its handling is outside the scope of this > document. > > IMO, this definition is too loose for the standard. > The NETMOD WG agreed that explicitly set means: > o Explicitly set data: > - any value set by the client > - any value (other than the schema default) set by the server I think the definition is ok - note that it defines the term "explicitly set default data", not "explicitly set data". However, I do not understand: Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. What is "simple default data"? Can this sentence be removed? Also, the last sentence ("Data, that is set ..." does not belong in the definition of the term "explicitly set default data"). /martin From david.kessens@nsn.com Mon Nov 9 01:30:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C63328C1F0 for ; Mon, 9 Nov 2009 01:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lZH1crUHEeX for ; Mon, 9 Nov 2009 01:30:16 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1769F3A6783 for ; Mon, 9 Nov 2009 01:30:15 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA99UcwQ007778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Nov 2009 10:30:38 +0100 Received: from localhost.localdomain ([10.138.51.24]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA99UaRa017891 for ; Mon, 9 Nov 2009 10:30:37 +0100 Received: from localhost.localdomain (david [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id nA99UZ7k008820 for ; Mon, 9 Nov 2009 01:30:35 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id nA99UE6r008819 for netmod@ietf.org; Mon, 9 Nov 2009 01:30:14 -0800 Date: Mon, 9 Nov 2009 01:30:14 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20091109093013.GH8503@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] Agenda for netmod session in Hiroshima X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:30:17 -0000 Please see below for the agenda for our session. Unfortunately, many of our speakers are not at the IETF meeting this time. However, we do have WebEx available to allow them to participate. We have reshuffled the agenda somewhat to accomodate remote speakers. We will send a seperate announcement to the list on how to join the meeting using WebEx. As the WebEx service as provided during the IETF is somewhat experimental, we would not be surprised if we hit some technical glitches. We will do our best to workaround these issues as much as possible and as a result, we might decide to change the order of agenda items. David Kessens & David Partain --- Agenda: NETMOD WG Meeting: IETF 76 Location: ANA Crowne Plaza Hiroshima Hotel, Hiroshima, Japan WG Chairs: David Kessens (david.kessens@nsn.com) David Partain (david.partain@ericsson.com) Jabber: xmpp:netmod@jabber.ietf.org WG URL: http://tools.ietf.org/wg/netmod/ WebEx: will be available, seperate announcement will be send to list TUESDAY, November 10, 2009 0900-1130 Cattleya East 1) Administrivia [chairs][ 5 min ] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing 2) Status Update [chairs][ 5 min ] - How we're doing against the charter 3) Active Drafts For each draft: current status, delta from previous draft, open issues, and discussion. 3.1 Common YANG Data Types http://tools.ietf.org/html/draft-ietf-netmod-yang-types-04 (Juergen Schoenwaelder - remote) 3.2 YANG - A data modeling language for NETCONF http://tools.ietf.org/html/draft-ietf-netmod-yang-08 (Martin Bjorklund - remote) 3.3 YANG Usage Guidelines http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02 (Andy Bierman - remote) 3.4 NETMOD Architecture http://tools.ietf.org/html/draft-ietf-netmod-arch-02 (Phil Shafer - remote) 3.5 Mapping of YANG to DSDL http://tools.ietf.org/html/draft-ietf-netmod-dsdl-map-04 (Ladislav Lhotka) 4) Other (non WG) Internet-Drafts, for feedback and discussion [chairs, we will only spend time on these items if we have time] 4.1 draft-linowski-netmod-yang-abstract-00.txt (time allowing) Bernd Linowski/Mehmet Ersue 5) I/O with other WGs (NETCONF/IPFIX/others ?), activities this week [chairs] 6) Plans post IETF76 WGLC for NETMOD Architecture? WGLC on YANG / YANG Data Types? 7) A.O.B. and open mike [N.N.] {please identify issues in advance} ---- From david.kessens@nsn.com Mon Nov 9 01:39:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F373E3A6961 for ; Mon, 9 Nov 2009 01:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xmhB9cAcmsp for ; Mon, 9 Nov 2009 01:39:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E57F53A6951 for ; Mon, 9 Nov 2009 01:39:31 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA99dssA001728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Nov 2009 10:39:54 +0100 Received: from localhost.localdomain ([10.138.51.24]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA99dpY1002673 for ; Mon, 9 Nov 2009 10:39:53 +0100 Received: from localhost.localdomain (david [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id nA99dpSd008878 for ; Mon, 9 Nov 2009 01:39:51 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id nA99doBP008877 for netmod@ietf.org; Mon, 9 Nov 2009 01:39:50 -0800 Date: Mon, 9 Nov 2009 01:39:50 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20091109093950.GJ8503@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] WebEx usage information X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:39:44 -0000 Please see below for the information required to join our meeting using WebEx. Note that we will not monitor the WebEx chat functionality, please use the normal IETF jabber room. Topic: netmod at IETF 76 Date: Tuesday, November 10, 2009 Time: 8:45 am, Japan Time (Tokyo, GMT+09:00) Meeting Number: 967 518 558 Meeting Password: netmod ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=130140937&UID=0&PW=NNDgxOGE0NzA4&RT=MiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: netmod 4. Click "Join Now". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=130140937&UID=0&PW=NNDgxOGE0NzA4&ORT=MiM0OQ%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:967 518 558 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=130140937&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=Wo0B9fqQW3WrUkRj9LFgNwov03i7t0qUcBcV4AFprG8=&RT=MiM0OQ%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. ----- David Kessens --- From mbj@tail-f.com Mon Nov 9 03:46:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C373A6A0C for ; Mon, 9 Nov 2009 03:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG6pl6OcpGiG for ; Mon, 9 Nov 2009 03:46:53 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EACED3A68B7 for ; Mon, 9 Nov 2009 03:46:52 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 160C4616001; Mon, 9 Nov 2009 12:47:18 +0100 (CET) Date: Mon, 09 Nov 2009 12:47:17 +0100 (CET) Message-Id: <20091109.124717.85972332.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257527153.3963.13.camel@missotis> References: <1257524805.3963.0.camel@missotis> <20091106164331.GA13386@elstar.local> <1257527153.3963.13.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:46:54 -0000 Ladislav Lhotka wrote: > I am just trying to understand what the acceptable (and likely) paths > are for module evolution, perhaps without the need for giving an exact > revision number. > > The change of a leaf definition from mandatory=true to (mandatory=false > & new default definition) seems a natural way for establishing a data > model default based on operational experience, and it shouldn't cause > any serious interoperability problems. This is also covered by the proposed update, repeated here again: - A "default" statement may be added to a leaf that does not have a default value (either directly or indirectly through its type). We already have: - A "mandatory" statement may be removed or changed from "true" to "false". /martin From mbj@tail-f.com Mon Nov 9 03:54:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2543A6A0C for ; Mon, 9 Nov 2009 03:54:03 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUGenKneazk3 for ; Mon, 9 Nov 2009 03:54:02 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2B5E83A6A0A for ; Mon, 9 Nov 2009 03:54:02 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 23BF9616001; Mon, 9 Nov 2009 12:54:28 +0100 (CET) Date: Mon, 09 Nov 2009 12:54:27 +0100 (CET) Message-Id: <20091109.125427.160545454.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AF459D3.5090208@netconfcentral.com> References: <20091105221852.GA10764@elstar.local> <1257524805.3963.0.camel@missotis> <4AF459D3.5090208@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:54:03 -0000 Andy Bierman wrote: > SMIv2-like CLRs to preserve backward compatibility don't > work very well in YANG. That's exactly what Section 10 "Updating a module" specifies. Are you suggesting we remove that section? I think these rules work (and FWIW, at our company we have some implementation experience from using them). > IMO, a better implementation > strategy for the client is to construct the server's > view of the schema tree from the and avoid any > heuristics based on the CLRs in Sec. 10. If the client > supports deviations, then the change-control rules are > totally irrelevant, since deviations don't follow any rules. > > (It would help if revisions were mandatory to use. > The CLRs do not help at all for revision-less modules. > Nothing does.) I think it would be ok to change the SHOULD in section 10 to MUST: OLD: For any published change, a new "revision" statement (^revision^) SHOULD be included NEW: For any published change, a new "revision" statement (^revision^) MUST be included > d. require revision on all modules and submodules, and think about > import-by-revision very carefully. The WG should understand how it will > function within the IETF wrt/ all processes. After there are specific > recommendations for module reuse practices, then rules for > import-by-revision > may be appropriate. I think text about import / include by revision should go into the usage guidelines document. At least some text that says "think carefully about it!", preferably with some guidelines on what impact an import-by revision has. /martin From lhotka@cesnet.cz Mon Nov 9 05:50:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C595C28C110 for ; Mon, 9 Nov 2009 05:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiC09R37H34o for ; Mon, 9 Nov 2009 05:50:23 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 07E323A6B3B for ; Mon, 9 Nov 2009 05:50:23 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 6BFB4D800F3; Mon, 9 Nov 2009 14:50:47 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091109.124717.85972332.mbj@tail-f.com> References: <1257524805.3963.0.camel@missotis> <20091106164331.GA13386@elstar.local> <1257527153.3963.13.camel@missotis> <20091109.124717.85972332.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 09 Nov 2009 22:50:40 +0900 Message-Id: <1257774640.3555.48.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:50:23 -0000 Martin Bjorklund píše v Po 09. 11. 2009 v 12:47 +0100: > Ladislav Lhotka wrote: > > I am just trying to understand what the acceptable (and likely) paths > > are for module evolution, perhaps without the need for giving an exact > > revision number. > > > > The change of a leaf definition from mandatory=true to (mandatory=false > > & new default definition) seems a natural way for establishing a data > > model default based on operational experience, and it shouldn't cause > > any serious interoperability problems. > > This is also covered by the proposed update, repeated here again: > > - A "default" statement may be added to a leaf that does not have a > default value (either directly or indirectly through its type). > > We already have: > > - A "mandatory" statement may be removed or changed from "true" to > "false". My point was rather that these two should mostly be used together - otherwise, an optional leaf without any default that gets a default in the next version looks suspicious and probably indicates the server used some value behind the scenes in the old version, which should be banned. Or is there any use case for such a situation? Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Nov 9 06:03:26 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11EE728C138 for ; Mon, 9 Nov 2009 06:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2ZEjj2cXIJ4 for ; Mon, 9 Nov 2009 06:03:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2CDEA28C0F1 for ; Mon, 9 Nov 2009 06:03:25 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A2D63616001; Mon, 9 Nov 2009 15:03:50 +0100 (CET) Date: Mon, 09 Nov 2009 15:03:50 +0100 (CET) Message-Id: <20091109.150350.86347075.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257774640.3555.48.camel@missotis> References: <1257527153.3963.13.camel@missotis> <20091109.124717.85972332.mbj@tail-f.com> <1257774640.3555.48.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:03:26 -0000 Ladislav Lhotka wrote: > [...] the server used > some value behind the scenes in the old version, which should be banned. I don't think this should be banned. I hope I don't re-open the endless discussions we already had, but I think we agreed that this is perferctly legal: leaf destinationPort { type inet:port-number; description "If not configured, the device uses the default port number for IPFIX, which is 4739 without transport layer security and 4740 if transport layer security is activated."; } /martin From lhotka@cesnet.cz Mon Nov 9 06:45:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB433A6942 for ; Mon, 9 Nov 2009 06:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzhFJZVIpW-h for ; Mon, 9 Nov 2009 06:45:19 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D11A53A6B7F for ; Mon, 9 Nov 2009 06:45:18 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 2D3F4D800F0; Mon, 9 Nov 2009 15:45:42 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091109.150350.86347075.mbj@tail-f.com> References: <1257527153.3963.13.camel@missotis> <20091109.124717.85972332.mbj@tail-f.com> <1257774640.3555.48.camel@missotis> <20091109.150350.86347075.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 09 Nov 2009 23:45:39 +0900 Message-Id: <1257777939.3555.92.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:45:20 -0000 Martin Bjorklund píše v Po 09. 11. 2009 v 15:03 +0100: > Ladislav Lhotka wrote: > > > [...] the server used > > some value behind the scenes in the old version, which should be banned. > > I don't think this should be banned. I hope I don't re-open the > endless discussions we already had, but I think we agreed that this is > perferctly legal: > > leaf destinationPort { > type inet:port-number; > description "If not configured, the device uses the default port > number for IPFIX, which is 4739 without transport layer > security and 4740 if transport layer security is activated."; > } Yes, but in this case I'd require that the server write the value to the configuration. If this happens, we can consider the destinationPort leaf mandatory - it must always exist in a valid configuration, either provided by the client or server. Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Nov 9 12:59:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F6E3A68E2 for ; Mon, 9 Nov 2009 12:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE6A5dZF9+fX for ; Mon, 9 Nov 2009 12:59:52 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 2B9723A68C7 for ; Mon, 9 Nov 2009 12:59:52 -0800 (PST) Received: (qmail 17147 invoked from network); 9 Nov 2009 20:53:39 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 09 Nov 2009 12:53:39 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: pXuwwSAVM1kg6RLHLSxsu8fAWaECTy1gu6w9lOzvj.26ux7Brmgt4Oq01PL7Tk0phNSkbiFeqmRC0ttSht2ORiaqLIykruqk5X_E7ICCnQ2qAc7gT4LAtEO9u._58lZn65aR8Qs_7Rs79UxKpr.IzF.7tUWC5..gz6RoYyiiRAk0GjfjThXT2KkZV5.TE.21T7sBkFyis_zBqMR00lNUwMuzg9tFbh0DRLOPF7fHJt3P_HtTYGW9Xdr52jSQ1LJB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF88164.1000001@netconfcentral.com> Date: Mon, 09 Nov 2009 12:53:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: [netmod] 2 bugs in ietf-ipfix-psamp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:59:52 -0000 Hi, I use your data model to test my YANG compiler. It is complaining about the latest version. In 'list selectionProcess', the must-stmt has an extra right parenthesis at the end. Within that list, 'list selector' has a unique-stmt for a non-config leaf (selectorId), even though that list is config=true. I am not sure this is an error though. I cc:ed the NETMOD WG because it is not clear if yang-08, sec 8.* covers this usage. I think a config=true node can only define constraints on other config=true nodes. If this is not the case, then the YANG draft (sec 8.1) should make that clear. The data-not-unique error does not apply, but the YANG text in sec. 13.1 does not make that clear. thanks, Andy From mbj@tail-f.com Mon Nov 9 15:31:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9193A68A0; Mon, 9 Nov 2009 15:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLoWtyXVf4Il; Mon, 9 Nov 2009 15:31:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 87B663A6819; Mon, 9 Nov 2009 15:31:29 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 408B5616001; Tue, 10 Nov 2009 00:31:55 +0100 (CET) Date: Tue, 10 Nov 2009 00:31:54 +0100 (CET) Message-Id: <20091110.003154.65949736.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AF88164.1000001@netconfcentral.com> References: <4AF88164.1000001@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, ipfix@ietf.org Subject: Re: [netmod] 2 bugs in ietf-ipfix-psamp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:31:30 -0000 Andy Bierman wrote: > Within that list, 'list selector' has a unique-stmt > for a non-config leaf (selectorId), even though that > list is config=true. > > I am not sure this is an error though. No it is ok. > I cc:ed the NETMOD WG because it > is not clear if yang-08, sec 8.* covers this usage. Section 7.8.3. says: If one of the referenced leafs represents configuration data, then all of the referenced leafs MUST represent configuration data. This requirment is clearly fulfilled in this case. Section 8.1 says: o If the constraint is defined on state data, it MUST be true in a reply to the command. This constraint is defined for state data, so it is ok. > I think a config=true node can only define constraints > on other config=true nodes. If this is not the case, > then the YANG draft (sec 8.1) should make that clear. > The data-not-unique error does not apply, > but the YANG text in sec. 13.1 does not make that clear. I will fork this thread here, since I suspect that the discussion on these details might not be of general interest. So I will respond to this on the NETMOD list only. /martin From mbj@tail-f.com Mon Nov 9 15:39:36 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4913A689C for ; Mon, 9 Nov 2009 15:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3-vq0eQY9zf for ; Mon, 9 Nov 2009 15:39:35 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 71F4A3A6828 for ; Mon, 9 Nov 2009 15:39:35 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5670A616001; Tue, 10 Nov 2009 00:40:01 +0100 (CET) Date: Tue, 10 Nov 2009 00:40:00 +0100 (CET) Message-Id: <20091110.004000.245781922.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <20091110.003154.65949736.mbj@tail-f.com> References: <4AF88164.1000001@netconfcentral.com> <20091110.003154.65949736.mbj@tail-f.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] 2 bugs in ietf-ipfix-psamp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:39:36 -0000 Hi, Martin Bjorklund wrote: > Andy Bierman wrote: > > I think a config=true node can only define constraints > > on other config=true nodes. If this is not the case, > > then the YANG draft (sec 8.1) should make that clear. Is there anything in the current text that suggests that this *is* the case? > > The data-not-unique error does not apply, > > but the YANG text in sec. 13.1 does not make that clear. Doesn't it? It says: If a NETCONF operation would result in configuration data where a unique constraint is invalidated, the following error is returned: I guess we could say: If a NETCONF operation would result in configuration data where a unique constraint defined on configuration data is invalidated, the following error is returned: If we do that, we should do that for the rest of 13.* as well, e.g. OLD: If a NETCONF operation would result in configuration data where a list or a leaf-list would have too many entries the following error is returned: NEW: If a NETCONF operation would result in configuration data where a configuration list or a leaf-list would have too many entries the following error is returned: But do we really need this? /martin From j.schoenwaelder@jacobs-university.de Mon Nov 9 17:15:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9313A6809 for ; Mon, 9 Nov 2009 17:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YevaUv87mZuT for ; Mon, 9 Nov 2009 17:15:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECECB3A69F5 for ; Mon, 9 Nov 2009 17:14:57 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E02AC0008; Tue, 10 Nov 2009 02:15:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jMYNJgIybn3F; Tue, 10 Nov 2009 02:15:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B91DC0003; Tue, 10 Nov 2009 02:15:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B09C7DABD8E; Tue, 10 Nov 2009 02:15:22 +0100 (CET) Date: Tue, 10 Nov 2009 02:15:22 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20091110011522.GA18622@elstar.local> Mail-Followup-To: Balazs Lengyel , netmod@ietf.org References: <4AF8BA6C.402@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF8BA6C.402@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netmod@ietf.org Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:15:02 -0000 On Tue, Nov 10, 2009 at 01:57:16AM +0100, Balazs Lengyel wrote: > Hello Juergen, > For the partial-lock draft I was instructed to use the > and tags for YANG modules. Will you add them to the > types draft? There are two different things here: a) The CODE BEGINS/ENDS tag for the license stuff. My understanding is that this tag is not needed for well-known code types, such as MIB modules or YANG modules. b) A marker that supports automatic extraction of code fragments like we did for MIB modules. The dsdl draft uses a creative version kind of combining both: == CODE BEGINS: file "define.rng" == CODE ENDS Perhaps if we use something like file "define.rng" we follow the IETF Trust policy closely (even though not necessarily required) and at the same time get a file name for automatic tools. (CCing the WG so we arrive at a common approach, right now the dsdl document is different from the yang and yang-types document and they are again different from the netconf-monitoring document.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Nov 9 17:58:47 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215F33A635F for ; Mon, 9 Nov 2009 17:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvooQnOt7CmF for ; Mon, 9 Nov 2009 17:58:46 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5AA773A6A49 for ; Mon, 9 Nov 2009 17:58:46 -0800 (PST) Received: from [133.93.19.175] (host-19-175.meeting.ietf.org [133.93.19.175]) by office2.cesnet.cz (Postfix) with ESMTP id 15B08D800FE; Tue, 10 Nov 2009 02:59:07 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091110011522.GA18622@elstar.local> References: <4AF8BA6C.402@ericsson.com> <20091110011522.GA18622@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Nov 2009 10:59:03 +0900 Message-Id: <1257818343.7700.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:58:47 -0000 Juergen Schoenwaelder píše v Út 10. 11. 2009 v 02:15 +0100: > On Tue, Nov 10, 2009 at 01:57:16AM +0100, Balazs Lengyel wrote: > > Hello Juergen, > > For the partial-lock draft I was instructed to use the > > and tags for YANG modules. Will you add them to the > > types draft? > > There are two different things here: > > a) The CODE BEGINS/ENDS tag for the license stuff. My understanding > is that this tag is not needed for well-known code types, such as > MIB modules or YANG modules. > > b) A marker that supports automatic extraction of code fragments like > we did for MIB modules. > > The dsdl draft uses a creative version kind of combining both: > > == CODE BEGINS: file "define.rng" > == CODE ENDS > > Perhaps if we use something like > > file "define.rng" > I decided not to use this particular form in the DSDL mapping draft as it looks like XML which it delimits. The IETF Trust Legal Provisions state "... and , or otherwise clearly labeled as a Code Component", so it should be OK. Lada > > we follow the IETF Trust policy closely (even though not necessarily > required) and at the same time get a file name for automatic tools. > > (CCing the WG so we arrive at a common approach, right now the dsdl > document is different from the yang and yang-types document and they > are again different from the netconf-monitoring document.) > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Nov 9 18:20:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27AA3A68C6 for ; Mon, 9 Nov 2009 18:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aL5b-jAlnlM for ; Mon, 9 Nov 2009 18:20:49 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EEB5E3A68C2 for ; Mon, 9 Nov 2009 18:20:48 -0800 (PST) Received: from [133.93.19.175] (host-19-175.meeting.ietf.org [133.93.19.175]) by office2.cesnet.cz (Postfix) with ESMTP id 69805D800E8 for ; Tue, 10 Nov 2009 03:21:13 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Tue, 10 Nov 2009 11:21:09 +0900 Message-Id: <1257819669.7700.42.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [netmod] order of case children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:20:49 -0000 Hi, YANG draft doesn't specify the ordering rules for children of 'case', so I propose to change Sec. 7.9.5: OLD The choice and case nodes are not visible in XML. NEW The choice and case nodes are not visible in XML. The child nodes of the selected 'case' statement MUST be encoded in the same order as they are defined in the 'case' statement if they are part of a RPC input or output parameter definition. Otherwise, the subelements may be encoded in any order. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Nov 9 22:17:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3CD28B56A for ; Mon, 9 Nov 2009 22:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LJo4YlxLfIU for ; Mon, 9 Nov 2009 22:17:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EF8443A6899 for ; Mon, 9 Nov 2009 22:17:00 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91B10C0008; Tue, 10 Nov 2009 07:17:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NBef4sOqlLgv; Tue, 10 Nov 2009 07:17:26 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07A11C0002; Tue, 10 Nov 2009 07:17:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D4D0BDAC316; Tue, 10 Nov 2009 07:17:25 +0100 (CET) Date: Tue, 10 Nov 2009 07:17:25 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091110061725.GA18883@elstar.local> Mail-Followup-To: Ladislav Lhotka , Balazs Lengyel , "netmod@ietf.org" References: <4AF8BA6C.402@ericsson.com> <20091110011522.GA18622@elstar.local> <1257818343.7700.32.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1257818343.7700.32.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:17:02 -0000 On Tue, Nov 10, 2009 at 02:59:03AM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v ??t 10. 11. 2009 v 02:15 +0100: > > On Tue, Nov 10, 2009 at 01:57:16AM +0100, Balazs Lengyel wrote: > > > Hello Juergen, > > > For the partial-lock draft I was instructed to use the > > > and tags for YANG modules. Will you add them to the > > > types draft? > > > > There are two different things here: > > > > a) The CODE BEGINS/ENDS tag for the license stuff. My understanding > > is that this tag is not needed for well-known code types, such as > > MIB modules or YANG modules. > > > > b) A marker that supports automatic extraction of code fragments like > > we did for MIB modules. > > > > The dsdl draft uses a creative version kind of combining both: > > > > == CODE BEGINS: file "define.rng" > > == CODE ENDS > > > > Perhaps if we use something like > > > > file "define.rng" > > > > I decided not to use this particular form in the DSDL mapping draft as > it looks like XML which it delimits. The IETF Trust Legal Provisions > state "... and , or otherwise clearly labeled as > a Code Component", so it should be OK. But for the purpose of automatic extraction, we better agree on _one_ format... All caps looks like ANS.1 - so what. ;-) /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 Nov 9 23:51:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478543A6837 for ; Mon, 9 Nov 2009 23:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qtQCzQiTS8p for ; Mon, 9 Nov 2009 23:51:28 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 80D2C3A67DD for ; Mon, 9 Nov 2009 23:51:28 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 27944616001; Tue, 10 Nov 2009 08:51:55 +0100 (CET) Date: Tue, 10 Nov 2009 08:51:54 +0100 (CET) Message-Id: <20091110.085154.232747393.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257819669.7700.42.camel@missotis> References: <1257819669.7700.42.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of case children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:51:29 -0000 Hi, Thank you Lada, fix applied. /martin Ladislav Lhotka wrote: > Hi, > > YANG draft doesn't specify the ordering rules for children of 'case', so > I propose to change Sec. 7.9.5: > > OLD > > The choice and case nodes are not visible in XML. > > NEW > > The choice and case nodes are not visible in XML. > > The child nodes of the selected 'case' statement MUST be encoded in the > same order as they are defined in the 'case' statement if they are part > of a RPC input or output parameter definition. Otherwise, the > subelements may be encoded in any order. From muenz@net.in.tum.de Tue Nov 10 01:16:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857973A687E; Tue, 10 Nov 2009 01:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKJrxhJGPvAx; Tue, 10 Nov 2009 01:16:23 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id B71C93A6844; Tue, 10 Nov 2009 01:16:23 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 461F9485A0; Tue, 10 Nov 2009 10:16:46 +0100 (CET) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 311ECB41; Tue, 10 Nov 2009 10:16:46 +0100 (CET) Message-ID: <4AF92FC4.1050708@net.in.tum.de> Date: Tue, 10 Nov 2009 10:17:56 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <4AF88164.1000001@netconfcentral.com> In-Reply-To: <4AF88164.1000001@netconfcentral.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050308060601080400010503" X-Virus-Scanned: ClamAV using ClamSMTP Cc: NETMOD Working Group , IPFIX Working Group Subject: Re: [netmod] [IPFIX] 2 bugs in ietf-ipfix-psamp.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:16:24 -0000 This is a cryptographically signed message in MIME format. --------------ms050308060601080400010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Andy Bierman wrote: > Hi, > > I use your data model to test my YANG compiler. > It is complaining about the latest version. > > In 'list selectionProcess', the must-stmt has an > extra right parenthesis at the end. Thanks. There should be a left parenthesis before "count" in the same must statement. Regards, Gerhard > Within that list, 'list selector' has a unique-stmt > for a non-config leaf (selectorId), even though that > list is config=true. > > I am not sure this is an error though. > I cc:ed the NETMOD WG because it > is not clear if yang-08, sec 8.* covers this usage. > > I think a config=true node can only define constraints > on other config=true nodes. If this is not the case, > then the YANG draft (sec 8.1) should make that clear. > The data-not-unique error does not apply, > but the YANG text in sec. 13.1 does not make that clear. > > > thanks, > Andy > --------------ms050308060601080400010503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTEwMDkxNzU2WjAjBgkqhkiG9w0BCQQxFgQU u9BPKOZE5ZUhqj97Vi/nxR43FK0wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQCIMZL5/OwRaKiBq3+2lezOwFXWCN62 sqA+DkUIAxMyah4YSdmhfy3AhCUHKQ/Kd80hOOVqisfP0SJOsG3DQ9dD5veeR30fx7seHpk0 5crRPXSCStP8YADnZIpQ8yjyoqRrTI2uJ6ElxFbV4cvaWeBv2iNdI7EhtUJxO1tzvMpcJHbC 2Bi/rK3tpSmE1nJeFHQ4rmVgUikgCkXw+HrJUMvBtZZxjAYb/XvMPEbNGMScFZZgZNpanTqW P6mfWrCcS3dlZiqZ8kUiDjUN/W+9TbnmX5QQBmCtarL6bmGIYQx1EIrRUn7SZzzC9I8k5nOh EDh+yaJnotU/PUuQwAcnrY0HAAAAAAAA --------------ms050308060601080400010503-- From lhotka@cesnet.cz Tue Nov 10 04:53:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB4B3A6903 for ; Tue, 10 Nov 2009 04:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prL3mK9iThdA for ; Tue, 10 Nov 2009 04:53:58 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 46BE53A6862 for ; Tue, 10 Nov 2009 04:53:58 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 52364D800CE; Tue, 10 Nov 2009 13:54:23 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091110061725.GA18883@elstar.local> References: <4AF8BA6C.402@ericsson.com> <20091110011522.GA18622@elstar.local> <1257818343.7700.32.camel@missotis> <20091110061725.GA18883@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Nov 2009 21:54:16 +0900 Message-Id: <1257857656.25407.0.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:53:59 -0000 Juergen Schoenwaelder píše v Út 10. 11. 2009 v 07:17 +0100: > On Tue, Nov 10, 2009 at 02:59:03AM +0100, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v ??t 10. 11. 2009 v 02:15 +0100: > > > On Tue, Nov 10, 2009 at 01:57:16AM +0100, Balazs Lengyel wrote: > > > > Hello Juergen, > > > > For the partial-lock draft I was instructed to use the > > > > and tags for YANG modules. Will you add them to the > > > > types draft? > > > > > > There are two different things here: > > > > > > a) The CODE BEGINS/ENDS tag for the license stuff. My understanding > > > is that this tag is not needed for well-known code types, such as > > > MIB modules or YANG modules. > > > > > > b) A marker that supports automatic extraction of code fragments like > > > we did for MIB modules. > > > > > > The dsdl draft uses a creative version kind of combining both: > > > > > > == CODE BEGINS: file "define.rng" > > > == CODE ENDS > > > > > > Perhaps if we use something like > > > > > > file "define.rng" > > > > > > > I decided not to use this particular form in the DSDL mapping draft as > > it looks like XML which it delimits. The IETF Trust Legal Provisions > > state "... and , or otherwise clearly labeled as > > a Code Component", so it should be OK. > > But for the purpose of automatic extraction, we better agree on _one_ > format... All caps looks like ANS.1 - so what. ;-) OK, no problem with that. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 10 05:43:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A89B3A6ABE for ; Tue, 10 Nov 2009 05:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmliAzJXt7l3 for ; Tue, 10 Nov 2009 05:43:06 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 72B4D3A6949 for ; Tue, 10 Nov 2009 05:43:06 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 24ACE616001; Tue, 10 Nov 2009 14:43:32 +0100 (CET) Date: Tue, 10 Nov 2009 14:43:31 +0100 (CET) Message-Id: <20091110.144331.242884015.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1257857656.25407.0.camel@missotis> References: <1257818343.7700.32.camel@missotis> <20091110061725.GA18883@elstar.local> <1257857656.25407.0.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 13:43:07 -0000 Ladislav Lhotka wrote: > > > > Perhaps if we use something like > > > > > > > > file "define.rng" > > > > > OK, no problem with that. Ok, so we agree to use the syntax above in the next revisions of our drafts then? /martin From lhotka@cesnet.cz Tue Nov 10 06:22:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88BF3A6AC8 for ; Tue, 10 Nov 2009 06:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ragV6udslfmk for ; Tue, 10 Nov 2009 06:22:16 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 31C803A69ED for ; Tue, 10 Nov 2009 06:22:16 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 16922D800F6; Tue, 10 Nov 2009 15:22:40 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091110.144331.242884015.mbj@tail-f.com> References: <1257818343.7700.32.camel@missotis> <20091110061725.GA18883@elstar.local> <1257857656.25407.0.camel@missotis> <20091110.144331.242884015.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Nov 2009 23:22:37 +0900 Message-Id: <1257862957.25407.54.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:22:17 -0000 Martin Bjorklund píše v Út 10. 11. 2009 v 14:43 +0100: > Ladislav Lhotka wrote: > > > > > Perhaps if we use something like > > > > > > > > > > file "define.rng" > > > > > > > > OK, no problem with that. > > Ok, so we agree to use the syntax above in the next revisions of our > drafts then? Fine with me. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Nov 10 06:37:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EAF93A6AEA for ; Tue, 10 Nov 2009 06:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF1aD-QZu8G6 for ; Tue, 10 Nov 2009 06:36:59 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CA1AB3A6AD7 for ; Tue, 10 Nov 2009 06:36:58 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77C79C000F; Tue, 10 Nov 2009 15:37:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FXc-wxPfWS9z; Tue, 10 Nov 2009 15:37:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87842C0002; Tue, 10 Nov 2009 15:37:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 653A5E16054; Tue, 10 Nov 2009 15:37:24 +0100 (CET) Date: Tue, 10 Nov 2009 15:37:24 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091110143724.GB24820@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netmod@ietf.org" References: <1257818343.7700.32.camel@missotis> <20091110061725.GA18883@elstar.local> <1257857656.25407.0.camel@missotis> <20091110.144331.242884015.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091110.144331.242884015.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:37:00 -0000 On Tue, Nov 10, 2009 at 02:43:31PM +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > > Perhaps if we use something like > > > > > > > > > > file "define.rng" > > > > > > > > OK, no problem with that. > > Ok, so we agree to use the syntax above in the next revisions of our > drafts then? I do not care much which format we pick as long as we stick to _one_ format. The above is OK for me but I am happy to use something else. Now that I think again about it, one could probably also go with just and have a script extracting modules search for the keyword 'module' (or 'submodule') and the following name to derive a filename. This is not much different from how smistrip for example derives a file name. I also noted differences in the meta data section between the yang-types and the netconf-monitoring documents and again it would be nice if we would be consistent since everybody will follow these initial YANG modules (I am using a reference statement in a revision statement for example and I have different copyright boilerplate text). And yes, ideally this all would be documented in the yang usage document (but right now the template in there is yet different). But I am optimisitc things will eventually converge. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Nov 10 06:42:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0043A6AED for ; Tue, 10 Nov 2009 06:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UzqWpWSDFgh for ; Tue, 10 Nov 2009 06:42:42 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CD7FB3A6A8B for ; Tue, 10 Nov 2009 06:42:41 -0800 (PST) Received: from [133.93.113.127] (host-113-127.meeting.ietf.org [133.93.113.127]) by office2.cesnet.cz (Postfix) with ESMTP id 78CE5D800C0; Tue, 10 Nov 2009 15:43:07 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091110143724.GB24820@elstar.local> References: <1257818343.7700.32.camel@missotis> <20091110061725.GA18883@elstar.local> <1257857656.25407.0.camel@missotis> <20091110.144331.242884015.mbj@tail-f.com> <20091110143724.GB24820@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Nov 2009 23:43:03 +0900 Message-Id: <1257864183.25407.74.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:42:42 -0000 Juergen Schoenwaelder píše v Út 10. 11. 2009 v 15:37 +0100: > On Tue, Nov 10, 2009 at 02:43:31PM +0100, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > > > > > > Perhaps if we use something like > > > > > > > > > > > > file "define.rng" > > > > > > > > > > > OK, no problem with that. > > > > Ok, so we agree to use the syntax above in the next revisions of our > > drafts then? > > I do not care much which format we pick as long as we stick to _one_ > format. The above is OK for me but I am happy to use something else. > Now that I think again about it, one could probably also go with just > > > > > and have a script extracting modules search for the keyword 'module' > (or 'submodule') and the following name to derive a filename. This is > not much different from how smistrip for example derives a file name. But this will not be used only for YANG modules. I prefer Martin's suggestion. Lada > > I also noted differences in the meta data section between the > yang-types and the netconf-monitoring documents and again it would be > nice if we would be consistent since everybody will follow these > initial YANG modules (I am using a reference statement in a revision > statement for example and I have different copyright boilerplate > text). And yes, ideally this all would be documented in the yang usage > document (but right now the template in there is yet different). But > I am optimisitc things will eventually converge. ;-) > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 10 06:44:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE90A3A689F for ; Tue, 10 Nov 2009 06:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGuA8-H6fXE9 for ; Tue, 10 Nov 2009 06:44:44 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 228B73A68AC for ; Tue, 10 Nov 2009 06:44:28 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3BB45616001; Tue, 10 Nov 2009 15:44:54 +0100 (CET) Date: Tue, 10 Nov 2009 15:44:53 +0100 (CET) Message-Id: <20091110.154453.107878659.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091110143724.GB24820@elstar.local> References: <1257857656.25407.0.camel@missotis> <20091110.144331.242884015.mbj@tail-f.com> <20091110143724.GB24820@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:44:45 -0000 Juergen Schoenwaelder wrote: > On Tue, Nov 10, 2009 at 02:43:31PM +0100, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > > > > > > Perhaps if we use something like > > > > > > > > > > > > file "define.rng" > > > > > > > > > > > OK, no problem with that. > > > > Ok, so we agree to use the syntax above in the next revisions of our > > drafts then? > > I do not care much which format we pick as long as we stick to _one_ > format. The above is OK for me but I am happy to use something else. > Now that I think again about it, one could probably also go with just > > > > > and have a script extracting modules search for the keyword 'module' > (or 'submodule') and the following name to derive a filename. This is > not much different from how smistrip for example derives a file name. This works fine for YANG (sub)modules, but not for e.g. an ABNF grammar or the dsdl-files. > I also noted differences in the meta data section between the > yang-types and the netconf-monitoring documents and again it would be > nice if we would be consistent since everybody will follow these > initial YANG modules (I am using a reference statement in a revision > statement for example and I have different copyright boilerplate > text). Agreed. I will align the monitoring module with your modules. /martin From andy@netconfcentral.com Tue Nov 10 07:21:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57AFE3A681C for ; Tue, 10 Nov 2009 07:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bdM6YXfAFD0 for ; Tue, 10 Nov 2009 07:21:37 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id A71CA3A67E6 for ; Tue, 10 Nov 2009 07:21:37 -0800 (PST) Received: (qmail 94351 invoked from network); 10 Nov 2009 15:22:03 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 10 Nov 2009 07:22:03 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: bo13MuMVM1nYEFCgyPxCjs9UACrDeKoIkRIvzJmn2iUO3hqn0OGhD1kQ0oKphYumNuWXetq2GcN4bMjPtgc8wZDQigTU2NB7zGRg2LfpsfQc1Dqo5nmZSk3FJ_NtT2FUH3Ii.MYKNuVf.lO72d4kPTisLD4u2vjt.P1Oq7VJ.RtCNFqf5A9NMiKYrOw6dLXZGusMOz8M7fS3j_oMr0Y78W92XeXqJoR6GXoompGWNqNN28SS_4YhLc.ALrUBNqrtjvvbOYwX__TnNjIcKwlvBB5r0xLef6RYUlwLGTl.JVA5tUtN8.SK X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF9849D.10103@netconfcentral.com> Date: Tue, 10 Nov 2009 07:19:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <1257857656.25407.0.camel@missotis> <20091110.144331.242884015.mbj@tail-f.com> <20091110143724.GB24820@elstar.local> <20091110.154453.107878659.mbj@tail-f.com> In-Reply-To: <20091110.154453.107878659.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 15:21:38 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Tue, Nov 10, 2009 at 02:43:31PM +0100, Martin Bjorklund wrote: >>> Ladislav Lhotka wrote: >>>>>>> Perhaps if we use something like >>>>>>> >>>>>>> file "define.rng" >>>>>>> >>>> OK, no problem with that. >>> Ok, so we agree to use the syntax above in the next revisions of our >>> drafts then? >> I do not care much which format we pick as long as we stick to _one_ >> format. The above is OK for me but I am happy to use something else. >> Now that I think again about it, one could probably also go with just >> >> >> >> >> and have a script extracting modules search for the keyword 'module' >> (or 'submodule') and the following name to derive a filename. This is >> not much different from how smistrip for example derives a file name. > > This works fine for YANG (sub)modules, but not for e.g. an ABNF > grammar or the dsdl-files. > >> I also noted differences in the meta data section between the >> yang-types and the netconf-monitoring documents and again it would be >> nice if we would be consistent since everybody will follow these >> initial YANG modules (I am using a reference statement in a revision >> statement for example and I have different copyright boilerplate >> text). > > Agreed. I will align the monitoring module with your modules. > Shouldn't this be an IETF-wide practice? Isn't the word 'file' redundant? > > /martin Andy From phil@juniper.net Tue Nov 10 07:33:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F143A6AF8 for ; Tue, 10 Nov 2009 07:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xULvzBfxPddt for ; Tue, 10 Nov 2009 07:33:42 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id A31893A6AF7 for ; Tue, 10 Nov 2009 07:33:41 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSvmH6fP/f1G/CvZjzX3hhZyqhcWIRs9V@postini.com; Tue, 10 Nov 2009 07:34:10 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 10 Nov 2009 07:27:04 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 07:27:04 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 07:27:03 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 07:27:02 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAAFR1j31161; Tue, 10 Nov 2009 07:27:02 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nAAFDkbh016804; Tue, 10 Nov 2009 15:13:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911101513.nAAFDkbh016804@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AF9849D.10103@netconfcentral.com> Date: Tue, 10 Nov 2009 10:13:46 -0500 From: Phil Shafer X-OriginalArrivalTime: 10 Nov 2009 15:27:02.0621 (UTC) FILETIME=[409D68D0:01CA621A] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 15:33:43 -0000 Andy Bierman writes: >>>>>>>> file "define.rng" >>>>>>>> >Shouldn't this be an IETF-wide practice? >Isn't the word 'file' redundant? Yes and yes, but doesn't is seem broken that we are using "<>" but not xml tags? " ... "? Or don't use "<>", like: --- code begins file define.rng --- blah --- code ends --- The xml use of "<>" in an xml-oriented protocol is like nails on chalkboard. Thanks, Phil From andy@netconfcentral.com Tue Nov 10 07:53:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E11D3A6AFB for ; Tue, 10 Nov 2009 07:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFj2I60O4vZR for ; Tue, 10 Nov 2009 07:53:16 -0800 (PST) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 684243A6965 for ; Tue, 10 Nov 2009 07:53:16 -0800 (PST) Received: (qmail 75985 invoked from network); 10 Nov 2009 15:53:41 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 10 Nov 2009 07:53:41 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: sHy4MR4VM1mFd3MwMgGXFDhnwmKrtLa9eF3jDehWy.Gcsyy5qLukgAj03fKmsqZuU4k2WKgSpUi8O1umPTw8DJ.11o0GMJIqjs3m7Q9IoLqYeWjt5byAW3uPUBJqMoip0gugIBlFjN3ABtcdYt6XELHoY3UrdhA7u1b5zZ7OjjKsFLLzMEE6UrsvRa8WhFG4aNhRsLmxZ3MU9KcbKCUPIyHODtfOHUkOAeldkQ45CJnlzFe6jpQxnLI5uBbpUjW9GQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF98C85.5060702@netconfcentral.com> Date: Tue, 10 Nov 2009 07:53:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200911101513.nAAFDkbh016804@idle.juniper.net> In-Reply-To: <200911101513.nAAFDkbh016804@idle.juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] CODE BEGINS ENDS in types draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 15:53:17 -0000 Phil Shafer wrote: > Andy Bierman writes: >>>>>>>>> file "define.rng" >>>>>>>>> >> Shouldn't this be an IETF-wide practice? >> Isn't the word 'file' redundant? > > Yes and yes, but doesn't is seem broken that we are using "<>" but > not xml tags? " ... "? > Or don't use "<>", like: > > --- code begins file define.rng --- > blah > --- code ends --- > > The xml use of "<>" in an xml-oriented protocol is like nails on > chalkboard. > I agree. I like Juergen's original format best. Here is the requirement: TLP, sec 4b: Identification. Text in IETF Contributions and IETF Documents of the types identified in Section 4.a above shall constitute “Code Components”. In addition, any text found between the markers and , or otherwise clearly labeled as a Code Component, shall be considered a “Code Component”. An alternative solution would be to add a section to the Usage Guidelines I-D like: The following convention MUST be used to identify a YANG module or submodule as a 'Code Component' within a document: == code-component "module-name.yang" module module-name { ... } == code-ends (Actual format is not important to me, but 1 format that never changes again would be nice.) > Thanks, > Phil > Andy From bertietf@bwijnen.net Wed Nov 11 04:02:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2E63A6961; Wed, 11 Nov 2009 04:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[AWL=-2.733, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGKGuEaM5qKk; Wed, 11 Nov 2009 04:02:04 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id B8BAA28C168; Wed, 11 Nov 2009 04:02:04 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N8Bu6-0004o2-OF; Wed, 11 Nov 2009 13:02:32 +0100 Received: from host-24-71.meeting.ietf.org (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 627892F5B3; Wed, 11 Nov 2009 13:02:24 +0100 (CET) Message-ID: <4AFAA7CF.3050005@bwijnen.net> Date: Wed, 11 Nov 2009 21:02:23 +0900 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: netmod@ietf.org, Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd430b4bc464d33bedb8573fdee82c25a72 Subject: [netmod] FYI - netconf/netmod for ietfSmartGrid ?] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:02:05 -0000 I am sitting in the IETF-smartGrid BarBof here. Hiroshi Esaki is presenting the approach they aretaking in Japan. He lists XML-Conf as a protocol for configuration. He clarified that he meant netconf. Maybe this is a place to get some YANG modules defined as well? Some of the discussion here will be what can be done in IETF in terms of standardization. Bert From lhotka@cesnet.cz Wed Nov 18 01:56:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB9928C1B9 for ; Wed, 18 Nov 2009 01:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+ewlAROt+b2 for ; Wed, 18 Nov 2009 01:56:31 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DF97E28C1B1 for ; Wed, 18 Nov 2009 01:56:30 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8EBA5D80096 for ; Wed, 18 Nov 2009 10:56:28 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Wed, 18 Nov 2009 10:56:27 +0100 Message-Id: <1258538187.23851.19.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 09:56:31 -0000 Hi, I have two questions regarding order of children: 1. Sec. 7.15.2 states: When a node is augmented, the augmenting child nodes are encoded as subelements to the augmented node, in any order. Is this true also inside RPC parameters? 2. container cont { leaf-list foo { ... } leaf bar { ... } } If these definitions are not inside RPC parameters, is the following a valid order in an instance XML? ... ... ... Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From Washam.Fan@huaweisymantec.com Wed Nov 18 03:50:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79273A6A70 for ; Wed, 18 Nov 2009 03:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTG+cuEC1KJC for ; Wed, 18 Nov 2009 03:50:28 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id EDD803A6A93 for ; Wed, 18 Nov 2009 03:50:27 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTA00LKLZJRACB0@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 18 Nov 2009 19:50:15 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTA00DPMZJRRW20@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 18 Nov 2009 19:50:15 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 18 Nov 2009 19:50:15 +0800 From: WashamFan To: Ladislav Lhotka Message-id: Date: Wed, 18 Nov 2009 19:50:15 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <1258538187.23851.19.camel@missotis> References: <1258538187.23851.19.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:50:28 -0000 > Hi, > > I have two questions regarding order of children: > > 1. Sec. 7.15.2 states: > > When a node is augmented, the augmenting child nodes are encoded as > subelements to the augmented node, in any order. > > Is this true also inside RPC parameters? This is true according to the text you quoted. And I think it should be true. > 2. container cont { > leaf-list foo { ... } > leaf bar { ... } > } > > If these definitions are not inside RPC parameters, is the following > a valid order in an instance XML? > > > ... > ... > ... > I don't think so. foo should have preceded not surrounded bar, IMO. washam > Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@cesnet.cz Wed Nov 18 04:21:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752743A6906 for ; Wed, 18 Nov 2009 04:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EydJrgkkC0j4 for ; Wed, 18 Nov 2009 04:21:14 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9552F3A681F for ; Wed, 18 Nov 2009 04:21:14 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 00F86D800CC; Wed, 18 Nov 2009 13:21:09 +0100 (CET) From: Ladislav Lhotka To: WashamFan In-Reply-To: References: <1258538187.23851.19.camel@missotis> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 18 Nov 2009 13:21:06 +0100 Message-Id: <1258546866.23851.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:21:15 -0000 WashamFan píše v St 18. 11. 2009 v 19:50 +0800: > > Hi, > > > > I have two questions regarding order of children: > > > > 1. Sec. 7.15.2 states: > > > > When a node is augmented, the augmenting child nodes are encoded as > > subelements to the augmented node, in any order. > > > > Is this true also inside RPC parameters? > > This is true according to the text you quoted. And I think > it should be true. Since there is the requirement on fixed element order in RPC parameters, I'd assume the fixed order is important in all cases, but with an augment it won't be fixed anymore. > > > 2. container cont { > > leaf-list foo { ... } > > leaf bar { ... } > > } > > > > If these definitions are not inside RPC parameters, is the following > > a valid order in an instance XML? > > > > > > ... > > ... > > ... > > > > I don't think so. foo should have preceded not surrounded > bar, IMO. Sec. 7.5.7: If the container defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the container statement. Otherwise, the subelements are encoded in any order. As I understand it, all three ordering options are possible: 'foo foo bar', 'bar foo foo' and also 'foo bar foo'. Only the relative order of list items may be important if the leaf-list is ordered-by user. I am happy with this, just asking whether this liberal interpretation was really intended - it has implications for the DSDL mapping. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Nov 18 08:57:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0135B3A6849 for ; Wed, 18 Nov 2009 08:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LttMtvht7w6X for ; Wed, 18 Nov 2009 08:57:43 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 195B73A67D2 for ; Wed, 18 Nov 2009 08:57:43 -0800 (PST) Received: (qmail 18748 invoked from network); 18 Nov 2009 16:57:38 -0000 Received: from adsl-68-120-228-104.dsl.irvnca.pacbell.net (andy@68.120.228.104 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 18 Nov 2009 08:57:33 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: qfDk2scVM1l54vMPWzT.FifPga2.ohFJOcW1hDwDfJomxns95BE80FVR78lzflANN5iwiefEKarCCuC4AuAmHmppe9j0nspj2_gGzwgqPpu01osqlWtkj469kiXBkxs_j6.HVE.hLuCjSnRxoMhST35rORwXupRqWkNMn6CyuGfw8FvTPYFXRaOLp_TamBlP.ajEzSPfdSQ3d1WvyLGVG5gF40QdPAK4.yN_yA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B042794.7@netconfcentral.com> Date: Wed, 18 Nov 2009 08:57:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1258538187.23851.19.camel@missotis> <1258546866.23851.38.camel@missotis> In-Reply-To: <1258546866.23851.38.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:57:44 -0000 Ladislav Lhotka wrote: > WashamFan píše v St 18. 11. 2009 v 19:50 +0800: >>> Hi, >>> >>> I have two questions regarding order of children: >>> >>> 1. Sec. 7.15.2 states: >>> >>> When a node is augmented, the augmenting child nodes are encoded as >>> subelements to the augmented node, in any order. >>> >>> Is this true also inside RPC parameters? >> This is true according to the text you quoted. And I think >> it should be true. > > Since there is the requirement on fixed element order in RPC parameters, > I'd assume the fixed order is important in all cases, but with an > augment it won't be fixed anymore. > >>> 2. container cont { >>> leaf-list foo { ... } >>> leaf bar { ... } >>> } >>> >>> If these definitions are not inside RPC parameters, is the following >>> a valid order in an instance XML? >>> >>> >>> ... >>> ... >>> ... >>> >> I don't think so. foo should have preceded not surrounded >> bar, IMO. > > Sec. 7.5.7: > If the container defines RPC input or output parameters, the > subelements are encoded in the same order as they are defined > within the container statement. Otherwise, the subelements > are encoded in any order. > > As I understand it, all three ordering options are possible: > 'foo foo bar', 'bar foo foo' and also 'foo bar foo'. Only the relative > order of list items may be important if the leaf-list is ordered-by > user. > > I am happy with this, just asking whether this liberal interpretation > was really intended - it has implications for the DSDL mapping. > I do not understand why we need any XML ordering CLRs. They exist for the benefit of 2 specific implementations of the parameter to the edit-config operation. IMO, the server MAY require RPC order, or it MAY accept RPC nodes out of order. Same for key leafs within in the PDU. This is better than the current MUST terminology. A server implementation other than the 2 that need this CLR should not be forced to treat out-of-order nodes (according to YANG CLRs) as errors. This violates the Postel Principle. A client needs to be aware that a server MAY treat out-of-YANG-order as an error, and a conservative client will always send in YANG order, since all servers MUST accept that. > Lada > Andy From lhotka@cesnet.cz Wed Nov 18 09:38:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9611A3A69A6 for ; Wed, 18 Nov 2009 09:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuqVTopXBTSv for ; Wed, 18 Nov 2009 09:38:07 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AFAAF3A694A for ; Wed, 18 Nov 2009 09:38:07 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 494A7D800E8; Wed, 18 Nov 2009 18:38:05 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B042794.7@netconfcentral.com> References: <1258538187.23851.19.camel@missotis> <1258546866.23851.38.camel@missotis> <4B042794.7@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 18 Nov 2009 18:38:03 +0100 Message-Id: <1258565883.23851.155.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:38:08 -0000 Andy Bierman píše v St 18. 11. 2009 v 08:57 -0800: > I do not understand why we need any XML ordering CLRs. > They exist for the benefit of 2 specific implementations > of the parameter to the edit-config operation. > > IMO, the server MAY require RPC order, or > it MAY accept RPC nodes out of order. > Same for key leafs within in the PDU. > This is better than the current MUST terminology. > > A server implementation other than the 2 that need > this CLR should not be forced to treat out-of-order > nodes (according to YANG CLRs) as errors. This violates > the Postel Principle. > > A client needs to be aware that a server MAY treat > out-of-YANG-order as an error, and a conservative > client will always send in YANG order, since all servers > MUST accept that. So what do you want the spec to state? The order of subelements is relevant for both client->server and server->client communication. I am personally in favor of allowing arbitrary order everywhere but IMO the rules must be clear. Saying that clients MAY send children in any order and the server MAY treat it as an error doesn't seem very useful. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Nov 18 09:48:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92003A67DD for ; Wed, 18 Nov 2009 09:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQXmQInd6XlN for ; Wed, 18 Nov 2009 09:48:11 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 1C7B73A67CC for ; Wed, 18 Nov 2009 09:48:11 -0800 (PST) Received: (qmail 8428 invoked from network); 18 Nov 2009 17:48:07 -0000 Received: from adsl-68-120-228-104.dsl.irvnca.pacbell.net (andy@68.120.228.104 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 18 Nov 2009 09:48:06 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: ZQIYOR8VM1k9ha8UjP2618K7iLR33qy_J5v3lpzONXA3XjPjriFb.wVSbOdIfVfbvVm46WK0coVhX0KgJhnCG5XTXzSYVPNTZdPB9N_.HgAuHkKP7kQ.hua4rWXeJKYUNmaj1iZtKwqeI7RMAFPWSx3GG3.RZhwdJiBYIt9a2eik3SKxhiHa2JlO47xCzjaRzaUZ7m4TRmOtea9cohVWIGxUjT.maSUyGQ3keEmyNknxKoGM6yIh828LxZ5qqblE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B04336E.4020702@netconfcentral.com> Date: Wed, 18 Nov 2009 09:48:30 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1258538187.23851.19.camel@missotis> <1258546866.23851.38.camel@missotis> <4B042794.7@netconfcentral.com> <1258565883.23851.155.camel@missotis> In-Reply-To: <1258565883.23851.155.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:48:12 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 18. 11. 2009 v 08:57 -0800: > >> I do not understand why we need any XML ordering CLRs. >> They exist for the benefit of 2 specific implementations >> of the parameter to the edit-config operation. >> >> IMO, the server MAY require RPC order, or >> it MAY accept RPC nodes out of order. >> Same for key leafs within in the PDU. >> This is better than the current MUST terminology. >> >> A server implementation other than the 2 that need >> this CLR should not be forced to treat out-of-order >> nodes (according to YANG CLRs) as errors. This violates >> the Postel Principle. >> >> A client needs to be aware that a server MAY treat >> out-of-YANG-order as an error, and a conservative >> client will always send in YANG order, since all servers >> MUST accept that. > > So what do you want the spec to state? The order of subelements is > relevant for both client->server and server->client communication. > > I am personally in favor of allowing arbitrary order everywhere but IMO > the rules must be clear. Saying that clients MAY send children in any > order and the server MAY treat it as an error doesn't seem very useful. > That isn't what I am suggesting. The server MAY reject requests that are not in the YANG specified order. This is much more robust than: The server MUST reject requests that are not in the YANG specified order. The only reason we have this CLR is to allow a particular implementation strategy. Both CLRs allow it, but the MUST mandates a particular implementation strategy, and that goes against IETF tradition (and perhaps policy). If the server can accept XML elements in any order, then that seems better than forcing it to check for error conditions that are not really errors at all. > Lada > Andy From randy_presuhn@mindspring.com Wed Nov 18 11:20:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AEB3A6938 for ; Wed, 18 Nov 2009 11:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnthIH-5dlMC for ; Wed, 18 Nov 2009 11:20:55 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id ABE6F3A69C5 for ; Wed, 18 Nov 2009 11:20:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=F5TPCoRWGhsu0Ll7/IR3pJTw9/EIh7nscxiOPWQppN9uPyuMgCslqNxTZWXYS0qz; 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.80] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NAq5F-0000De-KH for netmod@ietf.org; Wed, 18 Nov 2009 14:20:53 -0500 Message-ID: <006b01ca6884$5bc3a280$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <1258538187.23851.19.camel@missotis> <1258546866.23851.38.camel@missotis><4B042794.7@netconfcentral.com><1258565883.23851.155.camel@missotis> <4B04336E.4020702@netconfcentral.com> Date: Wed, 18 Nov 2009 11:21:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f95e89b044db5aaef05045df0fd3bf1d6b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.80 Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:20:56 -0000 Hi - > From: "Andy Bierman" > To: "Ladislav Lhotka" > Cc: "NETMOD Working Group" > Sent: Wednesday, November 18, 2009 9:48 AM > Subject: Re: [netmod] order of children > > Ladislav Lhotka wrote: > > Andy Bierman píše v St 18. 11. 2009 v 08:57 -0800: > > > >> I do not understand why we need any XML ordering CLRs. > >> They exist for the benefit of 2 specific implementations > >> of the parameter to the edit-config operation. > >> > >> IMO, the server MAY require RPC order, or > >> it MAY accept RPC nodes out of order. > >> Same for key leafs within in the PDU. > >> This is better than the current MUST terminology. > >> > >> A server implementation other than the 2 that need > >> this CLR should not be forced to treat out-of-order > >> nodes (according to YANG CLRs) as errors. This violates > >> the Postel Principle. > >> > >> A client needs to be aware that a server MAY treat > >> out-of-YANG-order as an error, and a conservative > >> client will always send in YANG order, since all servers > >> MUST accept that. > > > > So what do you want the spec to state? The order of subelements is > > relevant for both client->server and server->client communication. > > > > I am personally in favor of allowing arbitrary order everywhere but IMO > > the rules must be clear. Saying that clients MAY send children in any > > order and the server MAY treat it as an error doesn't seem very useful. > > > > That isn't what I am suggesting. > > The server MAY reject requests that are not in > the YANG specified order. > > This is much more robust than: > > The server MUST reject requests that are not in > the YANG specified order. > > The only reason we have this CLR is to allow a particular > implementation strategy. Both CLRs allow it, but the MUST > mandates a particular implementation strategy, and that > goes against IETF tradition (and perhaps policy). > If the server can accept XML elements in any order, > then that seems better than forcing it to check for > error conditions that are not really errors at all. When a specification uses a "MUST", it should be because doing otherwise won't work reliably. If servers MAY reject requests that are not in the YANG-specified order, then clients *MUST* send requests in the YANG-specified order to ensure interoperability. The net effect of all this is that even though servers wouldn't be required to enforce ordering, a conformant client would be required to abide by it. If we permit clients to mess with the ordering, while permitting servers to enforce it, interoperability will suffer. Randy From andy@netconfcentral.com Wed Nov 18 12:21:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891883A69D0 for ; Wed, 18 Nov 2009 12:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nstSy0W6aoXh for ; Wed, 18 Nov 2009 12:21:33 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id C0EA23A6A24 for ; Wed, 18 Nov 2009 12:21:33 -0800 (PST) Received: (qmail 45968 invoked from network); 18 Nov 2009 20:21:29 -0000 Received: from adsl-68-120-228-104.dsl.irvnca.pacbell.net (andy@68.120.228.104 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 18 Nov 2009 12:21:28 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: DMOjmr8VM1l21zuIdlsfUA63SpA.PUUAl4.vfoOUWCCI.v3OZ0zcWdT8RZMPyXsIC.RtELRbzTY33uIhIlOhIA1ZtyO67l6xhW4KRZpb2mGSCcUQocDYEBnyMfG2RKR2x.oeR6hzJHcs9mnFon3HwaNqsVDv6yDa.3JCiYtzdHXcCF07mAELTrE0ZSnJHNTpHn8JWGzgDQav8rPsrPnwsEzFfnLgiydcu.eLG.2f_UzdZmDSambu5fHNegOFCQlzKAap1ykCkhUSiB_DmmX1r4KEVlUdkOWVSc8jofFkne2vOAtwMbv8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B045760.6040108@netconfcentral.com> Date: Wed, 18 Nov 2009 12:21:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Randy Presuhn References: <1258538187.23851.19.camel@missotis> <1258546866.23851.38.camel@missotis><4B042794.7@netconfcentral.com><1258565883.23851.155.camel@missotis> <4B04336E.4020702@netconfcentral.com> <006b01ca6884$5bc3a280$6801a8c0@oemcomputer> In-Reply-To: <006b01ca6884$5bc3a280$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 20:21:34 -0000 Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Ladislav Lhotka" >> Cc: "NETMOD Working Group" >> Sent: Wednesday, November 18, 2009 9:48 AM >> Subject: Re: [netmod] order of children >> >> Ladislav Lhotka wrote: >>> Andy Bierman píše v St 18. 11. 2009 v 08:57 -0800: >>> >>>> I do not understand why we need any XML ordering CLRs. >>>> They exist for the benefit of 2 specific implementations >>>> of the parameter to the edit-config operation. >>>> >>>> IMO, the server MAY require RPC order, or >>>> it MAY accept RPC nodes out of order. >>>> Same for key leafs within in the PDU. >>>> This is better than the current MUST terminology. >>>> >>>> A server implementation other than the 2 that need >>>> this CLR should not be forced to treat out-of-order >>>> nodes (according to YANG CLRs) as errors. This violates >>>> the Postel Principle. >>>> >>>> A client needs to be aware that a server MAY treat >>>> out-of-YANG-order as an error, and a conservative >>>> client will always send in YANG order, since all servers >>>> MUST accept that. >>> So what do you want the spec to state? The order of subelements is >>> relevant for both client->server and server->client communication. >>> >>> I am personally in favor of allowing arbitrary order everywhere but IMO >>> the rules must be clear. Saying that clients MAY send children in any >>> order and the server MAY treat it as an error doesn't seem very useful. >>> >> That isn't what I am suggesting. >> >> The server MAY reject requests that are not in >> the YANG specified order. >> >> This is much more robust than: >> >> The server MUST reject requests that are not in >> the YANG specified order. >> >> The only reason we have this CLR is to allow a particular >> implementation strategy. Both CLRs allow it, but the MUST >> mandates a particular implementation strategy, and that >> goes against IETF tradition (and perhaps policy). >> If the server can accept XML elements in any order, >> then that seems better than forcing it to check for >> error conditions that are not really errors at all. > > When a specification uses a "MUST", it should be because doing otherwise > won't work reliably. If servers MAY reject requests that are > not in the YANG-specified order, then clients *MUST* send requests > in the YANG-specified order to ensure interoperability. The net effect > of all this is that even though servers wouldn't be required to enforce > ordering, a conformant client would be required to abide by it. > > If we permit clients to mess with the ordering, while permitting > servers to enforce it, interoperability will suffer. > Be conservative in what you send. Be liberal in what you accept. This has worked out pretty well so far. So what is the CLR? The client MUST send top-level children of the rpc-operation node in exact order, but all children of those nodes may appear in any order? 7 fred barney So a server needs code because it MUST support arbitrary order at XML layer 4+, and also MUST enforce an exact order at XML layer < 4? Is that the CLR the WG wants? I don't understand why this is a MUST requirement in the protocol. > Randy Andy From mbj@tail-f.com Wed Nov 18 12:42:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5531E3A68DA for ; Wed, 18 Nov 2009 12:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+ZTIlGriVFB for ; Wed, 18 Nov 2009 12:42:07 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A61433A69E2 for ; Wed, 18 Nov 2009 12:41:57 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 00A00616001; Wed, 18 Nov 2009 21:41:54 +0100 (CET) Date: Wed, 18 Nov 2009 21:41:54 +0100 (CET) Message-Id: <20091118.214154.165596403.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B045760.6040108@netconfcentral.com> References: <4B04336E.4020702@netconfcentral.com> <006b01ca6884$5bc3a280$6801a8c0@oemcomputer> <4B045760.6040108@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 20:42:08 -0000 Andy Bierman wrote: > So what is the CLR? > The client MUST send top-level children of the rpc-operation > node in exact order, but all children of those nodes > may appear in any order? Can't we stick with the current CLR that in RPCs, all elements are sent in the order defined? The problem is, as Lada pointed out, what to do with (multiply) augmented nodes: rpc foo { input { container x { leaf a { ... } leaf b { ... } } } } augment /foo/input/x { leaf c { ... } } augment /foo/input/x { leaf d { ... } } 'a' and 'b' must be sent in that order, and we could say that any augmented nodes are sent after the other nodes, in any order, so this is ok: ... ... ... ... /martin From randy_presuhn@mindspring.com Wed Nov 18 13:04:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93FDE3A6ACD for ; Wed, 18 Nov 2009 13:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5+l3dbi7vZE for ; Wed, 18 Nov 2009 13:04:13 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 788693A6ACE for ; Wed, 18 Nov 2009 13:04:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FR2BwkGP7NF0WFpGrOFBUGUnbPnSNYM497xeiwO/hm2hIUC6uhnHM3M0xNgtyNVY; 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.80] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NArhD-0002rn-86 for netmod@ietf.org; Wed, 18 Nov 2009 16:04:11 -0500 Message-ID: <00c301ca6892$c9383b60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <1258538187.23851.19.camel@missotis> <1258546866.23851.38.camel@missotis><4B042794.7@netconfcentral.com><1258565883.23851.155.camel@missotis> <4B04336E.4020702@netconfcentral.com> <006b01ca6884$5bc3a280$6801a8c0@oemcomputer> <4B045760.6040108@netconfcentral.com> Date: Wed, 18 Nov 2009 13:04:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9017972899907e3090d11f97e3fb27372350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.80 Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:04:14 -0000 Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: "NETMOD Working Group" > Sent: Wednesday, November 18, 2009 12:21 PM > Subject: Re: [netmod] order of children ... > Be conservative in what you send. > Be liberal in what you accept. > This has worked out pretty well so far. We agree on this. This is the principal that effectively turns a server's "MAY" ("liberal in what you accept") into a client's "MUST" ("conservative in what you send") if interoperability is to be maintained. If the WG believes there is value in permitting, but not requiring, server implementations to ignore ordering here, then the logical consequence of that decision is to REQUIRE that clients to send only ordered stuff. I'm not saying that I like this. Options and flexibility come at a cost, and should provide commensurate benefits. Presumably the WG has concluded that some benefit is provided by permitting servers to accept "disordered" requests, even though a robust client should never send them if it is going to interoperate with servers that *do* happen to enforce the order. Randy From phil@juniper.net Wed Nov 18 13:06:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DB13A6ACD for ; Wed, 18 Nov 2009 13:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaTeHvqc1mQ2 for ; Wed, 18 Nov 2009 13:06:23 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 525013A68DA for ; Wed, 18 Nov 2009 13:06:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSwRhylEl3H97ZFxxats6VLyjLR3yO3y5@postini.com; Wed, 18 Nov 2009 13:06:21 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Wed, 18 Nov 2009 13:00:30 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:00:30 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:00:30 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:00:29 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAIL0Hj66768; Wed, 18 Nov 2009 13:00:28 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nAIKksKR055449; Wed, 18 Nov 2009 20:46:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911182046.nAIKksKR055449@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091118.214154.165596403.mbj@tail-f.com> Date: Wed, 18 Nov 2009 15:46:53 -0500 From: Phil Shafer X-OriginalArrivalTime: 18 Nov 2009 21:00:29.0842 (UTC) FILETIME=[29270F20:01CA6892] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:06:24 -0000 Martin Bjorklund writes: >Can't we stick with the current CLR that in RPCs, all elements are >sent in the order defined? Isn't that a CLR? What is the benefit from enforcing this? IMHO the only ordering with a benefit is the "keys first" one, since this means buffering is not required. Beyond that, is there a strong reason that order should matter? Thanks, Phil From mbj@tail-f.com Wed Nov 18 13:13:36 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B2E3A6989 for ; Wed, 18 Nov 2009 13:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbLWYM9BxOlK for ; Wed, 18 Nov 2009 13:13:35 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8DF463A68DA for ; Wed, 18 Nov 2009 13:13:34 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 87E59616001; Wed, 18 Nov 2009 22:13:32 +0100 (CET) Date: Wed, 18 Nov 2009 22:13:32 +0100 (CET) Message-Id: <20091118.221332.136206088.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200911182046.nAIKksKR055449@idle.juniper.net> References: <20091118.214154.165596403.mbj@tail-f.com> <200911182046.nAIKksKR055449@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:13:36 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >Can't we stick with the current CLR that in RPCs, all elements are > >sent in the order defined? > > Isn't that a CLR? What is the benefit from enforcing this? IMHO > the only ordering with a benefit is the "keys first" one, since > this means buffering is not required. Beyond that, is there a > strong reason that order should matter? There is a buffering issue in copy-config with inline config. If you send the target *after* the inline config, the server has to buffer the entire config before it knows which datastore it will go to. /martin From phil@juniper.net Wed Nov 18 14:53:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36B43A6ADE for ; Wed, 18 Nov 2009 14:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuWqdYE0R8Kj for ; Wed, 18 Nov 2009 14:53:32 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 2633F3A6AC8 for ; Wed, 18 Nov 2009 14:53:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSwR65nppiHegkUEzviUf+qjdI3Ry6YzK@postini.com; Wed, 18 Nov 2009 14:53:30 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Wed, 18 Nov 2009 14:50:28 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 14:50:28 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 14:50:27 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 14:50:27 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAIMoNj16294; Wed, 18 Nov 2009 14:50:23 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nAIMaxdW067565; Wed, 18 Nov 2009 22:37:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911182237.nAIMaxdW067565@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091118.221332.136206088.mbj@tail-f.com> Date: Wed, 18 Nov 2009 17:36:59 -0500 From: Phil Shafer X-OriginalArrivalTime: 18 Nov 2009 22:50:27.0035 (UTC) FILETIME=[8562D2B0:01CA68A1] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 22:53:32 -0000 Martin Bjorklund writes: >There is a buffering issue in copy-config with inline config. If you >send the target *after* the inline config, the server has to buffer >the entire config before it knows which datastore it will go to. Ah, cool. Then I'm fine w/ ordering rpc elements. Thanks, Phil From andy@netconfcentral.com Wed Nov 18 16:22:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0935C3A6886 for ; Wed, 18 Nov 2009 16:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCAIn4yymjmM for ; Wed, 18 Nov 2009 16:22:13 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 51F9D3A67F0 for ; Wed, 18 Nov 2009 16:22:13 -0800 (PST) Received: (qmail 42987 invoked from network); 19 Nov 2009 00:22:08 -0000 Received: from adsl-68-120-228-104.dsl.irvnca.pacbell.net (andy@68.120.228.104 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 18 Nov 2009 16:22:07 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: YCquk3EVM1k3PmjTcIP.Jg.Vt94ZqxOnIjSwkmpl7Q.6w2rN1xKCvH2OTLL2DNFX8ua77EPdIsKunN2_xwxAA1Z9naTv5htRbujz27ye4T6MMyC2Si4pFCVpG.aOcQt.B2a0IbalEEJoW0FUbPc979v8yQkkKRYAbKwkY6Cf87my98LNz6wQ8gkrkTGTM6EVuC4x2QDcpETCXhQyJxwy4.E16zHC6ocjz9cOMXoFAdoha6VCzLOjlQE1WBAS9N8e37kcBUXgIClWzgbUuZkR25G9auDR1.k6JVOq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B048FC9.8000805@netconfcentral.com> Date: Wed, 18 Nov 2009 16:22:33 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091118.214154.165596403.mbj@tail-f.com> <200911182046.nAIKksKR055449@idle.juniper.net> <20091118.221332.136206088.mbj@tail-f.com> In-Reply-To: <20091118.221332.136206088.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 00:22:14 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> Can't we stick with the current CLR that in RPCs, all elements are >>> sent in the order defined? >> Isn't that a CLR? What is the benefit from enforcing this? IMHO >> the only ordering with a benefit is the "keys first" one, since >> this means buffering is not required. Beyond that, is there a >> strong reason that order should matter? > > There is a buffering issue in copy-config with inline config. If you > send the target *after* the inline config, the server has to buffer > the entire config before it knows which datastore it will go to. > I think the CLR is under-specified, and at the same time, it is over-reaching. As written, it seems to say that all descendant nodes of the rpc-operation are ordered. The contents of the node in edit-config/copy-config is an exception because it is type anyxml. This is where the CLR really falls apart. The server is expected to check for ordering within the anyxml node and make sure keys are first, etc., even though the YANG definition of the config node is an opaque 'anyxml' subtree. Augmenting nodes are unordered because the order depends on lots of implementation details. Top-level nodes contained in submodules are also implementation ordered. > > /martin > Andy From lhotka@cesnet.cz Wed Nov 18 23:07:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CBA3A689C for ; Wed, 18 Nov 2009 23:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV6cW8FHd3Fm for ; Wed, 18 Nov 2009 23:07:08 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A86893A67B8 for ; Wed, 18 Nov 2009 23:06:40 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5D709D800C0; Thu, 19 Nov 2009 08:06:38 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091118.214154.165596403.mbj@tail-f.com> References: <4B04336E.4020702@netconfcentral.com> <006b01ca6884$5bc3a280$6801a8c0@oemcomputer> <4B045760.6040108@netconfcentral.com> <20091118.214154.165596403.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 19 Nov 2009 08:06:36 +0100 Message-Id: <1258614397.17907.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 07:07:09 -0000 Martin Bjorklund píše v St 18. 11. 2009 v 21:41 +0100: > > rpc foo { > input { > container x { > leaf a { ... } > leaf b { ... } > } > } > } > > augment /foo/input/x { > leaf c { ... } > } > > augment /foo/input/x { > leaf d { ... } > } > > > 'a' and 'b' must be sent in that order, and we could say that any > augmented nodes are sent after the other nodes, in any order, so this > is ok: Looks good. How about the other issue - interleaving list items with other sibling elements? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Nov 18 23:42:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42173A694E for ; Wed, 18 Nov 2009 23:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RmCjJerC+Nl for ; Wed, 18 Nov 2009 23:42:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 184283A67EF for ; Wed, 18 Nov 2009 23:42:59 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CC30D616001; Thu, 19 Nov 2009 08:42:55 +0100 (CET) Date: Thu, 19 Nov 2009 08:42:55 +0100 (CET) Message-Id: <20091119.084255.170155006.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B048FC9.8000805@netconfcentral.com> References: <200911182046.nAIKksKR055449@idle.juniper.net> <20091118.221332.136206088.mbj@tail-f.com> <4B048FC9.8000805@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 07:43:00 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Phil Shafer wrote: > >> Martin Bjorklund writes: > >>> Can't we stick with the current CLR that in RPCs, all elements are > >>> sent in the order defined? > >> Isn't that a CLR? What is the benefit from enforcing this? IMHO > >> the only ordering with a benefit is the "keys first" one, since > >> this means buffering is not required. Beyond that, is there a > >> strong reason that order should matter? > > > > There is a buffering issue in copy-config with inline config. If you > > send the target *after* the inline config, the server has to buffer > > the entire config before it knows which datastore it will go to. > > > > I think the CLR is under-specified, and at the same time, > it is over-reaching. > > As written, it seems to say that all descendant nodes > of the rpc-operation are ordered. Yes. > The contents of > the node in edit-config/copy-config > is an exception because it is type anyxml. Yes. > This is where the CLR really falls apart. I disagree. The draft doesn't say anything about order within anyxml (obvsiously; since it is opaque). If all YANG did was to specify rpcs we would be done here. But YANG goes further, and specifies the contents of the data stores. This content has additional requirements on keys and ordering, and the server is expected to check for this. /martin From mbj@tail-f.com Wed Nov 18 23:49:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C250A3A6A31 for ; Wed, 18 Nov 2009 23:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci3k-yyMLRDz for ; Wed, 18 Nov 2009 23:49:14 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E3DE83A6A67 for ; Wed, 18 Nov 2009 23:49:13 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AB4D8616001; Thu, 19 Nov 2009 08:49:11 +0100 (CET) Date: Thu, 19 Nov 2009 08:49:11 +0100 (CET) Message-Id: <20091119.084911.171432518.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1258614397.17907.5.camel@missotis> References: <4B045760.6040108@netconfcentral.com> <20091118.214154.165596403.mbj@tail-f.com> <1258614397.17907.5.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 07:49:14 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAxOC4gMTEuIDIwMDkgdiAyMTo0MSArMDEwMDoNCj4gPiANCj4gPiAg IHJwYyBmb28gew0KPiA+ICAgICBpbnB1dCB7DQo+ID4gICAgICAgY29udGFpbmVyIHggew0KPiA+ ICAgICAgICAgbGVhZiBhIHsgLi4uIH0NCj4gPiAgICAgICAgIGxlYWYgYiB7IC4uLiB9DQo+ID4g ICAgICAgfQ0KPiA+ICAgICB9DQo+ID4gICB9DQo+ID4gDQo+ID4gICBhdWdtZW50IC9mb28vaW5w dXQveCB7DQo+ID4gICAgIGxlYWYgYyB7IC4uLiB9DQo+ID4gICB9DQo+ID4gDQo+ID4gICBhdWdt ZW50IC9mb28vaW5wdXQveCB7DQo+ID4gICAgIGxlYWYgZCB7IC4uLiB9DQo+ID4gICB9DQo+ID4g DQo+ID4gDQo+ID4gJ2EnIGFuZCAnYicgbXVzdCBiZSBzZW50IGluIHRoYXQgb3JkZXIsIGFuZCB3 ZSBjb3VsZCBzYXkgdGhhdCBhbnkNCj4gPiBhdWdtZW50ZWQgbm9kZXMgYXJlIHNlbnQgYWZ0ZXIg dGhlIG90aGVyIG5vZGVzLCBpbiBhbnkgb3JkZXIsIHNvIHRoaXMNCj4gPiBpcyBvazoNCj4gDQo+ IExvb2tzIGdvb2QuIEhvdyBhYm91dCB0aGUgb3RoZXIgaXNzdWUgLSBpbnRlcmxlYXZpbmcgbGlz dCBpdGVtcyB3aXRoDQo+IG90aGVyIHNpYmxpbmcgZWxlbWVudHM/DQoNCkkgdGhpbmsgd2UgZGlz Y3Vzc2VkIHRoaXMgYXQgc29tZSBwb2ludCAoc2VlIHRoZSB0aHJlYWQgc3RhcnRpbmcgYXQNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cwMTg2 Ny5odG1sKS4NCg0KSSdtIGZpbmUgZWl0aGVyIHdheS4gIEN1cnJlbnRseSB0aGVyZSBpcyBubyB0 ZXh0IHRoYXQgc2F5cyB0aGF0IHlvdQ0KY2Fubm90IGludGVybGVhdmUgKGxlYWYtKWxpc3QgZW50 cmllcyB3aXRoIG90aGVyIHNpYmxpbmdzLg0KDQoNCi9tYXJ0aW4NCg== From lhotka@cesnet.cz Thu Nov 19 00:31:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5C33A6A3B for ; Thu, 19 Nov 2009 00:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFdQqeQLi4Hl for ; Thu, 19 Nov 2009 00:31:52 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AF6273A67EF for ; Thu, 19 Nov 2009 00:31:38 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 447FCD800C0; Thu, 19 Nov 2009 09:31:36 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091119.084911.171432518.mbj@tail-f.com> References: <4B045760.6040108@netconfcentral.com> <20091118.214154.165596403.mbj@tail-f.com> <1258614397.17907.5.camel@missotis> <20091119.084911.171432518.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 19 Nov 2009 09:31:35 +0100 Message-Id: <1258619495.17907.37.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 08:31:53 -0000 Martin Bjorklund píše v ÄŒt 19. 11. 2009 v 08:49 +0100: > > > > Looks good. How about the other issue - interleaving list items with > > other sibling elements? > > I think we discussed this at some point (see the thread starting at > http://www.ietf.org/mail-archive/web/netmod/current/msg01867.html). > > I'm fine either way. Currently there is no text that says that you > cannot interleave (leaf-)list entries with other siblings. OK, do we all agree that interleaving is allowed? If so, it should be explicitly noted in sections 7.7.6 and 7.8.5, otherwise some implementors may be taken by surprise. Something like this can be added as the second paragraph in both sections: The elements representing list items MUST appear in the order specified by the user if the (leaf-)list is "ordered-by user", otherwise the order is implementation-dependent. In both cases, the elements representing list items MAY be interleaved with other sibling elements. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Nov 19 00:46:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF53428C15E for ; Thu, 19 Nov 2009 00:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzkmnJFWDu1S for ; Thu, 19 Nov 2009 00:46:01 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B932E28C12F for ; Thu, 19 Nov 2009 00:46:01 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 98DD1D800CC; Thu, 19 Nov 2009 09:45:59 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091119.084911.171432518.mbj@tail-f.com> References: <4B045760.6040108@netconfcentral.com> <20091118.214154.165596403.mbj@tail-f.com> <1258614397.17907.5.camel@missotis> <20091119.084911.171432518.mbj@tail-f.com> Content-Type: text/plain Organization: CESNET Date: Thu, 19 Nov 2009 09:45:58 +0100 Message-Id: <1258620358.17907.50.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: [netmod] persistence of element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 08:46:02 -0000 Hi, > http://www.ietf.org/mail-archive/web/netmod/current/msg01867.html). > Another issue that was discussed in this thread and that is perhaps worth mentioning in the YANG spec (or NETCONF?) is the persistence of element order, namely: 1. If the client does a copy-config and then retrieves the same datastore, the order of elements MAY be different. 2. If the same get(-config) operation is performed twice on the same datastore with the same contents, the order of elements MUST be identical. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Nov 19 04:15:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCED53A6B21 for ; Thu, 19 Nov 2009 04:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1io8Xli5NtT for ; Thu, 19 Nov 2009 04:15:53 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 099CD3A6B30 for ; Thu, 19 Nov 2009 04:15:52 -0800 (PST) Received: (qmail 53479 invoked from network); 19 Nov 2009 12:15:49 -0000 Received: from adsl-68-120-71-246.dsl.irvnca.pacbell.net (andy@68.120.71.246 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 19 Nov 2009 04:15:49 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: oRX4rbsVM1kY.J7pXRZsR4g6xKGn45dLn9BfwmIS8VqZxG3R1WON.VRutO6.eZrEzo0VnWdHaG5BhO_zQYpJ_arp2.hboWGbpjJn7GTrXtCJffreEkCHCi1TJd_jkmbRokAMZbOwfLuuBdgSUsqfEbkQ0nNSkVUSMDahepfNY.sicfYmp0hIdUmmroKRuuBlt__vXRvK5h0gnhbA7lKO2pbV67MRZFd7Y9sv.qWVYv1OmWKNtBuSh7CLHibq.qbAHV3a9AMvK6QJiuPbt85xcIRaCtroXE882Qii X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B053696.1070801@netconfcentral.com> Date: Thu, 19 Nov 2009 04:14:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200911182046.nAIKksKR055449@idle.juniper.net> <20091118.221332.136206088.mbj@tail-f.com> <4B048FC9.8000805@netconfcentral.com> <20091119.084255.170155006.mbj@tail-f.com> In-Reply-To: <20091119.084255.170155006.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:15:53 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Phil Shafer wrote: >>>> Martin Bjorklund writes: >>>>> Can't we stick with the current CLR that in RPCs, all elements are >>>>> sent in the order defined? >>>> Isn't that a CLR? What is the benefit from enforcing this? IMHO >>>> the only ordering with a benefit is the "keys first" one, since >>>> this means buffering is not required. Beyond that, is there a >>>> strong reason that order should matter? >>> There is a buffering issue in copy-config with inline config. If you >>> send the target *after* the inline config, the server has to buffer >>> the entire config before it knows which datastore it will go to. >>> >> I think the CLR is under-specified, and at the same time, >> it is over-reaching. >> >> As written, it seems to say that all descendant nodes >> of the rpc-operation are ordered. > > Yes. > >> The contents of >> the node in edit-config/copy-config >> is an exception because it is type anyxml. > > Yes. > >> This is where the CLR really falls apart. > > I disagree. The draft doesn't say anything about order within anyxml > (obvsiously; since it is opaque). If all YANG did was to specify rpcs > we would be done here. But YANG goes further, and specifies the > contents of the data stores. This content has additional requirements > on keys and ordering, and the server is expected to check for this. > There is no basis in XML for these hacks. They are just CLRs specific to YANG. YANG does not specify any order within an anyxml node. There is only hand-waving that get you from anyxml to an ordered database. As you pointed out, the standard ignores how an opaque XML blob is recognized as specific YANG database subtrees. Yet you want CLRs on the order of arbitrary sub-trees within an arbitrary XML blob. This is a new class of CLR. How are you going to specify the CLR precisely enough so it can be implemented consistently? Are you going to say that anyxml nodes named 'config' and 'data' are special in YANG? What criteria does an implementor use to determine that a particular anyxml blob is really the top-level root of a YANG database? > > > /martin > Andy From mbj@tail-f.com Thu Nov 19 04:32:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28303A6B19 for ; Thu, 19 Nov 2009 04:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqUhlwDTepjM for ; Thu, 19 Nov 2009 04:32:12 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C6B243A6A98 for ; Thu, 19 Nov 2009 04:32:02 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EDFFE616001; Thu, 19 Nov 2009 13:31:59 +0100 (CET) Date: Thu, 19 Nov 2009 13:31:59 +0100 (CET) Message-Id: <20091119.133159.24823194.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B053696.1070801@netconfcentral.com> References: <4B048FC9.8000805@netconfcentral.com> <20091119.084255.170155006.mbj@tail-f.com> <4B053696.1070801@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:32:12 -0000 Andy Bierman wrote: > Yet you want CLRs on the order of arbitrary sub-trees > within an arbitrary XML blob. No. I never said that. /martin From andy@netconfcentral.com Thu Nov 19 05:24:25 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9713A6B44 for ; Thu, 19 Nov 2009 05:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqfRIzrbDDD8 for ; Thu, 19 Nov 2009 05:24:24 -0800 (PST) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 6775F3A6B3D for ; Thu, 19 Nov 2009 05:24:24 -0800 (PST) Received: (qmail 15894 invoked from network); 19 Nov 2009 13:24:15 -0000 Received: from adsl-68-120-71-246.dsl.irvnca.pacbell.net (andy@68.120.71.246 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 19 Nov 2009 05:24:14 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: YWUPS68VM1kaANGuQh3GbW7vrSq88hlEMV2T1CRSqJCpOZ1goL.vQ_V38beIvmDRdjsFQUOx_xgHYcR34Mc8N4TP24ekGX0ap9f0yout_d25g0VkHMwiIH_e6wsAAC.fHgYEkeAxJPDEy_Z_QruMvzfbFBHqD8bdlJn46t3WLItPZjAqPd.CSfJwIsj7Bkibn7kyCckzEuLJQ9an4_krXeh5S7Stb_zyzhgqitBLFZ_upqBcgd2ABwL2suAJwfY0APFlx9Wf0KpTrmp5D68isUC1vv8c9P1QkGBGc4Nh98KF9GuyOKj5lblYSG3_Vw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B05471B.1070801@netconfcentral.com> Date: Thu, 19 Nov 2009 05:24:43 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B048FC9.8000805@netconfcentral.com> <20091119.084255.170155006.mbj@tail-f.com> <4B053696.1070801@netconfcentral.com> <20091119.133159.24823194.mbj@tail-f.com> In-Reply-To: <20091119.133159.24823194.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:24:25 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Yet you want CLRs on the order of arbitrary sub-trees >> within an arbitrary XML blob. > > No. I never said that. > How does the 'keys first' rule apply to a node nested within an 'anyxml'? In order to do that, the server must ignore the rules for anyxml and decide 'this XML blob is a list'. > > /martin > Andy From mbj@tail-f.com Thu Nov 19 05:31:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D927128C0E3 for ; Thu, 19 Nov 2009 05:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0VDfzg8upj2 for ; Thu, 19 Nov 2009 05:31:51 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E5D183A6B2F for ; Thu, 19 Nov 2009 05:31:50 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A55C616001; Thu, 19 Nov 2009 14:31:48 +0100 (CET) Date: Thu, 19 Nov 2009 14:31:48 +0100 (CET) Message-Id: <20091119.143148.63518283.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B05471B.1070801@netconfcentral.com> References: <4B053696.1070801@netconfcentral.com> <20091119.133159.24823194.mbj@tail-f.com> <4B05471B.1070801@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:31:52 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Yet you want CLRs on the order of arbitrary sub-trees > >> within an arbitrary XML blob. > > > > No. I never said that. > > > > How does the 'keys first' rule apply to a > node nested within an 'anyxml'? In order to do that, > the server must ignore the rules for anyxml > and decide 'this XML blob is a list'. Yes, the server treats the anyxml in edit-config different than other anyxml. Ordering is just one aspect. But it also checks the structure and type of leafs etc. The whole point of YANG is to describe the contents of the data store, so the server better have special handling for this anyxml. /martin From andy@netconfcentral.com Thu Nov 19 06:06:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BEB3A6969 for ; Thu, 19 Nov 2009 06:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZsvOFoKqQjH for ; Thu, 19 Nov 2009 06:06:14 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id BC12B3A6930 for ; Thu, 19 Nov 2009 06:06:14 -0800 (PST) Received: (qmail 6300 invoked from network); 19 Nov 2009 14:06:09 -0000 Received: from adsl-68-120-71-246.dsl.irvnca.pacbell.net (andy@68.120.71.246 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 19 Nov 2009 06:06:09 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: MSl7fUYVM1l7QVHrs7jEty1VJu4OCkJZl9p6JSrBEBXEEsRxDI1HPd8XWCjudq0OM9zHoX6vRKIWX1lcdH2TwLPpX7AGZP_CvSG7DQsNn2PIjVmbXaCsWk9CcE_uAitW4Z7pTaoCukjbe4XxAp6Lf4Ug8uQDEl4eVjqdFMYgAG3uByhnnIwbTGeq1FCVO.BaFbFtK.7NgkEcxiiXfIMnWrw0OFqYHgV_mUl0surEPfOuB2o1AZUsMAe65kF.Ww3PTcvo6fzX6mggvvdxsp6p51G5uj7Cc3WGEJI0cv0WVWZpSCtHCPAv4Al2.mvQAcsIXUVUZftQ1RLADAI3jtV5pff0tKtJt.lLYNSX1AhervdwdGElx7boPFy4cFgcavwDpZ9Xqcyc_hQ4CGtRWPb3WhpitzNklixw9dAvefjZdgM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0550ED.1000104@netconfcentral.com> Date: Thu, 19 Nov 2009 06:06:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B053696.1070801@netconfcentral.com> <20091119.133159.24823194.mbj@tail-f.com> <4B05471B.1070801@netconfcentral.com> <20091119.143148.63518283.mbj@tail-f.com> In-Reply-To: <20091119.143148.63518283.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:06:15 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Yet you want CLRs on the order of arbitrary sub-trees >>>> within an arbitrary XML blob. >>> No. I never said that. >>> >> How does the 'keys first' rule apply to a >> node nested within an 'anyxml'? In order to do that, >> the server must ignore the rules for anyxml >> and decide 'this XML blob is a list'. > > Yes, the server treats the anyxml in edit-config different than other > anyxml. Ordering is just one aspect. But it also checks the > structure and type of leafs etc. The whole point of YANG is to > describe the contents of the data store, so the server better have > special handling for this anyxml. > > I use an extension called ncx:root to deal with this problem, instead of hardwiring the QName of the special node. http://www.netconfcentral.org/modules/ncx/2009-06-12#root.455 I don't think the draft makes it clear that some special mechanism is needed to override YANG anyxml semantics. It seems to me the DSDL mapping will not make it clear to applications that a node in an rpc/input is supposed to be a config root, and therefore the only valid child nodes are top-level YANG module nodes advertised by the server. How does an application know that an anyxml blob called really is just an XML blob, but another one called is expected to be structured as a config root? (A: description-stmt, if any) > /martin > Andy From mbj@tail-f.com Thu Nov 19 06:09:41 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1F03A69DE for ; Thu, 19 Nov 2009 06:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKnQYopyMtzq for ; Thu, 19 Nov 2009 06:09:40 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B0CBB3A68AF for ; Thu, 19 Nov 2009 06:09:40 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B29EB616001; Thu, 19 Nov 2009 15:09:37 +0100 (CET) Date: Thu, 19 Nov 2009 15:09:37 +0100 (CET) Message-Id: <20091119.150937.222841285.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B0550ED.1000104@netconfcentral.com> References: <4B05471B.1070801@netconfcentral.com> <20091119.143148.63518283.mbj@tail-f.com> <4B0550ED.1000104@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:09:41 -0000 Andy Bierman wrote: > How does an application know that an anyxml blob called > really is just an XML blob, but another one called > is expected to be structured as a config root? > (A: description-stmt, if any) Yes, if any. The YANG draft already talks about how data nodes can be modified with edit-config. /martin From lhotka@cesnet.cz Thu Nov 19 08:47:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2627F3A692B for ; Thu, 19 Nov 2009 08:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtUoDTkmKwvz for ; Thu, 19 Nov 2009 08:47:42 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3DCF83A6781 for ; Thu, 19 Nov 2009 08:47:42 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 68755D800C0; Thu, 19 Nov 2009 17:47:39 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B048FC9.8000805@netconfcentral.com> References: <20091118.214154.165596403.mbj@tail-f.com> <200911182046.nAIKksKR055449@idle.juniper.net> <20091118.221332.136206088.mbj@tail-f.com> <4B048FC9.8000805@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 19 Nov 2009 17:47:37 +0100 Message-Id: <1258649257.17907.74.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:47:43 -0000 Andy Bierman píše v St 18. 11. 2009 v 16:22 -0800: > Martin Bjorklund wrote: > > Phil Shafer wrote: > >> Martin Bjorklund writes: > >>> Can't we stick with the current CLR that in RPCs, all elements are > >>> sent in the order defined? > >> Isn't that a CLR? What is the benefit from enforcing this? IMHO > >> the only ordering with a benefit is the "keys first" one, since > >> this means buffering is not required. Beyond that, is there a > >> strong reason that order should matter? > > > > There is a buffering issue in copy-config with inline config. If you > > send the target *after* the inline config, the server has to buffer > > the entire config before it knows which datastore it will go to. > > > > I think the CLR is under-specified, and at the same time, > it is over-reaching. > > As written, it seems to say that all descendant nodes > of the rpc-operation are ordered. The contents of > the node in edit-config/copy-config > is an exception because it is type anyxml. > > This is where the CLR really falls apart. > The server is expected to check for ordering > within the anyxml node and make sure keys are first, etc., > even though the YANG definition of the config node > is an opaque 'anyxml' subtree. I understand this 'anyxml' as a placeholder for the content layer to step in and define the structure of this blob. It is pretty much like the layering of network protocols: for IP, everything after byte 20 is opaque data, but TCP/UDP then provides more structure. Lada > > Augmenting nodes are unordered because the order depends > on lots of implementation details. Top-level > nodes contained in submodules are also implementation ordered. > > > > > /martin > > > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Nov 19 09:40:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077D43A68B3 for ; Thu, 19 Nov 2009 09:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn7LEMCdo6Yt for ; Thu, 19 Nov 2009 09:40:13 -0800 (PST) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 266A63A6844 for ; Thu, 19 Nov 2009 09:40:13 -0800 (PST) Received: (qmail 60760 invoked from network); 19 Nov 2009 17:40:08 -0000 Received: from ppp-67-126-131-72.dsl.irvnca.pacbell.net (andy@67.126.131.72 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 19 Nov 2009 09:40:07 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 3o8AvmcVM1kjGfttn2nuCBxHF_c86GB5TuV4kOtLnYjzsJAvmes1JXsszcdW.sylbn6le8ksjZ8kNmw_gukawB1Rw6ytxCOBbgBa2rw7p7R3UJi8ukvtoGeyLHf6robms1px_tr8XdLdsnM7K3A9RYjETRSbBCsYUf8869FGwjRr.KaPRnlAdLGHQnPb6ONkt4P8XECbPTC9NreYOASlMJAxImEMQktizFFLSQqS3EhQx8skBZp3W7RRSR4RsNnd1GTTcvnTByvkvRaszLMKuwaoI60wdmaQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0582F6.4060305@netconfcentral.com> Date: Thu, 19 Nov 2009 09:40:06 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <20091118.214154.165596403.mbj@tail-f.com> <200911182046.nAIKksKR055449@idle.juniper.net> <20091118.221332.136206088.mbj@tail-f.com> <4B048FC9.8000805@netconfcentral.com> <1258649257.17907.74.camel@missotis> In-Reply-To: <1258649257.17907.74.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:40:14 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 18. 11. 2009 v 16:22 -0800: >> Martin Bjorklund wrote: >>> Phil Shafer wrote: >>>> Martin Bjorklund writes: >>>>> Can't we stick with the current CLR that in RPCs, all elements are >>>>> sent in the order defined? >>>> Isn't that a CLR? What is the benefit from enforcing this? IMHO >>>> the only ordering with a benefit is the "keys first" one, since >>>> this means buffering is not required. Beyond that, is there a >>>> strong reason that order should matter? >>> There is a buffering issue in copy-config with inline config. If you >>> send the target *after* the inline config, the server has to buffer >>> the entire config before it knows which datastore it will go to. >>> >> I think the CLR is under-specified, and at the same time, >> it is over-reaching. >> >> As written, it seems to say that all descendant nodes >> of the rpc-operation are ordered. The contents of >> the node in edit-config/copy-config >> is an exception because it is type anyxml. >> >> This is where the CLR really falls apart. >> The server is expected to check for ordering >> within the anyxml node and make sure keys are first, etc., >> even though the YANG definition of the config node >> is an opaque 'anyxml' subtree. > > I understand this 'anyxml' as a placeholder for the content layer to > step in and define the structure of this blob. It is pretty much like > the layering of network protocols: for IP, everything after byte 20 is > opaque data, but TCP/UDP then provides more structure. > I think YANG leans the other way -- saying that a server does not have to support must/when 'inside' an anyxml node. Maybe the placeholder/layering text like your paragraph above needs to be added to the section on anyxml > Lada > Andy >> Augmenting nodes are unordered because the order depends >> on lots of implementation details. Top-level >> nodes contained in submodules are also implementation ordered. >> >>> /martin >>> >> >> Andy >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From randy_presuhn@mindspring.com Thu Nov 19 11:11:25 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137F728C10F for ; Thu, 19 Nov 2009 11:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMePb6CxNcBj for ; Thu, 19 Nov 2009 11:11:14 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 7A1A03A6876 for ; Thu, 19 Nov 2009 11:11:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sE3RsYXTM9SmmfEVQkoAKc9a+ffCYOZ19KJ5whg9nHFfFnifEiqBekw0dkMnWIhE; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.51.11] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NBCPM-0007Mh-PI for netmod@ietf.org; Thu, 19 Nov 2009 14:11:09 -0500 Message-ID: <004501ca694c$2a4cfd00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4B045760.6040108@netconfcentral.com><20091118.214154.165596403.mbj@tail-f.com><1258614397.17907.5.camel@missotis><20091119.084911.171432518.mbj@tail-f.com> <1258620358.17907.50.camel@missotis> Date: Thu, 19 Nov 2009 11:11:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f94b5db645ec47d8cbb4b48a1a37312f7e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.51.11 Subject: Re: [netmod] persistence of element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:11:25 -0000 Hi - > From: "Ladislav Lhotka" > To: "Martin Bjorklund" > Cc: > Sent: Thursday, November 19, 2009 12:45 AM > Subject: [netmod] persistence of element order ... > > http://www.ietf.org/mail-archive/web/netmod/current/msg01867.html). > > > > Another issue that was discussed in this thread and that is perhaps > worth mentioning in the YANG spec (or NETCONF?) is the persistence of > element order, namely: > > 1. If the client does a copy-config and then retrieves the same > datastore, the order of elements MAY be different. > > 2. If the same get(-config) operation is performed twice on the same > datastore with the same contents, the order of elements MUST be > identical. Be careful what you ask for. :-) This hinges on what you mean by "the same contents". Consider the case of a system with three datastores I'll call A, B, C for simplicity. B and C are "the same" in that they have exactly the same information, differing only in the order of some non-ordered elements, due to the way in which they were created. Client X does a copy-config B->A. Client X does a get of A, and gets something that looks exactly like B. Client Y does a copy-config C-> A. Client Y does a get of A and gets something that looks exactly like C. So far, everyone is happy, and someone observing both conversations will say the implementation didn't exercise the "MAY" in (1) above. Now client X does another get of A. If (2) above is to be honored, the server is in trouble. Randy From kwatsen@juniper.net Thu Nov 19 13:11:57 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A9228C0E4 for ; Thu, 19 Nov 2009 13:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTcAzossk9qX for ; Thu, 19 Nov 2009 13:11:51 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 0EAC53A6897 for ; Thu, 19 Nov 2009 13:11:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSwW0jB9MUNkYjG22PwmcBDnR8zCtCXOg@postini.com; Thu, 19 Nov 2009 13:11:45 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 19 Nov 2009 13:10:16 -0800 From: Kent Watsen To: 'Ladislav Lhotka' , Andy Bierman Date: Thu, 19 Nov 2009 13:10:15 -0800 Thread-Topic: [netmod] order of children Thread-Index: AcppOAPTiZWak2asRsq8pO9+hcZOgQAI5noQ Message-ID: <84600D05C20FF943918238042D7670FD3680124DF1@EMBX01-HQ.jnpr.net> References: <20091118.214154.165596403.mbj@tail-f.com> <200911182046.nAIKksKR055449@idle.juniper.net> <20091118.221332.136206088.mbj@tail-f.com> <4B048FC9.8000805@netconfcentral.com> <1258649257.17907.74.camel@missotis> In-Reply-To: <1258649257.17907.74.camel@missotis> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:11:57 -0000 > I understand this 'anyxml' as a placeholder for the content layer to > step in and define the structure of this blob. It is pretty much like > the layering of network protocols: for IP, everything after byte 20 is > opaque data, but TCP/UDP then provides more structure. This won't always be the case. For instance, JUNOS uses some anyxml nodes = for undocumented/hidden features. Only customers with explicit knowledge o= f the feature are able to configure it. In this case, the application is n= ever provided the schema to understand the blob. Maybe the solution here is to let the data-model define if order matters - = like the difference between xs:sequence and xs:all... Kent From Washam.Fan@huaweisymantec.com Thu Nov 19 17:56:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3723A6A10 for ; Thu, 19 Nov 2009 17:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSVIHwstGcoG for ; Thu, 19 Nov 2009 17:56:03 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 8861D3A6A0C for ; Thu, 19 Nov 2009 17:56:03 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTD00BBGXD23Q30@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 20 Nov 2009 09:55:51 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTD00AUOXD2MZ00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 20 Nov 2009 09:55:50 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 20 Nov 2009 09:55:50 +0800 From: WashamFan To: Randy Presuhn Message-id: Date: Fri, 20 Nov 2009 09:55:50 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <004501ca694c$2a4cfd00$6801a8c0@oemcomputer> References: <4B045760.6040108@netconfcentral.com> <20091118.214154.165596403.mbj@tail-f.com> <1258614397.17907.5.camel@missotis> <20091119.084911.171432518.mbj@tail-f.com> <1258620358.17907.50.camel@missotis> <004501ca694c$2a4cfd00$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] persistence of element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 01:56:04 -0000 > > Another issue that was discussed in this thread and that is perhaps > > worth mentioning in the YANG spec (or NETCONF?) is the persistence > of > > element order, namely: > > > > 1. If the client does a copy-config and then retrieves the same > > datastore, the order of elements MAY be different. > > > > 2. If the same get(-config) operation is performed twice on the > same > > datastore with the same contents, the order of elements MUST be > > > identical. > > Be careful what you ask for. :-) This hinges on what you mean by > "the same contents". Consider the case of a system with three > datastores I'll call A, B, C for simplicity. B and C are "the same" > in that they have exactly the same information, differing only in the > order of some non-ordered elements, due to the way in which they > were created. Client X does a copy-config B->A. Client X does > a get of A, and gets something that looks exactly like B. Client Y > does a copy-config C-> A. Client Y does a get of A and gets something > that looks exactly like C. So far, everyone is happy, and someone > observing both conversations will say the implementation didn't > exercise the "MAY" in (1) above. Now client X does another > get of A. If (2) above is to be honored, the server is in trouble. I'm afraid (2) above didn't mean this. datastore A when client X does the first get is NOT "with the same content" as datastore A when client X does the second get. (2) above wanted to say the datastore content should not be changed during the two identical operation performance, IMO. washam From mbj@tail-f.com Fri Nov 20 01:21:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A243A6881 for ; Fri, 20 Nov 2009 01:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMuSz0fla2eY for ; Fri, 20 Nov 2009 01:21:54 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C60633A63EB for ; Fri, 20 Nov 2009 01:21:52 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 56256616001; Fri, 20 Nov 2009 10:21:49 +0100 (CET) Date: Fri, 20 Nov 2009 10:21:49 +0100 (CET) Message-Id: <20091120.102149.125849948.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1258619495.17907.37.camel@missotis> References: <1258614397.17907.5.camel@missotis> <20091119.084911.171432518.mbj@tail-f.com> <1258619495.17907.37.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:21:55 -0000 Ladislav Lhotka wrote: > OK, do we all agree that interleaving is allowed? If so, it should be > explicitly noted in sections 7.7.6 and 7.8.5, otherwise some > implementors may be taken by surprise. Something like this can be added > as the second paragraph in both sections: > > The elements representing list items MUST appear in the order specified > by the user if the (leaf-)list is "ordered-by user", otherwise the order > is implementation-dependent. In both cases, the elements representing > list items MAY be interleaved with other sibling elements. Unless anyone objects, I will add this text to 7.7.6 (leaf-list version) and 7.8.5 (list version): The XML elements representing leaf-list entries MUST appear in the order specified by the user if the leaf-list is "ordered-by user", otherwise the order is implementation-dependent. The XML elements representing leaf-list entries MAY be interleaved with other sibling elements. /martin From andy@netconfcentral.com Fri Nov 20 03:30:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2805F3A67A2 for ; Fri, 20 Nov 2009 03:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyfg1ugLqnVj for ; Fri, 20 Nov 2009 03:30:48 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 7BE483A6820 for ; Fri, 20 Nov 2009 03:30:48 -0800 (PST) Received: (qmail 38589 invoked from network); 20 Nov 2009 11:30:40 -0000 Received: from ppp-67-126-131-72.dsl.irvnca.pacbell.net (andy@67.126.131.72 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 20 Nov 2009 03:30:40 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: kcQ4jUEVM1kQFjEob1mdt0y1ZxCQrZ0YvNUR9nvMt_MRytMkWWHCkBGMkjsYQVGrEoUlEwSmQCDJuC6m29HkNqRqdjS7uTS.0Ze9.t7.Gg_Y7CWk5z43SLk0g12as1tqQ8UPYGW6wDO3uAQY1Z4eqCGO6QAjJKL.XaWtHkpDcIHqXjswWFfgSUolD87rOSNrkUhC3QxymMXKrUfT6aC5n_X3qcsFofcU0lpz720DuGumhsD7KVVHwt2B5FvPid2b6eit7IMoiMmrgW262fmFvLE1xDe5IXv943rcZASRpFqukUTTNznE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B067DDD.9080501@netconfcentral.com> Date: Fri, 20 Nov 2009 03:30:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <1258614397.17907.5.camel@missotis> <20091119.084911.171432518.mbj@tail-f.com> <1258619495.17907.37.camel@missotis> <20091120.102149.125849948.mbj@tail-f.com> In-Reply-To: <20091120.102149.125849948.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 11:30:49 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> OK, do we all agree that interleaving is allowed? If so, it should be >> explicitly noted in sections 7.7.6 and 7.8.5, otherwise some >> implementors may be taken by surprise. Something like this can be added >> as the second paragraph in both sections: >> >> The elements representing list items MUST appear in the order specified >> by the user if the (leaf-)list is "ordered-by user", otherwise the order >> is implementation-dependent. In both cases, the elements representing >> list items MAY be interleaved with other sibling elements. > > Unless anyone objects, I will add this text to 7.7.6 (leaf-list > version) and 7.8.5 (list version): > > The XML elements representing leaf-list entries MUST appear in the > order specified by the user if the leaf-list is "ordered-by user", > otherwise the order is implementation-dependent. The XML elements > representing leaf-list entries MAY be interleaved with other sibling > elements. > Isn't it possible for lists to be interleaved as well? Does this impact the CLR you recently added about case members appearing in exact order? > > /martin > Andy From mbj@tail-f.com Fri Nov 20 03:35:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C523A67FD for ; Fri, 20 Nov 2009 03:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BvRM6JRrdbY for ; Fri, 20 Nov 2009 03:35:10 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5F7A93A67A2 for ; Fri, 20 Nov 2009 03:35:10 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B6DA616001; Fri, 20 Nov 2009 12:35:07 +0100 (CET) Date: Fri, 20 Nov 2009 12:35:06 +0100 (CET) Message-Id: <20091120.123506.195973345.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B067DDD.9080501@netconfcentral.com> References: <1258619495.17907.37.camel@missotis> <20091120.102149.125849948.mbj@tail-f.com> <4B067DDD.9080501@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 11:35:11 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > >> OK, do we all agree that interleaving is allowed? If so, it should be > >> explicitly noted in sections 7.7.6 and 7.8.5, otherwise some > >> implementors may be taken by surprise. Something like this can be added > >> as the second paragraph in both sections: > >> > >> The elements representing list items MUST appear in the order specified > >> by the user if the (leaf-)list is "ordered-by user", otherwise the order > >> is implementation-dependent. In both cases, the elements representing > >> list items MAY be interleaved with other sibling elements. > > > > Unless anyone objects, I will add this text to 7.7.6 (leaf-list > > version) and 7.8.5 (list version): > > > > The XML elements representing leaf-list entries MUST appear in the > > order specified by the user if the leaf-list is "ordered-by user", > > otherwise the order is implementation-dependent. The XML elements > > representing leaf-list entries MAY be interleaved with other sibling > > elements. > > > > Isn't it possible for lists to be interleaved as well? Yes, that's 7.8.5, list version. Same text as above with s/leaf-//g > Does this impact the CLR you recently added about case members > appearing in exact order? No, that was for rpc input / output. /martin From andy@netconfcentral.com Fri Nov 20 08:11:22 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270933A6906 for ; Fri, 20 Nov 2009 08:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HWpBmWhAKsr for ; Fri, 20 Nov 2009 08:11:21 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 569FD3A67A6 for ; Fri, 20 Nov 2009 08:11:21 -0800 (PST) Received: (qmail 69812 invoked from network); 20 Nov 2009 16:11:15 -0000 Received: from ppp-67-126-131-72.dsl.irvnca.pacbell.net (andy@67.126.131.72 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 20 Nov 2009 08:11:15 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .ySj9ZgVM1kYM6Z2KfR3gP.JyrmpSwfggypCXgcrjMpq.PtGu7bbbBN0TDGDqAp74PLf6ZXEOhyUOQM1.xP48tGnhoHHisqDCZvnRmv.be16nsNv.JE9i_CbCX_OGfVFhGWPo8anog7.IHpWMprf992ohysy90hw9muRpFlvaD2dSVHkRjXb1LoS9o1we1zYFFOGdjR50vTxd19YHTG5rSMFvVXhJOcv8caJjit3ozBB4mTpT6BAUm5zogO46hu68y22JtejVpVmhceLkj7RFsRxWx.GOaSu2gOiJahLZcHrROBjReiH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B06BF9F.603@netconfcentral.com> Date: Fri, 20 Nov 2009 08:11:11 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <1258619495.17907.37.camel@missotis> <20091120.102149.125849948.mbj@tail-f.com> <4B067DDD.9080501@netconfcentral.com> <20091120.123506.195973345.mbj@tail-f.com> In-Reply-To: <20091120.123506.195973345.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:11:22 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Ladislav Lhotka wrote: >>>> OK, do we all agree that interleaving is allowed? If so, it should be >>>> explicitly noted in sections 7.7.6 and 7.8.5, otherwise some >>>> implementors may be taken by surprise. Something like this can be added >>>> as the second paragraph in both sections: >>>> >>>> The elements representing list items MUST appear in the order specified >>>> by the user if the (leaf-)list is "ordered-by user", otherwise the order >>>> is implementation-dependent. In both cases, the elements representing >>>> list items MAY be interleaved with other sibling elements. >>> Unless anyone objects, I will add this text to 7.7.6 (leaf-list >>> version) and 7.8.5 (list version): >>> >>> The XML elements representing leaf-list entries MUST appear in the >>> order specified by the user if the leaf-list is "ordered-by user", >>> otherwise the order is implementation-dependent. The XML elements >>> representing leaf-list entries MAY be interleaved with other sibling >>> elements. >>> >> Isn't it possible for lists to be interleaved as well? > > Yes, that's 7.8.5, list version. Same text as above with s/leaf-//g > >> Does this impact the CLR you recently added about case members >> appearing in exact order? > > No, that was for rpc input / output. > But what if a list or leaf-list is a descendant of input-stmt or output-stmt? > > /martin > Andy From mehmet.ersue@nsn.com Fri Nov 20 10:32:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281C73A67AA; Fri, 20 Nov 2009 10:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRyaUZK8tkFi; Fri, 20 Nov 2009 10:32:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 832D53A6961; Fri, 20 Nov 2009 10:32:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAKIWXrK019581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Nov 2009 19:32:33 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAKIWVjY029641; Fri, 20 Nov 2009 19:32:33 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 19:32:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA6A0F.D1FCD315" Date: Fri, 20 Nov 2009 19:32:30 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call: With-Defaults as SHOULD in 4741bis Thread-Index: AcpqD9EtAgyl1/HvS2qsgWLqs7N6kg== From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "NETMOD Working Group" X-OriginalArrivalTime: 20 Nov 2009 18:32:31.0726 (UTC) FILETIME=[D23590E0:01CA6A0F] Subject: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:32:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6A0F.D1FCD315 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA6A0F.D1FCD315" ------_=_NextPart_002_01CA6A0F.D1FCD315 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, in the NETCONF/NETMOD conference call we discussed the=20 handling of with-defaults in 4741bis document and the=20 YANG specification. We had a rough consensus on having 'with-defaults' as=20 SHOULD to implement (see point 3 in the attached mail=20 from October 02, 2009), which is going to be added to=20 the 4741bis document if we have consensus. We do not want to go through a re-run of all arguments=20 for and against. Since this conclusion has an impact=20 on both NETCONF 4741bis and the YANG specifications=20 the co-chairs of NETCONF and NETMOD WGs are keen of=20 having a final consensus call on that.=20 All on NETCONF and NETMOD WG maillists, please read=20 the attached mail of David Partain and respond to this=20 mail by December 1, 2009 EOB PT. <<[netmod] Information from chair phone call on 24 September>>=20 If you agree with the conclusion having 'with-defaults'=20 as SHOULD to implement in 4741bis please state so. If you disagree with this consensus, state your opinion too. Thank you. Bert & Mehmet ------_=_NextPart_002_01CA6A0F.D1FCD315 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Consensus call: With-Defaults as SHOULD in 4741bis

Hi All,

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

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

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

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

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

Thank you.

Bert & Mehmet

------_=_NextPart_002_01CA6A0F.D1FCD315-- ------_=_NextPart_001_01CA6A0F.D1FCD315 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc023.nsn-intra.net ([10.150.128.36]) by DEMUEXC005.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:37:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CA433B.895A2C00" Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:37:12 +0200 Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n928bCP1010039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2009 10:37:12 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n928bBra002326; Fri, 2 Oct 2009 10:37:11 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C7F3A68E2; Fri, 2 Oct 2009 01:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7222B3A68BB; Fri, 2 Oct 2009 01:35:41 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfkZsIyilLfb; Fri, 2 Oct 2009 01:35:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C8C273A67F2; Fri, 2 Oct 2009 01:35:39 -0700 (PDT) Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1F.2C.15624.1BBB5CA4; Fri, 2 Oct 2009 10:37:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:36:20 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:36:20 +0200 Content-class: urn:content-classes:message Subject: [netmod] Information from chair phone call on 24 September Date: Fri, 2 Oct 2009 09:36:19 +0100 Message-ID: <200910021036.19330.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Information from chair phone call on 24 September Thread-Index: AcpDO4oagOlA/vfaRLmpSofowILzNg== List-Help: List-Subscribe: , List-Unsubscribe: , From: "ext David Partain" Sender: To: , "NETMOD Working Group" This is a multi-part message in MIME format. ------_=_NextPart_003_01CA433B.895A2C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This mail summarizes the conversation that the 4 co-chairs of NETCONF/NETMOD had with interested parties on default issue. This mail is NOT intended to re-open the question about default handling but to confirm that what we believe is a reasonable way forward is a decision that the working groups can live with. Silence will be considered consent! 1. There were a number of comments during the call that indicated that we need text that says that defaults are taken into consideration in validation. 2. The defaults question: No fundamental changes to the model are needed. That is, a server MAY choose not to send back values that are the default as defined in the YANG model. Instead, we are going to try to address some things that will tighten up potential inconsistencies (to "SHOULD level", not "MUST level") in dealing with defaults. There are cases where you don't necessarily know what a non-answer about an object with a default clause means. In particular, this means looking at upgrade rules, dealing with leafrefs and instance-identifiers. We should try to address the most common cases without trying to cover all possible corner cases. We need specific text, which Andy and Martin have been asked to address. Again, we are not re-opening this discussion by sending this mail: we wish to confirm that this is the right way forward. Some expressed a wish that there be a simple, short explanation of how defaults are handled in general so that one doesn't need to be privy of the entire YANG history to understand why things are the way they are. If you believe that this is useful, please offer text or, at a minimum, point out where you think text is missing. 3. The NETCONF WG to check consensus on whether 'with-defaults:' should be a SHOULD to implement. 4. In conjunction with the 'with-defaults:' work, the NETCONF WG can consider adding an XML attribute in a report-all response that tags default data as such to help NETCONF applications. (This discussion is already underway.) 5. Juergen agreed to help with some examples of XPath expressions refering to config / non-config / garbage data. (I think I got this right.) If others believe that other examples are needed, please suggest that on the mailing list. 6. We need to start thinking about (and writing about) the issue of config vs. statistics vs. operational data. This is something that needs to be given serious thought and energy. This will be done separately (and after) the YANG work is complete. 7. We will try to put text in the architecture draft as a sort of "placeholder" with respect to #5. Text has been suggested on the mailing list before and that should be put into the draft. Thanks. David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------_=_NextPart_003_01CA433B.895A2C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [netmod] Information from chair phone call on 24 = September

Hi,

This mail summarizes the conversation that the 4 = co-chairs of
NETCONF/NETMOD had with interested parties on default = issue.
This mail is NOT intended to re-open the question = about default
handling but to confirm that what we believe is a = reasonable way
forward is a decision that the working groups can = live with.
Silence will be considered consent!

1. There were a number of comments during the call = that indicated
that we need text that says that defaults are taken = into
consideration in validation.

2.  The defaults question: No fundamental changes = to the model
are needed.  That is, a server MAY choose not to = send back values
that are the default as defined in the YANG = model.  Instead, we
are going to try to address some things that will = tighten up
potential inconsistencies (to "SHOULD = level", not "MUST level")
in dealing with defaults.  There are cases where = you don't
necessarily know what a non-answer about an object = with a default
clause means.  In particular, this means looking = at upgrade
rules, dealing with leafrefs and = instance-identifiers.  We should
try to address the most common cases without trying = to cover all
possible corner cases. We need specific text, which = Andy and
Martin have been asked to address.

Again, we are not re-opening this discussion by = sending this
mail: we wish to confirm that this is the right way = forward.

Some expressed a wish that there be a simple, short = explanation
of how defaults are handled in general so that one = doesn't need
to be privy of the entire YANG history to understand = why things
are the way they are.  If you believe that this = is useful, please
offer text or, at a minimum, point out where you = think text is
missing.

3. The NETCONF WG to check consensus on whether = 'with-defaults:'
should be a SHOULD to implement.

4. In conjunction with the 'with-defaults:' work, the = NETCONF WG
can consider adding an XML attribute in a report-all = response
that tags default data as such to help NETCONF = applications.
(This discussion is already underway.)

5. Juergen agreed to help with some examples of XPath = expressions
refering to config / non-config / garbage data.  = (I think I got
this right.)  If others believe that other = examples are needed,
please suggest that on the mailing list.

6. We need to start thinking about (and writing about) = the issue
of config vs. statistics vs. operational data.  = This is something
that needs to be given serious thought and = energy.  This will be
done separately (and after) the YANG work is = complete.

7. We will try to put text in the architecture draft = as a sort of
"placeholder" with respect to #5.  = Text has been suggested on the
mailing list before and that should be put into the = draft.

Thanks.

David

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

------_=_NextPart_003_01CA433B.895A2C00-- ------_=_NextPart_001_01CA6A0F.D1FCD315-- From phil@juniper.net Fri Nov 20 10:59:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01433A6821; Fri, 20 Nov 2009 10:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LFbDCCpENf4; Fri, 20 Nov 2009 10:59:53 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id E4C1D3A66B4; Fri, 20 Nov 2009 10:59:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSwbnI7FnLgLoGhQIeMT2V2GEFI8vt9xR@postini.com; Fri, 20 Nov 2009 10:59:50 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Fri, 20 Nov 2009 10:53:37 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:53:37 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:53:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:53:36 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAKIrZj59609; Fri, 20 Nov 2009 10:53:35 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nAKIeAo9087472; Fri, 20 Nov 2009 18:40:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911201840.nAKIeAo9087472@idle.juniper.net> To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> Date: Fri, 20 Nov 2009 13:40:09 -0500 From: Phil Shafer X-OriginalArrivalTime: 20 Nov 2009 18:53:36.0391 (UTC) FILETIME=[C4022170:01CA6A12] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org, NETMOD Working Group Subject: Re: [netmod] [Netconf] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:59:54 -0000 "Ersue, Mehmet (NSN - DE/Munich)" writes: >We had a rough consensus on having 'with-defaults' as >SHOULD to implement (see point 3 in the attached mail >from October 02, 2009), which is going to be added to >the 4741bis document if we have consensus. As previously pointed out, the conf call's concensus was to ask the NETCONF mailing list about w-d, not that it was a SHOULD. >If you agree with the conclusion having 'with-defaults' >as SHOULD to implement in 4741bis please state so. >If you disagree with this consensus, state your opinion too. I do not want W-D to be a SHOULD requirement since it is not required for the proper operation of a NETCONF server. We have managed without it for a long long time and I do not see it as vital. Heck, there's no requirement in NETCONF for the data model to even _have_ default values. 4741 current says nothing about the data model's contents and says absolutely nothing about default values. I don't see a convincing reason why this should change. Thanks, Phil From bertietf@bwijnen.net Mon Nov 23 00:10:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEE03A68A6; Mon, 23 Nov 2009 00:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.188 X-Spam-Level: X-Spam-Status: No, score=-7.188 tagged_above=-999 required=5 tests=[AWL=-4.078, BAYES_05=-1.11, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR0mMo2ctFjl; Mon, 23 Nov 2009 00:10:15 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 4264A3A67F3; Mon, 23 Nov 2009 00:10:13 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NCTzs-0008R0-PA; Mon, 23 Nov 2009 09:10:08 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id BC3B22F583; Mon, 23 Nov 2009 09:10:08 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=guest-106.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NCTzs-0001NL-Lz; Mon, 23 Nov 2009 09:10:08 +0100 Message-ID: <4B0A4362.7070405@bwijnen.net> Date: Mon, 23 Nov 2009 08:10:10 +0000 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf , netmod@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd473427ef13626cca42930a1036735bed7 Subject: [netmod] Tentative Netconf/Netmod interoperability event X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:10:16 -0000 Netconf and Netmod WG participants, and specifically any implementers, Some of your WG chairs were informed bout a tentative interoperability event right before the next IETF meeting in Anaheim. We are not endorsing the company that organizes this, but thought it would be good to make you all aware. For more details, pls go to: http://www.iwl.com/winter-2009-newsletter.html interoperability testing is in general a good thing of course. Bert From mbj@tail-f.com Mon Nov 23 15:05:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880B43A6AAC; Mon, 23 Nov 2009 15:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1Rza9dOqxJc; Mon, 23 Nov 2009 15:05:49 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 819443A681D; Mon, 23 Nov 2009 15:05:49 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 61718616001; Tue, 24 Nov 2009 00:00:01 +0100 (CET) Date: Tue, 24 Nov 2009 00:00:00 +0100 (CET) Message-Id: <20091124.000000.152719236.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091123215203.GA9240@elstar.local> References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, netconf@ietf.org Subject: Re: [netmod] [Netconf] YANG module naming conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 23:05:50 -0000 Hi, Juergen Schoenwaelder wrote: > On Mon, Nov 23, 2009 at 10:29:42PM +0100, Mark Scott wrote: > > > 4. Top-level container change from ?netconf-state? to > > ?ietf-netconf-monitoring? > > > The rationale for these changes is consistency and alignment with > > the yang module usage guidelines (see > > http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02). > > I fail to find the guideline in netmod-yang-usage-02 that leads to a > toplevel name like ietf-netconf-monitoring. I am not saying its wrong > just that I do not understand the pointer to netmod-yang-usage-02. I also noted this, and we had this discussion some time ago. At this point, I don't think we should change it from netconf-state. > I guess I am missing a plan for a general strategy. If we have an IETF > protocol 'foo', do we expect YANG modules such as: > > YANG module YANG toplevel YANG contents > > ietf-foo-monitoring ietf-foo-monitoring config false objects > ietf-foo-config ietf-foo-config config true objects > ietf-foo - typedefs, groupings, rpcs > > Do we also allow / expect the following: > > ietf-foo-types - typedefs, groupings > ietf-foo-ops - operations Hopefully not... Looking at the netconf case, I think everything could be under 'netconf'. But not in the urn:...:ietf-netconf-monitoring namespace. Maybe it would be better to use a more generic namespace for netconf state and monitoring, and put monitoring in its own submodule(s) and config in other submodule(s). > Is the namespace always going to be > urn:ietf:params:xml:ns:yang:$MODULE-NAME[:DRAFT-$VERSION]? It is slightly redundant, since the $MODULE-NAME is on the form 'ietf-NAME'. I think urn:ietf:params:xml:ns:yang:netconf-monitoring would be fine. > Should ietf-foo-monitoring be in general ietf-foo-state or do we have > yet separate modules to report operational state? Perhaps the answer > to all this is we do not know - but I thought I at least bring up the > question so we don't do things by accident. > > /js > > PS: I am CCing NETMOD since this is mostly an YANG issue. Further > discussion should likely stay in NETMOD, assuming the NETCONF > monitoring people are on NETMOD as well. I think you forgot that, so I'm doing it now. /martin From andy@netconfcentral.com Mon Nov 23 15:23:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6F03A6844 for ; Mon, 23 Nov 2009 15:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCAQw4WQMrBU for ; Mon, 23 Nov 2009 15:23:03 -0800 (PST) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id D03983A67BD for ; Mon, 23 Nov 2009 15:23:03 -0800 (PST) Received: (qmail 54119 invoked from network); 23 Nov 2009 23:16:20 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 23 Nov 2009 15:16:20 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: rekJdWIVM1nknBmTtzqRzwsihgWzRtRtF8Jgk3fJmbOHGI_pg9cQlxUecAMsCGq1FGOAaGwnjIMv66NaSKsc27HzdinzaejbQ48j3z2BmhGYLUQlPdXW9OaVyImDi9ROy.gv_IGtasBPtZexGRqQatAApSCim3pRhht7Nn_SHrblreiPiVho8NzUzNfUGZBfwDvj7_RaP3WGwAKBOoeLDuTmODEo3nrvFBBJuOocNEB5V83mAq3UzT9PsX8p.vOeDZjvVSJoqCmm2eCrXp0pns4a9eq7JpgOIuc0Fw4pdw1MFgdLFD.8Taj3DD44fC.qREgyhnTPqQj0PjeoerLRzd9fkbJxnqJSPgkvEDGJmv9AKkqp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0B1739.7090502@netconfcentral.com> Date: Mon, 23 Nov 2009 15:14:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local> <20091124.000000.152719236.mbj@tail-f.com> In-Reply-To: <20091124.000000.152719236.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG module naming conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 23:23:04 -0000 Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: >> On Mon, Nov 23, 2009 at 10:29:42PM +0100, Mark Scott wrote: >> >>> 4. Top-level container change from ?netconf-state? to >>> ?ietf-netconf-monitoring? >>> The rationale for these changes is consistency and alignment with >>> the yang module usage guidelines (see >>> http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02). >> I fail to find the guideline in netmod-yang-usage-02 that leads to a >> toplevel name like ietf-netconf-monitoring. I am not saying its wrong >> just that I do not understand the pointer to netmod-yang-usage-02. > > I also noted this, and we had this discussion some time ago. At this > point, I don't think we should change it from netconf-state. > I agree. I am not sure if there is still a guideline that says the top-level container should be the same as the module name. This is not really needed. The module name is not a QName so it needs special naming considerations. The top-level element is a QName and there are no naming collisions to worry about (because the namespace URI was picked to be globally unique.) >> I guess I am missing a plan for a general strategy. If we have an IETF >> protocol 'foo', do we expect YANG modules such as: >> >> YANG module YANG toplevel YANG contents >> >> ietf-foo-monitoring ietf-foo-monitoring config false objects >> ietf-foo-config ietf-foo-config config true objects >> ietf-foo - typedefs, groupings, rpcs >> >> Do we also allow / expect the following: >> >> ietf-foo-types - typedefs, groupings >> ietf-foo-ops - operations > > Hopefully not... > > Looking at the netconf case, I think everything could be under > 'netconf'. But not in the urn:...:ietf-netconf-monitoring namespace. > We went though this issue awhile back. one container was config=true and the other was config=false. So one was renamed to netconf-state instead of augmenting the 4741 netconf node. > Maybe it would be better to use a more generic namespace for netconf > state and monitoring, and put monitoring in its own submodule(s) and > config in other submodule(s). > >> Is the namespace always going to be >> urn:ietf:params:xml:ns:yang:$MODULE-NAME[:DRAFT-$VERSION]? > > It is slightly redundant, since the $MODULE-NAME is on the form > 'ietf-NAME'. I think > > urn:ietf:params:xml:ns:yang:netconf-monitoring > > would be fine. > > >> Should ietf-foo-monitoring be in general ietf-foo-state or do we have >> yet separate modules to report operational state? Perhaps the answer >> to all this is we do not know - but I thought I at least bring up the >> question so we don't do things by accident. >> >> /js >> >> PS: I am CCing NETMOD since this is mostly an YANG issue. Further >> discussion should likely stay in NETMOD, assuming the NETCONF >> monitoring people are on NETMOD as well. > > I think you forgot that, so I'm doing it now. > > > /martin Andy From mbj@tail-f.com Wed Nov 25 12:32:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA78A3A6929 for ; Wed, 25 Nov 2009 12:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xENiIphtzArQ for ; Wed, 25 Nov 2009 12:32:56 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 298E03A689E for ; Wed, 25 Nov 2009 12:32:56 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 840A2616001 for ; Wed, 25 Nov 2009 21:32:50 +0100 (CET) Date: Wed, 25 Nov 2009 21:32:50 +0100 (CET) Message-Id: <20091125.213250.126337919.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] resolution of system-creatable discussion X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:32:56 -0000 Hi, Consensus after the long discussion on system-creatable was that we will not do this now, but mention this in the text. So here is proposed text for this issue: 5.7. Data Store Modification Data models may allow the server to alter the configuration data store. A formal mechanism for specifying the circumstances where these changes are allowed is out of scope for this specification. I'm not sure where this text should go; I put it in a new section 5.7. Please comment. /martin From mbj@tail-f.com Wed Nov 25 12:50:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674113A6969 for ; Wed, 25 Nov 2009 12:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+DJk9bDQL4H for ; Wed, 25 Nov 2009 12:50:09 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 98BDB3A689E for ; Wed, 25 Nov 2009 12:50:09 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B8ED616001; Wed, 25 Nov 2009 21:50:04 +0100 (CET) Date: Wed, 25 Nov 2009 21:50:03 +0100 (CET) Message-Id: <20091125.215003.54719021.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B06BF9F.603@netconfcentral.com> References: <4B067DDD.9080501@netconfcentral.com> <20091120.123506.195973345.mbj@tail-f.com> <4B06BF9F.603@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:50:10 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Ladislav Lhotka wrote: > >>>> OK, do we all agree that interleaving is allowed? If so, it should be > >>>> explicitly noted in sections 7.7.6 and 7.8.5, otherwise some > >>>> implementors may be taken by surprise. Something like this can be added > >>>> as the second paragraph in both sections: > >>>> > >>>> The elements representing list items MUST appear in the order specified > >>>> by the user if the (leaf-)list is "ordered-by user", otherwise the order > >>>> is implementation-dependent. In both cases, the elements representing > >>>> list items MAY be interleaved with other sibling elements. > >>> Unless anyone objects, I will add this text to 7.7.6 (leaf-list > >>> version) and 7.8.5 (list version): > >>> > >>> The XML elements representing leaf-list entries MUST appear in the > >>> order specified by the user if the leaf-list is "ordered-by user", > >>> otherwise the order is implementation-dependent. The XML elements > >>> representing leaf-list entries MAY be interleaved with other sibling > >>> elements. > >>> > >> Isn't it possible for lists to be interleaved as well? > > > > Yes, that's 7.8.5, list version. Same text as above with s/leaf-//g > > > >> Does this impact the CLR you recently added about case members > >> appearing in exact order? > > > > No, that was for rpc input / output. > > > > But what if a list or leaf-list is a descendant of input-stmt > or output-stmt? Does this work? The XML elements representing leaf-list entries MUST appear in the order specified by the user if the leaf-list is "ordered-by user", otherwise the order is implementation-dependent. The XML elements representing leaf-list entries MAY be interleaved with other sibling elements, unless the leaf-list defines RPC input or output parameters. /martin From andy@netconfcentral.com Wed Nov 25 13:49:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939103A6B8F for ; Wed, 25 Nov 2009 13:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2QN333LgOib for ; Wed, 25 Nov 2009 13:49:43 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id DE15C3A6B89 for ; Wed, 25 Nov 2009 13:49:43 -0800 (PST) Received: (qmail 38590 invoked from network); 25 Nov 2009 21:49:36 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 25 Nov 2009 13:49:36 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: z.WK_FIVM1laGrxBnzrqQFAEAwHhnRL8EWuTSSVcJMuwtmzMlZ_lakYZPfhnW2JkgH6N04_n2FwhapytTSmUBPcPXb.1PDjBhHMd.Ux8grltKtpwSWTZOFqV7VO7iDXWRJS0M7IbWRs.QIgfmA.5vlp4mbaaQOUUVP.w7Vh01khIiY7RoVquJifJqa_2gXmIbaMJx2O6RMWr18PUrd0EmQ7VFf9D8CGZV50qkSDqQusL7tVkvTZhnSAsZzXWsiceT4Mfn6C8a6efg1bGcZ8U9Ox7cYAfoi74rpHCI7EtBlEYmVLvE.FT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0DA670.1070404@netconfcentral.com> Date: Wed, 25 Nov 2009 13:49:36 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B067DDD.9080501@netconfcentral.com> <20091120.123506.195973345.mbj@tail-f.com> <4B06BF9F.603@netconfcentral.com> <20091125.215003.54719021.mbj@tail-f.com> In-Reply-To: <20091125.215003.54719021.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:49:44 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Ladislav Lhotka wrote: >>>>>> OK, do we all agree that interleaving is allowed? If so, it should be >>>>>> explicitly noted in sections 7.7.6 and 7.8.5, otherwise some >>>>>> implementors may be taken by surprise. Something like this can be added >>>>>> as the second paragraph in both sections: >>>>>> >>>>>> The elements representing list items MUST appear in the order specified >>>>>> by the user if the (leaf-)list is "ordered-by user", otherwise the order >>>>>> is implementation-dependent. In both cases, the elements representing >>>>>> list items MAY be interleaved with other sibling elements. >>>>> Unless anyone objects, I will add this text to 7.7.6 (leaf-list >>>>> version) and 7.8.5 (list version): >>>>> >>>>> The XML elements representing leaf-list entries MUST appear in the >>>>> order specified by the user if the leaf-list is "ordered-by user", >>>>> otherwise the order is implementation-dependent. The XML elements >>>>> representing leaf-list entries MAY be interleaved with other sibling >>>>> elements. >>>>> >>>> Isn't it possible for lists to be interleaved as well? >>> Yes, that's 7.8.5, list version. Same text as above with s/leaf-//g >>> >>>> Does this impact the CLR you recently added about case members >>>> appearing in exact order? >>> No, that was for rpc input / output. >>> >> But what if a list or leaf-list is a descendant of input-stmt >> or output-stmt? > > Does this work? > > The XML elements representing leaf-list entries MUST appear in the > order specified by the user if the leaf-list is "ordered-by user", > otherwise the order is implementation-dependent. The XML elements > representing leaf-list entries MAY be interleaved with other sibling > elements, unless the leaf-list defines RPC input or output > parameters. > The problem is that within edit-config and copy-config are RPC input parameters. Other than the optional parameter, there is no other way to specify configuration data in NETCONF. It seems to me that ALL rpc/input descendant nodes are strictly ordered, and the 'MAY be interleaved' only applies to remote based configs. Even though the client MUST send the correct order to be safe, there is no normative text that says the server MUST NOT accept interleaved RPC input parameters. IMO, the CLR needs to be simple and consistent. All rpc/input descendant nodes are ordered, according to the spec. The text should say the client MUST NOT interleave, and that gives a server the ability to refuse out-of-order rpc/input subtrees. > > /martin > > Andy From mbj@tail-f.com Wed Nov 25 13:56:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CB83A6B96 for ; Wed, 25 Nov 2009 13:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywTVy0R2NLY7 for ; Wed, 25 Nov 2009 13:56:02 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D1B653A6B92 for ; Wed, 25 Nov 2009 13:56:01 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0FB54616001; Wed, 25 Nov 2009 22:55:56 +0100 (CET) Date: Wed, 25 Nov 2009 22:55:55 +0100 (CET) Message-Id: <20091125.225555.210436334.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B0DA670.1070404@netconfcentral.com> References: <4B06BF9F.603@netconfcentral.com> <20091125.215003.54719021.mbj@tail-f.com> <4B0DA670.1070404@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:56:03 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> Martin Bjorklund wrote: > >>>>> Ladislav Lhotka wrote: > >>>>>> OK, do we all agree that interleaving is allowed? If so, it should be > >>>>>> explicitly noted in sections 7.7.6 and 7.8.5, otherwise some > >>>>>> implementors may be taken by surprise. Something like this can be added > >>>>>> as the second paragraph in both sections: > >>>>>> > >>>>>> The elements representing list items MUST appear in the order specified > >>>>>> by the user if the (leaf-)list is "ordered-by user", otherwise the order > >>>>>> is implementation-dependent. In both cases, the elements representing > >>>>>> list items MAY be interleaved with other sibling elements. > >>>>> Unless anyone objects, I will add this text to 7.7.6 (leaf-list > >>>>> version) and 7.8.5 (list version): > >>>>> > >>>>> The XML elements representing leaf-list entries MUST appear in the > >>>>> order specified by the user if the leaf-list is "ordered-by user", > >>>>> otherwise the order is implementation-dependent. The XML elements > >>>>> representing leaf-list entries MAY be interleaved with other sibling > >>>>> elements. > >>>>> > >>>> Isn't it possible for lists to be interleaved as well? > >>> Yes, that's 7.8.5, list version. Same text as above with s/leaf-//g > >>> > >>>> Does this impact the CLR you recently added about case members > >>>> appearing in exact order? > >>> No, that was for rpc input / output. > >>> > >> But what if a list or leaf-list is a descendant of input-stmt > >> or output-stmt? > > > > Does this work? > > > > The XML elements representing leaf-list entries MUST appear in the > > order specified by the user if the leaf-list is "ordered-by user", > > otherwise the order is implementation-dependent. The XML elements > > representing leaf-list entries MAY be interleaved with other sibling > > elements, unless the leaf-list defines RPC input or output > > parameters. > > > > The problem is that within edit-config and copy-config > are RPC input parameters. 1. Are you suggesting that this would not be a problem if we didn't have a YANG model in 4741bis? 2. Even with the YANG model in 4741bis, the config is defined as an anyxml, and the draft does not say anything at all about encoding within anyxml. So is this really a problem? /martin From MARKSCOT@nortel.com Wed Nov 25 14:01:41 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F533A67B1; Wed, 25 Nov 2009 14:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDIFcZqHciCP; Wed, 25 Nov 2009 14:01:40 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 04D0B3A6B4E; Wed, 25 Nov 2009 14:01:39 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAPM0vm01800; Wed, 25 Nov 2009 22:00:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 17:00:23 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> In-Reply-To: <4B0B1739.7090502@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] YANG module naming conventions Thread-Index: AcpskvyjY54S3SsSR9WQTDWVCsKZugBhYx/g References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local><20091124.000000.152719236.mbj@tail-f.com> <4B0B1739.7090502@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" , "Martin Bjorklund" Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG module naming conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:01:41 -0000 I agree we don't need to align the top-level container - and will keep /netconf-state/. I also dislike the redundancy and will update the namespace to 'urn:ietf:params:xml:ns:yang:netconf-monitoring'. - maybe update the yang usage guidelines accordingly? Mark "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com." -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Monday, November 23, 2009 6:14 PM To: Martin Bjorklund Cc: netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] YANG module naming conventions Martin Bjorklund wrote: > Hi, >=20 > Juergen Schoenwaelder wrote: >> On Mon, Nov 23, 2009 at 10:29:42PM +0100, Mark Scott wrote: >> >>> 4. Top-level container change from ?netconf-state? to >>> ?ietf-netconf-monitoring? >>> The rationale for these changes is consistency and alignment with >>> the yang module usage guidelines (see >>> http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-02). >> I fail to find the guideline in netmod-yang-usage-02 that leads to a >> toplevel name like ietf-netconf-monitoring. I am not saying its wrong >> just that I do not understand the pointer to netmod-yang-usage-02. >=20 > I also noted this, and we had this discussion some time ago. At this > point, I don't think we should change it from netconf-state. >=20 I agree. I am not sure if there is still a guideline that says the top-level container should be the same as the module name. This is not really needed. The module name is not a QName so it needs special naming considerations. The top-level element is a QName and there are no naming collisions to worry about (because the namespace URI was picked to be globally unique.) >> I guess I am missing a plan for a general strategy. If we have an IETF >> protocol 'foo', do we expect YANG modules such as: >> >> YANG module YANG toplevel YANG contents >> >> ietf-foo-monitoring ietf-foo-monitoring config false objects >> ietf-foo-config ietf-foo-config config true objects >> ietf-foo - typedefs, groupings, rpcs >> >> Do we also allow / expect the following: >> >> ietf-foo-types - typedefs, groupings >> ietf-foo-ops - operations >=20 > Hopefully not... >=20 > Looking at the netconf case, I think everything could be under > 'netconf'. But not in the urn:...:ietf-netconf-monitoring namespace. >=20 We went though this issue awhile back. one container was config=3Dtrue and the other was config=3Dfalse. So one was renamed to netconf-state instead of augmenting the 4741 netconf node. > Maybe it would be better to use a more generic namespace for netconf > state and monitoring, and put monitoring in its own submodule(s) and > config in other submodule(s). >=20 >> Is the namespace always going to be >> urn:ietf:params:xml:ns:yang:$MODULE-NAME[:DRAFT-$VERSION]? >=20 > It is slightly redundant, since the $MODULE-NAME is on the form > 'ietf-NAME'. I think >=20 > urn:ietf:params:xml:ns:yang:netconf-monitoring >=20 > would be fine. >=20 >=20 >> Should ietf-foo-monitoring be in general ietf-foo-state or do we have >> yet separate modules to report operational state? Perhaps the answer >> to all this is we do not know - but I thought I at least bring up the >> question so we don't do things by accident. >> >> /js >> >> PS: I am CCing NETMOD since this is mostly an YANG issue. Further >> discussion should likely stay in NETMOD, assuming the NETCONF >> monitoring people are on NETMOD as well. >=20 > I think you forgot that, so I'm doing it now. >=20 >=20 > /martin Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Wed Nov 25 14:18:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4354D3A6B63 for ; Wed, 25 Nov 2009 14:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqEtBsnKsJTC for ; Wed, 25 Nov 2009 14:18:37 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 473443A6B61 for ; Wed, 25 Nov 2009 14:18:37 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSw2tNwZ2Vf0brHjO72+J6xOFNv4q04A5@postini.com; Wed, 25 Nov 2009 14:18:32 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Wed, 25 Nov 2009 14:16:30 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:16:30 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:16:29 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:16:29 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAPMGSj32322 for ; Wed, 25 Nov 2009 14:16:28 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nAPM2vvh030564 for ; Wed, 25 Nov 2009 22:02:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911252202.nAPM2vvh030564@idle.juniper.net> To: netmod@ietf.org Date: Wed, 25 Nov 2009 17:02:57 -0500 From: Phil Shafer X-OriginalArrivalTime: 25 Nov 2009 22:16:29.0016 (UTC) FILETIME=[EF860D80:01CA6E1C] MIME-Version: 1.0 Content-Type: text/plain Subject: [netmod] when description and yang statement disagree X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:18:38 -0000 An issue Andy raised was what to do when the description statement and the other YANG statements disagree. Is it a bug? How are conflicts resolved. Here is some proposed text that addresses the issue. In some circumstances, the standard YANG modeling statements will not be sufficient to document all restrictions placed on the data model and its values. The "description" statement (and non-standard extensions) can be used to express these restrictions, but should be viewed as additional restrictions on the base information supplied in the standard YANG statements. The description should never be seen as allowing additional content that would be deemed as invalid by the contract specified in the YANG module. Sound reasonable? Thanks, Phil From phil@juniper.net Wed Nov 25 14:18:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F633A67E7 for ; Wed, 25 Nov 2009 14:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNlWu-WPvDTe for ; Wed, 25 Nov 2009 14:18:54 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 306A93A6774 for ; Wed, 25 Nov 2009 14:18:54 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSw2tR5zKaY4H5jTD+pli+XS01DYXQkFa@postini.com; Wed, 25 Nov 2009 14:18:49 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Wed, 25 Nov 2009 14:16:48 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:16:48 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:16:47 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:16:47 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAPMGkj32671; Wed, 25 Nov 2009 14:16:46 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id nAPM3Fhl030580; Wed, 25 Nov 2009 22:03:16 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200911252203.nAPM3Fhl030580@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091125.213250.126337919.mbj@tail-f.com> Date: Wed, 25 Nov 2009 17:03:15 -0500 From: Phil Shafer X-OriginalArrivalTime: 25 Nov 2009 22:16:47.0375 (UTC) FILETIME=[FA7769F0:01CA6E1C] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] resolution of system-creatable discussion X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:18:55 -0000 Martin Bjorklund writes: > Data models may allow the server to alter the configuration data > store. A formal mechanism for specifying the circumstances where > these changes are allowed is out of scope for this specification. Sounds good. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Nov 25 15:04:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7955C3A68E3 for ; Wed, 25 Nov 2009 15:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkFypA9tMpGZ for ; Wed, 25 Nov 2009 15:04:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 599423A6813 for ; Wed, 25 Nov 2009 15:04:08 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE1F0C003F; Thu, 26 Nov 2009 00:04:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HfgmQuAN-7No; Thu, 26 Nov 2009 00:04:02 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3D03C003B; Thu, 26 Nov 2009 00:04:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F3E6EE35AD4; Thu, 26 Nov 2009 00:04:00 +0100 (CET) Date: Thu, 26 Nov 2009 00:04:00 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20091125230400.GA10948@elstar.local> Mail-Followup-To: Phil Shafer , "netmod@ietf.org" References: <200911252202.nAPM2vvh030564@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911252202.nAPM2vvh030564@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] when description and yang statement disagree X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:04:09 -0000 On Wed, Nov 25, 2009 at 11:02:57PM +0100, Phil Shafer wrote: > An issue Andy raised was what to do when the description statement > and the other YANG statements disagree. Is it a bug? How are conflicts > resolved. Here is some proposed text that addresses the issue. > > In some circumstances, the standard YANG modeling statements > will not be sufficient to document all restrictions placed on > the data model and its values. The "description" statement (and > non-standard extensions) can be used to express these restrictions, > but should be viewed as additional restrictions on the base > information supplied in the standard YANG statements. The > description should never be seen as allowing additional content > that would be deemed as invalid by the contract specified in the > YANG module. > > Sound reasonable? When a description statement and other YANG statements disagree, then there is a bug and it requires human intelligence to figure out what is wrong. A blanket statement that one of them wins is of no real value. The text itself is relatively harmless but in the context it is posted, I am having an issue with it. My proposal is to do not nothing; I assume that contradictions in a specifications are considered a bug without explicit text stating this and as said before, the resolution of a bug requires understanding of the bug and human intelligence. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Nov 25 17:06:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C9F3A693F for ; Wed, 25 Nov 2009 17:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxSmBT6CJSsJ for ; Wed, 25 Nov 2009 17:06:15 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 5549C3A680C for ; Wed, 25 Nov 2009 17:06:15 -0800 (PST) Received: (qmail 56220 invoked from network); 26 Nov 2009 01:06:07 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 25 Nov 2009 17:06:07 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: l2xLx7MVM1nkSqzJM1JEzSpEI0npqfV4.Kr3YjQ_lJAQL6XgqA_AQNAM6NLmSivBsNaajCVops7wx_Rl1PvfCxjxeSf3SUALQF6pPWW_x.q.5mn9PE7lXU7DFnCB5XR2wid44nCs_uKRRMTznc1oEinVPYkv85BG5npscER4wEWkHW4akq8MBZ5HTdw02CUc6gfbMccx.LXgJ0f.LyKoN_JIHKn4rRkj6l0FarDPZ6BAO.9Pyd0G7G4bieQXHQLYl9p9FDU_m45_fXRLE6AmqNo2x8tOfeE_fYLOfq6Eu_pC431WVAPbAQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0DD47F.7060708@netconfcentral.com> Date: Wed, 25 Nov 2009 17:06:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B06BF9F.603@netconfcentral.com> <20091125.215003.54719021.mbj@tail-f.com> <4B0DA670.1070404@netconfcentral.com> <20091125.225555.210436334.mbj@tail-f.com> In-Reply-To: <20091125.225555.210436334.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 01:06:16 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Andy Bierman wrote: >>>>>> Martin Bjorklund wrote: >>>>>>> Ladislav Lhotka wrote: >>>>>>>> OK, do we all agree that interleaving is allowed? If so, it should be >>>>>>>> explicitly noted in sections 7.7.6 and 7.8.5, otherwise some >>>>>>>> implementors may be taken by surprise. Something like this can be added >>>>>>>> as the second paragraph in both sections: >>>>>>>> >>>>>>>> The elements representing list items MUST appear in the order specified >>>>>>>> by the user if the (leaf-)list is "ordered-by user", otherwise the order >>>>>>>> is implementation-dependent. In both cases, the elements representing >>>>>>>> list items MAY be interleaved with other sibling elements. >>>>>>> Unless anyone objects, I will add this text to 7.7.6 (leaf-list >>>>>>> version) and 7.8.5 (list version): >>>>>>> >>>>>>> The XML elements representing leaf-list entries MUST appear in the >>>>>>> order specified by the user if the leaf-list is "ordered-by user", >>>>>>> otherwise the order is implementation-dependent. The XML elements >>>>>>> representing leaf-list entries MAY be interleaved with other sibling >>>>>>> elements. >>>>>>> >>>>>> Isn't it possible for lists to be interleaved as well? >>>>> Yes, that's 7.8.5, list version. Same text as above with s/leaf-//g >>>>> >>>>>> Does this impact the CLR you recently added about case members >>>>>> appearing in exact order? >>>>> No, that was for rpc input / output. >>>>> >>>> But what if a list or leaf-list is a descendant of input-stmt >>>> or output-stmt? >>> Does this work? >>> >>> The XML elements representing leaf-list entries MUST appear in the >>> order specified by the user if the leaf-list is "ordered-by user", >>> otherwise the order is implementation-dependent. The XML elements >>> representing leaf-list entries MAY be interleaved with other sibling >>> elements, unless the leaf-list defines RPC input or output >>> parameters. >>> >> The problem is that within edit-config and copy-config >> are RPC input parameters. > > 1. Are you suggesting that this would not be a problem if we didn't > have a YANG model in 4741bis? > No -- it has to do with any , not just the ones in ietf-netconf.yang. > 2. Even with the YANG model in 4741bis, the config is defined as an > anyxml, and the draft does not say anything at all about encoding > within anyxml. > > So is this really a problem? > When can the client interleave list or leaf-list entries with other siblings? Is it in any message the client sends to the server except ? (which is just ) > > /martin > Andy From randy_presuhn@mindspring.com Wed Nov 25 19:21:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7029A3A696A; Wed, 25 Nov 2009 19:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egDktmPBVe3R; Wed, 25 Nov 2009 19:21:22 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id B58193A6877; Wed, 25 Nov 2009 19:21:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ahA3rWpxNd575LLzondUA62UhDO5d1slDJH/D5ExswAgtTHWcpzhGNVdPVDfh6RW; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.53.116] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NDUuz-0003fv-Ew; Wed, 25 Nov 2009 22:21:17 -0500 Message-ID: <001801ca6e47$ab53a700$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local><20091124.000000.152719236.mbj@tail-f.com><4B0B1739.7090502@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> Date: Wed, 25 Nov 2009 19:22:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9306e75ccec835930d6608cdc1eb2cbb3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.53.116 Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG module naming conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 03:21:23 -0000 Hi - > From: "Mark Scott" > To: "Andy Bierman" ; "Martin Bjorklund" > Cc: ; > Sent: Wednesday, November 25, 2009 2:00 PM > Subject: Re: [Netconf] YANG module naming conventions ... > "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who > is solely responsible for this email and its contents. All inquiries ... If the "who" above refers to "Ericsson" (the only way the sentence is grammatical), then it's not clear how this fits in with IETF process, which presumes participation by individuals rather than corporations. Is this yet another example of auto-generated text which should simply be ignored? Randy From mbj@tail-f.com Thu Nov 26 01:05:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878E23A6B9E for ; Thu, 26 Nov 2009 01:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kci+a9FwQPZB for ; Thu, 26 Nov 2009 01:05:22 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C01C33A67F0 for ; Thu, 26 Nov 2009 01:05:22 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F0C82616001; Thu, 26 Nov 2009 10:05:16 +0100 (CET) Date: Thu, 26 Nov 2009 10:05:16 +0100 (CET) Message-Id: <20091126.100516.80150903.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B0DD47F.7060708@netconfcentral.com> References: <4B0DA670.1070404@netconfcentral.com> <20091125.225555.210436334.mbj@tail-f.com> <4B0DD47F.7060708@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] order of children X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 09:05:23 -0000 Andy Bierman wrote: > When can the client interleave list or leaf-list entries > with other siblings? Is it in any message the client > sends to the server except ? (which is just ) It cannot interleave if the node is a descendant of the rpc statement, possibly via uses, or if it is augmented into a descendant of the rpc statement. As soon as the rpc contains anyxml, there are no rules for the encoding of the anyxml contents in general. But for the anyxml in edit-config and copy-config in ietf-netconf.yang, the encoding rules for data nodes apply, which means that nodes may be interleaved. /martin From j.schoenwaelder@jacobs-university.de Fri Nov 27 01:18:57 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E2E3A69E7; Fri, 27 Nov 2009 01:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhYZvlwYfsuQ; Fri, 27 Nov 2009 01:18:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1AA633A677D; Fri, 27 Nov 2009 01:18:56 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0ACBFC000D; Fri, 27 Nov 2009 10:18:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bdGdkYB+iLcF; Fri, 27 Nov 2009 10:18:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35EC1C0009; Fri, 27 Nov 2009 10:18:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0FE24E374B5; Fri, 27 Nov 2009 10:18:46 +0100 (CET) Date: Fri, 27 Nov 2009 10:18:46 +0100 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20091127091846.GA12557@elstar.local> Mail-Followup-To: Mark Scott , Andy Bierman , Martin Bjorklund , "netconf@ietf.org" , "netmod@ietf.org" References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local> <20091124.000000.152719236.mbj@tail-f.com> <4B0B1739.7090502@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] YANG module naming conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 09:18:57 -0000 On Wed, Nov 25, 2009 at 11:00:23PM +0100, Mark Scott wrote: > I agree we don't need to align the top-level container - and will keep > /netconf-state/. > > I also dislike the redundancy and will update the namespace to > 'urn:ietf:params:xml:ns:yang:netconf-monitoring'. > - maybe update the yang usage guidelines accordingly? If there is agreement to not carry the module name in the URN, we should indeed document that agreement and all modules should stick to the documented agreement. So there is no "maybe". And yes, "ietf" is redundant but then special casing the removal of a module name prefix for generating the URN does not really seem to make things simpler. For me, urn:ietf:params:xml:ns:yang:$MODULENAME is simpler than urn:ietf:params:xml:ns:yang:`echo $MODULENAME | sed s/^ietf-//` and this special casing will also lead to subsequent questions about how we deal with modules coming from other RFC streams. For me, simply copying the module name after the urn:ietf:params:xml:ns:yang: prefix is as simple as it can get (I can even get the module name from the namespace in the payload with straight cut'n paste). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Sun Nov 29 09:54:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FDA3A682B for ; Sun, 29 Nov 2009 09:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBbWQtJFdqvb for ; Sun, 29 Nov 2009 09:54:02 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 119823A67F3 for ; Sun, 29 Nov 2009 09:54:02 -0800 (PST) Received: (qmail 73519 invoked from network); 29 Nov 2009 17:53:53 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 29 Nov 2009 09:53:53 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: DxnwaX0VM1mmRPAeFcpPcNvEv9rcYvquoQPdHSi9keiqjBDD2j34asyMMJs1M2whFoLeeqFdqt8MFx6y9yNQztPOH2gZRbO0cwJ7DQbvQR5oKPBw_0Wp1BIvWVJS1CPpSSpDc.mMiEQQPh0TifoAW1EJJjKm6kdhgdo4vOEsB0Zs._yeXgkqjXaHO7hK4orcb4xVgiwBXQtCGGGkOZsRXWPErcsbl9U00WyjYQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B12B4BA.10800@netconfcentral.com> Date: Sun, 29 Nov 2009 09:51:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] 1 when-stmt vs. N must-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:54:02 -0000 Hi, It seems odd to me that only 1 when-stmt is allowed instead of AND-ing N of them together, like must-stmt. There is already an implicit AND of when-stmts via uses-stmt chain and augment-stmt chain. The use-cases are really the same as must-stmt: - more flexibility for the YANG writer - easier to read for non-XPath experts - allows new 'when' constraints to be added to existing 'when' constraints more cleanly We force all 'when' constraints into 1 giant XPath expression, but not 'must' constraints. Do we have a good reason for doing this, and I just missed that meeting? Andy From mbj@tail-f.com Sun Nov 29 23:25:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A663A68B1 for ; Sun, 29 Nov 2009 23:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp4kUOdbRb2h for ; Sun, 29 Nov 2009 23:25:36 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 79BCB3A67C1 for ; Sun, 29 Nov 2009 23:25:36 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EF39616001; Mon, 30 Nov 2009 08:25:28 +0100 (CET) Date: Mon, 30 Nov 2009 08:25:27 +0100 (CET) Message-Id: <20091130.082527.149650092.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4B12B4BA.10800@netconfcentral.com> References: <4B12B4BA.10800@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] 1 when-stmt vs. N must-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 07:25:37 -0000 Hi, Andy Bierman wrote: > It seems odd to me that only 1 when-stmt is allowed > instead of AND-ing N of them together, like must-stmt. > > There is already an implicit AND of when-stmts via > uses-stmt chain and augment-stmt chain. I don't understand what you mean. Can you give an example? > The use-cases are really the same as must-stmt: > - more flexibility for the YANG writer > - easier to read for non-XPath experts > - allows new 'when' constraints to be added > to existing 'when' constraints more cleanly When you look at multiple XPath expressions, you can view each of them independently - each such must expression must be true in a valid data model. When you write multiple must expressions, you probably make them independent, i.e. each must expression verifies one specific property. If we had multiple when expressions that were AND:ed together, you can not view each of them independently. If one such when expression is true, the object does not necessarily exist. Another way of seeing this is that the data model makes sense even if you don't take all must expressions into account, but with AND:ed when expressions, you need to take all of them into account in order to understand the data model. > We force all 'when' constraints into 1 giant XPath > expression, but not 'must' constraints. > Do we have a good reason for doing this, > and I just missed that meeting? I think we allowed mulitple must expressions so that you can have different error-message and/or error-app-tag statements for independent expressions. This doesn't apply to when. /martin From andy@netconfcentral.com Mon Nov 30 01:57:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045BC3A6864 for ; Mon, 30 Nov 2009 01:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_32=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPtttOoA8AHF for ; Mon, 30 Nov 2009 01:57:07 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 4C6093A6819 for ; Mon, 30 Nov 2009 01:57:07 -0800 (PST) Received: (qmail 43502 invoked from network); 30 Nov 2009 09:56:58 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2009 01:56:58 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: I4tqFEEVM1nC1a9.oM7c5dyGqIQyGI57BaJc1HHIBsb1aa1kctL26chn.dxi9BVuO5aN2D7c9tMP6M3o3.yol8jKSDbwhAz9Lf1Aee03m__mLbh.ZWAZHp_fe1UscwLE8u4Twjonx9y3zn2bBMKx0uEdrrDf1GkhxzdlGcm4QA0NqesyPzjS_w.nJc5SgqYWex_FiJMpHyVnF2hpDEHrUgaElmQo0VjUeqDFt4suDL3EgVUcfIq8UC2mNI.iHef3XczOmfXIkyYGXhbyNszDYeEsTYovcwGDtVK86PsgBhn3S_sJRIZ59DzfuRhMIQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B13967C.9050604@netconfcentral.com> Date: Mon, 30 Nov 2009 01:55:08 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B12B4BA.10800@netconfcentral.com> <20091130.082527.149650092.mbj@tail-f.com> In-Reply-To: <20091130.082527.149650092.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] 1 when-stmt vs. N must-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 09:57:08 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> It seems odd to me that only 1 when-stmt is allowed >> instead of AND-ing N of them together, like must-stmt. >> >> There is already an implicit AND of when-stmts via >> uses-stmt chain and augment-stmt chain. > > I don't understand what you mean. Can you give an example? > uses-stmt and augment-stmt both allow the when-stmt, right? These get added in with the normal when-stmt: grouping x { leaf bar { when "../foo > 3"; type string; } leaf foo { type int32; } } ... uses x { when "/a > 4"; } This obviously creates a combined 'when-stmt': when "(../foo > 3) and (/a > 4)"; The AND expression can grow via augment and uses-stmt within groupings. >> The use-cases are really the same as must-stmt: >> - more flexibility for the YANG writer >> - easier to read for non-XPath experts >> - allows new 'when' constraints to be added >> to existing 'when' constraints more cleanly > > When you look at multiple XPath expressions, you can view each of them > independently - each such must expression must be true in a valid data > model. When you write multiple must expressions, you probably make > them independent, i.e. each must expression verifies one specific > property. The same is true for 'when' stmt. All of them must be true for the expression to be true. I don't see how must-stmt is any different than when-stmt in this respect. > > If we had multiple when expressions that were AND:ed together, you can > not view each of them independently. If one such when expression is > true, the object does not necessarily exist. > This is nonsense. Of course you can view them just as independently as must-stmt, which is not at all. Must-stmts are not independent. They are all ANDed together, so ignoring some of them is not possible. > Another way of seeing this is that the data model makes sense even if > you don't take all must expressions into account, but with AND:ed when > expressions, you need to take all of them into account in order to > understand the data model. > There is no difference between must and when in this area. >> We force all 'when' constraints into 1 giant XPath >> expression, but not 'must' constraints. >> Do we have a good reason for doing this, >> and I just missed that meeting? > > I think we allowed mulitple must expressions so that you can have > different error-message and/or error-app-tag statements for > independent expressions. This doesn't apply to when. > The ANDing of must-stmts is no different than the ANDing of when-stmts from a data modeling perspective. > > /martin > > > > Andy From lhotka@cesnet.cz Mon Nov 30 05:04:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D053A6A66 for ; Mon, 30 Nov 2009 05:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgJCv7b5UYBW for ; Mon, 30 Nov 2009 05:04:03 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 017493A6A50 for ; Mon, 30 Nov 2009 05:04:02 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E825CD800C0; Mon, 30 Nov 2009 14:03:54 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B12B4BA.10800@netconfcentral.com> References: <4B12B4BA.10800@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 30 Nov 2009 14:03:53 +0100 Message-ID: <1259586233.7917.66.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] 1 when-stmt vs. N must-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 13:04:03 -0000 Andy Bierman píše v Ne 29. 11. 2009 v 09:51 -0800: > Hi, > > > It seems odd to me that only 1 when-stmt is allowed > instead of AND-ing N of them together, like must-stmt. > > There is already an implicit AND of when-stmts via > uses-stmt chain and augment-stmt chain. > > The use-cases are really the same as must-stmt: > - more flexibility for the YANG writer > - easier to read for non-XPath experts > - allows new 'when' constraints to be added > to existing 'when' constraints more cleanly > > > We force all 'when' constraints into 1 giant XPath > expression, but not 'must' constraints. > Do we have a good reason for doing this, > and I just missed that meeting? In my view, the 'when' mechanism is very scary, so I wouldn't make it any easier to use. More restrictions may actually be needed, because 'when' can lead to situations like this: leaf foo { type uint8; default 42; when "bar!=1"; } leaf bar { type uint8; default 1; when "foo!=42"; } If neither "foo" nor "bar" is present in an XML instance, we are in a nice deadlock: if the defaults apply, 'when' statements make both leafs invalid and so the defaults cannot apply. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Nov 30 05:29:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145A828C10E for ; Mon, 30 Nov 2009 05:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smGKzHaN7YiI for ; Mon, 30 Nov 2009 05:29:01 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4C8C33A6A4A for ; Mon, 30 Nov 2009 05:29:01 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 99218D80095 for ; Mon, 30 Nov 2009 14:28:53 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <1259586233.7917.66.camel@missotis> References: <4B12B4BA.10800@netconfcentral.com> <1259586233.7917.66.camel@missotis> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 30 Nov 2009 14:28:52 +0100 Message-ID: <1259587732.7917.72.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] 1 when-stmt vs. N must-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 13:29:02 -0000 Ladislav Lhotka píše v Po 30. 11. 2009 v 14:03 +0100: > > In my view, the 'when' mechanism is very scary, so I wouldn't make it > any easier to use. More restrictions may actually be needed, because > 'when' can lead to situations like this: > Sorry, the XPath expressions were wrong, this is the correct version: > leaf foo { > type uint8; > default 42; > when "not(../bar=1)"; > } > leaf bar { > type uint8; > default 1; > when "not(../foo=42)"; > } > > If neither "foo" nor "bar" is present in an XML instance, we are in a > nice deadlock: if the defaults apply, 'when' statements make both leafs > invalid and so the defaults cannot apply. > Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.partain@ericsson.com Mon Nov 30 06:00:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4C43A6811; Mon, 30 Nov 2009 06:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01LKVu-twpMY; Mon, 30 Nov 2009 06:00:49 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E5E213A676A; Mon, 30 Nov 2009 06:00:48 -0800 (PST) X-AuditID: c1b4fb3e-b7b33ae0000045f9-33-4b13d00871c0 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 14.1E.17913.800D31B4; Mon, 30 Nov 2009 15:00:40 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 15:00:40 +0100 Received: from selic023.ki.sw.ericsson.se ([147.214.22.154]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 15:00:40 +0100 From: David Partain Organization: Ericsson AB To: netconf@ietf.org, "NETMOD Working Group" Date: Mon, 30 Nov 2009 15:00:53 +0100 User-Agent: KMail/1.9.10 References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911301500.53656.david.partain@ericsson.com> X-OriginalArrivalTime: 30 Nov 2009 14:00:40.0627 (UTC) FILETIME=[802AE030:01CA71C5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 14:00:50 -0000 Greetings, > If you agree with the conclusion having 'with-defaults' > as SHOULD to implement in 4741bis please state so. +1 or... Yes, I agree with this conclusion. Cheers, David From andy@netconfcentral.com Mon Nov 30 07:54:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2014D3A68D6 for ; Mon, 30 Nov 2009 07:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0s7hXlbtthJ for ; Mon, 30 Nov 2009 07:54:06 -0800 (PST) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 58CF43A680F for ; Mon, 30 Nov 2009 07:54:06 -0800 (PST) Received: (qmail 40759 invoked from network); 30 Nov 2009 15:53:57 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 30 Nov 2009 07:53:56 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: iXHC5NAVM1nqToHhk.rPv7nVSI0JD1Q_FtCkRJ1acUz8uzU_qQCFGCm.VG_iS6EqijBKXt.FazRk.sp4liQqvoCejfz7eSvg57N8iBiIc3shSd5L.kD76LhwYtbOnSg5UAs0QCuyTQRDxORUpCDg_UYmUqXUkhQbtmnVpwzaOt3x0zODN9NqNfaLZfv27YHpJWHt6gmFiAg8DNH_AisG2CgvAwXFsEuojkxRcF99FwQNk4CwXtfQu1JBt4DGYjSY X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B13EAA3.9020408@netconfcentral.com> Date: Mon, 30 Nov 2009 07:54:11 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <4B12B4BA.10800@netconfcentral.com> <1259586233.7917.66.camel@missotis> In-Reply-To: <1259586233.7917.66.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] 1 when-stmt vs. N must-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 15:54:07 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Ne 29. 11. 2009 v 09:51 -0800: >> Hi, >> >> >> It seems odd to me that only 1 when-stmt is allowed >> instead of AND-ing N of them together, like must-stmt. >> >> There is already an implicit AND of when-stmts via >> uses-stmt chain and augment-stmt chain. >> >> The use-cases are really the same as must-stmt: >> - more flexibility for the YANG writer >> - easier to read for non-XPath experts >> - allows new 'when' constraints to be added >> to existing 'when' constraints more cleanly >> >> >> We force all 'when' constraints into 1 giant XPath >> expression, but not 'must' constraints. >> Do we have a good reason for doing this, >> and I just missed that meeting? > > In my view, the 'when' mechanism is very scary, so I wouldn't make it > any easier to use. More restrictions may actually be needed, because > 'when' can lead to situations like this: > Logic would suggest that the more difficult it is to use, the more scary it becomes, not the other way around. > leaf foo { > type uint8; > default 42; > when "bar!=1"; > } > leaf bar { > type uint8; > default 1; > when "foo!=42"; > } > > If neither "foo" nor "bar" is present in an XML instance, we are in a > nice deadlock: if the defaults apply, 'when' statements make both leafs > invalid and so the defaults cannot apply. > What does this have to do with splitting a big AND expression into multiple sub-expressions? The scenario you describe is a problem even with 1 when-stmt per leaf. > Lada > Andy From MARKSCOT@nortel.com Mon Nov 30 07:58:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8C93A6A95; Mon, 30 Nov 2009 07:58:30 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqoYYCwO7kM2; Mon, 30 Nov 2009 07:58:30 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CA75D3A6939; Mon, 30 Nov 2009 07:58:29 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAUFwHL09587; Mon, 30 Nov 2009 15:58:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 10:57:30 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B5E4198@zcarhxm2.corp.nortel.com> In-Reply-To: <200911301500.53656.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis Thread-Index: AcpxxYyYdvyNHpxdQlKdHmV8md7GyAAD/RuQ References: <80A0822C5E9A4440A5117C2F4CD36A641A0C02@DEMUEXC006.nsn-intra.net> <200911301500.53656.david.partain@ericsson.com> From: "Mark Scott" To: "David Partain" , , "NETMOD Working Group" Subject: Re: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 15:58:31 -0000 +1 in favour of SHOULD. Mark "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com." -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of David Partain Sent: Monday, November 30, 2009 9:01 AM To: netconf@ietf.org; NETMOD Working Group Subject: Re: [netmod] Consensus call: With-Defaults as SHOULD in 4741bis Greetings, > If you agree with the conclusion having 'with-defaults' > as SHOULD to implement in 4741bis please state so. +1=20 or... Yes, I agree with this conclusion. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From lhotka@cesnet.cz Mon Nov 30 08:24:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFE13A6950 for ; Mon, 30 Nov 2009 08:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsA4uJAbwKQU for ; Mon, 30 Nov 2009 08:24:33 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 71AB03A694F for ; Mon, 30 Nov 2009 08:24:33 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DB709D800C0; Mon, 30 Nov 2009 17:24:25 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4B13EAA3.9020408@netconfcentral.com> References: <4B12B4BA.10800@netconfcentral.com> <1259586233.7917.66.camel@missotis> <4B13EAA3.9020408@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 30 Nov 2009 17:24:24 +0100 Message-ID: <1259598264.7917.106.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] 1 when-stmt vs. N must-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:24:34 -0000 Andy Bierman píše v Po 30. 11. 2009 v 07:54 -0800: > > > > In my view, the 'when' mechanism is very scary, so I wouldn't make it > > any easier to use. More restrictions may actually be needed, because > > 'when' can lead to situations like this: > > > > Logic would suggest that the more difficult > it is to use, the more scary it becomes, not the > other way around. The easier it is to use, the more module authors may be tempted to really use it. Mostly (always?) there are alternatives for expressing the same constraint, e.g., using 'must'. > > > > leaf foo { > > type uint8; > > default 42; > > when "bar!=1"; > > } > > leaf bar { > > type uint8; > > default 1; > > when "foo!=42"; > > } > > > > If neither "foo" nor "bar" is present in an XML instance, we are in a > > nice deadlock: if the defaults apply, 'when' statements make both leafs > > invalid and so the defaults cannot apply. > > > > What does this have to do with splitting a big AND expression > into multiple sub-expressions? The scenario you describe > is a problem even with 1 when-stmt per leaf. Indeed, but multiple statements may create unexpected combinations, especially when one part comes from a remote place via augment. A single expression can always be inspected in its entirety. What does actually 'when' under 'uses' mean? This case seems to be missing in Sec. 7.19.5. Lada > > > Lada > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Nov 30 09:08:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5020C3A67F2 for ; Mon, 30 Nov 2009 09:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfWoLgpy2NDx for ; Mon, 30 Nov 2009 09:08:22 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 5C4DD3A6359 for ; Mon, 30 Nov 2009 09:08:22 -0800 (PST) Received: (qmail 94666 invoked from network); 30 Nov 2009 17:08:12 -0000 Received: from adsl-67-125-158-117.dsl.irvnca.pacbell.net (andy@67.125.158.117 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 30 Nov 2009 09:08:12 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: MwlGUFwVM1nYiz1OfF5vEL3XXsnyakD0xzNurAqc5ZF0sUK6NlNIdtF21h5vN3CV1ufUKrKAuSZfRSdtRkDZkWoRSb4Ch.jYRPy0belAm9v9xC9l1oyv68Q.5bxlZTSzTZ03E1S4iphvKkGDzoAHQrpZJmg.Cp4ik2r10GLuD9an3Sc84oPItPZukSD2HKrpnhYn1bv3AIahEojB79AT80DwSiHKuHlxqRrIc.jFEYmb8e7m0JsT6yMxIpDv7W9Z X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B13FB91.7010208@netconfcentral.com> Date: Mon, 30 Nov 2009 09:06:25 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <4B12B4BA.10800@netconfcentral.com> <1259586233.7917.66.camel@missotis> <4B13EAA3.9020408@netconfcentral.com> <1259598264.7917.106.camel@missotis> In-Reply-To: <1259598264.7917.106.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] 1 when-stmt vs. N must-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:08:23 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 30. 11. 2009 v 07:54 -0800: > >>> In my view, the 'when' mechanism is very scary, so I wouldn't make it >>> any easier to use. More restrictions may actually be needed, because >>> 'when' can lead to situations like this: >>> >> Logic would suggest that the more difficult >> it is to use, the more scary it becomes, not the >> other way around. > > The easier it is to use, the more module authors may be tempted to > really use it. Mostly (always?) there are alternatives for expressing > the same constraint, e.g., using 'must'. > >> >>> leaf foo { >>> type uint8; >>> default 42; >>> when "bar!=1"; >>> } >>> leaf bar { >>> type uint8; >>> default 1; >>> when "foo!=42"; >>> } >>> >>> If neither "foo" nor "bar" is present in an XML instance, we are in a >>> nice deadlock: if the defaults apply, 'when' statements make both leafs >>> invalid and so the defaults cannot apply. >>> >> What does this have to do with splitting a big AND expression >> into multiple sub-expressions? The scenario you describe >> is a problem even with 1 when-stmt per leaf. > > Indeed, but multiple statements may create unexpected combinations, > especially when one part comes from a remote place via augment. > A single expression can always be inspected in its entirety. > We already have this situation. The when-stmts can be spread out all over the place -- that is the nature of groupings. My proposal does not affect any of these issues that have been raised. CURRENT: leaf X { when "A and B and C"; must D; must E; must F; type string; } PROPOSED: leaf X { when A; when B; when C; must D; must E; must F; type string; } >From an XPath POV, there is no reason whatsoever to treat must-stmt differently than when-stmt. >From an implementation POV, the server already knows how to AND some XPath expressions together because must-stmt requires this functionality. Why doesn't the when-stmt have description-stmt and reference-stmt sub-clauses like must-stmt? This is a good use-case for needing to split the when-stmt into multiple sub-expressions. must-stmt = must-keyword sep string optsep (";" / "{" stmtsep ;; these stmts can appear in any order [error-message-stmt stmtsep] [error-app-tag-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}") when-stmt = when-keyword sep string stmtend Does the WG think that XPath expressions for 'must' constraints will be hard to understand, but not 'when' expressions? If so, why? > What does actually 'when' under 'uses' mean? This case seems to be > missing in Sec. 7.19.5. It means the uses-stmt does not really get expanded except when the when-stmt expression is true. The 'static' schema tree for the database changes on the fly, based on the contents of the database. (Talk about scary...) > > Lada > >>> Lada >>> >> Andy >> > > Andy From MARKSCOT@nortel.com Mon Nov 30 10:22:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751723A6AAD; Mon, 30 Nov 2009 10:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4dIw3KtleQk; Mon, 30 Nov 2009 10:22:18 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 466073A693C; Mon, 30 Nov 2009 10:22:18 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAUIM7L23619; Mon, 30 Nov 2009 18:22:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 13:21:58 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B64793A@zcarhxm2.corp.nortel.com> In-Reply-To: <001801ca6e47$ab53a700$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] YANG module naming conventions Thread-Index: AcpuR5tt4t3XlEnmSE2ZMomC/oyPoADoDd8g References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local><20091124.000000.152719236.mbj@tail-f.com><4B0B1739.7090502@netconfcentral.com><713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> <001801ca6e47$ab53a700$6801a8c0@oemcomputer> From: "Mark Scott" To: "Randy Presuhn" , Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG module naming conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:22:19 -0000 Randy, As a result of the acquisition of certain Nortel assets by Ericsson all emails originating from associated accounts must have this (exact) text appended. Please ignore the text. cheers, Mark "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com." -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, November 25, 2009 10:22 PM To: netconf@ietf.org Cc: netmod@ietf.org Subject: Re: [Netconf] YANG module naming conventions Hi - =20 > From: "Mark Scott" > To: "Andy Bierman" ; "Martin Bjorklund" > Cc: ; > Sent: Wednesday, November 25, 2009 2:00 PM > Subject: Re: [Netconf] YANG module naming conventions ... > "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who > is solely responsible for this email and its contents. All inquiries ... If the "who" above refers to "Ericsson" (the only way the sentence is grammatical), then it's not clear how this fits in with IETF process, which presumes participation by individuals rather than corporations. Is this yet another example of auto-generated text which should simply be ignored? Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From MARKSCOT@nortel.com Mon Nov 30 12:32:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852A73A685E; Mon, 30 Nov 2009 12:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvCDjGcGXtIh; Mon, 30 Nov 2009 12:32:54 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4E0FF3A6904; Mon, 30 Nov 2009 12:32:54 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAUKWAL00171; Mon, 30 Nov 2009 20:32:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 15:31:56 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41B647CB7@zcarhxm2.corp.nortel.com> In-Reply-To: <20091127091846.GA12557@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] [Netconf] YANG module naming conventions Thread-Index: AcpvQqNRW5ls22PeT5eGCYbiuwHarwCuVZIA References: <713043CE8B8E1348AF3C546DBE02C1B41B48EB78@zcarhxm2.corp.nortel.com> <20091123215203.GA9240@elstar.local> <20091124.000000.152719236.mbj@tail-f.com> <4B0B1739.7090502@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B41B542E18@zcarhxm2.corp.nortel.com> <20091127091846.GA12557@elstar.local> From: "Mark Scott" To: "Juergen Schoenwaelder" Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG module naming conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:32:55 -0000 Agree. No special case required and the complete module name is used in the URN (see v10). Mark "The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who is solely responsible for this email and its contents. All inquiries regarding this email should be addressed to Ericsson. Nortel has provided the use of the nortel.com domain to Ericsson in connection with this email solely for the purpose of connectivity and Nortel Networks has no liability for the email or its contents. The web site for Ericsson is www.ericsson.com." -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, November 27, 2009 4:19 AM To: Scott, Mark ERICSSON (CAR:2N00) Cc: Andy Bierman; Martin Bjorklund; netconf@ietf.org; netmod@ietf.org Subject: Re: [netmod] [Netconf] YANG module naming conventions On Wed, Nov 25, 2009 at 11:00:23PM +0100, Mark Scott wrote: > I agree we don't need to align the top-level container - and will keep > /netconf-state/. >=20 > I also dislike the redundancy and will update the namespace to > 'urn:ietf:params:xml:ns:yang:netconf-monitoring'. > - maybe update the yang usage guidelines accordingly? If there is agreement to not carry the module name in the URN, we should indeed document that agreement and all modules should stick to the documented agreement. So there is no "maybe". And yes, "ietf" is redundant but then special casing the removal of a module name prefix for generating the URN does not really seem to make things simpler. For me, urn:ietf:params:xml:ns:yang:$MODULENAME is simpler than urn:ietf:params:xml:ns:yang:`echo $MODULENAME | sed s/^ietf-//` and this special casing will also lead to subsequent questions about how we deal with modules coming from other RFC streams. For me, simply copying the module name after the urn:ietf:params:xml:ns:yang: prefix is as simple as it can get (I can even get the module name from the namespace in the payload with straight cut'n paste). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103