From owner-netconf@ops.ietf.org Wed Feb 01 00:57:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Azk-0007F4-Vc for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 00:57:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10344 for ; Wed, 1 Feb 2006 00:55:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Asc-000LXj-FM for netconf-data@psg.com; Wed, 01 Feb 2006 05:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.179.9.4] (helo=mail3.extremenetworks.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Asa-000LX9-GL for netconf@ops.ietf.org; Wed, 01 Feb 2006 05:50:08 +0000 Received: by mail3 with Internet Mail Service (5.5.2657.72) id ; Tue, 31 Jan 2006 21:50:07 -0800 Message-ID: <3DC3910A44FBD94B8513C8E2A3F220E101112F95@sc-msexch-16.extremenetworks.com> From: Zihong Lu To: "'Vincent Cridlig'" , ?? , netconf@ops.ietf.org Cc: Zihong Lu Subject: RE: how people implement in netconf over SOAP? Date: Tue, 31 Jan 2006 21:49:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks for replying. =20 Yes I am aware of that the filter selection model is vendor specific, = as described in the spec. Just wonder how you as a "vendor" implement = this. =20 One way to do it would be to hard-code your specific selection model = into your SOAP skeleton code, for example, use type mapping in gSoap. That = will avoid the XML parsing, but still, you are dealing with struct within = struct within struct, in C term. The other way is what I have suspected, and probably should be a new project like Ted Goddard suggested when I communicated with him a while back, to have a toolkit that handles the struct within struct within struct, to have a straight forward handling function like getFilterData(target t) The other problem that I have with the current netconf design is that = it doesn't allow vendors a chance to reinforce the schema, at the filter = level or at the config level, since there is no mechanism to show the data = model within the SOAP netconf wsdl, which leave a big hole in web services. = Not sure how people deal with this problem. Any suggesstion is highly appreciated. -Zihong > -----Original Message----- > From: Vincent Cridlig [mailto:vincent.cridlig@loria.fr] > Sent: Monday, January 30, 2006 12:04 AM > To: ?? > Cc: zlu@extremenetworks.com > Subject: Re: how people implement in netconf over SOAP? >=20 >=20 > Yes, it is the vendor's job. >=20 > "filter" is totally independant of the underlying application=20 > protocol=20 > (SOAP, SSH, BEEP...). > "filter" node selection model is Netconf-specific and, to my=20 > knowledge,=20 > no libraries are freely available. >=20 > Vincent >=20 >=20 > =E7=8E=8B=E7=BD=95 wrote: >=20 > >I guess it should be the vedors' job. > > > = >=C3=94=C3=9A=C3=84=C3=BA=C2=B5=C3=84=C3=80=C2=B4=C3=90=C3=85=C3=96=C3=90= =C3=94=C3=B8=C2=BE=C2=AD=C3=8C=C3=A1=C2=B5=C2=BD: > > =20 > > > >>From: Zihong Lu > >>Reply-To:=20 > >>To: "'netconf@ops.ietf.org'" > >>Subject: how people implement in netconf over SOAP? > >>Date:Fri, 27 Jan 2006 11:07:12 -0800 > >> > >> > >> > >> > >> =20 > >> > >>>I am looking into the implementation detail of netconf=20 > over SOAP. Wonder > >>>how people implement in SOAP. Can any one please=20 > shed some > >>>light? =20 > >>> > >>> > >>>In general, SOAP is a service function based protocol. It=20 > should be > >>>possible to be message-based, but it will not be as easy=20 > to implement, and > >>>the SOAP benefit will mostly be lost. For example, the=20 > part, > >>>we have a message looks like this: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> =20 > >>> > > > > > > > >-- > >to unsubscribe send a message to netconf-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > =20 > > >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 03:18:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4DBf-0002Fv-Tc for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 03:18:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21080 for ; Wed, 1 Feb 2006 03:16:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4D59-0003Qc-SH for netconf-data@psg.com; Wed, 01 Feb 2006 08:11:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4D57-0003QG-Cu for netconf@ops.ietf.org; Wed, 01 Feb 2006 08:11:13 +0000 Received: (qmail 18363 invoked from network); 1 Feb 2006 08:11:12 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 1 Feb 2006 08:11:12 -0000 Message-ID: <43E06D1F.4090504@andybierman.com> Date: Wed, 01 Feb 2006 00:11:11 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andy Bierman , "Netconf (E-mail)" Subject: Re: terminology change References: <43E01AFF.4000304@andybierman.com> <20060201044326.GA20461@noname> In-Reply-To: <20060201044326.GA20461@noname> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Tue, Jan 31, 2006 at 06:20:47PM -0800, Andy Bierman wrote: > > >> We are going back to our original term "transport mapping", >> which aligns with our architecture diagrams (which include >> the transport, rpc, operations, and application layers). >> > > Thank you very much. Very strong support from me here. > Funny how we were just discussing this on the MIB Doctors list, but this is a case where one IESG reviewer told us to change a WG selected term to something else. We did that. We didn't like it, but we did it. Then a subsequent review points out that our terminology is totally confusing, why would we do it that way, please change it back. This is the problem with subjective reviews... > /js > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 03:57:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4DoI-0007G0-BA for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 03:57:54 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23442 for ; Wed, 1 Feb 2006 03:56:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Dj7-0005sA-S1 for netconf-data@psg.com; Wed, 01 Feb 2006 08:52:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Dj5-0005rQ-8m for netconf@ops.ietf.org; Wed, 01 Feb 2006 08:52:31 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4F5564D941; Wed, 1 Feb 2006 09:52:30 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04710-10; Wed, 1 Feb 2006 09:52:27 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3708E4D8D2; Wed, 1 Feb 2006 09:52:27 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 723255E2883; Wed, 1 Feb 2006 09:52:28 +0100 (CET) Date: Wed, 1 Feb 2006 09:52:28 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Netconf (E-mail)" Subject: Re: terminology change Message-ID: <20060201085228.GA21100@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , "Netconf (E-mail)" References: <43E01AFF.4000304@andybierman.com> <20060201044326.GA20461@noname> <43E06D1F.4090504@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E06D1F.4090504@andybierman.com> Fcc: =SENT User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Feb 01, 2006 at 12:11:11AM -0800, Andy Bierman wrote: > Funny how we were just discussing this on the MIB Doctors list, > but this is a case where one IESG reviewer told us to change > a WG selected term to something else. We did that. We didn't > like it, but we did it. Then a subsequent review points out > that our terminology is totally confusing, why would we do it > that way, please change it back. > > This is the problem with subjective reviews... Would life not be boring without all this? ;-) What really matters is that at the end we use the IMHO right term. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 05:00:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4EmK-0006ar-Ay for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 05:00:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27801 for ; Wed, 1 Feb 2006 04:58:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4EgN-0009RA-VT for netconf-data@psg.com; Wed, 01 Feb 2006 09:53:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4EgK-0009Qw-Ae for netconf@ops.ietf.org; Wed, 01 Feb 2006 09:53:44 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E5DBF62F8A; Wed, 1 Feb 2006 10:53:42 +0100 (CET) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id D2E2C61B68; Wed, 1 Feb 2006 10:41:29 +0100 (CET) Message-ID: <43E082D3.4050006@loria.fr> Date: Wed, 01 Feb 2006 10:43:47 +0100 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zihong Lu Cc: ?? , netconf@ops.ietf.org Subject: Re: how people implement in netconf over SOAP? References: <3DC3910A44FBD94B8513C8E2A3F220E101112F95@sc-msexch-16.extremenetworks.com> In-Reply-To: <3DC3910A44FBD94B8513C8E2A3F220E101112F95@sc-msexch-16.extremenetworks.com> Content-Type: multipart/mixed; boundary="------------080201070904040304040106" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080201070904040304040106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA27801 Zihong Lu wrote: >Thanks for replying. =20 > >Yes I am aware of that the filter selection model is vendor specific, as >described in the spec. Just wonder how you as a "vendor" implement this= . =20 > =20 > Here is how we implement it in YencaP: The agent builds a super set of the config contained in the filter. This=20 super set is the document that will be filtered. This super set is a subset of the whole config (running, for example): "filter config" smaller than "super set" smaller than "running" How we build this super set is specific to our software. It uses a=20 partial cache document and XPath to find the sub data models involved. Then, a recursive algorithm is processing the filter, looking for=20 content match nodes, selection nodes, ... at each XML level. Each XML level matches a recursive level. I know this is not optimal in terms of cpu consumption but it is easy to=20 implement and it works (pretty fast). Hope this helps, Vincent >One way to do it would be to hard-code your specific selection model int= o >your SOAP skeleton code, for example, use type mapping in gSoap. That w= ill >avoid the XML parsing, but still, you are dealing with struct within str= uct >within struct, in C term. The other way is what I have suspected, and >probably should be a new project like Ted Goddard suggested when I >communicated with him a while back, to have a toolkit that handles the >struct within struct within struct, to have a straight forward handling >function like > > getFilterData(target t) > >The other problem that I have with the current netconf design is that it >doesn't allow vendors a chance to reinforce the schema, at the filter le= vel >or at the config level, since there is no mechanism to show the data mod= el >within the SOAP netconf wsdl, which leave a big hole in web services. N= ot >sure how people deal with this problem. Any suggesstion is highly >appreciated. > >-Zihong > > > > =20 > >>-----Original Message----- >>From: Vincent Cridlig [mailto:vincent.cridlig@loria.fr] >>Sent: Monday, January 30, 2006 12:04 AM >>To: ?? >>Cc: zlu@extremenetworks.com >>Subject: Re: how people implement in netconf over SOAP? >> >> >>Yes, it is the vendor's job. >> >>"filter" is totally independant of the underlying application=20 >>protocol=20 >>(SOAP, SSH, BEEP...). >>"filter" node selection model is Netconf-specific and, to my=20 >>knowledge,=20 >>no libraries are freely available. >> >>Vincent >> >> >>=E7=8E=8B=E7=BD=95 wrote: >> >> =20 >> >>>I guess it should be the vedors' job. >>> >>>=C3=94=C3=9A=C3=84=C3=BA=C2=B5=C3=84=C3=80=C2=B4=C3=90=C3=85=C3=96=C3=90= =C3=94=C3=B8=C2=BE=C2=AD=C3=8C=C3=A1=C2=B5=C2=BD: >>>=20 >>> >>> =20 >>> >>>>From: Zihong Lu >>>>Reply-To:=20 >>>>To: "'netconf@ops.ietf.org'" >>>>Subject: how people implement in netconf over SOAP? >>>>Date:Fri, 27 Jan 2006 11:07:12 -0800 >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>I am looking into the implementation detail of netconf=20 >>>>> =20 >>>>> >>over SOAP. Wonder >> =20 >> >>>>>how people implement in SOAP. Can any one please=20 >>>>> =20 >>>>> >>shed some >> =20 >> >>>>>light? =20 >>>>> >>>>> >>>>>In general, SOAP is a service function based protocol. It=20 >>>>> =20 >>>>> >>should be >> =20 >> >>>>>possible to be message-based, but it will not be as easy=20 >>>>> =20 >>>>> >>to implement, and >> =20 >> >>>>>the SOAP benefit will mostly be lost. For example, the=20 >>>>> =20 >>>>> >> part, >> =20 >> >>>>>we have a message looks like this: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>> >>>-- >>>to unsubscribe send a message to netconf-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>>=20 >>> >>> =20 >>> >> =20 >> --------------080201070904040304040106 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Disposition: attachment; filename="vincent.cridlig.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQNCmZuOlZpbmNlbnQgQ3JpZGxpZw0KbjpDcmlkbGlnO1ZpbmNlbnQNCm9y ZzpMT1JJQSAtIElOUklBIExvcnJhaW5lO01hZHluZXMNCmFkcjo7OztOYW5jeTs7O0ZyYW5j ZQ0KZW1haWw7aW50ZXJuZXQ6Y3JpZGxpZ3ZAbG9yaWEuZnINCnRpdGxlOlBoRCBTdHVkZW50 DQp0ZWw7d29yazorMzMgKDApMyA4MyA1OSAyMCA0OA0KdXJsOmh0dHA6Ly93d3cubG9yaWEu ZnIvfmNyaWRsaWd2DQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------080201070904040304040106-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 08:27:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4I1W-0001qp-Km for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 08:27:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25185 for ; Wed, 1 Feb 2006 08:26:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Hpl-000LH5-Nw for netconf-data@psg.com; Wed, 01 Feb 2006 13:15:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4AGk-000Jer-7S for netconf@ops.ietf.org; Wed, 01 Feb 2006 05:11:02 +0000 Received: (qmail 13628 invoked from network); 31 Jan 2006 17:54:42 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 31 Jan 2006 17:54:42 -0000 Message-ID: <43DFA460.6040903@andybierman.com> Date: Tue, 31 Jan 2006 09:54:40 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: FYI: XSD Best Practices Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Not sure how accurate or up-to-date the following WEB site is, but the articles I looked at seem pretty good: http://www.xfront.com/BestPracticesHomepage.html Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 12:46:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4M40-0008Do-B9 for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 12:46:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18221 for ; Wed, 1 Feb 2006 12:45:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Luu-000C1U-8Z for netconf-data@psg.com; Wed, 01 Feb 2006 17:37:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4LuH-000Bzx-Pl for netconf@ops.ietf.org; Wed, 01 Feb 2006 17:36:37 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k11HaWvs017383; Wed, 1 Feb 2006 11:36:33 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Feb 2006 18:36:31 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509391576@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: j.schoenwaelder@iu-bremen.de, Andy Bierman Cc: "Netconf (E-mail)" Subject: RE: terminology change Date: Wed, 1 Feb 2006 18:36:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk Too many people take an IESG COMMENT to mean: MUST change. It is a comment that you can evaluating. COMMENTs are certainly NOT blocking. Too many people also take an IESG DISCUSS to mean: MUST change. It is not. the term "discuss" means that the AD who holds the DISCUSS wants to discuss his concern and s/he may have a suggestion for a solution, but normally, the ADs all DO EXPECT that you evaluate the DISCUSS make a chnage if you agree, or come back with arguments when you rather not change and see if we can to agreement by talking/discussing the issue. It is one of the problems I have seen/experienced far too often: when WG members see an IESG or IAB person speak they think it has more weight than when other WG participants speak. Pls do always challenge IESG and IAB members if you think they are wrong or if you think they may be missing some context etc. I suspect I missed this specific case. Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, February 01, 2006 00:52 > To: Andy Bierman > Cc: Netconf (E-mail) > Subject: Re: terminology change > > > On Wed, Feb 01, 2006 at 12:11:11AM -0800, Andy Bierman wrote: > > > Funny how we were just discussing this on the MIB Doctors list, > > but this is a case where one IESG reviewer told us to change > > a WG selected term to something else. We did that. We didn't > > like it, but we did it. Then a subsequent review points out > > that our terminology is totally confusing, why would we do it > > that way, please change it back. > > > > This is the problem with subjective reviews... > > Would life not be boring without all this? ;-) What really matters is > that at the end we use the IMHO right term. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 12:48:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4M5g-0000vb-1E for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 12:48:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18327 for ; Wed, 1 Feb 2006 12:46:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4M13-000CPU-J4 for netconf-data@psg.com; Wed, 01 Feb 2006 17:43:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4M11-000CPF-Ow for netconf@ops.ietf.org; Wed, 01 Feb 2006 17:43:36 +0000 Received: (qmail 6298 invoked from network); 1 Feb 2006 17:07:56 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 1 Feb 2006 17:07:56 -0000 Message-ID: <43E0EAEA.3040400@andybierman.com> Date: Wed, 01 Feb 2006 09:07:54 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: proposal to change URL capability syntax Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Our URL capability uses the term 'protocol': urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file As this snippet of RFC 3986 shows, we are using the term "protocol" instead of the proper term "scheme". ("file" is not a protocol) foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose We are proposing to change the term "protocol" to "scheme" in the URL capability syntax to align with RFC 3986 terminology. This change will require existing pre-standard implementations to be updated. Unless there are any strong objections, prot-11 will include this update. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 13:13:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4MU3-00084W-P2 for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 13:13:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19770 for ; Wed, 1 Feb 2006 13:11:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4MQF-000E1S-G9 for netconf-data@psg.com; Wed, 01 Feb 2006 18:09:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4MQE-000E1F-PZ for netconf@ops.ietf.org; Wed, 01 Feb 2006 18:09:38 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k11I9W546732; Wed, 1 Feb 2006 10:09:32 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k11I9R521513; Wed, 1 Feb 2006 10:09:27 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k11IEhYE017781; Wed, 1 Feb 2006 13:14:43 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200602011814.k11IEhYE017781@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: proposal to change URL capability syntax In-Reply-To: Your message of "Wed, 01 Feb 2006 09:07:54 PST." <43E0EAEA.3040400@andybierman.com> Date: Wed, 01 Feb 2006 13:14:43 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Sounds good to me. Thanks, Phil Andy Bierman writes: >Hi, > >Our URL capability uses the term 'protocol': > >urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file > > >As this snippet of RFC 3986 shows, we are using the term "protocol" >instead of the proper term "scheme". ("file" is not a protocol) > > > foo://example.com:8042/over/there?name=ferret#nose > \_/ \______________/\_________/ \_________/ \__/ > | | | | | > scheme authority path query fragment > | _____________________|__ > / \ / \ > urn:example:animal:ferret:nose > > >We are proposing to change the term "protocol" to "scheme" >in the URL capability syntax to align with RFC 3986 terminology. > > >This change will require existing pre-standard implementations to be >updated. > > >Unless there are any strong objections, prot-11 will include this update. > > >Andy > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 15:33:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Ofl-0008DG-9p for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 15:33:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03329 for ; Wed, 1 Feb 2006 15:32:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4OZx-0004mn-9G for netconf-data@psg.com; Wed, 01 Feb 2006 20:27:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [63.240.77.84] (helo=sccrmhc14.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4OZw-0004ma-D8 for netconf@ops.ietf.org; Wed, 01 Feb 2006 20:27:48 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc14) with SMTP id <2006020120270601400kc3mhe>; Wed, 1 Feb 2006 20:27:07 +0000 Reply-To: From: "David B Harrington" To: , "'Andy Bierman'" Cc: "'Netconf \(E-mail\)'" Subject: RE: terminology change Date: Wed, 1 Feb 2006 15:26:59 -0500 Message-ID: <02f801c6276d$dab7b970$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYm6u0tN75qhQ95T12bKZF4OL6FRAAgt5dg In-Reply-To: <20060201044326.GA20461@noname> Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I also strongly support the change. David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, January 31, 2006 11:43 PM > To: Andy Bierman > Cc: Netconf (E-mail) > Subject: Re: terminology change > > On Tue, Jan 31, 2006 at 06:20:47PM -0800, Andy Bierman wrote: > > > We are going back to our original term "transport mapping", > > which aligns with our architecture diagrams (which include > > the transport, rpc, operations, and application layers). > > Thank you very much. Very strong support from me here. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 01 23:54:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4WU3-0001Vn-3p for netconf-archive@megatron.ietf.org; Wed, 01 Feb 2006 23:54:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25551 for ; Wed, 1 Feb 2006 23:52:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4WM8-0002uT-5c for netconf-data@psg.com; Thu, 02 Feb 2006 04:46:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4WM5-0002uE-4g for netconf@ops.ietf.org; Thu, 02 Feb 2006 04:46:01 +0000 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 01 Feb 2006 20:45:54 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,245,1136188800"; d="scan'208"; a="525063710:sNHT23546004" Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 20:46:00 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: terminology change Date: Wed, 1 Feb 2006 20:45:57 -0800 Message-ID: Thread-Topic: terminology change Thread-Index: AcYm6maK785fMWh2SSuZ0KiIPEWwVQAyRbNA From: "Rob Enns" To: , "Andy Bierman" Cc: "Netconf \(E-mail\)" X-OriginalArrivalTime: 02 Feb 2006 04:46:00.0294 (UTC) FILETIME=[90765060:01C627B3] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree with this change. Thanks. Rob=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, January 31, 2006 8:43 PM > To: Andy Bierman > Cc: Netconf (E-mail) > Subject: Re: terminology change >=20 > On Tue, Jan 31, 2006 at 06:20:47PM -0800, Andy Bierman wrote: > =20 > > We are going back to our original term "transport mapping", > > which aligns with our architecture diagrams (which include > > the transport, rpc, operations, and application layers). >=20 > Thank you very much. Very strong support from me here. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 12:06:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4huF-0001kW-Or for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 12:06:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20790 for ; Thu, 2 Feb 2006 12:04:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4hlu-000F6p-UC for netconf-data@psg.com; Thu, 02 Feb 2006 16:57:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4hlq-000F6V-T0 for netconf@ops.ietf.org; Thu, 02 Feb 2006 16:57:23 +0000 Received: (qmail 27868 invoked from network); 2 Feb 2006 16:48:57 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 2 Feb 2006 16:48:57 -0000 Message-ID: <43E23839.8040105@andybierman.com> Date: Thu, 02 Feb 2006 08:50:01 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: problems with 'ignore-error' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We have heard from one implementer that says they cannot support the ignore-error in the operation. Now one more. Here is the total documentation on the ignore-error option: ignore-error: Continue to process configuration data on error; error is recorded and negative response is generated if any errors occur. 1) How many operators want this option? 2) How many vendors are supporting this option? 3) What does this option really mean? - ignore malformed XML? Most tools won't do that. This is not only dangerous, it isn't very easy to do. - ignore missing parameters? What happens if the parameter is missing? - ignore extra parameters? - use RPC parameters that don't pass the schema validation tests? - ignore access control violations? - ignore lock access violations? - ignore unsupported portions of the config parameter sub-tree? - use parameters that fail the referential integrity tests? - continue to install child nodes of a parent node with errors? (How?) IMO, this mandatory feature of the NETCONF protocol is poorly defined, hard or impossible to implement, and has no chance of interoperability. It needs to be fixed or removed from the protocol. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 12:59:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ijf-0000s9-Ek for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 12:59:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24616 for ; Thu, 2 Feb 2006 12:57:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4if3-000J2O-N9 for netconf-data@psg.com; Thu, 02 Feb 2006 17:54:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4iez-000J2A-Ue for netconf@ops.ietf.org; Thu, 02 Feb 2006 17:54:21 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2006 09:54:21 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k12HsLWF022609; Thu, 2 Feb 2006 09:54:21 -0800 (PST) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 09:54:21 -0800 Received: from 10.21.82.196 ([10.21.82.196]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2006 17:54:21 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 02 Feb 2006 09:55:05 -0800 Subject: Re: problems with 'ignore-error' From: Steve Berl To: Andy Bierman , "Netconf (E-mail)" Message-ID: Thread-Topic: problems with 'ignore-error' Thread-Index: AcYoIcwbCrn8oJQVEdqRRQARJNUQLA== In-Reply-To: <43E23839.8040105@andybierman.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2006 17:54:21.0457 (UTC) FILETIME=[B2270010:01C62821] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The original intent of the option was to have behavior similar to Cisco IOS doing "copy tftp://foo/blah running-config". In this case the configuration is a list of lines, each represents an atomic configuration change operation. If one line generates an error we can continue on and execute the remaining lines, ignoring the error. The idea is that commands that don't make sense can be ignored, but the ones that do make sense can be applied. This proves to be a convenient behavior when an existing configuration runs on a different device than it was originally created for, or when a device has the software upgraded and some older commands are no longer supported, or if the line cards in a device have changed so that some interfaces that were there are now missing. One of the data models that we are supporting in the Cisco implementation of netconf is a list of command lines and this same behavior can be maintained with the ignore-error option. So, to better define the behavior in the netconf spec we need to be clear about the errors that we are choosing to ignore. I think that these are the errors that occur in the processing (not the parsing) of the element in an . There's probably a better way to say that. -steve On 2/2/06 8:50 AM, "Andy Bierman" wrote: > Hi, > > We have heard from one implementer that says they cannot > support the ignore-error in the operation. > Now one more. > > Here is the total documentation on the ignore-error option: > > ignore-error: Continue to process configuration data on error; > error is recorded and negative response is generated if any > errors occur. > > 1) How many operators want this option? > > 2) How many vendors are supporting this option? > > 3) What does this option really mean? > > - ignore malformed XML? > Most tools won't do that. This is not only dangerous, > it isn't very easy to do. > > - ignore missing parameters? What happens if the > parameter is missing? > > - ignore extra parameters? > > - use RPC parameters that don't pass the schema validation tests? > > - ignore access control violations? > > - ignore lock access violations? > > - ignore unsupported portions of the config parameter sub-tree? > > - use parameters that fail the referential integrity tests? > > - continue to install child nodes of a parent node with errors? > (How?) > > > IMO, this mandatory feature of the NETCONF protocol is poorly defined, > hard or impossible to implement, and has no chance of interoperability. > It needs to be fixed or removed from the protocol. > > Andy > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 13:39:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jMx-0008Po-3d for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 13:39:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27763 for ; Thu, 2 Feb 2006 13:38:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jIJ-000Lm8-QU for netconf-data@psg.com; Thu, 02 Feb 2006 18:34:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jIH-000Llq-DM for netconf@ops.ietf.org; Thu, 02 Feb 2006 18:34:57 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k12IYr1Z092990; Thu, 2 Feb 2006 10:34:53 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k12IYq554358; Thu, 2 Feb 2006 10:34:52 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k12Ie8YE021190; Thu, 2 Feb 2006 13:40:08 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200602021840.k12Ie8YE021190@idle.juniper.net> To: Steve Berl cc: Andy Bierman , "Netconf (E-mail)" Subject: Re: problems with 'ignore-error' In-Reply-To: Your message of "Thu, 02 Feb 2006 09:55:05 PST." Date: Thu, 02 Feb 2006 13:40:08 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Steve Berl writes: >So, to better define the behavior in the netconf spec we need to be clear >about the errors that we are choosing to ignore. I think that these are the >errors that occur in the processing (not the parsing) of the >element in an . Clarity may be difficult, given the Twilight Zone of failure cases. If the client gives you a element but a is only valid (or worse, only parsable) if the GRUE FRU is plugged into your box, the difference between processing errors and parsing errors becomes pretty vague. Recovery may just be best effort. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 13:53:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jZt-0004HO-Sn for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 13:53:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28846 for ; Thu, 2 Feb 2006 13:51:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jVw-000MrC-I7 for netconf-data@psg.com; Thu, 02 Feb 2006 18:49:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jVt-000Mqy-MJ for netconf@ops.ietf.org; Thu, 02 Feb 2006 18:49:01 +0000 Received: (qmail 4362 invoked from network); 2 Feb 2006 18:49:00 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 2 Feb 2006 18:49:00 -0000 Message-ID: <43E2541A.2060306@andybierman.com> Date: Thu, 02 Feb 2006 10:48:58 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Steve Berl CC: "Netconf (E-mail)" Subject: Re: problems with 'ignore-error' References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steve Berl wrote: > The original intent of the option was to have behavior similar to Cisco IOS > doing "copy tftp://foo/blah running-config". In this case the configuration > is a list of lines, each represents an atomic configuration change > operation. If one line generates an error we can continue on and execute the > remaining lines, ignoring the error. The idea is that commands that don't > make sense can be ignored, but the ones that do make sense can be applied. > Are you talking about simple XML-ifies CLI? blah-blah blah-blah This is a trivial case. Real XML data models are not so easy to implement for this feature. > This proves to be a convenient behavior when an existing configuration runs > on a different device than it was originally created for, or when a device > has the software upgraded and some older commands are no longer supported, > or if the line cards in a device have changed so that some interfaces that > were there are now missing. > I understand the intent of the feature. I don't think it is specified in a manner that will allow developers to create interoperable implementations. > One of the data models that we are supporting in the Cisco implementation of > netconf is a list of command lines and this same behavior can be maintained > with the ignore-error option. > > So, to better define the behavior in the netconf spec we need to be clear > about the errors that we are choosing to ignore. I think that these are the > errors that occur in the processing (not the parsing) of the > element in an . > I think you mean the application of config changes. If a config change passes all tests then apply it, otherwise go on to the next config change. I think that's what you mean. Just because an operation parses doesn't mean resources like locks are free, or access control rules are met. > There's probably a better way to say that. > The problem with this feature is that netconf is not a CLI. There is no concept in netconf that the XML payload within an operation is serialized into an integral number of "lines". "When an error occurs, continue to the next line" does not mean anything in XML. Support of this feature requires a lot of custom work, and prevents widely available validation tools from being used (because they validate an entire sub-tree or nothing). You can't even say "on error continue at the next sibling node" because that isn't always true. All you can say is "it is an implementation-specific matter if and where processing of the sub-tree will continue after an error is encountered." IMO, this means "no interoperability whatsoever". > -steve > Andy > On 2/2/06 8:50 AM, "Andy Bierman" wrote: > > >> Hi, >> >> We have heard from one implementer that says they cannot >> support the ignore-error in the operation. >> Now one more. >> >> Here is the total documentation on the ignore-error option: >> >> ignore-error: Continue to process configuration data on error; >> error is recorded and negative response is generated if any >> errors occur. >> >> 1) How many operators want this option? >> >> 2) How many vendors are supporting this option? >> >> 3) What does this option really mean? >> >> - ignore malformed XML? >> Most tools won't do that. This is not only dangerous, >> it isn't very easy to do. >> >> - ignore missing parameters? What happens if the >> parameter is missing? >> >> - ignore extra parameters? >> >> - use RPC parameters that don't pass the schema validation tests? >> >> - ignore access control violations? >> >> - ignore lock access violations? >> >> - ignore unsupported portions of the config parameter sub-tree? >> >> - use parameters that fail the referential integrity tests? >> >> - continue to install child nodes of a parent node with errors? >> (How?) >> >> >> IMO, this mandatory feature of the NETCONF protocol is poorly defined, >> hard or impossible to implement, and has no chance of interoperability. >> It needs to be fixed or removed from the protocol. >> >> Andy >> >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 13:53:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ja7-0004In-Kh for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 13:53:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28865 for ; Thu, 2 Feb 2006 13:51:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jV3-000MnX-8m for netconf-data@psg.com; Thu, 02 Feb 2006 18:48:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jUs-000Mmp-OM for netconf@ops.ietf.org; Thu, 02 Feb 2006 18:47:58 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2006 10:47:58 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k12IlwWF001718; Thu, 2 Feb 2006 10:47:58 -0800 (PST) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 10:47:58 -0800 Received: from 10.21.82.196 ([10.21.82.196]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2006 18:47:57 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 02 Feb 2006 10:48:42 -0800 Subject: Re: problems with 'ignore-error' From: Steve Berl To: Phil Shafer CC: Andy Bierman , "Netconf (E-mail)" Message-ID: Thread-Topic: problems with 'ignore-error' Thread-Index: AcYoKUmWiAQs4ZQcEdqRRQARJNUQLA== In-Reply-To: <200602021840.k12Ie8YE021190@idle.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2006 18:47:58.0152 (UTC) FILETIME=[2F73B480:01C62829] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps we can leave the specification of what errors are "ignorable" to be part of the data model description. It seems to be coupled to the way the contents of the element are processed. -steve On 2/2/06 10:40 AM, "Phil Shafer" wrote: > Steve Berl writes: >> So, to better define the behavior in the netconf spec we need to be clear >> about the errors that we are choosing to ignore. I think that these are the >> errors that occur in the processing (not the parsing) of the >> element in an . > > Clarity may be difficult, given the Twilight Zone of failure cases. > If the client gives you a element but a is only valid > (or worse, only parsable) if the GRUE FRU is plugged into your box, > the difference between processing errors and parsing errors becomes > pretty vague. Recovery may just be best effort. > > Thanks, > Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 14:55:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kXl-0005qm-BZ for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 14:55:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04117 for ; Thu, 2 Feb 2006 14:53:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4kSF-0001AP-DF for netconf-data@psg.com; Thu, 02 Feb 2006 19:49:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4kSC-0001AB-IL for netconf@ops.ietf.org; Thu, 02 Feb 2006 19:49:16 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2006 11:49:16 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k12JnFKT016352; Thu, 2 Feb 2006 11:49:15 -0800 (PST) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 11:49:15 -0800 Received: from 10.21.82.196 ([10.21.82.196]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2006 19:49:15 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 02 Feb 2006 11:49:59 -0800 Subject: Re: problems with 'ignore-error' From: Steve Berl To: Andy Bierman CC: "Netconf (E-mail)" Message-ID: Thread-Topic: problems with 'ignore-error' Thread-Index: AcYoMdlAF8olfJQlEdqRRQARJNUQLA== In-Reply-To: <43E2541A.2060306@andybierman.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2006 19:49:15.0667 (UTC) FILETIME=[BF6BF630:01C62831] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit See my response to Phil. I propose that the errors that are "ignorable" be part of the description of the data model as the behavior seems to be coupled to the contents of the element. I think we have the same problem with "stop-on-error" as we do with "ignore-error". In either case there is a partial success and partial failure of the request. How can we stop-on-error how do we know which parts of the request worked and which didn't get executed? It is specific to the data/processing model that is being used. The whole idea of the error-option depends on the notion that there are multiple atomic operations described in the element, and that some may succeed and some may fail. The order in which these atomic operations are to be attempted may be specified in the content of the element, or not. In the case below, the boundaries and order of the atomic operations is pretty clear. In some other data models it might not be as obvious, but they may still be there. In order for there to be any way to understand the meaning of the stop-on-error and ignore-error options the boundaries of the atomic operations need to be understood. See some other comments below. On 2/2/06 10:48 AM, "Andy Bierman" wrote: > Steve Berl wrote: >> The original intent of the option was to have behavior similar to Cisco IOS >> doing "copy tftp://foo/blah running-config". In this case the configuration >> is a list of lines, each represents an atomic configuration change >> operation. If one line generates an error we can continue on and execute the >> remaining lines, ignoring the error. The idea is that commands that don't >> make sense can be ignored, but the ones that do make sense can be applied. >> > > Are you talking about simple XML-ifies CLI? > > > blah-blah > blah-blah > > > This is a trivial case. It is a simple data model, yet we do support this in our implementation. It is very useful considering the existing base of tools and knowledge that understand the CLI. > Real XML data models are not so easy to implement for this feature. > >> This proves to be a convenient behavior when an existing configuration runs >> on a different device than it was originally created for, or when a device >> has the software upgraded and some older commands are no longer supported, >> or if the line cards in a device have changed so that some interfaces that >> were there are now missing. >> > > I understand the intent of the feature. > I don't think it is specified in a manner that will > allow developers to create interoperable implementations. > I agree. The behavior is specific to the data/processing model that is being used. > > >> One of the data models that we are supporting in the Cisco implementation of >> netconf is a list of command lines and this same behavior can be maintained >> with the ignore-error option. >> >> So, to better define the behavior in the netconf spec we need to be clear >> about the errors that we are choosing to ignore. I think that these are the >> errors that occur in the processing (not the parsing) of the >> element in an . >> > > I think you mean the application of config changes. > If a config change passes all tests then apply it, > otherwise go on to the next config change. > > I think that's what you mean. Yes. I think that is a better way to say it. > Just because an operation parses doesn't mean resources like locks > are free, or access control rules are met. > >> There's probably a better way to say that. >> > > The problem with this feature is that netconf is not a CLI. > There is no concept in netconf that the XML payload within > an operation is serialized into an integral number > of "lines". "When an error occurs, continue to the next line" > does not mean anything in XML. Well, the netconf protocol is supposed to be agnostic to the data/processing model, so it should be able to work for a model that consists of a list of text commands that are executed in order. > > Support of this feature requires a lot of custom work, > and prevents widely available validation tools from being > used (because they validate an entire sub-tree or nothing). This is back to the definition of what errors are "ignorable". If we say that errors that are detected in the XML validation are not ignorable, but those detected in the application of the configuration changes are ignorable, then this is no problem. If a particular data model definition wants to say that no errors are ignorable, then that is fine also. > > You can't even say "on error continue at the next sibling node" > because that isn't always true. All you can say is "it is an > implementation-specific matter if and where processing > of the sub-tree will continue after an error is > encountered." > > IMO, this means "no interoperability whatsoever". Unless there are interoperable data models, their wasn't any interoperability at this level anyway. > > >> -steve >> > > Andy > >> On 2/2/06 8:50 AM, "Andy Bierman" wrote: >> >> >>> Hi, >>> >>> We have heard from one implementer that says they cannot >>> support the ignore-error in the operation. >>> Now one more. >>> >>> Here is the total documentation on the ignore-error option: >>> >>> ignore-error: Continue to process configuration data on error; >>> error is recorded and negative response is generated if any >>> errors occur. >>> >>> 1) How many operators want this option? >>> >>> 2) How many vendors are supporting this option? >>> >>> 3) What does this option really mean? >>> >>> - ignore malformed XML? >>> Most tools won't do that. This is not only dangerous, >>> it isn't very easy to do. >>> >>> - ignore missing parameters? What happens if the >>> parameter is missing? >>> >>> - ignore extra parameters? >>> >>> - use RPC parameters that don't pass the schema validation tests? >>> >>> - ignore access control violations? >>> >>> - ignore lock access violations? >>> >>> - ignore unsupported portions of the config parameter sub-tree? >>> >>> - use parameters that fail the referential integrity tests? >>> >>> - continue to install child nodes of a parent node with errors? >>> (How?) >>> >>> >>> IMO, this mandatory feature of the NETCONF protocol is poorly defined, >>> hard or impossible to implement, and has no chance of interoperability. >>> It needs to be fixed or removed from the protocol. >>> >>> Andy >>> >>> >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >> >> >> -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 15:48:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4lNl-0006EA-Gg for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 15:48:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08019 for ; Thu, 2 Feb 2006 15:46:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4lJG-0004py-3f for netconf-data@psg.com; Thu, 02 Feb 2006 20:44:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4lJB-0004pf-Ml for netconf@ops.ietf.org; Thu, 02 Feb 2006 20:44:01 +0000 Received: (qmail 25879 invoked from network); 2 Feb 2006 20:40:23 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 2 Feb 2006 20:40:23 -0000 Message-ID: <43E26E36.3050404@andybierman.com> Date: Thu, 02 Feb 2006 12:40:22 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Steve Berl CC: "Netconf (E-mail)" Subject: Re: problems with 'ignore-error' References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steve Berl wrote: So you want to punt the issue to the data model specification? I still think some text is needed to make it clear that NETCONF in no way specifies what it means to "continue after an error". It will be up to the data model specification to make it clear how two implementations of the the command for the same data model will behave in the same way. The current text does not make it clear at all that we only mean ignore-errors in the XML under the element. The term 'ignore-errors' is misleading because sub-commands with errors are not executed. The term 'continue-on-error' would have been better, but it's not worth changing now. Andy > See my response to Phil. I propose that the errors that are "ignorable" be > part of the description of the data model as the behavior seems to be > coupled to the contents of the element. > > I think we have the same problem with "stop-on-error" as we do with > "ignore-error". In either case there is a partial success and partial > failure of the request. How can we stop-on-error how do we know which parts > of the request worked and which didn't get executed? It is specific to the > data/processing model that is being used. > > The whole idea of the error-option depends on the notion that there are > multiple atomic operations described in the element, and that some > may succeed and some may fail. The order in which these atomic operations > are to be attempted may be specified in the content of the element, > or not. In the case below, the boundaries and order of the atomic > operations is pretty clear. In some other data models it might not be as > obvious, but they may still be there. In order for there to be any way to > understand the meaning of the stop-on-error and ignore-error options the > boundaries of the atomic operations need to be understood. > > > See some other comments below. > > > On 2/2/06 10:48 AM, "Andy Bierman" wrote: > > >> Steve Berl wrote: >> >>> The original intent of the option was to have behavior similar to Cisco IOS >>> doing "copy tftp://foo/blah running-config". In this case the configuration >>> is a list of lines, each represents an atomic configuration change >>> operation. If one line generates an error we can continue on and execute the >>> remaining lines, ignoring the error. The idea is that commands that don't >>> make sense can be ignored, but the ones that do make sense can be applied. >>> >>> >> Are you talking about simple XML-ifies CLI? >> >> >> blah-blah >> blah-blah >> >> >> This is a trivial case. >> > > It is a simple data model, yet we do support this in our implementation. It > is very useful considering the existing base of tools and knowledge that > understand the CLI. > > >> Real XML data models are not so easy to implement for this feature. >> >> >>> This proves to be a convenient behavior when an existing configuration runs >>> on a different device than it was originally created for, or when a device >>> has the software upgraded and some older commands are no longer supported, >>> or if the line cards in a device have changed so that some interfaces that >>> were there are now missing. >>> >>> >> I understand the intent of the feature. >> I don't think it is specified in a manner that will >> allow developers to create interoperable implementations. >> >> > > I agree. The behavior is specific to the data/processing model that is being > used. > > >> >>> One of the data models that we are supporting in the Cisco implementation of >>> netconf is a list of command lines and this same behavior can be maintained >>> with the ignore-error option. >>> >>> So, to better define the behavior in the netconf spec we need to be clear >>> about the errors that we are choosing to ignore. I think that these are the >>> errors that occur in the processing (not the parsing) of the >>> element in an . >>> >>> >> I think you mean the application of config changes. >> If a config change passes all tests then apply it, >> otherwise go on to the next config change. >> >> I think that's what you mean. >> > > Yes. I think that is a better way to say it. > > >> Just because an operation parses doesn't mean resources like locks >> are free, or access control rules are met. >> >> >>> There's probably a better way to say that. >>> >>> >> The problem with this feature is that netconf is not a CLI. >> There is no concept in netconf that the XML payload within >> an operation is serialized into an integral number >> of "lines". "When an error occurs, continue to the next line" >> does not mean anything in XML. >> > > Well, the netconf protocol is supposed to be agnostic to the data/processing > model, so it should be able to work for a model that consists of a list of > text commands that are executed in order. > > >> Support of this feature requires a lot of custom work, >> and prevents widely available validation tools from being >> used (because they validate an entire sub-tree or nothing). >> > > This is back to the definition of what errors are "ignorable". If we say > that errors that are detected in the XML validation are not ignorable, but > those detected in the application of the configuration changes are > ignorable, then this is no problem. If a particular data model definition > wants to say that no errors are ignorable, then that is fine also. > > >> You can't even say "on error continue at the next sibling node" >> because that isn't always true. All you can say is "it is an >> implementation-specific matter if and where processing >> of the sub-tree will continue after an error is >> encountered." >> >> IMO, this means "no interoperability whatsoever". >> > > Unless there are interoperable data models, their wasn't any > interoperability at this level anyway. > > >> >>> -steve >>> >>> >> Andy >> >> >>> On 2/2/06 8:50 AM, "Andy Bierman" wrote: >>> >>> >>> >>>> Hi, >>>> >>>> We have heard from one implementer that says they cannot >>>> support the ignore-error in the operation. >>>> Now one more. >>>> >>>> Here is the total documentation on the ignore-error option: >>>> >>>> ignore-error: Continue to process configuration data on error; >>>> error is recorded and negative response is generated if any >>>> errors occur. >>>> >>>> 1) How many operators want this option? >>>> >>>> 2) How many vendors are supporting this option? >>>> >>>> 3) What does this option really mean? >>>> >>>> - ignore malformed XML? >>>> Most tools won't do that. This is not only dangerous, >>>> it isn't very easy to do. >>>> >>>> - ignore missing parameters? What happens if the >>>> parameter is missing? >>>> >>>> - ignore extra parameters? >>>> >>>> - use RPC parameters that don't pass the schema validation tests? >>>> >>>> - ignore access control violations? >>>> >>>> - ignore lock access violations? >>>> >>>> - ignore unsupported portions of the config parameter sub-tree? >>>> >>>> - use parameters that fail the referential integrity tests? >>>> >>>> - continue to install child nodes of a parent node with errors? >>>> (How?) >>>> >>>> >>>> IMO, this mandatory feature of the NETCONF protocol is poorly defined, >>>> hard or impossible to implement, and has no chance of interoperability. >>>> It needs to be fixed or removed from the protocol. >>>> >>>> Andy >>>> >>>> >>>> >>>> -- >>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: >>>> >>>> >>> >>> > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 16:40:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mC2-0000v5-3i for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 16:40:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15801 for ; Thu, 2 Feb 2006 16:38:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4m5b-0008KN-9k for netconf-data@psg.com; Thu, 02 Feb 2006 21:34:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.225] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4m5W-0008K5-DC for netconf@ops.ietf.org; Thu, 02 Feb 2006 21:33:59 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 106586414; Thu, 02 Feb 2006 22:33:54 +0100 Date: Thu, 02 Feb 2006 22:33:43 +0100 (CET) Message-Id: <20060202.223343.104030977.mbj@tail-f.com> To: sberl@cisco.com Cc: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: problems with 'ignore-error' From: Martin Bjorklund In-Reply-To: References: <43E23839.8040105@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steve Berl wrote: > The original intent of the option was to have behavior similar to Cisco IOS > doing "copy tftp://foo/blah running-config". In this case the configuration > is a list of lines, each represents an atomic configuration change > operation. If one line generates an error we can continue on and execute the > remaining lines, ignoring the error. The idea is that commands that don't > make sense can be ignored, but the ones that do make sense can be applied. > > This proves to be a convenient behavior when an existing configuration runs > on a different device than it was originally created for, or when a device > has the software upgraded and some older commands are no longer supported, > or if the line cards in a device have changed so that some interfaces that > were there are now missing. > > One of the data models that we are supporting in the Cisco implementation of > netconf is a list of command lines and this same behavior can be maintained > with the ignore-error option. > > So, to better define the behavior in the netconf spec we need to be clear > about the errors that we are choosing to ignore. I think that these are the > errors that occur in the processing (not the parsing) of the > element in an . Aha! This makes a lot of sense. The feature to reload a configuration which may contain old obsolete config parameters is very convenient. We have been talking about how to implement this within netconf... The text should be updated though - both for stop-on-error and ignore-error. However, I think it would make more sense to have this option on which is the command to use if you want to reload an old config e.g. from a url. I've mentioned this one before. If the agent supports rollback-on-error, I think that it should be up to the agent to use that strategy instead of stop-on-error, which the text says is default. In which case would a manager actually prefer stop-on-error before rollback-on-error? Further, the text says that a "negative" response is generated. I assume that it should be "partial-operation". This should also be stated, since although an rpc-error was returned, the target configuration has actaully changed. A manager must be able to detect this case unambiguously. If a full config contains a single now obsolete parameter, the reply might contain all good elements as , and the single obsolete one as . Suppose the request was 1 some text www eth0 2 Now, suppose the interface/name has been changed to ifName, and that servers/descr has been removed in the current data model. The error-info of the partial-operation could be: id descr name name id or worse: descr name Imagine what it would look like if the config was big. If the order of the elements are known to be in the same order as in the incoming config, and all always present, it might be possible to figure out what happened, but it's certainly not easy. It's probably too late to change this now, but maybe the contents of the error-info could be defined by the data model, and not the protocol? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 18:28:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4nsY-0006Uu-10 for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 18:28:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26320 for ; Thu, 2 Feb 2006 18:26:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4nn2-000FkZ-Ma for netconf-data@psg.com; Thu, 02 Feb 2006 23:23:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4nmz-000Fjz-Ia for netconf@ops.ietf.org; Thu, 02 Feb 2006 23:22:57 +0000 Received: (qmail 30973 invoked from network); 2 Feb 2006 23:22:56 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 2 Feb 2006 23:22:56 -0000 Message-ID: <43E2944F.9070903@andybierman.com> Date: Thu, 02 Feb 2006 15:22:55 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: sberl@cisco.com, netconf@ops.ietf.org Subject: Re: problems with 'ignore-error' References: <43E23839.8040105@andybierman.com> <20060202.223343.104030977.mbj@tail-f.com> In-Reply-To: <20060202.223343.104030977.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: > Steve Berl wrote: > >> The original intent of the option was to have behavior similar to Cisco IOS >> doing "copy tftp://foo/blah running-config". In this case the configuration >> is a list of lines, each represents an atomic configuration change >> operation. If one line generates an error we can continue on and execute the >> remaining lines, ignoring the error. The idea is that commands that don't >> make sense can be ignored, but the ones that do make sense can be applied. >> >> This proves to be a convenient behavior when an existing configuration runs >> on a different device than it was originally created for, or when a device >> has the software upgraded and some older commands are no longer supported, >> or if the line cards in a device have changed so that some interfaces that >> were there are now missing. >> >> One of the data models that we are supporting in the Cisco implementation of >> netconf is a list of command lines and this same behavior can be maintained >> with the ignore-error option. >> >> So, to better define the behavior in the netconf spec we need to be clear >> about the errors that we are choosing to ignore. I think that these are the >> errors that occur in the processing (not the parsing) of the >> element in an . >> > > Aha! This makes a lot of sense. The feature to reload a > configuration which may contain old obsolete config parameters is very > convenient. We have been talking about how to implement this within > netconf... The text should be updated though - both for stop-on-error > and ignore-error. > > However, I think it would make more sense to have this option on > which is the command to use if you want to reload an old > config e.g. from a url. > I don't want to start adding features to operations that didn't already have them. I just want to clarify the error-option in edit-config. > I've mentioned this one before. If the agent supports > rollback-on-error, I think that it should be up to the agent to use > that strategy instead of stop-on-error, which the text says is > default. In which case would a manager actually prefer stop-on-error > before rollback-on-error? > The manager should use rollback-on-error if that's what they want. They default is only applied when the parameter is missing. I don't think it's ever a good idea to rely on defaults. We already decided not to have conditional default values based on various capabilities. I think we should stick with that decision. > > Further, the text says that a "negative" response is generated. I > assume that it should be "partial-operation". This should also be > stated, since although an rpc-error was returned, the target > configuration has actaully changed. A manager must be able to detect > this case unambiguously. > It's hard to say what the error responses should be in any arbitrary case. The data model must make it clear (good luck!). I agree with you that a partial operation needs to be identified if some but not all of the config element content is applied. > If a full config contains a single now obsolete parameter, the reply > might contain all good elements as , and the single > obsolete one as . Suppose the request was > > > > > > 1 > some text > www > > > > > eth0 > 2 > > > > > > Now, suppose the interface/name has been changed to ifName, and that > servers/descr has been removed in the current data model. The > error-info of the partial-operation could be: > > > id > descr > name > name > id > > > or worse: > > > descr > name > > > Imagine what it would look like if the config was big. > > If the order of the elements are known to be in the same order as in > the incoming config, and all always present, it might be possible to > figure out what happened, but it's certainly not easy. > > It's probably too late to change this now, but maybe the contents of > the error-info could be defined by the data model, and not the > protocol? > Not sure what problem you are describing here. I will have to read it again later. > > > /martin > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 19:01:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4oNy-0000wy-1J for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 19:01:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28502 for ; Thu, 2 Feb 2006 18:59:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4oIw-000IEs-AA for netconf-data@psg.com; Thu, 02 Feb 2006 23:55:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4oIr-000IEL-Bk for netconf@ops.ietf.org; Thu, 02 Feb 2006 23:55:53 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2006 15:55:53 -0800 X-IronPort-AV: i="4.02,81,1139212800"; d="scan'208"; a="400073776:sNHT36798258" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k12Ntqjt011294; Thu, 2 Feb 2006 15:55:52 -0800 (PST) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 15:55:52 -0800 Received: from 10.21.122.30 ([10.21.122.30]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2006 23:55:52 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 02 Feb 2006 15:56:34 -0800 Subject: Re: problems with 'ignore-error' From: Steve Berl To: Andy Bierman CC: "Netconf (E-mail)" Message-ID: Thread-Topic: problems with 'ignore-error' Thread-Index: AcYoVEvBijYO4pRHEdqRRQARJNUQLA== In-Reply-To: <43E26E36.3050404@andybierman.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2006 23:55:52.0841 (UTC) FILETIME=[33398790:01C62854] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think I agree with you completely. It would be clearer if the choices were "stop-on-error", "continue-on-error", and "rollback-on-error". I'll leave it up to the editor and WG chair to decide whether to change it or not. The text should also make clear that these only apply to errors in applying the changes described in the element. Errors outside of the element are real errors in the use of the netconf protocol and cannot be ignored. The result should be no change to the device configuration. -steve On 2/2/06 12:40 PM, "Andy Bierman" wrote: > Steve Berl wrote: > > So you want to punt the issue to the data model specification? > > I still think some text is needed to make it clear that NETCONF > in no way specifies what it means to "continue after an error". It will be > up to the data model specification to make it clear how two > implementations of the the command for the > same data model will behave in the same way. > > The current text does not make it clear at all that we only mean > ignore-errors in the XML under the element. > The term 'ignore-errors' is misleading because sub-commands with > errors are not executed. The term 'continue-on-error' would have > been better, but it's not worth changing now. > > Andy > > > >> See my response to Phil. I propose that the errors that are "ignorable" be >> part of the description of the data model as the behavior seems to be >> coupled to the contents of the element. >> >> I think we have the same problem with "stop-on-error" as we do with >> "ignore-error". In either case there is a partial success and partial >> failure of the request. How can we stop-on-error how do we know which parts >> of the request worked and which didn't get executed? It is specific to the >> data/processing model that is being used. >> >> The whole idea of the error-option depends on the notion that there are >> multiple atomic operations described in the element, and that some >> may succeed and some may fail. The order in which these atomic operations >> are to be attempted may be specified in the content of the element, >> or not. In the case below, the boundaries and order of the atomic >> operations is pretty clear. In some other data models it might not be as >> obvious, but they may still be there. In order for there to be any way to >> understand the meaning of the stop-on-error and ignore-error options the >> boundaries of the atomic operations need to be understood. >> >> >> See some other comments below. >> >> >> On 2/2/06 10:48 AM, "Andy Bierman" wrote: >> >> >>> Steve Berl wrote: >>> >>>> The original intent of the option was to have behavior similar to Cisco IOS >>>> doing "copy tftp://foo/blah running-config". In this case the configuration >>>> is a list of lines, each represents an atomic configuration change >>>> operation. If one line generates an error we can continue on and execute >>>> the >>>> remaining lines, ignoring the error. The idea is that commands that don't >>>> make sense can be ignored, but the ones that do make sense can be applied. >>>> >>>> >>> Are you talking about simple XML-ifies CLI? >>> >>> >>> blah-blah >>> blah-blah >>> >>> >>> This is a trivial case. >>> >> >> It is a simple data model, yet we do support this in our implementation. It >> is very useful considering the existing base of tools and knowledge that >> understand the CLI. >> >> >>> Real XML data models are not so easy to implement for this feature. >>> >>> >>>> This proves to be a convenient behavior when an existing configuration runs >>>> on a different device than it was originally created for, or when a device >>>> has the software upgraded and some older commands are no longer supported, >>>> or if the line cards in a device have changed so that some interfaces that >>>> were there are now missing. >>>> >>>> >>> I understand the intent of the feature. >>> I don't think it is specified in a manner that will >>> allow developers to create interoperable implementations. >>> >>> >> >> I agree. The behavior is specific to the data/processing model that is being >> used. >> >> >>> >>>> One of the data models that we are supporting in the Cisco implementation >>>> of >>>> netconf is a list of command lines and this same behavior can be maintained >>>> with the ignore-error option. >>>> >>>> So, to better define the behavior in the netconf spec we need to be clear >>>> about the errors that we are choosing to ignore. I think that these are the >>>> errors that occur in the processing (not the parsing) of the >>>> element in an . >>>> >>>> >>> I think you mean the application of config changes. >>> If a config change passes all tests then apply it, >>> otherwise go on to the next config change. >>> >>> I think that's what you mean. >>> >> >> Yes. I think that is a better way to say it. >> >> >>> Just because an operation parses doesn't mean resources like locks >>> are free, or access control rules are met. >>> >>> >>>> There's probably a better way to say that. >>>> >>>> >>> The problem with this feature is that netconf is not a CLI. >>> There is no concept in netconf that the XML payload within >>> an operation is serialized into an integral number >>> of "lines". "When an error occurs, continue to the next line" >>> does not mean anything in XML. >>> >> >> Well, the netconf protocol is supposed to be agnostic to the data/processing >> model, so it should be able to work for a model that consists of a list of >> text commands that are executed in order. >> >> >>> Support of this feature requires a lot of custom work, >>> and prevents widely available validation tools from being >>> used (because they validate an entire sub-tree or nothing). >>> >> >> This is back to the definition of what errors are "ignorable". If we say >> that errors that are detected in the XML validation are not ignorable, but >> those detected in the application of the configuration changes are >> ignorable, then this is no problem. If a particular data model definition >> wants to say that no errors are ignorable, then that is fine also. >> >> >>> You can't even say "on error continue at the next sibling node" >>> because that isn't always true. All you can say is "it is an >>> implementation-specific matter if and where processing >>> of the sub-tree will continue after an error is >>> encountered." >>> >>> IMO, this means "no interoperability whatsoever". >>> >> >> Unless there are interoperable data models, their wasn't any >> interoperability at this level anyway. >> >> >>> >>>> -steve >>>> >>>> >>> Andy >>> >>> >>>> On 2/2/06 8:50 AM, "Andy Bierman" wrote: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> We have heard from one implementer that says they cannot >>>>> support the ignore-error in the operation. >>>>> Now one more. >>>>> >>>>> Here is the total documentation on the ignore-error option: >>>>> >>>>> ignore-error: Continue to process configuration data on error; >>>>> error is recorded and negative response is generated if any >>>>> errors occur. >>>>> >>>>> 1) How many operators want this option? >>>>> >>>>> 2) How many vendors are supporting this option? >>>>> >>>>> 3) What does this option really mean? >>>>> >>>>> - ignore malformed XML? >>>>> Most tools won't do that. This is not only dangerous, >>>>> it isn't very easy to do. >>>>> >>>>> - ignore missing parameters? What happens if the >>>>> parameter is missing? >>>>> >>>>> - ignore extra parameters? >>>>> >>>>> - use RPC parameters that don't pass the schema validation tests? >>>>> >>>>> - ignore access control violations? >>>>> >>>>> - ignore lock access violations? >>>>> >>>>> - ignore unsupported portions of the config parameter sub-tree? >>>>> >>>>> - use parameters that fail the referential integrity tests? >>>>> >>>>> - continue to install child nodes of a parent node with errors? >>>>> (How?) >>>>> >>>>> >>>>> IMO, this mandatory feature of the NETCONF protocol is poorly defined, >>>>> hard or impossible to implement, and has no chance of interoperability. >>>>> It needs to be fixed or removed from the protocol. >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>> -- >>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>>> the word 'unsubscribe' in a single line as the message text body. >>>>> archive: >>>>> >>>>> >>>> >>>> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> >> -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 20:20:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pcr-00051C-74 for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 20:20:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07923 for ; Thu, 2 Feb 2006 20:18:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4pX3-000NrT-Ab for netconf-data@psg.com; Fri, 03 Feb 2006 01:14:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4pX0-000Nr9-SO for netconf@ops.ietf.org; Fri, 03 Feb 2006 01:14:35 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k131EX1Z099581; Thu, 2 Feb 2006 17:14:33 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k131EW561276; Thu, 2 Feb 2006 17:14:32 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k131JmYE023485; Thu, 2 Feb 2006 20:19:49 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200602030119.k131JmYE023485@idle.juniper.net> To: Steve Berl cc: Andy Bierman , "Netconf (E-mail)" Subject: Re: problems with 'ignore-error' In-Reply-To: Your message of "Thu, 02 Feb 2006 15:56:34 PST." Date: Thu, 02 Feb 2006 20:19:48 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Steve Berl writes: >It would be clearer if the choices were "stop-on-error", >"continue-on-error", and "rollback-on-error". I'll leave it up to the editor >and WG chair to decide whether to change it or not. Sounds good to me. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 02 20:58:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4qDq-00013V-MG for netconf-archive@megatron.ietf.org; Thu, 02 Feb 2006 20:58:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10317 for ; Thu, 2 Feb 2006 20:57:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4q8X-0000f7-KJ for netconf-data@psg.com; Fri, 03 Feb 2006 01:53:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4q8T-0000eu-LH for netconf@ops.ietf.org; Fri, 03 Feb 2006 01:53:17 +0000 Received: (qmail 25978 invoked from network); 3 Feb 2006 01:53:16 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 3 Feb 2006 01:53:16 -0000 Message-ID: <43E2B78B.10804@andybierman.com> Date: Thu, 02 Feb 2006 17:53:15 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Steve Berl CC: "Netconf (E-mail)" Subject: Re: problems with 'ignore-error' References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steve Berl wrote: > I think I agree with you completely. > > It would be clearer if the choices were "stop-on-error", > "continue-on-error", and "rollback-on-error". I'll leave it up to the editor > and WG chair to decide whether to change it or not. > > I don't mind. IMO, "ignore-errors" is really confusing. It's not in the form of an action to take when an error occurs, like the other 2 choices. A NETCONF data model should describe its referential integrity requirements somehow, so that implementers know which instances of which objects are conceptually coupled. It does not need to describe any error-option specific behavior. The real issue is not how agent implementers will deal with this, but rather "will applications get consistent error info for the same set of conditions from one agent to another?" > The text should also make clear that these only apply to errors in applying > the changes described in the element. Errors outside of the > element are real errors in the use of the netconf protocol and > cannot be ignored. The result should be no change to the device > configuration. > Can we say "application layer errors within the element."? Does that cover it? Also: "It is a data-model specific matter how an agent divides an operation into sub-operations for the implementation of the 'stop-on-error' and 'continue-on-error' error-option values. If one or more of the sub-operations completes, but one or more sub-operations does not complete (due to errors), then the agent MUST return a 'partial-operation' error tag in the ." > -steve > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Feb 03 17:39:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59Zr-0007QL-Tn for netconf-archive@megatron.ietf.org; Fri, 03 Feb 2006 17:39:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22814 for ; Fri, 3 Feb 2006 17:37:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F59Rg-000Aj3-2S for netconf-data@psg.com; Fri, 03 Feb 2006 22:30:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F59Rf-000Aiq-Ap for netconf@ops.ietf.org; Fri, 03 Feb 2006 22:30:23 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k13MU7nE014642; Fri, 3 Feb 2006 14:30:11 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1HRXXGPG>; Fri, 3 Feb 2006 14:30:08 -0800 Message-ID: From: "McDonald, Ira" To: "'Andy Bierman'" , Steve Berl Cc: "Netconf (E-mail)" Subject: RE: problems with 'ignore-error' Date: Fri, 3 Feb 2006 14:30:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, FWIW - the Internet Printing Protocol v1.1 (RFC 2911) defined several relevant values for the "status-code" always returned in operation responses: 'successful-ok' - The request has succeeded and no request attributes were substituted or ignored. 'successful-ok-ignored-or-substituted-attributes' - The request has succeeded, but some supplied (1) attributes were ignored or (2) unsupported values were substituted with supported values or were ignored in order to perform the operation without rejecting it. Unsupported attributes, attribute syntaxes, or values MUST be returned in the Unsupported Attributes group of the response for all operations. 'successful-ok-conflicting-attributes' - The request has succeeded, but some supplied attribute values conflicted with the values of other supplied attributes. These conflicting values were either (1) substituted with (supported) values or (2) the attributes were removed in order to process the job without rejecting it. Attributes or values which conflict with other attributes and have been substituted or ignored MUST be returned in the Unsupported Attributes group of the response for all operations as supplied by the client. And later, to provide more explicit control for the submitter, the PWG IPP Job Extensions (PWG 5100.5, October 2003), defined the new "job-mandatory-attributes" element (translate IPP 'attribute' to XML schema 'element' not 'attribute', by the way). IPP/1.1 receivers are uniquely able to gracefully handle unsupported attributes, because the IPP wire encoding includes strong typing and lengths (so that it's always possible to skip over an unsupported or unrecognized attribute in a request). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Thursday, February 02, 2006 8:53 PM > To: Steve Berl > Cc: Netconf (E-mail) > Subject: Re: problems with 'ignore-error' > > > Steve Berl wrote: > > I think I agree with you completely. > > > > It would be clearer if the choices were "stop-on-error", > > "continue-on-error", and "rollback-on-error". I'll leave it > up to the editor > > and WG chair to decide whether to change it or not. > > > > > > I don't mind. IMO, "ignore-errors" is really confusing. > It's not in the form of an action to take when an error occurs, > like the other 2 choices. > > A NETCONF data model should describe its referential integrity > requirements somehow, so that implementers know which instances > of which objects are conceptually coupled. It does not need to > describe any error-option specific behavior. > > The real issue is not how agent implementers will deal with this, > but rather "will applications get consistent error info for > the same set of conditions from one agent to another?" > > > The text should also make clear that these only apply to > errors in applying > > the changes described in the element. Errors outside of the > > element are real errors in the use of the netconf > protocol and > > cannot be ignored. The result should be no change to the device > > configuration. > > > > Can we say "application layer errors within the element."? > Does that cover it? > > Also: > > "It is a data-model specific matter how an agent divides > an operation into sub-operations > for the implementation of the 'stop-on-error' and 'continue-on-error' > error-option values. If one or more of the sub-operations > completes, but one or more sub-operations does not complete (due > to errors), then the agent MUST return a 'partial-operation' error tag > in the ." > > > > > -steve > > > Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Feb 04 17:06:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5VY4-0003Jy-9g for netconf-archive@megatron.ietf.org; Sat, 04 Feb 2006 17:06:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11726 for ; Sat, 4 Feb 2006 17:04:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5VPt-0001fB-Ig for netconf-data@psg.com; Sat, 04 Feb 2006 21:58:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5VPs-0001ey-Fr for netconf@ops.ietf.org; Sat, 04 Feb 2006 21:58:00 +0000 Received: (qmail 31393 invoked from network); 4 Feb 2006 21:57:59 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 4 Feb 2006 21:57:59 -0000 Message-ID: <43E52366.3030204@andybierman.com> Date: Sat, 04 Feb 2006 13:57:58 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rob Enns CC: "Netconf (E-mail)" Subject: XSD session-id clarification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Rob, I hate to make you add another change, but I think the XSD is supposed to help automate tool development, and the 'session-id' schema is wrong. Zero is never a valid value for session-id in a hello message or kill-session operation. There are really 2 types: SessionId (type="unsignedInt" minInclusive="1") SessionIdOrZero (type="unsignedInt") The places SessionId is used (should leave alone): - kill-session : session-id parameter - hello : session-id parameter The place SessionId should be changed to SessionIdOrZero: - not in the XSD! - the content for a lock-denied error is a session-id element (type is really SessionIdOrZero) - I guess we don't technically need this simpleType If you add a minInclusive="1" restriction to the SessionId simpleType, then the XSD will be correct (for sessionId at least ;-) thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Feb 05 14:23:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5pTo-0006x7-83 for netconf-archive@megatron.ietf.org; Sun, 05 Feb 2006 14:23:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05097 for ; Sun, 5 Feb 2006 14:21:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5pME-000EPL-89 for netconf-data@psg.com; Sun, 05 Feb 2006 19:15:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5pMD-000EP8-Kn for netconf@ops.ietf.org; Sun, 05 Feb 2006 19:15:33 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k15JFN0U001752; Sun, 5 Feb 2006 11:15:28 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BXRXVJ>; Sun, 5 Feb 2006 11:15:24 -0800 Message-ID: From: "McDonald, Ira" To: "'Andy Bierman'" , Rob Enns Cc: "Netconf (E-mail)" Subject: RE: XSD session-id clarification Date: Sun, 5 Feb 2006 11:15:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, Agreed, but 'SessionIdOrZero' should definitely have a 'minInclusive=0' facet. A negative session ID is meaningless. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Saturday, February 04, 2006 4:58 PM > To: Rob Enns > Cc: Netconf (E-mail) > Subject: XSD session-id clarification > > > Hi Rob, > > I hate to make you add another change, > but I think the XSD is supposed to help automate > tool development, and the 'session-id' schema is wrong. > Zero is never a valid value for session-id in a hello > message or kill-session operation. > > There are really 2 types: > > SessionId (type="unsignedInt" minInclusive="1") > > SessionIdOrZero (type="unsignedInt") > > > The places SessionId is used (should leave alone): > > - kill-session : session-id parameter > > - hello : session-id parameter > > The place SessionId should be changed to SessionIdOrZero: > > - not in the XSD! > - the content for a lock-denied error is > a session-id element (type is really SessionIdOrZero) > - I guess we don't technically need this simpleType > > > If you add a minInclusive="1" restriction to the SessionId > simpleType, then the XSD will be correct (for sessionId at least ;-) > > > > thanks, > Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Feb 05 15:00:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5q3p-0000xq-IZ for netconf-archive@megatron.ietf.org; Sun, 05 Feb 2006 15:00:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07934 for ; Sun, 5 Feb 2006 14:58:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5pz8-000H40-2d for netconf-data@psg.com; Sun, 05 Feb 2006 19:55:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5pz7-000H3o-Ep for netconf@ops.ietf.org; Sun, 05 Feb 2006 19:55:45 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k15JtcX52242; Sun, 5 Feb 2006 11:55:38 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k15JtW590345; Sun, 5 Feb 2006 11:55:33 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k15K0mYE035165; Sun, 5 Feb 2006 15:00:48 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200602052000.k15K0mYE035165@idle.juniper.net> To: "McDonald, Ira" cc: "'Andy Bierman'" , Rob Enns , "Netconf (E-mail)" Subject: Re: XSD session-id clarification In-Reply-To: Your message of "Sun, 05 Feb 2006 11:15:23 PST." Date: Sun, 05 Feb 2006 15:00:48 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk >Andy Bierman said: >> There are really 2 types: >> SessionId (type="unsignedInt" minInclusive="1") >> SessionIdOrZero (type="unsignedInt") "McDonald, Ira" writes: >Agreed, but 'SessionIdOrZero' should definitely have >a 'minInclusive=0' facet. A negative session ID is >meaningless. unsignedInt can't be negative. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 06 04:39:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F62ps-0000Cz-6H for netconf-archive@megatron.ietf.org; Mon, 06 Feb 2006 04:39:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02025 for ; Mon, 6 Feb 2006 04:37:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F62eG-000EqS-6Q for netconf-data@psg.com; Mon, 06 Feb 2006 09:27:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F62eF-000Eq3-7H for netconf@ops.ietf.org; Mon, 06 Feb 2006 09:27:03 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DAFC04F0013 for ; Mon, 6 Feb 2006 10:27:01 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 10:27:00 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 10:26:59 +0100 Message-ID: <43E71656.5080101@ericsson.com> Date: Mon, 06 Feb 2006 10:26:46 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Clarifications Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2006 09:26:59.0181 (UTC) FILETIME=[7ACB51D0:01C62AFF] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, - The validate operation might contain inline config as well as I understand the XSD. In the text only datastore name is mentioned. Which is correct ? - Is it true that one RPC can contain only one operation? The XSD seems to indicate this, but maybe it should be mentioned in the text as well. -- Balazs Lengyel Ericsson Hungary Ltd. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 06 11:39:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F69OH-0008It-8s for netconf-archive@megatron.ietf.org; Mon, 06 Feb 2006 11:39:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02208 for ; Mon, 6 Feb 2006 11:37:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F69FF-000KYw-4W for netconf-data@psg.com; Mon, 06 Feb 2006 16:29:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F69FE-000KYh-Fm for netconf@ops.ietf.org; Mon, 06 Feb 2006 16:29:40 +0000 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 06 Feb 2006 08:29:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,92,1139212800"; d="scan'208"; a="525892095:sNHT23939464" Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 08:29:39 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: XSD session-id clarification Date: Mon, 6 Feb 2006 08:29:10 -0800 Message-ID: Thread-Topic: XSD session-id clarification Thread-Index: AcYp1hbxKGQu92tLQna244VAD20w+ABZEAbQ From: "Rob Enns" To: "Andy Bierman" Cc: "Netconf \(E-mail\)" X-OriginalArrivalTime: 06 Feb 2006 16:29:39.0483 (UTC) FILETIME=[86B64EB0:01C62B3A] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable No worries, this is a good change. Rob=20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Saturday, February 04, 2006 1:58 PM > To: Rob Enns > Cc: Netconf (E-mail) > Subject: XSD session-id clarification >=20 > Hi Rob, >=20 > I hate to make you add another change, > but I think the XSD is supposed to help automate > tool development, and the 'session-id' schema is wrong. > Zero is never a valid value for session-id in a hello > message or kill-session operation. >=20 > There are really 2 types: >=20 > SessionId (type=3D"unsignedInt" minInclusive=3D"1") >=20 > SessionIdOrZero (type=3D"unsignedInt") >=20 >=20 > The places SessionId is used (should leave alone): >=20 > - kill-session : session-id parameter >=20 > - hello : session-id parameter >=20 > The place SessionId should be changed to SessionIdOrZero: >=20 > - not in the XSD! > - the content for a lock-denied error is > a session-id element (type is really SessionIdOrZero) > - I guess we don't technically need this simpleType >=20 >=20 > If you add a minInclusive=3D"1" restriction to the SessionId > simpleType, then the XSD will be correct (for sessionId at least ;-) >=20 >=20 >=20 > thanks, > Andy >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Feb 10 10:29:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aDW-0005FH-Ob for netconf-archive@megatron.ietf.org; Fri, 10 Feb 2006 10:29:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27897 for ; Fri, 10 Feb 2006 10:28:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7a1V-000AsJ-3q for netconf-data@psg.com; Fri, 10 Feb 2006 15:17:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7a1T-000As5-UQ for netconf@ops.ietf.org; Fri, 10 Feb 2006 15:17:24 +0000 Received: (qmail 24955 invoked from network); 10 Feb 2006 15:16:30 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 10 Feb 2006 15:16:30 -0000 Message-ID: <43ECAE4D.6070208@andybierman.com> Date: Fri, 10 Feb 2006 07:16:29 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Balazs Lengyel CC: netconf@ops.ietf.org Subject: Re: Clarifications References: <43E71656.5080101@ericsson.com> In-Reply-To: <43E71656.5080101@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Balazs Lengyel wrote: > Hello, > - The validate operation might contain inline config as well as I > understand the XSD. In the text only datastore name is mentioned. > Which is correct ? inline also -- this bug was already found > > - Is it true that one RPC can contain only one operation? The XSD > seems to indicate this, but maybe it should be mentioned in the text > as well. > yes. I believe this is the text in question (from prot-10 [4.1]): The element is used to enclose a NETCONF request sent from the client to the server. If we meant N requests this sentence would say "enclose one or more NETCONF requests" instead. All along, we keep referring to our operations layer as if it really is independent of the RPC layer. But as sec. 4 clearly indicates (to me anyway), from the RPC layer POV, there is no operations layer. There is a top node which indicates the RPC method to call, and any child nodes of that are just input parameters to the RPC method. There is only one RPC method call per element. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Feb 10 16:03:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7fQl-00029B-Mo for netconf-archive@megatron.ietf.org; Fri, 10 Feb 2006 16:03:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28854 for ; Fri, 10 Feb 2006 16:02:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7fDQ-0007QE-LE for netconf-data@psg.com; Fri, 10 Feb 2006 20:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7fDP-0007PQ-8j for netconf@ops.ietf.org; Fri, 10 Feb 2006 20:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F7fDN-0008EA-TV; Fri, 10 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-prot-11.txt Message-Id: Date: Fri, 10 Feb 2006 15:50:01 -0500 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Configuration Protocol Author(s) : R. Enns Filename : draft-ietf-netconf-prot-11.txt Pages : 104 Date : 2006-2-10 The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-prot-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-prot-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-10151438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-prot-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-prot-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-10151438.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Feb 10 19:57:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7j4h-0004Ya-CY for netconf-archive@megatron.ietf.org; Fri, 10 Feb 2006 19:57:21 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25923 for ; Fri, 10 Feb 2006 19:55:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7ixI-000LyM-Oc for netconf-data@psg.com; Sat, 11 Feb 2006 00:49:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7ixH-000LyA-KI for netconf@ops.ietf.org; Sat, 11 Feb 2006 00:49:39 +0000 Received: (qmail 5200 invoked from network); 11 Feb 2006 00:49:38 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 11 Feb 2006 00:49:38 -0000 Message-ID: <43ED34E2.6070301@andybierman.com> Date: Fri, 10 Feb 2006 16:50:42 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: netconf implementation guide Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I think eventually we will keep collecting clarifications, maybe even enough for a NETCONF Implementation Guide RFC. Are there any WG members willing to work on a NETCONF Implementation Guide (Informational) RFC? Is there community interest in having such a document? If so, the first step is collecting implementation experience, FAQ material, document clarifications and errata, etc. ========================================== 2 more issues that aren't very obvious (No, nothing more is going into prot-11; NETCONF Version 1 is in the can.) 1) Error processing hierarchy There are some errors that need to be processed before others. It is reasonable for an agent to stop looking for certain types of errors after particular errors have already occurred. For example, if the target of an edit-config is an unknown configuration name, or the user doesn't have access rights to invoke the edit-config method, then the element sub-tree may not be analyzed for errors, regardless of the 'continue-on-error' flag. It is therefore possible (e.g., big edit-config request) for a manager to receive an rpc-reply before it finishes sending the matching request. 2) Edit-config processing The merge order is data model dependent. A NETCONF data model definition which allows multiple instances of an element must indicate the merge order somehow. When processing a replace operation, it is important to know if a sub-node (in the data model, not the PDU!) is 1) mandatory 2) mandatory-with-default 3) optional If (1) then missing sub-elements are errors. If (2) then missing sub-elements with defaults are filled in before checking for missing elements. If (3) then this is not an error, but any corresponding nodes in the target that match the missing nodes must be removed A NETCONF data model definition must indicate the replace behavior somehow. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Feb 10 20:35:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7jft-00069q-GV for netconf-archive@megatron.ietf.org; Fri, 10 Feb 2006 20:35:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27690 for ; Fri, 10 Feb 2006 20:33:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7jYJ-000OCW-9O for netconf-data@psg.com; Sat, 11 Feb 2006 01:27:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.179.9.4] (helo=extrgate1.extremenetworks.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7jYI-000OCJ-FI for netconf@ops.ietf.org; Sat, 11 Feb 2006 01:27:54 +0000 Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Fri, 10 Feb 2006 17:27:53 -0800 Message-ID: <3DC3910A44FBD94B8513C8E2A3F220E101112FCE@sc-msexch-16.extremenetworks.com> From: Zihong Lu To: "'Andy Bierman'" , "Netconf (E-mail)" Subject: RE: netconf implementation guide Date: Fri, 10 Feb 2006 17:27:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk A document with netconf implementation guide, compliance requirements and inter-operate testing rules will benefit the community a lot. -Zihong > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Friday, February 10, 2006 4:51 PM > To: Netconf (E-mail) > Subject: netconf implementation guide > > > Hi, > > I think eventually we will keep collecting clarifications, > maybe even enough for a NETCONF Implementation Guide RFC. > > Are there any WG members willing to work on a > NETCONF Implementation Guide (Informational) RFC? > Is there community interest in having such a document? > > If so, the first step is collecting implementation experience, > FAQ material, document clarifications and errata, etc. > > > ========================================== > > 2 more issues that aren't very obvious > (No, nothing more is going into prot-11; > NETCONF Version 1 is in the can.) > > 1) Error processing hierarchy > > There are some errors that need to be processed before others. > It is reasonable for an agent to stop looking for certain types > of errors after particular errors have already occurred. > > For example, if the target of an edit-config is an unknown > configuration name, or the user doesn't have access rights to > invoke the edit-config method, then the element sub-tree > may not be analyzed for errors, regardless of the > 'continue-on-error' flag. > > It is therefore possible (e.g., big edit-config request) for a manager > to receive an rpc-reply before it finishes sending the matching > request. > > 2) Edit-config processing > > The merge order is data model dependent. > A NETCONF data model definition which allows > multiple instances of an element must indicate the > merge order somehow. > > When processing a replace operation, it is important > to know if a sub-node (in the data model, not the PDU!) is > 1) mandatory > 2) mandatory-with-default > 3) optional > > If (1) then missing sub-elements are errors. > If (2) then missing sub-elements with defaults are filled in before > checking for missing elements. > If (3) then this is not an error, but any corresponding nodes > in the target that match the missing nodes must be removed > > A NETCONF data model definition must indicate the > replace behavior somehow. > > > > Andy > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Feb 10 20:59:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7k2x-0007MF-EY for netconf-archive@megatron.ietf.org; Fri, 10 Feb 2006 20:59:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28947 for ; Fri, 10 Feb 2006 20:57:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7jxu-000Pqz-7X for netconf-data@psg.com; Sat, 11 Feb 2006 01:54:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7jxt-000Pqn-Gd for netconf@ops.ietf.org; Sat, 11 Feb 2006 01:54:21 +0000 Received: (qmail 26793 invoked from network); 11 Feb 2006 01:47:48 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr5.mgt.bos.netsol.com with SMTP; 11 Feb 2006 01:47:48 -0000 Message-ID: <43ED428C.5090206@andybierman.com> Date: Fri, 10 Feb 2006 17:49:00 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Zihong Lu CC: "Netconf (E-mail)" Subject: Re: netconf implementation guide References: <3DC3910A44FBD94B8513C8E2A3F220E101112FCE@sc-msexch-16.extremenetworks.com> In-Reply-To: <3DC3910A44FBD94B8513C8E2A3F220E101112FCE@sc-msexch-16.extremenetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Zihong Lu wrote: > A document with netconf implementation guide, compliance requirements and > inter-operate testing rules will benefit the community a lot. > > An implementation guide is an Informational RFC, which means it doesn't contain requirements and rules. The protocol specifications themselves provide all the normative compliance and interoperability requirements. If even we wanted to add lots of CLRs (clever little rules), which we don't, it is still too early for us to have enough collective wisdom to get it right. > -Zihong > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Feb 11 12:28:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7yXW-0003yk-N2 for netconf-archive@megatron.ietf.org; Sat, 11 Feb 2006 12:28:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18422 for ; Sat, 11 Feb 2006 12:26:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7yOa-000GIN-2t for netconf-data@psg.com; Sat, 11 Feb 2006 17:18:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7yOY-000GIA-Pl for netconf@ops.ietf.org; Sat, 11 Feb 2006 17:18:51 +0000 Received: (qmail 21296 invoked from network); 11 Feb 2006 17:18:49 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 11 Feb 2006 17:18:49 -0000 Message-ID: <43EE1CF3.1020109@andybierman.com> Date: Sat, 11 Feb 2006 09:20:51 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: element order error processing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am confused as to which error-tag to use for wrong element order. For example: Given a simple data model: element foo { element a, element b, element c } The use of missing-element vs. unknown-element error-tag is confusing: Given this PDU fragment: It is clear that a 'missing-element' error for "/foo/b" should be generated here. What about this?: A reasonable implementation choice would lead one to generate a 'missing-element' error for "/foo/b" when "/foo/c" is encountered. But "b" isn't missing, it is in the wrong place. The only other error choice seems to be 'unknown-element' for "/foo/b" in this case, which is totally confusing because "b" is not unknown at all. Generating a 'missing-element' and 'unknown-element' for "b" in the same is even worse. What should the correct error response be in this case? Is an agent implementation allowed to ignore wrong-order errors or must all elements always be given in a fixed order? This seems like a CLR to me. thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Feb 12 13:39:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8M8W-0007Ow-Cw for netconf-archive@megatron.ietf.org; Sun, 12 Feb 2006 13:39:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05996 for ; Sun, 12 Feb 2006 13:38:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8M17-000Pw1-Fm for netconf-data@psg.com; Sun, 12 Feb 2006 18:32:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8M16-000Pvm-9p for netconf@ops.ietf.org; Sun, 12 Feb 2006 18:32:12 +0000 Received: (qmail 3329 invoked from network); 12 Feb 2006 18:32:11 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 12 Feb 2006 18:32:11 -0000 Message-ID: <43EF7F2E.4020002@andybierman.com> Date: Sun, 12 Feb 2006 10:32:14 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: element order error processing References: <43EE1CF3.1020109@andybierman.com> <20060212.160042.26344568.mbj@tail-f.com> In-Reply-To: <20060212.160042.26344568.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: > Andy Bierman wrote: > >> Hi, >> >> I am confused as to which error-tag to use for wrong element order. >> >> For example: >> >> Given a simple data model: >> >> element foo { >> element a, >> element b, >> element c >> } >> >> The use of missing-element vs. unknown-element error-tag is confusing: >> >> Given this PDU fragment: >> >> >> >> >> >> >> It is clear that a 'missing-element' error for "/foo/b" should >> be generated here. >> >> What about this?: >> >> >> >> >> >> >> >> A reasonable implementation choice would lead one to generate >> a 'missing-element' error for "/foo/b" when "/foo/c" is encountered. >> But "b" isn't missing, it is in the wrong place. >> > > We're generating 'missing-element' in this case. > > me too >> The only other >> error choice seems to be 'unknown-element' for "/foo/b" >> > > I'd say that the other alternative would be unknown-element for > /foo/c. > Well, once I see that 'b' is missing, I bump the current-node pointer to 'c', so it is not unexpected. Since 'c' is last, the error code that looks for extra nodes will catch this, and generate an (unexpected) unknown-element error for 'b'. It's the combination that seems crazy, and yet also appears to be most correct, at the same time. > >> in this case, which is totally confusing because "b" is not unknown >> at all. >> > > Actually, unknown-element is defined as "An unexpected element is > present". So it just says that the element is "unexpected" not that > it actually is "unknown". > I know -- I was trying to point out that our error codes are overloaded. IMO, we will probably want to refine this sooner or later. An application really wants to know the difference between: - agent doesn't know this node (maybe misspelled, or data model version mismatch?) - node is in the wrong order - more than the expected number of instances of a node are present But the 'unknown-element' error-tag will be returned for all these error conditions. > >> Generating a 'missing-element' and 'unknown-element' for "b" >> in the same is even worse. >> >> What should the correct error response be in this case? >> > > I think missing-element for /foo/b and unknown-element for /foo/c are > equally good (or bad). > > However, your implementation could use an error-app-tag to further > describe this situation, if you can detect it. > Yes, I guess I will. But this is not good enough for an interoperable standard. > >> Is an agent implementation allowed to ignore wrong-order errors >> or must all elements always be given in a fixed order? >> > > This must be depending on the data model. A data model could be > defined with a strict order or not. (compare w/ xs:all in a > complexType in XML Schema). > So it's up to the data modeling language, not XML itself? That's what I was hoping. So we don't HAVE to ignore the Postel Principle if we don't want to? It really goes against common sense to reject an RPC with an error like "parameter 2 and 3 are in the wrong order". If the agent knows all the parameters are present and accounted for, that is good enough. I'm not trying to force every agent to do this (I would say MAY, not MUST). You may have noticed that CLI and Unix config file implementations only enforce command order when they absolutely have to. > > > /martin > > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 13 11:37:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gho-0004Ic-Sx for netconf-archive@megatron.ietf.org; Mon, 13 Feb 2006 11:37:41 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05620 for ; Mon, 13 Feb 2006 11:35:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8gZy-000GYQ-BU for netconf-data@psg.com; Mon, 13 Feb 2006 16:29:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8gZx-000GYE-5W for netconf@ops.ietf.org; Mon, 13 Feb 2006 16:29:33 +0000 Received: (qmail 23703 invoked from network); 13 Feb 2006 16:29:32 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 13 Feb 2006 16:29:32 -0000 Message-ID: <43F0B42A.1010701@andybierman.com> Date: Mon, 13 Feb 2006 08:30:34 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: netconf implementation guide References: <43ED34E2.6070301@andybierman.com> <20060213.131916.127095981.mbj@tail-f.com> In-Reply-To: <20060213.131916.127095981.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: > Andy Bierman wrote: > >> Hi, >> >> I think eventually we will keep collecting clarifications, >> maybe even enough for a NETCONF Implementation Guide RFC. >> >> Are there any WG members willing to work on a >> NETCONF Implementation Guide (Informational) RFC? >> Is there community interest in having such a document? >> >> If so, the first step is collecting implementation experience, >> FAQ material, document clarifications and errata, etc. >> > > I think this is a great idea, and I'm willing to help with this work. > Great -- will you be at the Dallas IETF? I am planning to hold an Editors meetings/Bar BoF in Dallas to get this started. > > /martin > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 13 15:42:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kWu-0004vP-6Z for netconf-archive@megatron.ietf.org; Mon, 13 Feb 2006 15:42:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21535 for ; Mon, 13 Feb 2006 15:40:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8kPr-0004ep-4J for netconf-data@psg.com; Mon, 13 Feb 2006 20:35:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DEAR_SOMETHING autolearn=no version=3.1.0 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8kPp-0004eY-8N for netconf@ops.ietf.org; Mon, 13 Feb 2006 20:35:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k1DKZHRG009020; Mon, 13 Feb 2006 21:35:17 +0100 Received: from courrier.rennes.enst-bretagne.fr (f1-clust.rennes.enst-bretagne.fr [193.52.74.16]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k1DKZG3X009009; Mon, 13 Feb 2006 21:35:16 +0100 Received: from [127.0.0.1] (adel.maisel.rennes.enst-bretagne.fr [192.168.0.65]) by courrier.rennes.enst-bretagne.fr (8.12.11/8.12.11/2004.01.01) with ESMTP id k1DKZAjm010811; Mon, 13 Feb 2006 21:35:16 +0100 (MET) Message-ID: <43F0EE1B.9090303@enst-bretagne.fr> Date: Mon, 13 Feb 2006 21:37:47 +0100 From: Adel_JARIFI User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: netconf@ops.ietf.org CC: Arnaud Goulois Subject: Information about Netconf industrial implementation References: <43ED34E2.6070301@andybierman.com> <20060213.131916.127095981.mbj@tail-f.com> <43F0B42A.1010701@andybierman.com> In-Reply-To: <43F0B42A.1010701@andybierman.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: amavisd-new at enst-bretagne.fr Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA21535 Dear Sir, Madam, We are a group of students from ENST Brittany (National School of=20 telecommunication of Brittany) =96 located in Rennes - France=20 (http://international.enst-bretagne.fr/welcome/). We work on a network management project based on the Netconf protocol.=20 In a first place we were interested in the protocol itself and currently=20 we are looking into the various open source and proprietary=20 implementations of Netconf. We know that MADYNES team of INRIA has developed a set of software=20 called =93Ensuite=94, but we don=92t know if industrial companies and net= work=20 equipment providers such as Cisco, HP, Juniper, etc=85are developing on=20 there side any solution based on Netconf. I would like to know if you have some information about some proprietary=20 implementation. Thank you in advance for your help and support. Best regards, Adel JARIFI -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 14 07:16:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8z6R-0002ng-OD for netconf-archive@megatron.ietf.org; Tue, 14 Feb 2006 07:16:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19949 for ; Tue, 14 Feb 2006 07:14:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8ysC-000439-7g for netconf-data@psg.com; Tue, 14 Feb 2006 12:01:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.225] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8ysB-00042u-35 for netconf@ops.ietf.org; Tue, 14 Feb 2006 12:01:35 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 117361934; Sun, 12 Feb 2006 16:00:53 +0100 Date: Sun, 12 Feb 2006 16:00:42 +0100 (CET) Message-Id: <20060212.160042.26344568.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: element order error processing From: Martin Bjorklund In-Reply-To: <43EE1CF3.1020109@andybierman.com> References: <43EE1CF3.1020109@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy Bierman wrote: > Hi, > > I am confused as to which error-tag to use for wrong element order. > > For example: > > Given a simple data model: > > element foo { > element a, > element b, > element c > } > > The use of missing-element vs. unknown-element error-tag is confusing: > > Given this PDU fragment: > > > > > > > It is clear that a 'missing-element' error for "/foo/b" should > be generated here. > > What about this?: > > > > > > > > A reasonable implementation choice would lead one to generate > a 'missing-element' error for "/foo/b" when "/foo/c" is encountered. > But "b" isn't missing, it is in the wrong place. We're generating 'missing-element' in this case. > The only other > error choice seems to be 'unknown-element' for "/foo/b" I'd say that the other alternative would be unknown-element for /foo/c. > in this case, which is totally confusing because "b" is not unknown > at all. Actually, unknown-element is defined as "An unexpected element is present". So it just says that the element is "unexpected" not that it actually is "unknown". > Generating a 'missing-element' and 'unknown-element' for "b" > in the same is even worse. > > What should the correct error response be in this case? I think missing-element for /foo/b and unknown-element for /foo/c are equally good (or bad). However, your implementation could use an error-app-tag to further describe this situation, if you can detect it. > Is an agent implementation allowed to ignore wrong-order errors > or must all elements always be given in a fixed order? This must be depending on the data model. A data model could be defined with a strict order or not. (compare w/ xs:all in a complexType in XML Schema). /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 14 14:39:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F961M-0003KN-Qy for netconf-archive@megatron.ietf.org; Tue, 14 Feb 2006 14:39:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21889 for ; Tue, 14 Feb 2006 14:37:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F95sO-0005qg-Q2 for netconf-data@psg.com; Tue, 14 Feb 2006 19:30:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.193] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F95sN-0005qS-L1 for netconf@ops.ietf.org; Tue, 14 Feb 2006 19:30:15 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe07.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 121143275; Mon, 13 Feb 2006 13:29:48 +0100 Date: Mon, 13 Feb 2006 13:29:41 +0100 (CET) Message-Id: <20060213.132941.48203534.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: element order error processing From: Martin Bjorklund In-Reply-To: <43EF7F2E.4020002@andybierman.com> References: <43EE1CF3.1020109@andybierman.com> <20060212.160042.26344568.mbj@tail-f.com> <43EF7F2E.4020002@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy Bierman wrote: > I know -- I was trying to point out that our error codes are overloaded. > > IMO, we will probably want to refine this sooner or later. I agree. > > However, your implementation could use an error-app-tag to further > > describe this situation, if you can detect it. > > > > Yes, I guess I will. > But this is not good enough for an interoperable standard. I agree. Currently we have 5 app-tags, all of them data modelling specific. > >> Is an agent implementation allowed to ignore wrong-order errors > >> or must all elements always be given in a fixed order? > >> > > > > This must be depending on the data model. A data model could be > > defined with a strict order or not. (compare w/ xs:all in a > > complexType in XML Schema). > > > > So it's up to the data modeling language, not XML itself? > That's what I was hoping. > > So we don't HAVE to ignore the Postel Principle if we don't want to? > > It really goes against common sense to reject an RPC with an error > like "parameter 2 and 3 are in the wrong order". If the agent knows > all the parameters are present and accounted for, that is good enough. > I'm not trying to force every agent to do this (I would say MAY, not MUST). A well-defined order might be easier to implement - an agent might have to buffer lots of data if the order is undefined. We do not use xs:all in our modelling language, i.e. we have a strict order. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 05:38:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9K3Z-0007M2-PI for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 05:38:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27270 for ; Wed, 15 Feb 2006 05:36:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Jv1-0002zF-TP for netconf-data@psg.com; Wed, 15 Feb 2006 10:29:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Jv0-0002z1-JJ for netconf@ops.ietf.org; Wed, 15 Feb 2006 10:29:54 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C78C962D62 for ; Wed, 15 Feb 2006 11:29:52 +0100 (CET) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id 6173B62D62 for ; Wed, 15 Feb 2006 11:29:46 +0100 (CET) Message-ID: <43F30326.40608@loria.fr> Date: Wed, 15 Feb 2006 11:32:06 +0100 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Capabilities and MIBs Content-Type: multipart/mixed; boundary="------------000207010207020509020002" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000207010207020509020002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I would like that our agent advertises its supported "MIBs". Are capabilities the regular way to do it ? Like, for example, for the agent to advertise that it supports "bgp" MIB, "routes" MIB and "network interfaces" MIB. urn:ietf:params:netconf:base:1.0 urn:ietf:params:netconf:capability:startup:1.0 urn:madynes:module:bgp urn:madynes:module:routes urn:madynes:module:interfaces 4 Is it acceptable ? Thanks for your help. Vincent Cridlig --------------000207010207020509020002 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Disposition: attachment; filename="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------000207010207020509020002-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 07:42:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Lyy-00054Y-DG for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 07:42:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05160 for ; Wed, 15 Feb 2006 07:40:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Lrj-000A1o-7E for netconf-data@psg.com; Wed, 15 Feb 2006 12:34:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Lrf-000A1R-AC for netconf@ops.ietf.org; Wed, 15 Feb 2006 12:34:35 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 67DAD11 for ; Wed, 15 Feb 2006 13:34:34 +0100 (CET) Date: Wed, 15 Feb 2006 13:34:26 +0100 (CET) Message-Id: <20060215.133426.78721175.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: url clarification From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I once asked what it means to lock a remote url. Now I might have found the answer. The text in section 8.8.5 and the schema differ, and that usually means that the text is correct. The schema allows a element as a target, but the text in 8.8.5 does not. Does this mean that you can't lock a url? (however, the text in 8.8.1 is a bit more generic than 8.8.5) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 08:29:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MiU-0004eW-Da for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 08:29:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08926 for ; Wed, 15 Feb 2006 08:27:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Md1-000DJE-8m for netconf-data@psg.com; Wed, 15 Feb 2006 13:23:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Md0-000DJ2-KR for netconf@ops.ietf.org; Wed, 15 Feb 2006 13:23:30 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1FDNQX01297; Wed, 15 Feb 2006 05:23:28 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1FDNK594129; Wed, 15 Feb 2006 05:23:20 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k1FDSXYE071140; Wed, 15 Feb 2006 08:28:36 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200602151328.k1FDSXYE071140@idle.juniper.net> To: Vincent Cridlig cc: netconf@ops.ietf.org Subject: Re: Capabilities and MIBs In-Reply-To: Your message of "Wed, 15 Feb 2006 11:32:06 +0100." <43F30326.40608@loria.fr> Date: Wed, 15 Feb 2006 08:28:33 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Vincent Cridlig writes: >Is it acceptable ? Absolutely. You might want some sort of versioning information also, which could be done by including the rfc number in the capability string. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 08:34:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MnJ-0005yG-Ry for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 08:34:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09339 for ; Wed, 15 Feb 2006 08:32:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Mj4-000Dnq-Ba for netconf-data@psg.com; Wed, 15 Feb 2006 13:29:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Mj3-000Dnd-Pa for netconf@ops.ietf.org; Wed, 15 Feb 2006 13:29:45 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1FDTgX01376; Wed, 15 Feb 2006 05:29:42 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1FDTb594980; Wed, 15 Feb 2006 05:29:37 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k1FDYrYE071269; Wed, 15 Feb 2006 08:34:53 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200602151334.k1FDYrYE071269@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: url clarification In-Reply-To: Your message of "Wed, 15 Feb 2006 13:34:26 +0100." <20060215.133426.78721175.mbj@tail-f.com> Date: Wed, 15 Feb 2006 08:34:53 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Martin Bjorklund writes: >I once asked what it means to lock a remote url. Now I might have >found the answer. The text in section 8.8.5 and the schema differ, and >that usually means that the text is correct. The schema allows a > element as a target, but the text in 8.8.5 does not. >Does this mean that you can't lock a url? The original idea was that the world was divided into two halves, databases and files. Files could be overwritten and fetched, but did not have/require the additional overhead of being searchable, replacable, lockable, etc. So you could copy-config a file, but not edit-config or lock-config it. The text and schema should be corrected to make this clear. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 08:37:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Mqk-0006dZ-C0 for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 08:37:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09608 for ; Wed, 15 Feb 2006 08:35:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Mmv-000E9C-RQ for netconf-data@psg.com; Wed, 15 Feb 2006 13:33:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Mmv-000E8y-6D for netconf@ops.ietf.org; Wed, 15 Feb 2006 13:33:45 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 434D011; Wed, 15 Feb 2006 14:33:44 +0100 (CET) Date: Wed, 15 Feb 2006 14:33:37 +0100 (CET) Message-Id: <20060215.143337.75441396.mbj@tail-f.com> To: phil@juniper.net Cc: netconf@ops.ietf.org Subject: Re: url clarification From: Martin Bjorklund In-Reply-To: <200602151334.k1FDYrYE071269@idle.juniper.net> References: <20060215.133426.78721175.mbj@tail-f.com> <200602151334.k1FDYrYE071269@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: > Martin Bjorklund writes: > >I once asked what it means to lock a remote url. Now I might have > >found the answer. The text in section 8.8.5 and the schema differ, and > >that usually means that the text is correct. The schema allows a > > element as a target, but the text in 8.8.5 does not. > >Does this mean that you can't lock a url? > > The original idea was that the world was divided into two halves, > databases and files. Files could be overwritten and fetched, but > did not have/require the additional overhead of being searchable, > replacable, lockable, etc. This makes sense. > So you could copy-config a file, but > not edit-config or lock-config it. Aha, not even edit-config? That's explicitly allowed by 8.8.5.1. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 09:14:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9NQh-00045B-7A for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 09:14:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12588 for ; Wed, 15 Feb 2006 09:13:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9NJv-000GWr-Kw for netconf-data@psg.com; Wed, 15 Feb 2006 14:07:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9NJv-000GWg-3J for netconf@ops.ietf.org; Wed, 15 Feb 2006 14:07:51 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k1FE7o1Z017079; Wed, 15 Feb 2006 06:07:50 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1FE7n501636; Wed, 15 Feb 2006 06:07:50 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k1FED5YE071428; Wed, 15 Feb 2006 09:13:05 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200602151413.k1FED5YE071428@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: url clarification In-Reply-To: Your message of "Wed, 15 Feb 2006 14:33:37 +0100." <20060215.143337.75441396.mbj@tail-f.com> Date: Wed, 15 Feb 2006 09:13:05 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Martin Bjorklund writes: >> So you could copy-config a file, but >> not edit-config or lock-config it. >Aha, not even edit-config? That's explicitly allowed by 8.8.5.1. Hmmm.... that's a bug in the draft IMHO. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 12:43:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Qgi-0007Nf-4b for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 12:43:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15701 for ; Wed, 15 Feb 2006 12:41:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9QZz-0004Iw-3s for netconf-data@psg.com; Wed, 15 Feb 2006 17:36:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9QZy-0004Ii-Ch for netconf@ops.ietf.org; Wed, 15 Feb 2006 17:36:38 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k1FHaPNV002649; Wed, 15 Feb 2006 09:36:25 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BX6QKD>; Wed, 15 Feb 2006 09:36:25 -0800 Message-ID: From: "McDonald, Ira" To: "'Phil Shafer'" , Vincent Cridlig Cc: netconf@ops.ietf.org Subject: RE: Capabilities and MIBs Date: Wed, 15 Feb 2006 09:36:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, And besides versioning (RFC number is an excellent solution), your base tag for a MIB should certainly be the case-sensitive value on the BEGIN statement in the first line of the MIB (NOT the tag on the MODULE-IDENTITY, which only works for SMIv2 MIBs and is not the target of an IMPORTS clause). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Phil Shafer > Sent: Wednesday, February 15, 2006 8:29 AM > To: Vincent Cridlig > Cc: netconf@ops.ietf.org > Subject: Re: Capabilities and MIBs > > > Vincent Cridlig writes: > >Is it acceptable ? > > Absolutely. You might want some sort of versioning information > also, which could be done by including the rfc number in the > capability string. > > Thanks, > Phil > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 15:53:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Te9-0002Rm-Ko for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 15:53:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00600 for ; Wed, 15 Feb 2006 15:51:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9TXT-0004xR-6Q for netconf-data@psg.com; Wed, 15 Feb 2006 20:46:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [207.69.195.64] (helo=pop-knobcone.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9TXS-0004xF-Ap for netconf@ops.ietf.org; Wed, 15 Feb 2006 20:46:14 +0000 Received: from h-68-165-2-223.snvacaid.dynamic.covad.net ([68.165.2.223] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1F9TXR-0002UJ-00 for netconf@ops.ietf.org; Wed, 15 Feb 2006 15:46:13 -0500 Message-ID: <000101c63271$0a7a0560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200602151328.k1FDSXYE071140@idle.juniper.net> Subject: Re: Capabilities and MIBs Date: Wed, 15 Feb 2006 12:44:49 -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 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > From: "Phil Shafer" > To: "Vincent Cridlig" > Cc: > Sent: Wednesday, February 15, 2006 5:28 AM > Subject: Re: Capabilities and MIBs > > Vincent Cridlig writes: > >Is it acceptable ? > > Absolutely. You might want some sort of versioning information > also, which could be done by including the rfc number in the > capability string. ... Do you see a need for anything analogous to a reference to an AGENT-CAPABILITIES or MODULE-COMPLIANCE, whether coming from an RFC or from some other source? Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 16:07:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9TsB-0007oq-DS for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 16:07:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04237 for ; Wed, 15 Feb 2006 16:05:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9ToD-00065u-6e for netconf-data@psg.com; Wed, 15 Feb 2006 21:03:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9ToC-00065j-6T for netconf@ops.ietf.org; Wed, 15 Feb 2006 21:03:32 +0000 Received: (qmail 13815 invoked from network); 15 Feb 2006 21:03:31 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 15 Feb 2006 21:03:31 -0000 Message-ID: <43F39725.1000001@andybierman.com> Date: Wed, 15 Feb 2006 13:03:33 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: element order error processing References: <43EE1CF3.1020109@andybierman.com> <20060212.160042.26344568.mbj@tail-f.com> In-Reply-To: <20060212.160042.26344568.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: > Andy Bierman wrote: > >> >.... >> What about this?: >> >> >> >> >> >> >> >> A reasonable implementation choice would lead one to generate >> a 'missing-element' error for "/foo/b" when "/foo/c" is encountered. >> But "b" isn't missing, it is in the wrong place. >> > > We're generating 'missing-element' in this case. > > >> The only other >> error choice seems to be 'unknown-element' for "/foo/b" >> > > I'd say that the other alternative would be unknown-element for > /foo/c. > I see why you are doing this now. Given this example: Advancing the 'current pointer' as I described before will cause an incorrect unknown-element error for 'b' and 'c' in this case. The most correct response in this example is one for unknown-element(blah). I still think it is easier not to enforce a strict order. Consider the error complexity when the previous example grows up a tiny bit: element { element a?, element b*; element c*, element d? } Now checking for strict order is even harder. Throw in some 'choice' clauses, and even harder. I'm not trying to change the protocol spec. This is a data model matter after all. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 16:40:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9UO0-0002Qc-5P for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 16:40:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09812 for ; Wed, 15 Feb 2006 16:38:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9UJi-0008Np-7A for netconf-data@psg.com; Wed, 15 Feb 2006 21:36:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9UJh-0008Na-Gv for netconf@ops.ietf.org; Wed, 15 Feb 2006 21:36:05 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 4FC6930; Wed, 15 Feb 2006 22:36:04 +0100 (CET) Date: Wed, 15 Feb 2006 22:35:57 +0100 (CET) Message-Id: <20060215.223557.35799705.mbj@tail-f.com> To: phil@juniper.net Cc: netconf@ops.ietf.org Subject: Re: url clarification From: Martin Bjorklund In-Reply-To: <200602151413.k1FED5YE071428@idle.juniper.net> References: <20060215.143337.75441396.mbj@tail-f.com> <200602151413.k1FED5YE071428@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: > Martin Bjorklund writes: > >> So you could copy-config a file, but > >> not edit-config or lock-config it. > >Aha, not even edit-config? That's explicitly allowed by 8.8.5.1. > > Hmmm.... that's a bug in the draft IMHO. Sorry, I got it wrong. 8.8.5.1 allows instead of in an . is not allowed as an target. An example is given in D.1.5. (the schema is wrong though). However, the example in D.1.5 should probably use instead of , since an w/o operation attributes (which is used in the example) will use the default "merge", which may give different results than . An alternative is to set default-operation to "replace" on the . /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 17:28:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9V85-0002HY-JM for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 17:28:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12623 for ; Wed, 15 Feb 2006 17:26:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9V1c-000B8L-Ux for netconf-data@psg.com; Wed, 15 Feb 2006 22:21:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9V1a-000B85-4G for netconf@ops.ietf.org; Wed, 15 Feb 2006 22:21:26 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k1FMLMZ1014493; Wed, 15 Feb 2006 14:21:22 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BX6XZ6>; Wed, 15 Feb 2006 14:21:23 -0800 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , netconf@ops.ietf.org Subject: RE: Capabilities and MIBs Date: Wed, 15 Feb 2006 14:21:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Randy, Actually, a URL to a network copy of an AGENT-CAPABILITIES and/or to an optional MODULE-COMPLIANCE statement would be a good method of being very clear. But most vendors (maybe only many) don't seem to have ever written MODULE-COMPLIANCE statements. So a lighter weight solution is just to name the MIB and the version (by URL to an RFC or a private vendor MIB). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Randy Presuhn > Sent: Wednesday, February 15, 2006 3:45 PM > To: netconf@ops.ietf.org > Subject: Re: Capabilities and MIBs > > > Hi - > > > From: "Phil Shafer" > > To: "Vincent Cridlig" > > Cc: > > Sent: Wednesday, February 15, 2006 5:28 AM > > Subject: Re: Capabilities and MIBs > > > > Vincent Cridlig writes: > > >Is it acceptable ? > > > > Absolutely. You might want some sort of versioning information > > also, which could be done by including the rfc number in the > > capability string. > ... > > Do you see a need for anything analogous to a reference to an > AGENT-CAPABILITIES or MODULE-COMPLIANCE, whether coming from > an RFC or from some other source? > > Randy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 18:21:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9VxU-0006yh-Pe for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 18:21:17 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17565 for ; Wed, 15 Feb 2006 18:19:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Vsr-000EAe-NL for netconf-data@psg.com; Wed, 15 Feb 2006 23:16:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Vsr-000EAT-5F for netconf@ops.ietf.org; Wed, 15 Feb 2006 23:16:29 +0000 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id k1FNGY1l004322; Wed, 15 Feb 2006 15:16:34 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k1FNGOOD010313; Wed, 15 Feb 2006 15:16:24 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k1FNGNZr010309; Wed, 15 Feb 2006 15:16:24 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 15 Feb 2006 15:16:23 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Vincent Cridlig cc: netconf@ops.ietf.org Subject: Re: Capabilities and MIBs In-Reply-To: <43F30326.40608@loria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk HI, I believe that you should put the MIB module name (it starts with an uppercase letter), and include for version the value from the LAST-UPDATED clause in the MODULE-IDENTITY definition for modules in SMIv2 format, and an associated date for modules in the SMIv1 format. Note that MIB module names are not globally unique, and they need to be quallified. I believe the best qualifier is the organization's "IANA Enterprise Number". Technically, a system advertises what capabilities it has with AGENT-CAPABILITIES definitions (a definition descriptor that is qualified by Enterprise number, module name, and last-update date). Also, if you want a manager to tell the system what it needs, you can you MODULE-COMPLIANCE definitions (a definition descriptor that is qualified by Enterprise number, module name, and last-update date) On Wed, 15 Feb 2006, Vincent Cridlig wrote: > Hi, > > I would like that our agent advertises its supported "MIBs". > Are capabilities the regular way to do it ? > > Like, for example, for the agent to advertise that it supports "bgp" MIB, "routes" MIB and "network interfaces" MIB. > > > > urn:ietf:params:netconf:base:1.0 > urn:ietf:params:netconf:capability:startup:1.0 > urn:madynes:module:bgp > urn:madynes:module:routes > urn:madynes:module:interfaces > > 4 > > > Is it acceptable ? > > Thanks for your help. > Vincent Cridlig Regards, /david t. perkins -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 18:56:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WVo-0006ya-7y for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 18:56:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20014 for ; Wed, 15 Feb 2006 18:54:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9WQW-000H82-Ik for netconf-data@psg.com; Wed, 15 Feb 2006 23:51:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [204.127.192.82] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9WQV-000H7q-QA for netconf@ops.ietf.org; Wed, 15 Feb 2006 23:51:15 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc12) with SMTP id <20060215235114m1200qn134e>; Wed, 15 Feb 2006 23:51:15 +0000 Reply-To: From: "David B Harrington" To: "'Vincent Cridlig'" , Subject: RE: Capabilities and MIBs Date: Wed, 15 Feb 2006 18:51:05 -0500 Message-ID: <02af01c6328a$b27bc7d0$7703bc12@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <43F30326.40608@loria.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYyHAO/hZIyP/XRRaOUg3nh2LQ13QAbk3hA Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Are you referring to SNMP (SMIv1 or v2) MIBs, or are you talking about data models designed for use with netconf? I think it is important to make the distinction between (SNMP) MIBs and netconf data models. David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Vincent Cridlig > Sent: Wednesday, February 15, 2006 5:32 AM > To: netconf@ops.ietf.org > Subject: Capabilities and MIBs > > Hi, > > I would like that our agent advertises its supported "MIBs". > Are capabilities the regular way to do it ? > > Like, for example, for the agent to advertise that it > supports "bgp" MIB, "routes" MIB and "network interfaces" MIB. > > > > urn:ietf:params:netconf:base:1.0 > > urn:ietf:params:netconf:capability:startup:1.0 pability> > urn:madynes:module:bgp > urn:madynes:module:routes > urn:madynes:module:interfaces > > 4 > > > Is it acceptable ? > > Thanks for your help. > Vincent Cridlig > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 20:43:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9YAr-0000Ph-TO for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 20:43:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03127 for ; Wed, 15 Feb 2006 20:41:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Y3r-000NXz-5k for netconf-data@psg.com; Thu, 16 Feb 2006 01:35:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9Y3p-000NXn-JP for netconf@ops.ietf.org; Thu, 16 Feb 2006 01:35:57 +0000 Received: (qmail 1246 invoked from network); 16 Feb 2006 01:28:51 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr5.mgt.bos.netsol.com with SMTP; 16 Feb 2006 01:28:51 -0000 Message-ID: <43F3D556.4070009@andybierman.com> Date: Wed, 15 Feb 2006 17:28:54 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: dbharrington@comcast.net CC: "'Vincent Cridlig'" , netconf@ops.ietf.org Subject: Re: Capabilities and MIBs References: <02af01c6328a$b27bc7d0$7703bc12@DJYXPY41> In-Reply-To: <02af01c6328a$b27bc7d0$7703bc12@DJYXPY41> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David B Harrington wrote: > Hi, > > Are you referring to SNMP (SMIv1 or v2) MIBs, or are you talking about > data models designed for use with netconf? > > I think it is important to make the distinction between (SNMP) MIBs > and netconf data models. > Yes please. Some of us want to experiment with data modeling ideas without being constrained by SNMP or SMI. The original question was about advertising the data models that a NETCONF agent supports. If you want to call them NETCONF MIBs, I don't care. But they are not SNMP MIBs. It was always the intent that the agent would advertise the namespace URI of each data model it supports. However, if you don't use a different namespace for each data model, then this won't work. You have to list modules by name and version, as suggested. IMO, you need to also advertise the namespace used for each module. In order for XML to work correctly, and distinguish (in a NETCONF PDU) between the element in the FOO-MODULE and the one defined in the BAR-MODULE, some mechanism like namespaces is needed. This is a standard, and we have to prevent cross-organization naming collisions under the element. > David Harrington > dbharrington@comcast.net > Andy > > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Vincent Cridlig >> Sent: Wednesday, February 15, 2006 5:32 AM >> To: netconf@ops.ietf.org >> Subject: Capabilities and MIBs >> >> Hi, >> >> I would like that our agent advertises its supported "MIBs". >> Are capabilities the regular way to do it ? >> >> Like, for example, for the agent to advertise that it >> supports "bgp" MIB, "routes" MIB and "network interfaces" MIB. >> >> >> >> urn:ietf:params:netconf:base:1.0 >> >> urn:ietf:params:netconf:capability:startup:1.0> pability> >> urn:madynes:module:bgp >> urn:madynes:module:routes >> urn:madynes:module:interfaces >> >> 4 >> >> >> Is it acceptable ? >> >> Thanks for your help. >> Vincent Cridlig >> >> >> >> > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 15 22:28:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Zoc-0001z7-Py for netconf-archive@megatron.ietf.org; Wed, 15 Feb 2006 22:28:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10893 for ; Wed, 15 Feb 2006 22:26:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9ZhB-0003rf-7O for netconf-data@psg.com; Thu, 16 Feb 2006 03:20:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.129] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9ZhA-0003pY-8A for netconf@ops.ietf.org; Thu, 16 Feb 2006 03:20:40 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe05.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 19277318; Mon, 13 Feb 2006 13:19:23 +0100 Date: Mon, 13 Feb 2006 13:19:16 +0100 (CET) Message-Id: <20060213.131916.127095981.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: netconf implementation guide From: Martin Bjorklund In-Reply-To: <43ED34E2.6070301@andybierman.com> References: <43ED34E2.6070301@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy Bierman wrote: > Hi, > > I think eventually we will keep collecting clarifications, > maybe even enough for a NETCONF Implementation Guide RFC. > > Are there any WG members willing to work on a > NETCONF Implementation Guide (Informational) RFC? > Is there community interest in having such a document? > > If so, the first step is collecting implementation experience, > FAQ material, document clarifications and errata, etc. I think this is a great idea, and I'm willing to help with this work. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 00:24:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bKj-0000MM-OD for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 00:06:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14723 for ; Thu, 16 Feb 2006 00:03:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9bFH-0009MA-5b for netconf-data@psg.com; Thu, 16 Feb 2006 04:59:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [216.148.227.152] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9bFG-0009Lx-J3 for netconf@ops.ietf.org; Thu, 16 Feb 2006 04:59:58 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc12) with SMTP id <20060216045957m1200qmpsne>; Thu, 16 Feb 2006 04:59:57 +0000 Reply-To: From: "David B Harrington" To: "'Andy Bierman'" Cc: "'Vincent Cridlig'" , Subject: RE: Capabilities and MIBs Date: Wed, 15 Feb 2006 23:59:53 -0500 Message-ID: <001001c632b5$d3c28d90$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43F3D556.4070009@andybierman.com> Thread-Index: AcYymlzOqgyNbyn8T+WsSsR6id1G8QAGp5GQ Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I was asking the original poster for clarification about what they wanted to advertise. It is possible they wanted to advertise SNMP MIBs that they wanted to make available through netconf. It is possible they wanted to advertise netconf-specific data models that are not SNMP MIBs. I think how to advertise either is similar, and Phil's answer addressed that. A lot of the discussion that followed the original question, however, is about SNMP MIBs, not netconf-specific data models. Such responses may not be appropriate to the original question asked. David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, February 15, 2006 8:29 PM > To: dbharrington@comcast.net > Cc: 'Vincent Cridlig'; netconf@ops.ietf.org > Subject: Re: Capabilities and MIBs > > David B Harrington wrote: > > Hi, > > > > Are you referring to SNMP (SMIv1 or v2) MIBs, or are you > talking about > > data models designed for use with netconf? > > > > I think it is important to make the distinction between (SNMP) MIBs > > and netconf data models. > > > > Yes please. > Some of us want to experiment with data modeling ideas > without being constrained by SNMP or SMI. > > The original question was about advertising the data models that > a NETCONF agent supports. If you want to call them NETCONF MIBs, > I don't care. But they are not SNMP MIBs. > > It was always the intent that the agent would advertise the > namespace URI > of each data model it supports. However, if you don't use a different > namespace for each data model, then this won't work. You have to > list modules by name and version, as suggested. IMO, you need to > also advertise the namespace used for each module. > > In order for XML to work correctly, and distinguish > (in a NETCONF PDU) between the element in the FOO-MODULE > and the one defined in the BAR-MODULE, some mechanism like namespaces > is needed. This is a standard, and we have to prevent > cross-organization naming > collisions under the element. > > > David Harrington > > dbharrington@comcast.net > > > > Andy > > > > > > > > >> -----Original Message----- > >> From: owner-netconf@ops.ietf.org > >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Vincent Cridlig > >> Sent: Wednesday, February 15, 2006 5:32 AM > >> To: netconf@ops.ietf.org > >> Subject: Capabilities and MIBs > >> > >> Hi, > >> > >> I would like that our agent advertises its supported "MIBs". > >> Are capabilities the regular way to do it ? > >> > >> Like, for example, for the agent to advertise that it > >> supports "bgp" MIB, "routes" MIB and "network interfaces" MIB. > >> > >> > >> > >> urn:ietf:params:netconf:base:1.0 > >> > >> urn:ietf:params:netconf:capability:startup:1.0 >> pability> > >> urn:madynes:module:bgp > >> urn:madynes:module:routes > >> urn:madynes:module:interfaces > >> > >> 4 > >> > >> > >> Is it acceptable ? > >> > >> Thanks for your help. > >> Vincent Cridlig > >> > >> > >> > >> > > > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 00:51:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9c27-0004I0-6Z for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 00:50:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14382 for ; Wed, 15 Feb 2006 23:58:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9b8l-0008xF-Ai for netconf-data@psg.com; Thu, 16 Feb 2006 04:53:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,MSGID_FROM_MTA_HEADER autolearn=no version=3.1.0 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9b8k-0008wz-6m for netconf@ops.ietf.org; Thu, 16 Feb 2006 04:53:14 +0000 Received: (eyou send program); Thu, 16 Feb 2006 12:31:09 +0800 Message-ID: <340111069.16144@njupt.edu.cn> Received: from 10.10.136.120 by em.njupt.edu.cn with HTTP; Thu, 16 Feb 2006 12:31:09 +0800 X-WebMAIL-MUA: [10.10.136.120] From: "=?gb2312?B?zfW6sQ==?=" To: netconf@ops.ietf.org Date: Thu, 16 Feb 2006 12:31:09 +0800 Reply-To: "=?gb2312?B?zfW6sQ==?=" X-Priority: 3 Subject: RE: netconf implementation guide Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk I agree > > Behalf Of Andy Bierman > > Sent: Friday, February 10, 2006 4:51 PM > > To: Netconf (E-mail) > > Subject: netconf implementation guide > > > > > > Hi, > > > > I think eventually we will keep collecting clarifications, > > maybe even enough for a NETCONF Implementation Guide RFC. > > > > Are there any WG members willing to work on a > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 03:37:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9edw-0004X8-Vr for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 03:37:41 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28930 for ; Thu, 16 Feb 2006 03:35:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9eVr-000M4V-P0 for netconf-data@psg.com; Thu, 16 Feb 2006 08:29:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9eVq-000M4D-D5 for netconf@ops.ietf.org; Thu, 16 Feb 2006 08:29:18 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F05176258A; Thu, 16 Feb 2006 09:29:14 +0100 (CET) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id E83E66258A; Thu, 16 Feb 2006 09:29:11 +0100 (CET) Message-ID: <43F43865.7090103@loria.fr> Date: Thu, 16 Feb 2006 09:31:33 +0100 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dbharrington@comcast.net, netconf@ops.ietf.org Subject: Re: Capabilities and MIBs References: <02af01c6328a$b27bc7d0$7703bc12@DJYXPY41> In-Reply-To: <02af01c6328a$b27bc7d0$7703bc12@DJYXPY41> Content-Type: multipart/mixed; boundary="------------040004070804090601030603" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------040004070804090601030603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David B Harrington wrote: >Hi, > >Are you referring to SNMP (SMIv1 or v2) MIBs, or are you talking about >data models designed for use with netconf? > > I was talking about data models designed for use with netconf. I realize now that my question was ambiguous. I meant "MIB" in the general meaning of a Management Information Base (not SNMP MIB). Sorry about that. Vincent --------------040004070804090601030603 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Disposition: attachment; filename="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------040004070804090601030603-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 03:43:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ejO-0006GE-BP for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 03:43:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29307 for ; Thu, 16 Feb 2006 03:41:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9eeU-000MeM-BF for netconf-data@psg.com; Thu, 16 Feb 2006 08:38:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9eeT-000Me6-Jc for netconf@ops.ietf.org; Thu, 16 Feb 2006 08:38:13 +0000 Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1G8Xf3V020570 for ; Thu, 16 Feb 2006 03:33:42 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k1G8Z4hj000596 for ; Thu, 16 Feb 2006 03:35:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Capabilities and MIBs Date: Thu, 16 Feb 2006 10:38:07 +0200 Message-ID: Thread-Topic: Capabilities and MIBs Thread-Index: AcYy02eYlRJJvZ2LQcSVeWi0TvgWWwAAF1Ag From: "Romascanu, Dan \(Dan\)" To: "Vincent Cridlig" , , X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable That's an important clarification, because the discussion since yesterday very much related to SNMP MIBs.=20 If we are talking about supported versions (capabilities) of the netconf data model in agents, my assumption was that a list of namespace URIs would be enough, and those would include information about versions.=20 Regards, Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Vincent Cridlig > Sent: Thursday, February 16, 2006 10:32 AM > To: dbharrington@comcast.net; netconf@ops.ietf.org > Subject: Re: Capabilities and MIBs >=20 > David B Harrington wrote: >=20 > >Hi, > > > >Are you referring to SNMP (SMIv1 or v2) MIBs, or are you=20 > talking about=20 > >data models designed for use with netconf? > > =20 > > > I was talking about data models designed for use with netconf. > I realize now that my question was ambiguous. I meant "MIB"=20 > in the general meaning of a Management Information Base (not=20 > SNMP MIB). Sorry about that. >=20 > Vincent >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 15:08:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9pQ9-00089p-Hk for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 15:08:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29464 for ; Thu, 16 Feb 2006 15:06:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9pGA-000Hu4-N6 for netconf-data@psg.com; Thu, 16 Feb 2006 19:57:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [207.69.195.62] (helo=pop-altamira.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9pG9-000Hss-RN for netconf@ops.ietf.org; Thu, 16 Feb 2006 19:57:50 +0000 Received: from h-64-105-34-25.snvacaid.dynamic.covad.net ([64.105.34.25] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1F9pG4-00053v-00 for netconf@ops.ietf.org; Thu, 16 Feb 2006 14:57:44 -0500 Message-ID: <005101c63333$77206c00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: Capabilities and MIBs Date: Thu, 16 Feb 2006 11:59:14 -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 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > From: "Romascanu, Dan (Dan)" > To: "Vincent Cridlig" ; ; > Sent: Thursday, February 16, 2006 12:38 AM > Subject: RE: Capabilities and MIBs > > That's an important clarification, because the discussion since > yesterday very much related to SNMP MIBs. > > If we are talking about supported versions (capabilities) of the netconf > data model in agents, my assumption was that a list of namespace URIs > would be enough, and those would include information about versions. ... This brings us full circle to my question. To re-phrase: will there be anything analogous to AGENT-CAPABILITIES for netconf data models? Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 15:29:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9plF-0007QZ-4B for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 15:29:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01544 for ; Thu, 16 Feb 2006 15:28:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9phN-000K4q-Mb for netconf-data@psg.com; Thu, 16 Feb 2006 20:25:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [204.127.192.81] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9phL-000K4N-4N for netconf@ops.ietf.org; Thu, 16 Feb 2006 20:25:55 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc11) with SMTP id <20060216202553m1100po4sbe>; Thu, 16 Feb 2006 20:25:54 +0000 Reply-To: From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: Capabilities and MIBs Date: Thu, 16 Feb 2006 15:25:49 -0500 Message-ID: <007001c63337$2db82ae0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <005101c63333$77206c00$7f1afea9@oemcomputer> Thread-Index: AcYzNLe0pblfgUWdTSOtnDKtAE77KgAAmHgQ Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Will there be any netconf data models? ;-) David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Randy Presuhn > Sent: Thursday, February 16, 2006 2:59 PM > To: netconf@ops.ietf.org > Subject: Re: Capabilities and MIBs > > Hi - > > > From: "Romascanu, Dan (Dan)" > > To: "Vincent Cridlig" ; > ; > > Sent: Thursday, February 16, 2006 12:38 AM > > Subject: RE: Capabilities and MIBs > > > > > That's an important clarification, because the discussion since > > yesterday very much related to SNMP MIBs. > > > > If we are talking about supported versions (capabilities) > of the netconf > > data model in agents, my assumption was that a list of > namespace URIs > > would be enough, and those would include information about > versions. > ... > > This brings us full circle to my question. To re-phrase: > will there be anything analogous to AGENT-CAPABILITIES for > netconf data models? > > Randy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 15:32:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9pnv-0001X9-S4 for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 15:32:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01871 for ; Thu, 16 Feb 2006 15:30:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9pk2-000KGs-Kc for netconf-data@psg.com; Thu, 16 Feb 2006 20:28:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9pk1-000KGa-Ur for netconf@ops.ietf.org; Thu, 16 Feb 2006 20:28:42 +0000 Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100]) by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1GJP5cY024196 for ; Thu, 16 Feb 2006 14:25:06 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k1GKD6Yj019745 for ; Thu, 16 Feb 2006 15:13:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Capabilities and MIBs Date: Thu, 16 Feb 2006 22:28:39 +0200 Message-ID: Thread-Topic: Capabilities and MIBs Thread-Index: AcYzNLe0pblfgUWdTSOtnDKtAE77KgAAmHgQAAAYyFA= From: "Romascanu, Dan \(Dan\)" To: , "Randy Presuhn" , X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Some people believe that there will be :-) =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington > Sent: Thursday, February 16, 2006 10:26 PM > To: 'Randy Presuhn'; netconf@ops.ietf.org > Subject: RE: Capabilities and MIBs >=20 > Will there be any netconf data models? ;-) >=20 > David Harrington > dbharrington@comcast.net >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 15:35:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9pqe-0005gu-Gj for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 15:35:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02079 for ; Thu, 16 Feb 2006 15:33:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9pnY-000Kdt-KN for netconf-data@psg.com; Thu, 16 Feb 2006 20:32:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9pnX-000KdW-Kh for netconf@ops.ietf.org; Thu, 16 Feb 2006 20:32:19 +0000 Received: (qmail 546 invoked from network); 16 Feb 2006 20:32:18 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 16 Feb 2006 20:32:18 -0000 Message-ID: <43F4E137.9020703@andybierman.com> Date: Thu, 16 Feb 2006 12:31:51 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Randy Presuhn CC: netconf@ops.ietf.org Subject: Re: Capabilities and MIBs References: <005101c63333$77206c00$7f1afea9@oemcomputer> In-Reply-To: <005101c63333$77206c00$7f1afea9@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Hi - > > >> From: "Romascanu, Dan (Dan)" >> To: "Vincent Cridlig" ; ; >> Sent: Thursday, February 16, 2006 12:38 AM >> Subject: RE: Capabilities and MIBs >> >> > > >> That's an important clarification, because the discussion since >> yesterday very much related to SNMP MIBs. >> >> If we are talking about supported versions (capabilities) of the netconf >> data model in agents, my assumption was that a list of namespace URIs >> would be enough, and those would include information about versions. >> > ... > > This brings us full circle to my question. To re-phrase: > will there be anything analogous to AGENT-CAPABILITIES for > netconf data models? > Good question. One of many completely unknown aspects of netconf data modeling. - what does a netconf data model look like, independent of the NETCONF protocol? (different subsets are allowed for different operations and different capabilities. How does XSD deal with this again? ;-) - what does netconf modularity look like? - how do modules easily use definitions from other modules? - what do nested tables and "row" instance naming look like? - what does netconf data model conformance look like? - what does netconf data model conformance variation look like? (your question) - what is the access control model that provides for RPC method invocation control in addition to data access control? - what is the model for partial database locking? However all this is out of scope for the time being. That doesn't mean that individuals and vendors can't work on the answers now. It would be good to have reasonable answers before any standards effort begins. > Randy > Andy > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 16:13:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qRN-0002P8-G2 for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 16:13:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10119 for ; Thu, 16 Feb 2006 16:11:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9qMl-000NX4-7U for netconf-data@psg.com; Thu, 16 Feb 2006 21:08:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9qMk-000NUb-Bx for netconf@ops.ietf.org; Thu, 16 Feb 2006 21:08:42 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k1GL85kW008123; Thu, 16 Feb 2006 13:08:05 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BX75Y8>; Thu, 16 Feb 2006 13:08:05 -0800 Message-ID: From: "McDonald, Ira" To: "'Andy Bierman'" , Randy Presuhn Cc: netconf@ops.ietf.org Subject: RE: Capabilities and MIBs Date: Thu, 16 Feb 2006 13:08:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Andy, Excellent set of questions, showing the depth of the problem space! If NetConf ever succeeds in standardizing a data model, then Relax NG and Schematron are going to become very important tools, because XSD is terminally deficient to answer many of your questions. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Thursday, February 16, 2006 3:32 PM > To: Randy Presuhn > Cc: netconf@ops.ietf.org > Subject: Re: Capabilities and MIBs > > > Randy Presuhn wrote: > > Hi - > > > > > >> From: "Romascanu, Dan (Dan)" > >> To: "Vincent Cridlig" ; > ; > >> Sent: Thursday, February 16, 2006 12:38 AM > >> Subject: RE: Capabilities and MIBs > >> > >> > > > > > >> That's an important clarification, because the discussion since > >> yesterday very much related to SNMP MIBs. > >> > >> If we are talking about supported versions (capabilities) > of the netconf > >> data model in agents, my assumption was that a list of > namespace URIs > >> would be enough, and those would include information about > versions. > >> > > ... > > > > This brings us full circle to my question. To re-phrase: > > will there be anything analogous to AGENT-CAPABILITIES for > > netconf data models? > > > > Good question. > One of many completely unknown aspects of netconf data modeling. > - what does a netconf data model look like, independent of > the NETCONF > protocol? > (different subsets are allowed for different operations > and different > capabilities. > How does XSD deal with this again? ;-) > - what does netconf modularity look like? > - how do modules easily use definitions from other modules? > - what do nested tables and "row" instance naming look like? > - what does netconf data model conformance look like? > - what does netconf data model conformance variation look > like? (your > question) > - what is the access control model that provides for RPC > method invocation > control in addition to data access control? > - what is the model for partial database locking? > > However all this is out of scope for the time being. > That doesn't mean that individuals and vendors can't work on > the answers > now. > It would be good to have reasonable answers before any > standards effort > begins. > > > Randy > > > > Andy > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Feb 16 17:24:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9rY9-0003Mi-IH for netconf-archive@megatron.ietf.org; Thu, 16 Feb 2006 17:24:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17180 for ; Thu, 16 Feb 2006 17:22:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9rTE-0002NH-16 for netconf-data@psg.com; Thu, 16 Feb 2006 22:19:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9rTD-0002N2-2t for netconf@ops.ietf.org; Thu, 16 Feb 2006 22:19:27 +0000 Received: (qmail 16746 invoked from network); 16 Feb 2006 21:41:16 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 16 Feb 2006 21:41:16 -0000 Message-ID: <43F4F156.5000908@andybierman.com> Date: Thu, 16 Feb 2006 13:40:38 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "McDonald, Ira" CC: Randy Presuhn , netconf@ops.ietf.org Subject: Re: Capabilities and MIBs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit McDonald, Ira wrote: > Hi Andy, > > Excellent set of questions, showing the depth of the problem > space! > > If NetConf ever succeeds in standardizing a data model, then > Relax NG and Schematron are going to become very important > tools, because XSD is terminally deficient to answer many of > your questions. > I will have to look into Schematron. I agree with you about XSD. IMO, RelaxNG is overkill in some areas, perfect in other areas, and totally deficient in still other areas. (Not the right mailing list to go into details...) > Cheers, > - Ira > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Feb 18 13:32:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAWsM-00082P-A2 for netconf-archive@lists.ietf.org; Sat, 18 Feb 2006 13:32:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAWsJ-00059S-UR for netconf-archive@lists.ietf.org; Sat, 18 Feb 2006 13:32:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAWj3-000EKX-6A for netconf-data@psg.com; Sat, 18 Feb 2006 18:22:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAWj1-000EKJ-WC for netconf@ops.ietf.org; Sat, 18 Feb 2006 18:22:32 +0000 Received: (qmail 10904 invoked from network); 18 Feb 2006 18:22:31 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 18 Feb 2006 18:22:31 -0000 Message-ID: <43F765E6.9050500@andybierman.com> Date: Sat, 18 Feb 2006 10:22:30 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, netconf@ops.ietf.org Subject: Re: url clarification References: <20060215.143337.75441396.mbj@tail-f.com> <200602151413.k1FED5YE071428@idle.juniper.net> <20060215.223557.35799705.mbj@tail-f.com> In-Reply-To: <20060215.223557.35799705.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Martin Bjorklund wrote: > Phil Shafer wrote: > >> Martin Bjorklund writes: >> >>>> So you could copy-config a file, but >>>> not edit-config or lock-config it. >>>> >>> Aha, not even edit-config? That's explicitly allowed by 8.8.5.1. >>> >> Hmmm.... that's a bug in the draft IMHO. >> > > Sorry, I got it wrong. 8.8.5.1 allows instead of in an > . is not allowed as an target. An > example is given in D.1.5. (the schema is wrong though). > > However, the example in D.1.5 should probably use > instead of , since an w/o operation > attributes (which is used in the example) will use the default > "merge", which may give different results than . An > alternative is to set default-operation to "replace" on the > . > Did we ever resolve all the issues here? (A: no) Here are the operations that use rpcOperationTargetType: operation text-allows-url notes ------------------------------------------------ edit-config N 1 copy-config Y 2 delete-config Y 3 lock N 4 unlock N 4 Notes: 1) The WG never explicitly allowed or disallowed local or remote files as the target of an edit-config. The intent was as Phil described. The rationale is that edit-config involves partial editing, which is an attribute of configuration databases, not files. 2) An implementation does not have to support remote to remote copies via URLs. 3) This is mandatory to support if :url capability is advertised; otherwise there is no way to delete local files, after they have been copied to the device via copy-config. 4) It was never the intent of the WG that remote URLs could be locked and unlocked But this is not explicitly allowed or disallowed. Summary Issues: A) Which is right: The text or the XSD? Should the edit-config, lock, and unlock XSD definitions change from rpcOperationTargetType to configNameType? This will explicitly disallow URL as in these operations. B) If an agent advertises the :url capability, what operations MUST, SHOULD, or MAY it apply to? What if an agent only supports URLs as the parameter and not the parameter on some or all operations? > > /martin > > Andy > - -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Feb 18 15:00:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAYFa-0001Ih-Hl for netconf-archive@lists.ietf.org; Sat, 18 Feb 2006 15:00:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAYFV-0006Y1-WB for netconf-archive@lists.ietf.org; Sat, 18 Feb 2006 15:00:14 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAY7S-000JTv-7G for netconf-data@psg.com; Sat, 18 Feb 2006 19:51:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAY7R-000JTj-Fg for netconf@ops.ietf.org; Sat, 18 Feb 2006 19:51:49 +0000 Received: (qmail 14541 invoked from network); 18 Feb 2006 19:51:48 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 18 Feb 2006 19:51:48 -0000 Message-ID: <43F77AD3.4040803@andybierman.com> Date: Sat, 18 Feb 2006 11:51:47 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vincent Cridlig CC: netconf@ops.ietf.org Subject: Re: Capabilities and MIBs References: <43F30326.40608@loria.fr> In-Reply-To: <43F30326.40608@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi, I want to follow-up on the namespace vs. module identity issue. I like the idea of identifying the module, independent of its namespace, in case namespaces aren't used. (!) However, in order for an implementation to differentiate data models from multiple organizations within the same element -- well, namespaces have already been invented for that. (I can use an "owner" attribute instead of NS, but that's not standard.) So knowing the module ID is not good enough. You need to know the namespace to use with it. I propose the following conventions (for comment, write-up TBD): 1) Agents SHOULD the advertise data model modules they support Managers MAY advertise modules (but why?) 2) The format for a data model module capability URN SHOULD be: urn::params:netconf:module:[:] e.g. urn:madynes:params:netconf:module:bgp:1.0 3) The namespace URN to use for a particular module SHOULD be: urn::params:netconf:ns:[:] e.g. urn:madynes:params:netconf:ns:bgp:1.0 The extra "params:netconf" in the string makes IETF and vendor strings consistent. Not sure how much this matters. If a hard-wired URN for namespace is not acceptable, then some extension to the element is needed to associate a namespace with a module. 4) SNMP MIB conversions are not standardized, but a convention for a module name could be: urn::params:netconf:module:[:] e.g., urn:ietf:params:netconf:module:RMON2-MIB:9605270000Z This allows MIB modules that are not in RFCs to specify a version. Not sure this helps at all without a SMIv2 to XML translation standard. Comments? Waste of time on CLRs? Experimental? BCP? Informational? Normative? Andy > Hi, > > I would like that our agent advertises its supported "MIBs". > Are capabilities the regular way to do it ? > > Like, for example, for the agent to advertise that it supports "bgp" > MIB, "routes" MIB and "network interfaces" MIB. > > > > urn:ietf:params:netconf:base:1.0 > > urn:ietf:params:netconf:capability:startup:1.0 > urn:madynes:module:bgp > urn:madynes:module:routes > urn:madynes:module:interfaces > > 4 > > > Is it acceptable ? > > Thanks for your help. > Vincent Cridlig > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Feb 19 02:13:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAikw-0005S4-FN for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 02:13:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAiku-0000xJ-W9 for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 02:13:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAid6-0000X6-CJ for netconf-data@psg.com; Sun, 19 Feb 2006 07:05:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAid5-0000Ws-1u for netconf@ops.ietf.org; Sun, 19 Feb 2006 07:05:11 +0000 Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1J70SxF032515 for ; Sun, 19 Feb 2006 02:00:29 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k1J723hj024168 for ; Sun, 19 Feb 2006 02:02:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Capabilities and MIBs Date: Sun, 19 Feb 2006 09:05:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Capabilities and MIBs Thread-Index: AcY0xRroV8nRn9gLTEmbVcOxA0enEwAXJRhw From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Vincent Cridlig" Cc: X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c I believe it's a good thing. Would not it be useful to include a last-updated-time parameter in the format for a data model module capability URN? Like=20 =20 urn::params:netconf:module:[:][:] I would like to avoid future CLRs about how we sub-version work-in-progress data-models.=20 Experimental by now, Normative if it catches and especially if we decide to standardize data models some time.=20 Regards, Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Saturday, February 18, 2006 9:52 PM > To: Vincent Cridlig > Cc: netconf@ops.ietf.org > Subject: Re: Capabilities and MIBs >=20 > Hi, >=20 >=20 > I want to follow-up on the namespace vs. module identity issue. >=20 > I like the idea of identifying the module, independent of its=20 > namespace, in case namespaces aren't used. (!) >=20 > However, in order for an implementation to differentiate data=20 > models from multiple organizations within the same =20 > element -- well, namespaces have already been invented for that. > (I can use an "owner" attribute instead of NS, but that's not=20 > standard.) >=20 > So knowing the module ID is not good enough. > You need to know the namespace to use with it. >=20 > I propose the following conventions (for comment, write-up TBD): >=20 > 1) Agents SHOULD the advertise data model modules they support > Managers MAY advertise modules (but why?) >=20 > 2) The format for a data model module capability URN SHOULD be: >=20 > =20 > urn::params:netconf:module:[:] > =20 > e.g. urn:madynes:params:netconf:module:bgp:1.0 >=20 > 3) The namespace URN to use for a particular module SHOULD be: >=20 > urn::params:netconf:ns:[:] > =20 > e.g. urn:madynes:params:netconf:ns:bgp:1.0 > =20 > The extra "params:netconf" in the string makes IETF and=20 > vendor strings > consistent. Not sure how much this matters. >=20 > If a hard-wired URN for namespace is not acceptable, then some > extension to the element is needed to associate > a namespace with a module. >=20 > 4) SNMP MIB conversions are not standardized, but a convention for > a module name could be: >=20 > =20 > urn::params:netconf:module:[: ed-time>] >=20 > e.g., urn:ietf:params:netconf:module:RMON2-MIB:9605270000Z >=20 > This allows MIB modules that are not in RFCs to specify a version. > Not sure this helps at all without a SMIv2 to XML=20 > translation standard. >=20 >=20 > Comments?=20 > Waste of time on CLRs? > Experimental? BCP? Informational? Normative? >=20 >=20 > Andy >=20 > > Hi, > > > > I would like that our agent advertises its supported "MIBs". > > Are capabilities the regular way to do it ? > > > > Like, for example, for the agent to advertise that it=20 > supports "bgp"=20 > > MIB, "routes" MIB and "network interfaces" MIB. > > > > > > > > urn:ietf:params:netconf:base:1.0 > > =20 > >=20 > urn:ietf:params:netconf:capability:startup:1.0 pability> > > urn:madynes:module:bgp > > urn:madynes:module:routes > > urn:madynes:module:interfaces > > > > 4 > > > > > > Is it acceptable ? > > > > Thanks for your help. > > Vincent Cridlig > > > > >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Feb 19 12:06:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAs0d-0003UT-3G for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 12:06:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAs0a-00074b-Mv for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 12:06:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FArrj-0005nq-Mt for netconf-data@psg.com; Sun, 19 Feb 2006 16:56:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FArrj-0005ne-1D for netconf@ops.ietf.org; Sun, 19 Feb 2006 16:56:55 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k1JGurVp008660 for ; Sun, 19 Feb 2006 08:56:53 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BX07A5>; Sun, 19 Feb 2006 08:56:53 -0800 Message-ID: From: "McDonald, Ira" To: netconf@ops.ietf.org Subject: [Capabilities] SMIv2 to XML Schema conversions Date: Sun, 19 Feb 2006 08:56:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi, I wrote a tool three years ago that converts SMIv2 MIBs to XSD files. It's been used for the canonical translations of printer industry MIBs (e.g., Printer MIB v2, RFC 3805) for the IEEE-ISTO PWG's standard Semantic Model. I'm not willing to open source this tool, but if anyone's interested in the approaches used, I'd be happy to talk offline. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Feb 19 13:44:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtXQ-0005YK-3t for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 13:44:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAtXM-0001SJ-IX for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 13:44:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAtS9-000CwH-Fo for netconf-data@psg.com; Sun, 19 Feb 2006 18:38:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAtRy-000Cuy-8t for netconf@ops.ietf.org; Sun, 19 Feb 2006 18:38:26 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6C0474D793; Sun, 19 Feb 2006 19:38:23 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14346-10; Sun, 19 Feb 2006 19:38:21 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id C68804D159; Sun, 19 Feb 2006 19:38:21 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 6201C6020E9; Sun, 19 Feb 2006 19:38:22 +0100 (CET) Date: Sun, 19 Feb 2006 19:38:21 +0100 From: Juergen Schoenwaelder To: "McDonald, Ira" Cc: netconf@ops.ietf.org Subject: Re: [Capabilities] SMIv2 to XML Schema conversions Message-ID: <20060219183821.GA26974@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "McDonald, Ira" , netconf@ops.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.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Sun, Feb 19, 2006 at 08:56:44AM -0800, McDonald, Ira wrote: > I wrote a tool three years ago that converts SMIv2 MIBs to > XSD files. It's been used for the canonical translations > of printer industry MIBs (e.g., Printer MIB v2, RFC 3805) > for the IEEE-ISTO PWG's standard Semantic Model. > > I'm not willing to open source this tool, but if anyone's > interested in the approaches used, I'd be happy to talk > offline. How does the tools output differ from what 'smidump -f xsd' generates? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Feb 19 13:45:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtZ8-0005b5-9V for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 13:45:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAtZ6-0001TZ-Vi for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 13:45:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAtV9-000D7X-KY for netconf-data@psg.com; Sun, 19 Feb 2006 18:41:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAtV9-000D7L-3G for netconf@ops.ietf.org; Sun, 19 Feb 2006 18:41:43 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k1JIfWtX011823; Sun, 19 Feb 2006 10:41:32 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BX09Z2>; Sun, 19 Feb 2006 10:41:33 -0800 Message-ID: From: "McDonald, Ira" To: "'j.schoenwaelder@iu-bremen.de'" , "McDonald, Ira" Cc: netconf@ops.ietf.org Subject: RE: [Capabilities] SMIv2 to XML Schema conversions Date: Sun, 19 Feb 2006 10:41:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi Juergen, Sorry, I'm not familiar with 'smidump', so I don't know the answer. No doubt people should probably just use 'smidump'. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Sunday, February 19, 2006 1:38 PM > To: McDonald, Ira > Cc: netconf@ops.ietf.org > Subject: Re: [Capabilities] SMIv2 to XML Schema conversions > > > On Sun, Feb 19, 2006 at 08:56:44AM -0800, McDonald, Ira wrote: > > > I wrote a tool three years ago that converts SMIv2 MIBs to > > XSD files. It's been used for the canonical translations > > of printer industry MIBs (e.g., Printer MIB v2, RFC 3805) > > for the IEEE-ISTO PWG's standard Semantic Model. > > > > I'm not willing to open source this tool, but if anyone's > > interested in the approaches used, I'd be happy to talk > > offline. > > How does the tools output differ from what 'smidump -f xsd' generates? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Feb 19 15:36:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAvIL-0000Ee-69 for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 15:36:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAvIK-0004pH-NW for netconf-archive@lists.ietf.org; Sun, 19 Feb 2006 15:36:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAvDd-000Jgd-KE for netconf-data@psg.com; Sun, 19 Feb 2006 20:31:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAvDc-000JgJ-B6 for netconf@ops.ietf.org; Sun, 19 Feb 2006 20:31:44 +0000 Received: (qmail 20655 invoked from network); 19 Feb 2006 20:31:43 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 19 Feb 2006 20:31:43 -0000 Message-ID: <43F8D5C9.5010601@andybierman.com> Date: Sun, 19 Feb 2006 12:32:09 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Cridlig Vincent CC: "Netconf (E-mail)" Subject: Re: Capabilities and MIBs References: <43F30326.40608@loria.fr> <43F77AD3.4040803@andybierman.com> <43F8A8E0.5010301@loria.fr> In-Reply-To: <43F8A8E0.5010301@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cridlig Vincent wrote: [I cc:ed the WG list because your comments are important to the WG] > >> >> I want to follow-up on the namespace vs. module identity issue. >> >> I like the idea of identifying the module, independent of its >> namespace, in case namespaces aren't used. (!) > > I don't see why two different identities should be defined, even if > namespaces aren't used. > In the hello message, there is no difference of using a module ID or a > namespace. It will match a unique data model in both cases. > And in the config element, elements will belong to a namespace or not... > Maybe I didn't get well something ?? > IMHO, using a unique ID (I mean a namespace) that can be used both as > a capability advertisement and as namespace, is more simple and > consistent. I agree with you -- now. When I wrote this mail, I was thinking there is probably some IETF rule that says a namespace URN has to have the "ns:" in the URN. Who cares. The capability string can be the namespace identifier. > > However, I am very interested that the wg defines a format for data > model namespaces. > In our prototype, we don't really know how to define them in a > standard way. Nobody does. Yet. ;-) I am using the per-module namespace approach now, but I don't like it. A supported option -- one namespace per owner, and let the owner manage name collision (like MIBs). You can't load 2 modules with owner-space collisions, so this is a compile time problem. A "version" attribute in the data model start node can be used to detect version mismatches, instead of namespaces. > >> I propose the following conventions (for comment, write-up TBD): >> >> 1) Agents SHOULD the advertise data model modules they support >> Managers MAY advertise modules (but why?) > > I agree. I don't find any use case where it will be useful for a > manager to advertise its supported data models. > No -- the WG discussed this in detail at an interim meeting. The thinking was "is there a way the agent can save resources by knowing which data model modules the manager cared about?". This idea was quickly tossed because manager functionality might be dynamically extensible and the list of supported modules might keep changing. It might be a really big list too. Plus, why do you need to tell an Acme agent about all the proprietary data models from other vendors you support? Still, an agent must be able to at least ignore such capabilities in the from the manager. (Not that hard ;-) Andy >> >> 2) The format for a data model module capability URN SHOULD be: >> >> urn::params:netconf:module:[:] >> >> e.g. urn:madynes:params:netconf:module:bgp:1.0 >> >> 3) The namespace URN to use for a particular module SHOULD be: >> >> urn::params:netconf:ns:[:] >> >> e.g. urn:madynes:params:netconf:ns:bgp:1.0 >> The extra "params:netconf" in the string makes IETF and >> vendor strings >> consistent. Not sure how much this matters. >> >> If a hard-wired URN for namespace is not acceptable, then some >> extension to the element is needed to associate >> a namespace with a module. >> >> 4) SNMP MIB conversions are not standardized, but a convention for >> a module name could be: >> >> >> urn::params:netconf:module:[:] >> >> e.g., urn:ietf:params:netconf:module:RMON2-MIB:9605270000Z >> >> This allows MIB modules that are not in RFCs to specify a version. >> Not sure this helps at all without a SMIv2 to XML translation >> standard. >> >> >> Comments? Waste of time on CLRs? >> Experimental? BCP? Informational? Normative? >> >> >> Andy >> >>> Hi, >>> >>> I would like that our agent advertises its supported "MIBs". >>> Are capabilities the regular way to do it ? >>> >>> Like, for example, for the agent to advertise that it supports "bgp" >>> MIB, "routes" MIB and "network interfaces" MIB. >>> >>> >>> >>> urn:ietf:params:netconf:base:1.0 >>> >>> urn:ietf:params:netconf:capability:startup:1.0 >>> urn:madynes:module:bgp >>> urn:madynes:module:routes >>> urn:madynes:module:interfaces >>> >>> 4 >>> >>> >>> Is it acceptable ? >>> >>> Thanks for your help. >>> Vincent Cridlig >>> >>> >> > > > > > > > ___________________________________________________________________________ > Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les > tarifs exceptionnels pour appeler la France et l'international. > Téléchargez sur http://fr.messenger.yahoo.com > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 02:46:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB5kx-0007zY-LD for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 02:46:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB5kv-0005fq-4E for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 02:46:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FB5ba-000CDy-Hs for netconf-data@psg.com; Mon, 20 Feb 2006 07:37:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FB5bY-000CDa-Ku for netconf@ops.ietf.org; Mon, 20 Feb 2006 07:37:08 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 88BE54D3C6; Mon, 20 Feb 2006 08:37:07 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08559-01; Mon, 20 Feb 2006 08:37:05 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id B4C354C4AB; Mon, 20 Feb 2006 08:37:05 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 55A1760243A; Mon, 20 Feb 2006 08:37:06 +0100 (CET) Date: Mon, 20 Feb 2006 08:37:06 +0100 From: Juergen Schoenwaelder To: "McDonald, Ira" Cc: netconf@ops.ietf.org Subject: Re: [Capabilities] SMIv2 to XML Schema conversions Message-ID: <20060220073706.GB27153@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "McDonald, Ira" , netconf@ops.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.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Sun, Feb 19, 2006 at 10:41:31AM -0800, McDonald, Ira wrote: > Sorry, I'm not familiar with 'smidump', so I don't know the > answer. No doubt people should probably just use 'smidump'. While you can download smidump and see what it generates and how the XSD differs from what your tool generates, I can't do the same with your tool. Since you are familiar with the Printer-MIB, I have put the output of 'smidump -f xsd' online: ftp://ftp.eecs.iu-bremen.de/netconf/Printer-MIB.xsd I would be curious to know what you did differently, but perhaps this is getting off-topic for this mailing list and we should either move that discussion to the netconfmodel list or yet somewhere else. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 04:21:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7EQ-0002pT-Sy for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 04:21:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7EP-0008Ae-Bd for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 04:21:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FB77U-000J0C-3h for netconf-data@psg.com; Mon, 20 Feb 2006 09:14:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FB77T-000Izz-2B for netconf@ops.ietf.org; Mon, 20 Feb 2006 09:14:11 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id F3DB033; Mon, 20 Feb 2006 10:14:09 +0100 (CET) Date: Mon, 20 Feb 2006 10:14:02 +0100 (CET) Message-Id: <20060220.101402.26961260.mbj@tail-f.com> To: ietf@andybierman.com Cc: phil@juniper.net, netconf@ops.ietf.org Subject: Re: url clarification From: Martin Bjorklund In-Reply-To: <43F765E6.9050500@andybierman.com> References: <200602151413.k1FED5YE071428@idle.juniper.net> <20060215.223557.35799705.mbj@tail-f.com> <43F765E6.9050500@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Andy Bierman wrote: > Did we ever resolve all the issues here? (A: no) > > Here are the operations that use rpcOperationTargetType: > > operation text-allows-url notes > ------------------------------------------------ > edit-config N 1 > copy-config Y 2 > delete-config Y 3 > lock N 4 > unlock N 4 [...] > Summary Issues: > > A) Which is right: The text or the XSD? > Should the edit-config, lock, and unlock XSD definitions change from > rpcOperationTargetType to configNameType? This will explicitly > disallow URL as in these operations. I think the text makes more sense than the XSD. > B) If an agent advertises the :url capability, what operations > MUST, SHOULD, or MAY it apply to? What if an agent only > supports URLs as the parameter and not the parameter > on some or all operations? One example is the http/https schemes as target to copy-config. Which HTTP operation should the agent use? PUT? POST? Another thing which is not clear is what the file pointed to by an url looks like. Suppose you send the agent the following command: ftp://ftp.server.com/my.conf ... ... What will the 'my.conf' file look like? Like this: ... ... This would be a valid XML document, where 'config' does not belong to any namespace. Another alternative is the same contents but w/o the element, but that wouldn't be valid XML. There are some other reasonable alterantives as well. Maybe this also is implementation-specific? (with the usual inter-op drawbacks) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 08:47:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBBOP-0001Xk-Ik for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 08:47:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBBON-0007py-5l for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 08:47:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBBDT-0008ci-EM for netconf-data@psg.com; Mon, 20 Feb 2006 13:36:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBBDS-0008cV-4g for netconf@ops.ietf.org; Mon, 20 Feb 2006 13:36:38 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 866EC4F0012; Mon, 20 Feb 2006 14:36:36 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 14:36:36 +0100 Received: from daphne.ted.ericsson.se ([213.159.189.28]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 14:36:35 +0100 Received: from tedchly by daphne.ted.ericsson.se with local (Exim 4.60) (envelope-from ) id 1FBBDP-00074l-Sq; Mon, 20 Feb 2006 14:36:35 +0100 From: Christian Lynbech To: Andy Bierman Cc: "McDonald, Ira" , Randy Presuhn , netconf@ops.ietf.org Subject: Re: Capabilities and MIBs References: <43F4F156.5000908@andybierman.com> Date: Mon, 20 Feb 2006 14:36:35 +0100 In-Reply-To: <43F4F156.5000908@andybierman.com> (Andy Bierman's message of "Thu, 16 Feb 2006 13:40:38 -0800") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 20 Feb 2006 13:36:36.0119 (UTC) FILETIME=[AB873270:01C63622] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Admittedly dangerous territory to enter for a newcomer, but has anybody considered Document Structure Descriptions: http://www.brics.dk/DSD/dsd2.html as a possible vehicle for model definitions? ------------------------+----------------------------------------------------- Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J ------------------------+----------------------------------------------------- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 10:39:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBD8k-0006Nt-Dh for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 10:39:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBD8h-0002nB-Uc for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 10:39:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBD2c-000Feu-7u for netconf-data@psg.com; Mon, 20 Feb 2006 15:33:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBD2b-000Feg-0w for netconf@ops.ietf.org; Mon, 20 Feb 2006 15:33:33 +0000 Received: (qmail 18594 invoked from network); 20 Feb 2006 15:33:32 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 20 Feb 2006 15:33:32 -0000 Message-ID: <43F9E14A.5070703@andybierman.com> Date: Mon, 20 Feb 2006 07:33:30 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, netconf@ops.ietf.org Subject: Re: url clarification References: <200602151413.k1FED5YE071428@idle.juniper.net> <20060215.223557.35799705.mbj@tail-f.com> <43F765E6.9050500@andybierman.com> <20060220.101402.26961260.mbj@tail-f.com> In-Reply-To: <20060220.101402.26961260.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Martin Bjorklund wrote: > Andy Bierman wrote: > >> Did we ever resolve all the issues here? (A: no) >> >> Here are the operations that use rpcOperationTargetType: >> >> operation text-allows-url notes >> ------------------------------------------------ >> edit-config N 1 >> copy-config Y 2 >> delete-config Y 3 >> lock N 4 >> unlock N 4 >> > > [...] > > >> Summary Issues: >> >> A) Which is right: The text or the XSD? >> Should the edit-config, lock, and unlock XSD definitions change from >> rpcOperationTargetType to configNameType? This will explicitly >> disallow URL as in these operations. >> > > I think the text makes more sense than the XSD. > I can see it both ways. One one hand, I sure don't want to make it mandatory for the :url capability to include as a target of edit-config. On the other, I don't want to prohibit it without reason either. Section 8.8.5 is the critical text here. Taken literally, this section says that as a target for must be supported, but the target should be a local file. Lock and unlock are not allowed (they are not listed in this section). This part seems kind of broken to me. It is data model specific what it means to edit a file instead of configuration datastore. I don't think the WG ever really thought through the details of this section, especially 8.8.5.1. The one thing that is clear is that the text in several sections is out of sync with the XSD wrt/ the element. > > >> B) If an agent advertises the :url capability, what operations >> MUST, SHOULD, or MAY it apply to? What if an agent only >> supports URLs as the parameter and not the parameter >> on some or all operations? >> > > One example is the http/https schemes as target to copy-config. Which > HTTP operation should the agent use? PUT? POST? > good question > > Another thing which is not clear is what the file pointed to by an url > looks like. Suppose you send the agent the following command: > > > > ftp://ftp.server.com/my.conf > > > > > ... > > > ... > > > > > > What will the 'my.conf' file look like? Like this: > > > > ... > > > ... > > > The WG decided awhile back to remove the text vs. XML "format" parameter from these operations. There is only XML. (Even if a text config file is only conceptually wrapped in a top-level element.) What my.conf looks like is data model dependent. > This would be a valid XML document, where 'config' does not belong to > any namespace. Another alternative is the same contents but w/o the > element, but that wouldn't be valid XML. There are some > other reasonable alterantives as well. Maybe this also is > implementation-specific? (with the usual inter-op drawbacks) > Data-model specific, not implementation-specific. There is a big difference. Here is what I mean by top-level wrapper: (Top-level element name doesn't really matter) ascii config file command ascii config file command ascii config file command > > > /martin > > > > Andy > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 10:59:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDRT-0007kB-Rs for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 10:59:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBDRT-00036t-Em for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 10:59:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBDMh-000Gtr-UZ for netconf-data@psg.com; Mon, 20 Feb 2006 15:54:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBDMh-000GtT-0I for netconf@ops.ietf.org; Mon, 20 Feb 2006 15:54:19 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id D80E02D; Mon, 20 Feb 2006 16:54:17 +0100 (CET) Date: Mon, 20 Feb 2006 16:54:10 +0100 (CET) Message-Id: <20060220.165410.44984206.mbj@tail-f.com> To: ietf@andybierman.com Cc: phil@juniper.net, netconf@ops.ietf.org Subject: Re: url clarification From: Martin Bjorklund In-Reply-To: <43F9E14A.5070703@andybierman.com> References: <43F765E6.9050500@andybierman.com> <20060220.101402.26961260.mbj@tail-f.com> <43F9E14A.5070703@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > > > >> Did we ever resolve all the issues here? (A: no) > >> > >> Here are the operations that use rpcOperationTargetType: > >> > >> operation text-allows-url notes > >> ------------------------------------------------ > >> edit-config N 1 > >> copy-config Y 2 > >> delete-config Y 3 > >> lock N 4 > >> unlock N 4 > >> > > > > [...] > > > > > >> Summary Issues: > >> > >> A) Which is right: The text or the XSD? > >> Should the edit-config, lock, and unlock XSD definitions change from > >> rpcOperationTargetType to configNameType? This will explicitly > >> disallow URL as in these operations. > >> > > > > I think the text makes more sense than the XSD. > > > > I can see it both ways. > One one hand, I sure don't want to make it mandatory > for the :url capability to include as a target of edit-config. > On the other, I don't want to prohibit it without reason either. > > Section 8.8.5 is the critical text here. > Taken literally, this section says that as > a target for must be supported, > but the target should be a local file. It says (8.8.5.1) that must be accepted as an alternative to , i.e. as the "source" of the edit-config command. And it must be a local file (for some reason). The parameter cannot be an url. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 11:12:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDec-0008W1-Ky for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 11:12:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBDeb-0003OH-8w for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 11:12:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBDXA-000Hg2-UI for netconf-data@psg.com; Mon, 20 Feb 2006 16:05:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBDXA-000Hfp-9C for netconf@ops.ietf.org; Mon, 20 Feb 2006 16:05:08 +0000 Received: (qmail 10361 invoked from network); 20 Feb 2006 16:05:07 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 20 Feb 2006 16:05:07 -0000 Message-ID: <43F9E8B1.5090604@andybierman.com> Date: Mon, 20 Feb 2006 08:05:05 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, netconf@ops.ietf.org Subject: Re: url clarification References: <43F765E6.9050500@andybierman.com> <20060220.101402.26961260.mbj@tail-f.com> <43F9E14A.5070703@andybierman.com> <20060220.165410.44984206.mbj@tail-f.com> In-Reply-To: <20060220.165410.44984206.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Martin Bjorklund wrote: > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>> >>> >>>> Did we ever resolve all the issues here? (A: no) >>>> >>>> Here are the operations that use rpcOperationTargetType: >>>> >>>> operation text-allows-url notes >>>> ------------------------------------------------ >>>> edit-config N 1 >>>> copy-config Y 2 >>>> delete-config Y 3 >>>> lock N 4 >>>> unlock N 4 >>>> >>>> >>> [...] >>> >>> >>> >>>> Summary Issues: >>>> >>>> A) Which is right: The text or the XSD? >>>> Should the edit-config, lock, and unlock XSD definitions change from >>>> rpcOperationTargetType to configNameType? This will explicitly >>>> disallow URL as in these operations. >>>> >>>> >>> I think the text makes more sense than the XSD. >>> >>> >> I can see it both ways. >> One one hand, I sure don't want to make it mandatory >> for the :url capability to include as a target of edit-config. >> On the other, I don't want to prohibit it without reason either. >> >> Section 8.8.5 is the critical text here. >> Taken literally, this section says that as >> a target for must be supported, >> but the target should be a local file. >> > > It says (8.8.5.1) that must be accepted as an alternative to > , i.e. as the "source" of the edit-config command. And it > must be a local file (for some reason). The parameter cannot > be an url. > > oops -- you're right. So the text is right and the XSD is wrong. The "rpcOperationTargetType" needs to be changed to "configNameType" for edit-config, lock, and unlock. End of problem. > > > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 12:17:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBEfK-0006tE-RU for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 12:17:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBEfH-0005mu-EB for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 12:17:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBEaC-000M3E-Pb for netconf-data@psg.com; Mon, 20 Feb 2006 17:12:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBEaA-000M25-BS for netconf@ops.ietf.org; Mon, 20 Feb 2006 17:12:18 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k1KHCEAA019293; Mon, 20 Feb 2006 09:12:14 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BYA05Z>; Mon, 20 Feb 2006 09:12:14 -0800 Message-ID: From: "McDonald, Ira" To: "'j.schoenwaelder@iu-bremen.de'" , "McDonald, Ira" Cc: netconf@ops.ietf.org Subject: RE: [Capabilities] SMIv2 to XML Schema conversions Date: Mon, 20 Feb 2006 09:12:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi Juergen, I hadn't realized that there _was_ a netconf model list. NetConf and IETF Languge Tag Registration Updates are accounting for 80 messages a day that I mostly try to read. The link you sent below appears to be broken (I can't use a command line FTP or a web browser to that site). The translations of the two modules in Printer MIB v2 (RFC 3805) from my tool are permanently posted at: ftp://ftp.pwg.org/pub/pwg/wims/schemas/rfc3805a-20040805.xsd - IANA-PRINTER-MIB (textual conventions registry) ftp://ftp.pwg.org/pub/pwg/wims/schemas/rfc3805b-20040805.xsd - Printer-MIB If you send me your translation as an attachment, I'll try to find time to look at it and compare. I'm very busy just now, so it may take a little while. And since you make smidump available and you're the expert, it's probably the right choice for others to use. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Monday, February 20, 2006 2:37 AM > To: McDonald, Ira > Cc: netconf@ops.ietf.org > Subject: Re: [Capabilities] SMIv2 to XML Schema conversions > > > On Sun, Feb 19, 2006 at 10:41:31AM -0800, McDonald, Ira wrote: > > > Sorry, I'm not familiar with 'smidump', so I don't know the > > answer. No doubt people should probably just use 'smidump'. > > While you can download smidump and see what it generates and how the > XSD differs from what your tool generates, I can't do the same with > your tool. > > Since you are familiar with the Printer-MIB, I have put the output of > 'smidump -f xsd' online: > > ftp://ftp.eecs.iu-bremen.de/netconf/Printer-MIB.xsd > > I would be curious to know what you did differently, but perhaps this > is getting off-topic for this mailing list and we should either move > that discussion to the netconfmodel list or yet somewhere else. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 13:36:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBFtX-0001pY-UQ for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 13:36:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBFtR-0000ap-1D for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 13:36:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBFiU-000100-B6 for netconf-data@psg.com; Mon, 20 Feb 2006 18:24:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBFiM-0000zT-1s for netconf@ops.ietf.org; Mon, 20 Feb 2006 18:24:51 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id E42D74D46E; Mon, 20 Feb 2006 19:24:48 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14844-02; Mon, 20 Feb 2006 19:24:47 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id D96E94D4C3; Mon, 20 Feb 2006 19:24:42 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id AB26D602ABB; Mon, 20 Feb 2006 19:24:43 +0100 (CET) Date: Mon, 20 Feb 2006 19:24:43 +0100 From: Juergen Schoenwaelder To: "McDonald, Ira" Cc: netconf@ops.ietf.org Subject: Re: [Capabilities] SMIv2 to XML Schema conversions Message-ID: <20060220182443.GD28468@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "McDonald, Ira" , netconf@ops.ietf.org References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f34996213d8155085892842dfee2567 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 20, 2006 at 09:12:12AM -0800, McDonald, Ira wrote: > I hadn't realized that there _was_ a netconf model list. > NetConf and IETF Languge Tag Registration Updates are > accounting for 80 messages a day that I mostly try to read. > > The link you sent below appears to be broken (I can't > use a command line FTP or a web browser to that site). Seems to be a middlebox issue - some clients seem to work while others don't. > The translations of the two modules in Printer MIB v2 > (RFC 3805) from my tool are permanently posted at: > > ftp://ftp.pwg.org/pub/pwg/wims/schemas/rfc3805a-20040805.xsd > - IANA-PRINTER-MIB (textual conventions registry) > > ftp://ftp.pwg.org/pub/pwg/wims/schemas/rfc3805b-20040805.xsd > - Printer-MIB > > If you send me your translation as an attachment, I'll try > to find time to look at it and compare. I'm very busy just > now, so it may take a little while. I am attaching it. Note that we tried to keep as much information as possible and hence your translation appears much more verbose. (Some people have used the translation in an SNMP/XML gateway where this additional information was useful.) > And since you make smidump available and you're the expert, > it's probably the right choice for others to use. I like to understand what proper mappings are. I am sure that are differences in the details and I like to understand them and perhaps improve upon what we have. I am not talking about implementations here - I am interested to figure out whether there have been common ways to do things or whether it is possible to agree on a common way to do things. This is IMHO the first step in writing up a specification. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Printer-MIB.xsd" The MIB module for management of printers. Copyright (C) The Internet Society (2004). This version of this MIB module was published in RFC 3805. For full legal notices see the RFC itself. not-accessible 1.3.6.1.2.1.43.5.1.1 current An entry exists in this table for each device entry in the host resources MIB device table with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.5.2.1 current This table will have an entry for each entry in the Host Resources MIB storage table that represents storage associated with a printer managed by this agent. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.5.3.1 current This table will have an entry for each entry in the Host Resources MIB device table that represents a device associated with a printer managed by this agent. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.6.1.1 current Information about a cover or interlock. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.7.1.1 current A description of a localization. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.8.2.1 current Attributes of a device capable of providing media for input to the printing process. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.9.2.1 current Attributes of a device capable of receiving media delivered from the printing process. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.10.2.1 current Entries in this table define the characteristics and status of each marker sub-unit in the printer. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.11.1.1 current Attributes of a marker supply. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.12.1.1 current Attributes of a colorant available on the printer. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.13.4.1 current Entries may exist in the table for each device index with a device type of 'printer' Each entry defines the physical characteristics of and the status of the media path. The data provided indicates the maximum throughput and the media size limitations of these subunits. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.14.1.1 current Entries may exist in the table for each device index with a device type of 'printer'. Each channel table entry is characterized by a unique protocol stack and/or addressing. The channel may also have printer dependent features that are associated with a printing language. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.15.1.1 current Entries may exist in the table for each device index with a device type of 'printer'. Each table entry provides a complete description of the interpreter, including version information, rendering resolutions, default character sets, output orientation, and communication capabilities. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.16.5.1 current This table contains one entry for each physical line on the display. Lines cannot be added or deleted. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.17.6.1 current Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. not-accessible 1.3.6.1.2.1.43.18.1.1 current Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.5.1.1.1 current Counts configuration changes within the printer. A configuration change is defined to be an action that results in a change to any MIB object other than those that reflect status or level, or those that act as counters or gauges. In addition, any action that results in a row being added or deleted from any table in the Printer MIB is considered a configuration change. Such changes will often affect the capability of the printer to service certain types of print jobs. Management applications may cache infrequently changed configuration information about sub units within the printer. This object should be incremented whenever the agent wishes to notify management applications that any cached configuration information for this device is to be considered 'stale'. At this point, the management application should flush any configuration information cached about this device and fetch new configuration information. The following are examples of actions that would cause the prtGeneralConfigChanges object to be incremented: - Adding an output bin - Changing the media in a sensing input tray - Changing the value of prtInputMediaType Note that the prtGeneralConfigChanges counter would not be incremented when an input tray is temporarily removed to load additional paper or when the level of an input device changes. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.5.1.1.2 current The value of the prtLocalizationIndex corresponding to the current language, country, and character set to be used for localized string values that are identified as being dependent on the value of this object. Note that this object does not apply to localized strings in the prtConsole group or to any object that is not explicitly identified as being localized according to prtGeneralCurrentLocalization. When an object's 'charset' is controlled by the value of prtGeneralCurrentLocalization, it MUST specify PrtLocalizedDescriptionStringTC as its syntax. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.5.1.1.3 current Setting this value to 'powerCycleReset', 'resetToNVRAM', or 'resetToFactoryDefaults' will result in the resetting of the printer. When read, this object will always have the value 'notResetting(3)', and a SET of the value 'notResetting' shall have no effect on the printer. Some of the defined values are optional. However, every implementation must support at least the values 'notResetting' and 'resetToNVRAM'. read-write 1.3.6.1.2.1.43.5.1.1.4 current The name of the person who is responsible for operating this printer. It is suggested that this string include information that would enable other humans to reach the operator, such as a phone number. As a convention to facilitate automatic notification of the operator by the agent or network management station, the phone number, fax number or email address should be indicated by the URL schemes 'tel:', 'fax:' and 'mailto:', respectively. If either the phone, fax, or email information is not available, then a line should not be included for this information. NOTE: For interoperability purposes, it is advisable to use email addresses formatted according to [RFC2822] requirements. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.5.1.1.5 current The name of the person responsible for servicing this printer. It is suggested that this string include information that would enable other humans to reach the service person, such as a phone number. As a convention to facilitate automatic notification of the operator by the agent or network management station, the phone number, fax number or email address should be indicated by the URL schemes 'tel:', 'fax:' and 'mailto:', respectively. If either the phone, fax, or email information is not available, then a line should not be included for this information. NOTE: For interoperability purposes, it is advisable to use email addresses formatted per [RFC2822] requirements. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.5.1.1.6 current The value of prtInputIndex corresponding to the default input sub-unit: that is, this object selects the default source of input media. read-write 1.3.6.1.2.1.43.5.1.1.7 current The value of prtOutputIndex corresponding to the default output sub-unit; that is, this object selects the default output destination. read-write 1.3.6.1.2.1.43.5.1.1.8 current The value of prtMarkerIndex corresponding to the default marker sub-unit; that is, this object selects the default marker. read-write 1.3.6.1.2.1.43.5.1.1.9 current The value of prtMediaPathIndex corresponding to the default media path; that is, the selection of the default media path. read-write 1.3.6.1.2.1.43.5.1.1.10 current The value of the prtLocalizationIndex corresponding to the language, country, and character set to be used for the console. This localization applies both to the actual display on the console as well as the encoding of these console objects in management operations. When an object's 'charset' is controlled by the value of prtConsoleLocalization, it MUST specify PrtConsoleDescriptionStringTC as its syntax. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.5.1.1.11 current The number of lines on the printer's physical display. This value is 0 if there are no lines on the physical display or if there is no physical display read-only 1.3.6.1.2.1.43.5.1.1.12 current The number of characters per line displayed on the physical display. This value is 0 if there are no lines on the physical display or if there is no physical display read-write 1.3.6.1.2.1.43.5.1.1.13 current This value indicates how input is (or is not) accepted from the operator console. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.5.1.1.14 current Used to enable or disable printing a startup page. If enabled, a startup page will be printed shortly after power-up, when the device is ready. Typical startup pages include test patterns and/or printer configuration information. read-write 1.3.6.1.2.1.43.5.1.1.15 current Used to enable or disable printing banner pages at the beginning of jobs. This is a master switch which applies to all jobs, regardless of interpreter. read-write 1.3.6.1.2.1.43.5.1.1.16 current An administrator-specified name for this printer. Depending upon implementation of this printer, the value of this object may or may not be same as the value for the MIB-II 'SysName' object. read-write 1.3.6.1.2.1.43.5.1.1.17 current A recorded serial number for this device that indexes some type device catalog or inventory. This value is usually set by the device manufacturer but the MIB supports the option of writing for this object for site-specific administration of device inventory or tracking. read-only 1.3.6.1.2.1.43.5.1.1.18 current A running counter of the number of critical alert events that have been recorded in the alert table. The value of this object is RESET in the event of a power cycle operation (i.e., the value is not persistent. read-only 1.3.6.1.2.1.43.5.1.1.19 current A running counter of the total number of alert event entries (critical and non-critical) that have been recorded in the alert table read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. read-only 1.3.6.1.2.1.43.5.2.1.2 current The value of the hrDeviceIndex of the printer device that this storageEntry is associated with. read-only 1.3.6.1.2.1.25.2.3.1.1 current A unique value for each logical storage area contained by the host. not-accessible 1.3.6.1.2.1.43.5.2.1.1 current This value will be unique amongst all entries with a common value of hrStorageIndex. This object allows a storage entry to point to the multiple printer devices with which it is associated. read-only 1.3.6.1.2.1.43.5.3.1.2 current The value of the hrDeviceIndex of the printer device that this deviceEntry is associated with. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.5.3.1.1 current This value will be unique amongst all entries with a common value of hrDeviceIndex. This object allows a device entry to point to the multiple printer devices with which it is associated. read-only 1.3.6.1.2.1.43.6.1.1.2 current The manufacturer provided cover sub-mechanism name in the localization specified by prtGeneralCurrentLocalization. read-only 1.3.6.1.2.1.43.6.1.1.3 current The status of this cover sub-unit. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.6.1.1.1 current A unique value used by the printer to identify this Cover sub unit. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new cover sub-units to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.7.1.1.2 current A two character language code from ISO 639. Examples en, es, fr, de. NOTE: These examples were shown as upper case in RFC 1759 and are now shown as lower case to agree with ISO 639. read-only 1.3.6.1.2.1.43.7.1.1.3 current A two character country code from ISO 3166, a blank string (two space characters) shall indicate that the country is not defined. Examples: US, GB, FR, DE, ... read-only 1.3.6.1.2.1.43.7.1.1.4 current The coded character set used for this localization. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.7.1.1.1 current A unique value used by the printer to identify this localization entry. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new localization data to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.8.2.1.2 current The type of technology (discriminated primarily according to feeder mechanism type) employed by the input sub-unit. Note, the Input Class provides for a descriptor field to further qualify the other choice. read-only 1.3.6.1.2.1.43.8.2.1.3 current The unit of measurement for use calculating and relaying dimensional values for this input sub-unit. read-write 1.3.6.1.2.1.43.8.2.1.4 current This object provides the value of the declared dimension, in the feed direction, of the media that is (or, if empty, was or will be) in this input sub-unit. The feed direction is the direction in which the media is fed on this sub-unit. This dimension is measured in input sub-unit dimensional units (controlled by prtInputDimUnit, which uses PrtMediaUnitTC). If this input sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests. Otherwise, the value may be changed. The value (-1) means other and specifically means that this sub-unit places no restriction on this parameter. The value (-2) indicates unknown. read-write 1.3.6.1.2.1.43.8.2.1.5 current This object provides the value of the declared dimension, in the cross feed direction, of the media that is (or, if empty, was or will be) in this input sub-unit. The cross feed direction is ninety degrees relative to the feed direction associated with this sub-unit. This dimension is measured in input sub-unit dimensional units (controlled by prtInputDimUnit,which uses PrtMediaUnitTC). If this input sub- unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests. Otherwise, the value may be changed. The value (-1) means other and specifically means that this sub-unit places no restriction on this parameter. The value (-2) indicates unknown. read-only 1.3.6.1.2.1.43.8.2.1.6 current The printer will act as if media of the chosen dimension (in the feed direction) is present in this input source. Note that this value will be used even if the input tray is empty. Feed dimension measurements are taken relative to the feed direction associated with that sub-unit and are in input sub-unit dimensional units (controlled by prtInputDimUnit, which uses PrtMediaUnitTC). If the printer supports the declared dimension,the granted dimension is the same as the declared dimension. If not, the granted dimension is set to the closest dimension that the printer supports when the declared dimension is set. The value (-1) means other and specifically indicates that this sub-unit places no restriction on this parameter. The value (-2)indicates unknown. read-only 1.3.6.1.2.1.43.8.2.1.7 current The printer will act as if media of the chosen dimension (in the cross feed direction) is present in this input source. Note that this value will be used even if the input tray is empty. The cross feed direction is ninety degrees relative to the feed direction associated with this sub-unit. This dimension is measured in input sub-unit dimensional units (controlled by prtInputDimUnit, which uses PrtMediaUnitTC). If the printer supports the declare dimension, the granted dimension is the same as the declared dimension. If not, the granted dimension is set to the closest dimension that the printer supports when the declared dimension is set. The value (-1) means other and specifically indicates that this sub-unit places no restriction on this parameter. The value (-2) indicates unknown. read-only 1.3.6.1.2.1.43.8.2.1.8 current The unit of measurement for use in calculating and relaying capacity values for this input sub-unit. read-write 1.3.6.1.2.1.43.8.2.1.9 current The maximum capacity of the input sub-unit in input sub-unit capacity units (PrtCapacityUnitTC). There is no convention associated with the media itself so this value reflects claimed capacity. If this input sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. read-write 1.3.6.1.2.1.43.8.2.1.10 current The current capacity of the input sub-unit in input sub-unit capacity units (PrtCapacityUnitTC). If this input sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. The value (-3) means that the printer knows that at least one unit remains. read-only 1.3.6.1.2.1.43.8.2.1.11 current The current status of this input sub-unit. read-write 1.3.6.1.2.1.43.8.2.1.12 current A description of the media contained in this input sub-unit; This description is to be used by a client to format and Localize a string for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g., prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). read-write 1.3.6.1.2.1.43.8.2.1.13 current The name assigned to this input sub-unit. read-only 1.3.6.1.2.1.43.8.2.1.14 current The vendor name of this input sub-unit. read-only 1.3.6.1.2.1.43.8.2.1.15 current The model name of this input sub-unit. read-only 1.3.6.1.2.1.43.8.2.1.16 current The version of this input sub-unit. read-only 1.3.6.1.2.1.43.8.2.1.17 current The serial number assigned to this input sub-unit. read-only 1.3.6.1.2.1.43.8.2.1.18 current A free-form text description of this input sub-unit in the localization specified by prtGeneralCurrentLocalization. read-write 1.3.6.1.2.1.43.8.2.1.19 current Indicates if this input sub-unit has some security associated with it. read-write 1.3.6.1.2.1.43.8.2.1.20 current The weight of the medium associated with this input sub-unit in grams / per meter squared. The value (-2) means unknown. read-write 1.3.6.1.2.1.43.8.2.1.21 current The name of the type of medium associated with this input sub unit. This name need not be processed by the printer; it might simply be displayed to an operator. NOTE: The above description has been modified from RFC 1759. read-write 1.3.6.1.2.1.43.8.2.1.22 current The name of the color of the medium associated with this input sub-unit using standardized string values. NOTE: The above description has been modified from RFC 1759. read-write 1.3.6.1.2.1.43.8.2.1.23 current The number of parts associated with the medium associated with this input sub-unit if the medium is a multi-part form. The value (-1) means other and specifically indicates that the device places no restrictions on this parameter. The value (-2) means unknown. read-write 1.3.6.1.2.1.43.8.2.1.24 current When the printer is not able to print due to a subunit being empty or the requested media must be manually loaded, the printer will wait for the duration (in seconds) specified by this object. Upon expiration of the time-out, the printer will take the action specified by prtInputNextIndex. The event which causes the printer to enter the waiting state is product specific. If the printer is not waiting for manually fed media, it may switch from an empty subunit to a different subunit without waiting for the time-out to expire. A value of (-1) implies 'other' or 'infinite' which translates to 'wait forever'. The action which causes printing to continue is product specific. A value of (-2) implies 'unknown'. read-write 1.3.6.1.2.1.43.8.2.1.25 current The value of prtInputIndex corresponding to the input subunit which will be used when this input subunit is emptied and the time-out specified by prtInputMediaLoadTimeout expires. A value of zero(0) indicates that auto input switching will not occur when this input subunit is emptied. If the time-out specified by prtInputLoadMediaTimeout expires and this value is zero(0), the job will be aborted. A value of (-1) means other. The value (-2)means 'unknown' and specifically indicates that an implementation specific method will determine the next input subunit to use at the time this subunit is emptied and the time out expires. The value(-3) means input switching is not supported for this subunit. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.8.2.1.1 current A unique value used by the printer to identify this input sub-unit. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new input sub-units to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.9.2.1.2 current The type of technology supported by this output sub-unit. read-only 1.3.6.1.2.1.43.9.2.1.3 current The unit of measurement for use in calculating and relaying capacity values for this output sub-unit. read-write 1.3.6.1.2.1.43.9.2.1.4 current The maximum capacity of this output sub-unit in output sub- unit capacity units (PrtCapacityUnitTC). There is no convention associated with the media itself so this value essentially reflects claimed capacity. If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. read-write 1.3.6.1.2.1.43.9.2.1.5 current The remaining capacity of the possible output sub-unit capacity in output sub-unit capacity units (PrtCapacityUnitTC)of this output sub-unit. If this output sub- unit can reliably sense this value, the value is sensed by the printer and may not be modified by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. The value (-3) means that the printer knows that there remains capacity for at least one unit. read-only 1.3.6.1.2.1.43.9.2.1.6 current The current status of this output sub-unit. read-write 1.3.6.1.2.1.43.9.2.1.7 current The name assigned to this output sub-unit. read-only 1.3.6.1.2.1.43.9.2.1.8 current The vendor name of this output sub-unit. read-only 1.3.6.1.2.1.43.9.2.1.9 current The model name assigned to this output sub-unit. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.9.2.1.10 current The version of this output sub-unit. read-only 1.3.6.1.2.1.43.9.2.1.11 current The serial number assigned to this output sub-unit. read-only 1.3.6.1.2.1.43.9.2.1.12 current A free-form text description of this output sub-unit in the localization specified by prtGeneralCurrentLocalization. read-write 1.3.6.1.2.1.43.9.2.1.13 current Indicates if this output sub-unit has some security associated with it and if that security is enabled or not. read-only 1.3.6.1.2.1.43.9.2.1.14 current The unit of measurement for use in calculating and relaying dimensional values for this output sub-unit. read-write 1.3.6.1.2.1.43.9.2.1.15 current The maximum dimensions supported by this output sub-unit for measurements taken parallel relative to the feed direction associated with that sub-unit in output sub-unit dimensional units (controlled by prtOutputDimUnit, which uses PrtMediaUnitTC). If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed with management protocol operations. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification and to explain the purpose of (-1) and (-2). read-write 1.3.6.1.2.1.43.9.2.1.16 current The maximum dimensions supported by this output sub-unit for measurements taken ninety degrees relative to the feed direction associated with that sub-unit in output sub-unit dimensional units (controlled by prtOutputDimUnit, which uses PrtMediaUnitTC). If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed with management protocol operations. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification and to explain the purpose of (-1) and (-2). read-write 1.3.6.1.2.1.43.9.2.1.17 current The minimum dimensions supported by this output sub-unit for measurements taken parallel relative to the feed direction associated with that sub-unit in output sub-unit dimensional units (controlled by prtOutputDimUnit, which uses PrtMediaUnitTC). If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed with management protocol operations. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification and to explain the purpose of (-1) and (-2). read-write 1.3.6.1.2.1.43.9.2.1.18 current The minimum dimensions supported by this output sub-unit for measurements taken ninety degrees relative to the feed direction associated with that sub-unit in output sub-unit dimensional units (controlled by prtOutputDimUnit, which uses PrtMediaUnitTC). If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed with management protocol operations. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification and to explain the purpose of (-1) and (-2). read-write 1.3.6.1.2.1.43.9.2.1.19 current The current state of the stacking order for the associated output sub-unit. 'FirstToLast' means that as pages are output the front of the next page is placed against the back of the previous page. 'LasttoFirst' means that as pages are output the back of the next page is placed against the front of the previous page. read-write 1.3.6.1.2.1.43.9.2.1.20 current The reading surface that will be 'up' when pages are delivered to the associated output sub-unit. Values are faceUp and faceDown. (Note: interpretation of these values is in general context-dependent based on locale; presentation of these values to an end-user should be normalized to the expectations of the user). read-write 1.3.6.1.2.1.43.9.2.1.21 current This object indicates that the outputting sub-unit supports bursting, and if so, whether the feature is enabled. Bursting is the process by which continuous media is separated into individual sheets, typically by bursting along pre-formed perforations. read-write 1.3.6.1.2.1.43.9.2.1.22 current This object indicates that the output supports decollating, and if so, whether the feature is enabled. Decollating is the process by which the individual parts within a multi-part form are separated and sorted into separate stacks for each part. read-write 1.3.6.1.2.1.43.9.2.1.23 current This object indicates that the output sub-unit supports page collation, and if so, whether the feature is enabled. See RFC 3805 Appendix A, Glossary Of Terms, for definition of how this document defines collation. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.9.2.1.24 current This object indicates that the output supports offset stacking,and if so, whether the feature is enabled. See RFC 3805 Appendix A, Glossary Of Terms, for how Offset Stacking is defined by this document. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.9.2.1.1 current A unique value used by this printer to identify this output sub-unit. Although these values may change due to a major reconfiguration of the sub-unit (e.g., the addition of new output devices to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.10.2.1.2 current The type of marking technology used for this marking sub-unit. read-only 1.3.6.1.2.1.43.10.2.1.3 current The unit that will be used by the printer when reporting counter values for this marking sub-unit. The time units of measure are provided for a device like a strip recorder that does not or cannot track the physical dimensions of the media and does not use characters, lines or sheets. read-only 1.3.6.1.2.1.43.10.2.1.4 current The count of the number of units of measure counted during the life of printer using units of measure as specified by prtMarkerCounterUnit. Note: This object should be implemented as a persistent object with a reliable value throughout the lifetime of the printer. read-only 1.3.6.1.2.1.43.10.2.1.5 current The count of the number of units of measure counted since the equipment was most recently powered on using units of measure as specified by prtMarkerCounterUnit. read-only 1.3.6.1.2.1.43.10.2.1.6 current The number of process colors supported by this marker. A process color of 1 implies monochrome. The value of this object and prtMarkerSpotColorants cannot both be 0. The value of prtMarkerProcessColorants must be 0 or greater. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.10.2.1.7 current The number of spot colors supported by this marker. The value of this object and prtMarkerProcessColorants cannot both be 0. Must be 0 or greater. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.10.2.1.8 current The unit of measure of distances, as applied to the marker's resolution. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.10.2.1.9 current The maximum number of addressable marking positions in the feed direction per 10000 units of measure specified by prtMarkerAddressabilityUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.10.2.1.10 current The maximum number of addressable marking positions in the cross feed direction in 10000 units of measure specified by prtMarkerAddressabilityUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.10.2.1.11 current The margin, in units identified by prtMarkerAddressabilityUnit, from the leading edge of the medium as the medium flows through the marking engine with the side to be imaged facing the observer. The leading edge is the North edge and the other edges are defined by the normal compass layout of directions with the compass facing the observer. Printing within the area bounded by all four margins is guaranteed for all interpreters. The value (-2) means unknown. read-only 1.3.6.1.2.1.43.10.2.1.12 current The margin from the South edge (see prtMarkerNorthMargin) of the medium in units identified by prtMarkerAddressabilityUnit. Printing within the area bounded by all four margins is guaranteed for all interpreters. The value (-2) means unknown. read-only 1.3.6.1.2.1.43.10.2.1.13 current The margin from the West edge (see prtMarkerNorthMargin) of the medium in units identified by prtMarkerAddressabilityUnit. Printing within the area bounded by all four margins is guaranteed for all interpreters. The value (-2) means unknown. read-only 1.3.6.1.2.1.43.10.2.1.14 current The margin from the East edge (see prtMarkerNorthMargin) of the medium in units identified by prtMarkerAddressabilityUnit. Printing within the area bounded by all four margins is guaranteed for all interpreters. The value (-2) means unknown. read-only 1.3.6.1.2.1.43.10.2.1.15 current The current status of this marker sub-unit. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.10.2.1.1 current A unique value used by the printer to identify this marking SubUnit. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new marking sub-units to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.11.1.1.2 current The value of prtMarkerIndex corresponding to the marking sub unit with which this marker supply sub-unit is associated. read-only 1.3.6.1.2.1.43.11.1.1.3 current The value of prtMarkerColorantIndex corresponding to the colorant with which this marker supply sub-unit is associated. This value shall be 0 if there is no colorant table or if this supply does not depend on a single specified colorant. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.11.1.1.4 current Indicates whether this supply entity represents a supply that is consumed or a receptacle that is filled. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.11.1.1.5 current The type of this supply. read-only 1.3.6.1.2.1.43.11.1.1.6 current The description of this supply container/receptacle in the localization specified by prtGeneralCurrentLocalization. read-only 1.3.6.1.2.1.43.11.1.1.7 current Unit of measure of this marker supply container/receptacle. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.11.1.1.8 current The maximum capacity of this supply container/receptacle expressed in prtMarkerSuppliesSupplyUnit. If this supply container/receptacle can reliably sense this value, the value is reported by the printer and is read-only; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. read-write 1.3.6.1.2.1.43.11.1.1.9 current The current level if this supply is a container; the remaining space if this supply is a receptacle. If this supply container/receptacle can reliably sense this value, the value is reported by the printer and is read-only; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. A value of (-3) means that the printer knows that there is some supply/remaining space, respectively. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.11.1.1.1 current A unique value used by the printer to identify this marker supply. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new marker supplies to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.12.1.1.2 current The value of prtMarkerIndex corresponding to the marker sub unit with which this colorant entry is associated. read-only 1.3.6.1.2.1.43.12.1.1.3 current The role played by this colorant. read-only 1.3.6.1.2.1.43.12.1.1.4 current The name of the color of this colorant using standardized string names from ISO 10175 (DPA) and ISO 10180 (SPDL) such as: other unknown white red green blue cyan magenta yellow black Implementers may add additional string values. The naming conventions in ISO 9070 are recommended in order to avoid potential name clashes read-only 1.3.6.1.2.1.43.12.1.1.5 current The distinct levels of tonality realizable by a marking sub unit when using this colorant. This value does not include the number of levels of tonal difference that an interpreter can obtain by techniques such as half toning. This value must be at least 2. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.12.1.1.1 current A unique value used by the printer to identify this colorant. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new colorants to the printer) , values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.13.4.1.2 current The unit of measure used in specifying the speed of all media paths in the printer. read-only 1.3.6.1.2.1.43.13.4.1.3 current The units of measure of media size for use in calculating and relaying dimensional values for all media paths in the printer. read-only 1.3.6.1.2.1.43.13.4.1.4 current The maximum printing speed of this media path expressed in prtMediaPathMaxSpeedUnit's. A value of (-1) implies 'other'. read-only 1.3.6.1.2.1.43.13.4.1.5 current The maximum physical media size in the feed direction of this media path expressed in units of measure specified by PrtMediaPathMediaSizeUnit. A value of (-1) implies 'unlimited' a value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.13.4.1.6 current The maximum physical media size across the feed direction of this media path expressed in units of measure specified by prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.13.4.1.7 current The minimum physical media size in the feed direction of this media path expressed in units of measure specified by prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.13.4.1.8 current The minimum physical media size across the feed direction of this media path expressed in units of measure specified by prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.13.4.1.9 current The type of the media path for this media path. read-only 1.3.6.1.2.1.43.13.4.1.10 current The manufacturer-provided description of this media path in the localization specified by prtGeneralCurrentLocalization. read-only 1.3.6.1.2.1.43.13.4.1.11 current The current status of this media path. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.13.4.1.1 current A unique value used by the printer to identify this media path. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new media paths to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.14.1.1.2 current The type of this print data channel. This object provides the linkage to ChannelType-specific groups that may (conceptually) extend the prtChannelTable with additional details about that channel. read-only 1.3.6.1.2.1.43.14.1.1.3 current The version of the protocol used on this channel. The format used for version numbering depends on prtChannelType. read-write 1.3.6.1.2.1.43.14.1.1.4 current The value of prtInterpreterIndex corresponding to the Control Language Interpreter for this channel. This interpreter defines the syntax used for control functions, such as querying or changing environment variables and identifying job boundaries (e.g., PJL, PostScript, NPAP). A value of zero indicates that there is no current Job Control Language Interpreter for this channel. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.14.1.1.5 current The value of prtInterpreterIndex corresponding to the Page Description Language Interpreter for this channel. This interpreter defines the default Page Description Language interpreter to be used for the print data unless the Control Language is used to select a specific interpreter (e.g., PCL, PostScript Language, auto-sense). A value of zero indicates that there is no default page description language interpreter for this channel. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.14.1.1.6 current The state of this print data channel. The value determines whether control information and print data is allowed through this channel or not. read-write 1.3.6.1.2.1.43.14.1.1.7 current The value of ifIndex in the ifTable; see the Interfaces Group MIB [RFC2863] which corresponds to this channel. When more than one row of the ifTable is relevant, this is the index of the row representing the topmost layer in the interface hierarchy. A value of zero indicates that no interface is associated with this channel. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.14.1.1.8 current The current status of the channel. read-only 1.3.6.1.2.1.43.14.1.1.9 current Auxiliary information to allow a printing application to use the channel for data submission to the printer. An application capable of using a specific PrtChannelType should be able to use the combined information from the prtChannelInformation and other channel and interface group objects to 'bootstrap' its use of the channel. prtChannelInformation is not intended to provide a general channel description, nor to provide information that is available once the channel is in use. The encoding and interpretation of the prtChannelInformation object is specific to channel type. The description of each PrtChannelType enum value for which prtChannelInformation is defined specifies the appropriate encoding and interpretation, including interaction with other objects. For channel types that do not specify a prtChannelInformation value, its value shall be null (0 length). When a new PrtChannelType enumeration value is registered, its accompanying description must specify the encoding and interpretation of the prtChannelInformation value for the channel type. prtChannelInformation semantics for an existing PrtChannelType may be added or amended in the same manner as described in section 2.4.1 for type 2 enumeration values. The prtChannelInformation specifies values for a collection of channel attributes, represented as text according to the following rules: 1. The prtChannelInformation is not affected by localization. 2. The prtChannelInformation is a list of entries representing the attribute values. Each entry consists of the following items, in order: a. A keyword, composed of alphabetic characters (A-Z, a-z) represented by their NVT ASCII [RFC854] codes, that identifies a channel attribute, b. The NVT ASCII code for an Equals Sign (=) (code 61) to delimit the keyword, c. A data value encoded using rules specific to the PrtChannelType to with the prtChannelInformation applies which must in no case allow an octet with value 10 (the NVT ASCII Line Feed code), d. the NVT ASCII code for a Line Feed character (code 10) to delimit the data value. No other octets shall be present. Keywords are case-sensitive. Conventionally, keywords are capitalized (including each word of a multi-word keyword) and since they occupy space in the prtChannelInformation, they are kept short. 3. If a channel attribute has multiple values, it is represented by multiple entries with the same keyword, each specifying one value. Otherwise, there shall be at most one entry for each attribute. 4. By default, entries may appear in any order. If there are ordering constraints for particular entries, these must be specified in their definitions. 5. The prtChannelInformation value by default consists of text represented by NVT ASCII graphics character codes. However, other representations may be specified: a. In cases where the prtChannelInformation value contains information not normally coded in textual form, whatever symbolic representation is conventionally used for the information should be used for encoding the prtChannelInformation value. (For instance, a binary port value might be represented as a decimal number using NVT ASCII codes.) Such encoding must be specified in the definition of the value. b. The value may contain textual information in a character set other than NVT ASCII graphics characters. (For instance, an identifier might consist of ISO 10646 text encoded using the UTF-8 encoding scheme.) Such a character set and its encoding must be specified in the definition of the value. 6. For each PrtChannelType for which prtChannelInformation entries are defined, the descriptive text associated with the PrtChannelType enumeration value shall specify the following information for each entry: Title: Brief description phrase, e.g.: 'Port name', 'Service Name', etc. Keyword: The keyword value, e.g.: 'Port' or 'Service' Syntax: The encoding of the entry value if it cannot be directly represented by NVT ASCII. Status: 'Mandatory', 'Optional', or 'Conditionally Mandatory' Multiplicity: 'Single' or 'Multiple' to indicate whether the entry may be present multiple times. Description: Description of the use of the entry, other information required to complete the definition (e.g.: ordering constraints, interactions between entries). Applications that interpret prtChannelInformation should ignore unrecognized entries, so they are not affected if new entry types are added. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.14.1.1.1 current A unique value used by the printer to identify this data channel. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new data channels to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.15.1.1.2 current The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.15.1.1.3 current The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language. read-only 1.3.6.1.2.1.43.15.1.1.4 current The date code or version of the language which this interpreter is interpreting or emulating. read-only 1.3.6.1.2.1.43.15.1.1.5 current A string to identify this interpreter in the localization specified by prtGeneralCurrentLocalization as opposed to the language which is being interpreted. It is anticipated that this string will allow manufacturers to unambiguously identify their interpreters. read-only 1.3.6.1.2.1.43.15.1.1.6 current The date code, version number, or other product specific information tied to this interpreter. This value is associated with the interpreter, rather than with the version of the language which is being interpreted or emulated. read-write 1.3.6.1.2.1.43.15.1.1.7 current The current orientation default for this interpreter. This value may be overridden for a particular job (e.g., by a command in the input data stream). read-only 1.3.6.1.2.1.43.15.1.1.8 current The maximum interpreter addressability in the feed direction in 10000 prtMarkerAddressabilityUnits (as specified by prtMarkerDefaultIndex) for this interpreter. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.15.1.1.9 current The maximum interpreter addressability in the cross feed direction in 10000 prtMarkerAddressabilityUnits (as specified by prtMarkerDefaultIndex) for this interpreter. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.15.1.1.10 current The default coded character set for input octets encountered outside a context in which the Page Description Language established the interpretation of the octets. (Input octets are presented to the interpreter through a path defined in the channel group.) read-write 1.3.6.1.2.1.43.15.1.1.11 current The default character set for data coming from this interpreter through the printer's output channel (i.e. the 'backchannel'). read-only 1.3.6.1.2.1.43.15.1.1.12 current Indicates whether or not this interpreter returns information back to the host. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.15.1.1.1 current A unique value for each PDL or control language for which there exists an interpreter or emulator in the printer. The value is used to identify this interpreter. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new interpreters to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.16.5.1.2 current The content of a line in the logical display buffer of the operator's console of the printer. When a write operation occurs, normally a critical message, to one of the LineText strings, the agent should make that line displayable if a physical display is present. Writing a zero length string clears the line. It is an implementation- specific matter as to whether the agent allows a line to be overwritten before it has been cleared. Printer generated strings shall be in the localization specified by prtConsoleLocalization.Management Application generated strings should be localized by the Management Application. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.16.5.1.1 current A unique value for each console line in the printer. The value is used to identify this console line. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new console lines to the printer). Values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.17.6.1.2 current This object, in conjunction with prtConsoleOffTime, defines the current status of the light. If both prtConsoleOnTime and prtConsoleOffTime are non-zero, the lamp is blinking and the values presented define the on time and off time, respectively, in milliseconds. If prtConsoleOnTime is zero and prtConsoleOffTime is non-zero, the lamp is off. If prtConsoleOffTime is zero and prtConsoleOnTime is non-zero, the lamp is on. If both values are zero the lamp is off. NOTE: The above description has been modified from RFC 1759 for clarification. read-write 1.3.6.1.2.1.43.17.6.1.3 current This object, in conjunction with prtConsoleOnTime, defines the current status of the light. If both prtConsoleOnTime and prtConsoleOffTime are non-zero, the lamp is blinking and the values presented define the on time and off time, respectively, in milliseconds. If prtConsoleOnTime is zero and prtConsoleOffTime is non-zero, the lamp is off. If prtConsoleOffTime is zero and prtConsoleOnTime is non-zero, the lamp is on. If both values are zero the lamp is off. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.17.6.1.4 current The color of this light. read-only 1.3.6.1.2.1.43.17.6.1.5 current The vendor description or label of this light in the localization specified by prtConsoleLocalization. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. not-accessible 1.3.6.1.2.1.43.17.6.1.1 current A unique value used by the printer to identify this light. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new lights to the printer). Values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.18.1.1.2 current The level of severity of this alert table entry. The printer determines the severity level assigned to each entry into the table. read-only 1.3.6.1.2.1.43.18.1.1.3 current See TEXTUAL-CONVENTION PrtAlertTrainingLevelTC. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.18.1.1.4 current The type of sub-unit within the printer model that this alert is related. Input, output, and markers are examples of printer model groups, i.e., examples of types of sub-units. Wherever possible, these enumerations match the sub-identifier that identifies the relevant table in the printmib. read-only 1.3.6.1.2.1.43.18.1.1.5 current The low-order index of the row within the table identified by prtAlertGroup that represents the sub-unit of the printer that caused this alert, or -1 if not applicable. The combination of the prtAlertGroup and the prtAlertGroupIndex defines exactly which printer sub-unit caused the alert; for example, Input #3, Output#2, and Marker #1. Every object in this MIB is indexed with hrDeviceIndex and optionally, another index variable. If this other index variable is present in the table that generated the alert, it will be used as the value for this object. Otherwise, this value shall be -1. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.18.1.1.6 current The sub-unit location that is defined by the printer manufacturer to further refine the location of this alert within the designated sub-unit. The location is used in conjunction with the Group and GroupIndex values; for example, there is an alert in Input #2 at location number 7. The value (-2) indicates unknown. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.18.1.1.7 current See associated TEXTUAL-CONVENTION PrtAlertCodeTC. NOTE: The above description has been modified from RFC 1759 for clarification. read-only 1.3.6.1.2.1.43.18.1.1.8 current A description of this alert entry in the localization specified by prtGeneralCurrentLocalization. The description is provided by the printer to further elaborate on the enumerated alert or provide information in the case where the code is classified as 'other' or 'unknown'. The printer is required to return a description string but the string may be a null string. read-only 1.3.6.1.2.1.43.18.1.1.9 current The value of sysUpTime at the time that this alert was generated. read-only 1.3.6.1.2.1.25.3.2.1.1 current A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization. read-only 1.3.6.1.2.1.43.18.1.1.1 current The index value used to determine which alerts have been added or removed from the alert table. This is an incrementing integer initialized to 1 when the printer is reset. (i.e., The first event placed in the alert table after a reset of the printer shall have an index value of 1.) When the printer adds an alert to the table, that alert is assigned the next higher integer value from the last item entered into the table. If the index value reaches its maximum value, the next index value used must be 1. NOTE: The management application will read the alert table when a trap or event notification occurs or at a periodic rate and then parse the table to determine if any new entries were added by comparing the last known index value with the current highest index value. The management application will then update its copy of the alert table. When the printer discovers that an alert is no longer active, the printer shall remove the row for that alert from the table and shall reduce the number of rows in the table. The printer may add or delete any number of rows from the table at any time. The management station can detect when binary change alerts have been deleted by requesting an attribute of each alert, and noting alerts as deleted when that retrieval is not possible. The objects 'prtAlertCriticalEvents'and 'prtAlertAllEvents' in the 'prtGeneralTable' reduce the need for management applications to scan the 'prtAlertTable'. NOTE: The above description has been modified from RFC 1759 for clarification. Units of measure for media dimensions. 3 4 Units of measure for media dimensions. 3 4 Units of measure for media capacity. 1 2 3 4 8 16 17 18 19 Units of measure for media capacity. 3 4 8 16 17 A generic representation for printing orientation on a 'page'. 1 3 4 Status of a printer sub-unit. The SubUnitStatus is an integer that is the sum of 5 distinct values, Availability, Non-Critical, Critical, On-line, and Transitioning. These values are: Availability Value Available and Idle 0 0000'b Available and Standby 2 0010'b Available and Active 4 0100'b Available and Busy 6 0110'b Unavailable and OnRequest 1 0001'b Unavailable because Broken 3 0011'b Unknown 5 0101'b Non-Critical No Non-Critical Alerts 0 0000'b Non-Critical Alerts 8 1000'b Critical No Critical Alerts 0 0000'b Critical Alerts 16 1 0000'b On-Line State is On-Line 0 0000'b State is Off-Line 32 10 0000'b Transitioning At intended state 0 0000'b Transitioning to intended state 64 100 0000'b Status of a printer sub-unit. The SubUnitStatus is an integer that is the sum of 5 distinct values, Availability, Non-Critical, Critical, On-line, and Transitioning. These values are: Availability Value Available and Idle 0 0000'b Available and Standby 2 0010'b Available and Active 4 0100'b Available and Busy 6 0110'b Unavailable and OnRequest 1 0001'b Unavailable because Broken 3 0011'b Unknown 5 0101'b Non-Critical No Non-Critical Alerts 0 0000'b Non-Critical Alerts 8 1000'b Critical No Critical Alerts 0 0000'b Critical Alerts 16 1 0000'b On-Line State is On-Line 0 0000'b State is Off-Line 32 10 0000'b Transitioning At intended state 0 0000'b Transitioning to intended state 64 100 0000'b Presence and configuration of a device or feature. 1 3 4 5 An object MUST use this TEXTUAL-CONVENTION when its 'charset' is controlled by the value of prtGeneralCurrentLocalization. An object MUST use this TEXTUAL-CONVENTION when its 'charset' is controlled by the value of prtConsoleLocalization. The original description clause from RFC 1759 [RFC1759] was technically inaccurate and therefore has been deleted. 1 The state of this print job delivery channel. The value determines whether print data is allowed through this channel. 1 3 4 The current state of the stacking order for the associated output sub-unit. 'firstToLast' means that as pages are output, the front of the next page is placed against the back of the previous page. 'lastToFirst' means that as pages are output, the back of the next page is placed against the front of the previous page. 2 3 4 The reading surface that will be 'up' when pages are delivered to the associated output sub-unit. Values are Face-Up and Face Down (Note: interpretation of these values is, in general, context-dependent based on locale; presentation of these values to an end-user should be normalized to the expectations of the user. 3 4 The unit that will be used by the printer when reporting counter values for this marking sub-unit. The time units of measure are provided for a device like a strip recorder that does not or cannot track the physical dimensions of the media and does not use characters, lines or sheets. 3 4 5 6 7 8 9 11 16 17 Unit of this marker supply container/receptacle. 1 2 3 4 7 8 11 12 13 14 15 16 17 18 19 Indicates whether this supply entity represents a supply that is consumed or a receptacle that is filled. 1 3 4 The role played by this colorant. 1 3 4 The unit of measure of distances, as applied to the marker's resolution. 3 4 The unit of measure used in specifying the speed of all media paths in the printer. 3 4 5 6 7 8 9 16 17 Indicates whether or not this interpreter returns information back to the host. 3 4 The level of severity of this alert table entry. The printer determines the severity level assigned to each entry in the table. A critical alert is binary by nature and definition. A warning is defined to be a non-critical alert. The original and most common warning is unary. The binary warning was added later and given a more distinguished name. 1 3 4 5 --k1lZvvs/B4yU6o8G-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 15:21:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHXc-0000jP-AU for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 15:21:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBHXa-0004Oa-M9 for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 15:21:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBHQm-0008E9-Tr for netconf-data@psg.com; Mon, 20 Feb 2006 20:14:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBHQl-0008Dv-K2 for netconf@ops.ietf.org; Mon, 20 Feb 2006 20:14:47 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1KKEhL02587 for ; Mon, 20 Feb 2006 15:14:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capabilities] SMIv2 to XML Schema conversions Date: Mon, 20 Feb 2006 15:14:42 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B406FCD185@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capabilities] SMIv2 to XML Schema conversions Thread-Index: AcY2QdIupQENpwfcSbOQ/PTwkgg8XwAGEm/w From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 hi Information on the Netconf Modeling list can be found at http://standards.nortel.com/netconf/index.html Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of McDonald, Ira Sent: Monday, February 20, 2006 12:12 PM To: 'j.schoenwaelder@iu-bremen.de'; McDonald, Ira Cc: netconf@ops.ietf.org Subject: RE: [Capabilities] SMIv2 to XML Schema conversions Hi Juergen, I hadn't realized that there _was_ a netconf model list. =20 NetConf and IETF Languge Tag Registration Updates are=20 accounting for 80 messages a day that I mostly try to read. The link you sent below appears to be broken (I can't use a command line FTP or a web browser to that site). The translations of the two modules in Printer MIB v2=20 (RFC 3805) from my tool are permanently posted at: ftp://ftp.pwg.org/pub/pwg/wims/schemas/rfc3805a-20040805.xsd - IANA-PRINTER-MIB (textual conventions registry) ftp://ftp.pwg.org/pub/pwg/wims/schemas/rfc3805b-20040805.xsd - Printer-MIB If you send me your translation as an attachment, I'll try to find time to look at it and compare. I'm very busy just now, so it may take a little while. And since you make smidump available and you're the expert, it's probably the right choice for others to use. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Monday, February 20, 2006 2:37 AM > To: McDonald, Ira > Cc: netconf@ops.ietf.org > Subject: Re: [Capabilities] SMIv2 to XML Schema conversions >=20 >=20 > On Sun, Feb 19, 2006 at 10:41:31AM -0800, McDonald, Ira wrote: >=20 > > Sorry, I'm not familiar with 'smidump', so I don't know the answer. > > No doubt people should probably just use 'smidump'. >=20 > While you can download smidump and see what it generates and how the=20 > XSD differs from what your tool generates, I can't do the same with=20 > your tool. >=20 > Since you are familiar with the Printer-MIB, I have put the output of=20 > 'smidump -f xsd' online: >=20 > ftp://ftp.eecs.iu-bremen.de/netconf/Printer-MIB.xsd >=20 > I would be curious to know what you did differently, but perhaps this=20 > is getting off-topic for this mailing list and we should either move=20 > that discussion to the netconfmodel list or yet somewhere else. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Feb 20 17:25:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBJTC-0006vm-1a for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 17:25:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBJTA-0008Ge-Eo for netconf-archive@lists.ietf.org; Mon, 20 Feb 2006 17:25:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBJNj-000Gjl-25 for netconf-data@psg.com; Mon, 20 Feb 2006 22:19:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBJNh-000GjZ-QD for netconf@ops.ietf.org; Mon, 20 Feb 2006 22:19:45 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k1KMJamv028346; Mon, 20 Feb 2006 14:19:40 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BYB256>; Mon, 20 Feb 2006 14:19:37 -0800 Message-ID: From: "McDonald, Ira" To: "'Sharon Chisholm'" , netconf@ops.ietf.org Subject: RE: [Capabilities] SMIv2 to XML Schema conversions Date: Mon, 20 Feb 2006 14:19:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Hi Sharon, Thanks - I just subscribed to the NetConf Model list. Not sure I'll have much to contribute. NetConf seems heavily focused on network infrastructure (routers, etc.). And I've been singularly unsuccessful in convincing printer vendors that NetConf is interesting for printers (and perhaps it's not supposed to be??). The printing industry is now largely focused on aligning the DMTF CIM model with the last twelve years of printing standards, on the assumption that Oasis WSDM and DMTF WS-Management will eventually use some future remapping of the CIM model into WS-Resource/RDF frameworks. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Sharon Chisholm > Sent: Monday, February 20, 2006 3:15 PM > To: netconf@ops.ietf.org > Subject: RE: [Capabilities] SMIv2 to XML Schema conversions > > > hi > > Information on the Netconf Modeling list can be found at > http://standards.nortel.com/netconf/index.html > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On > Behalf Of McDonald, Ira > Sent: Monday, February 20, 2006 12:12 PM > To: 'j.schoenwaelder@iu-bremen.de'; McDonald, Ira > Cc: netconf@ops.ietf.org > Subject: RE: [Capabilities] SMIv2 to XML Schema conversions > > > Hi Juergen, > > I hadn't realized that there _was_ a netconf model list. > NetConf and IETF Languge Tag Registration Updates are > accounting for 80 messages a day that I mostly try to read. > > The link you sent below appears to be broken (I can't > use a command line FTP or a web browser to that site). > > The translations of the two modules in Printer MIB v2 > (RFC 3805) from my tool are permanently posted at: > > ftp://ftp.pwg.org/pub/pwg/wims/schemas/rfc3805a-20040805.xsd > - IANA-PRINTER-MIB (textual conventions registry) > > ftp://ftp.pwg.org/pub/pwg/wims/schemas/rfc3805b-20040805.xsd > - Printer-MIB > > If you send me your translation as an attachment, I'll try > to find time to look at it and compare. I'm very busy just now, so it > may take a little while. > > And since you make smidump available and you're the expert, it's > probably the right choice for others to use. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > Sent: Monday, February 20, 2006 2:37 AM > > To: McDonald, Ira > > Cc: netconf@ops.ietf.org > > Subject: Re: [Capabilities] SMIv2 to XML Schema conversions > > > > > > On Sun, Feb 19, 2006 at 10:41:31AM -0800, McDonald, Ira wrote: > > > > > Sorry, I'm not familiar with 'smidump', so I don't know > the answer. > > > > No doubt people should probably just use 'smidump'. > > > > While you can download smidump and see what it generates > and how the > > XSD differs from what your tool generates, I can't do the same with > > your tool. > > > > Since you are familiar with the Printer-MIB, I have put the > output of > > 'smidump -f xsd' online: > > > > ftp://ftp.eecs.iu-bremen.de/netconf/Printer-MIB.xsd > > > > I would be curious to know what you did differently, but > perhaps this > > is getting off-topic for this mailing list and we should > either move > > that discussion to the netconfmodel list or yet somewhere else. > > > > /js > > > > -- > > Juergen Schoenwaelder International > University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 21 09:54:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBYu1-0001yo-89 for netconf-archive@lists.ietf.org; Tue, 21 Feb 2006 09:54:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBYu0-0005Oh-Ri for netconf-archive@lists.ietf.org; Tue, 21 Feb 2006 09:54:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBYjt-000LT8-17 for netconf-data@psg.com; Tue, 21 Feb 2006 14:43:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBYjs-000LSg-5f for netconf@ops.ietf.org; Tue, 21 Feb 2006 14:43:40 +0000 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id k1K6uf43029503; Sun, 19 Feb 2006 22:57:40 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k1K68f1l005906; Sun, 19 Feb 2006 22:08:41 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k1K68emj005898; Sun, 19 Feb 2006 22:08:40 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 19 Feb 2006 22:08:40 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Andy Bierman cc: Cridlig Vincent , "Netconf (E-mail)" Subject: Re: Capabilities and MIBs In-Reply-To: <43F8D5C9.5010601@andybierman.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c HI, I'm cutting most of your response, and responding to a single part. On Sun, 19 Feb 2006, Andy Bierman wrote: > Cridlig Vincent wrote: > >> I propose the following conventions (for comment, write-up TBD): > >> > >> 1) Agents SHOULD the advertise data model modules they support > >> Managers MAY advertise modules (but why?) > > > > I agree. I don't find any use case where it will be useful for a > > manager to advertise its supported data models. > > > > No -- the WG discussed this in detail at an interim meeting. > The thinking was "is there a way the agent can save resources > by knowing which data model modules the manager cared about?". > This idea was quickly tossed because manager functionality > might be dynamically extensible and the list of supported modules > might keep changing. It might be a really big list too. Plus, > why do you need to tell an Acme agent about all the proprietary > data models from other vendors you support? > > Still, an agent must be able to at least ignore such capabilities > in the from the manager. (Not that hard ;-) > > Andy I agree that "at connect time", that it is only needed that the managed system provide to the manager its capabilities to determine if "useful" work can be done. That is, a manager does not need to tell the managed system what it needs to be supported (unless the managed system does not want to reveal, but that is a different issue.) However, I have always thought that it was a "good thing to do" to describe the capabilities needed by a management application. For example, for the management app to perform function X, the managed system must have at least capability Y. This assumes that a management app is developed first, and vendors supply managed systems with enough capabilities to be managed by the management app. Experience has shown that vendors just field products with what they believe is needed, and management apps are written later using what ever is provided by the managed system. That is, the development of management apps ALWAYS lags (and most times, by a great amount) the development of a managed system. Maybe it will be different this time around. However, I doubt it. Regards, /david t. perkins -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 21 13:54:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcei-00033D-BA for netconf-archive@lists.ietf.org; Tue, 21 Feb 2006 13:54:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBceh-0001LM-W1 for netconf-archive@lists.ietf.org; Tue, 21 Feb 2006 13:54:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcXl-000FHQ-Qs for netconf-data@psg.com; Tue, 21 Feb 2006 18:47:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcXk-000FHB-HI for netconf@ops.ietf.org; Tue, 21 Feb 2006 18:47:25 +0000 Received: (qmail 4478 invoked from network); 21 Feb 2006 18:44:06 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 21 Feb 2006 18:44:06 -0000 Message-ID: <43FB5F80.5010703@andybierman.com> Date: Tue, 21 Feb 2006 10:44:16 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: IETF 65 NETCONF WG agenda Content-Type: multipart/mixed; boundary="------------060405000100050109090903" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. --------------060405000100050109090903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI, Send comments or presentation requests to the WG mailing list. Andy --------------060405000100050109090903 Content-Type: text/plain; name="netconf_ietf65_agenda.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netconf_ietf65_agenda.txt" Network Configuration WG (netconf) IETF #65 March 20, 2006 : 0900 - 1130 =============================== Chairs: Simon Leinen Andy Bierman Agenda: - Status of Completed WG Documents (10 min) - NETCONF Configuration Protocol - Using the NETCONF Protocol over BEEP - Using the NETCONF Protocol over SOAP - Using the NETCONF Protocol over SSH - NETCONF Experimental Namespace and Extension Registry (15 min) - Discuss need/interest in an experimental "branch" for NETCONF protocol extensions. - NETCONF Implementation Guide (15 min) - Discuss need/interest in an Informational RFC to help NETCONF protocol developers produce interoperable implementations - NETCONF Event Notifications (90 min) - Discuss current Notifications draft - Identify areas of WG consensus (or lack thereof) - Identify all open issues - Open Discussion / Unchartered Items (20 min) - NETCONF Data Modeling - Access Control Model - ??? Internet Drafts: NETCONF Configuration Protocol http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-11.txt Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-08.txt Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-07.txt Using the NETCONF Configuration Protocol over Secure Shell (SSH) http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-05.txt NETCONF Event Notifications http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-00.txt --------------060405000100050109090903-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 08:55:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBuSR-00053f-Ms for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 08:55:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBuSP-00041B-8Z for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 08:55:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBuLn-000CNV-OQ for netconf-data@psg.com; Wed, 22 Feb 2006 13:48:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBuLm-000CNJ-Rn for netconf@ops.ietf.org; Wed, 22 Feb 2006 13:48:15 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 3A0CE2D; Wed, 22 Feb 2006 14:48:13 +0100 (CET) Date: Wed, 22 Feb 2006 14:48:05 +0100 (CET) Message-Id: <20060222.144805.35010291.mbj@tail-f.com> To: ietf@andybierman.com Cc: phil@juniper.net, netconf@ops.ietf.org Subject: Re: url clarification From: Martin Bjorklund In-Reply-To: <43F9E8B1.5090604@andybierman.com> References: <43F9E14A.5070703@andybierman.com> <20060220.165410.44984206.mbj@tail-f.com> <43F9E8B1.5090604@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi, Andy Bierman wrote: > Martin Bjorklund wrote: > > > > It says (8.8.5.1) that must be accepted as an alternative to > > , i.e. as the "source" of the edit-config command. And it > > must be a local file (for some reason). The parameter cannot > > be an url. > > > > > > oops -- you're right. > > So the text is right and the XSD is wrong. > The "rpcOperationTargetType" needs to be changed > to "configNameType" for edit-config, lock, and unlock. > End of problem. I still think that allowing a url as "source" to is a problem, or at least quite limited. If it has to be a local file (as it is now), this file must be created somehow. D.1.2 shows an example where the file is created by doing a to the file. Then in D.1.5 the file is used in . This is a "type-mismatch" problem. The parameter of is a "complete configuration datastore", but the parameter of is not - it's "all or part" of a configuration. So maybe copy-config to a file is just a dumb verbatim copy? Then in D.1.3, the incoming file (the "all or part" of a configuration), is validated. Is this supposed to work? I.e. is validate really supposed to validate anything that can be sent to ? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 09:18:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBupU-0006hb-4M for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 09:18:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBupS-0005as-Rp for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 09:18:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBuid-000E2W-O8 for netconf-data@psg.com; Wed, 22 Feb 2006 14:11:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBuid-000E2K-3B for netconf@ops.ietf.org; Wed, 22 Feb 2006 14:11:51 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1MEBfX44819; Wed, 22 Feb 2006 06:11:42 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1MEBa518989; Wed, 22 Feb 2006 06:11:36 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k1MEGpYE096163; Wed, 22 Feb 2006 09:16:51 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200602221416.k1MEGpYE096163@idle.juniper.net> To: Martin Bjorklund cc: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: url clarification In-Reply-To: Your message of "Wed, 22 Feb 2006 14:48:05 +0100." <20060222.144805.35010291.mbj@tail-f.com> Date: Wed, 22 Feb 2006 09:16:51 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Martin Bjorklund writes: >So maybe copy-config to a file is just a dumb verbatim copy? That was the original intention. >Then in D.1.3, the incoming file (the "all or part" of a >configuration), is validated. Is this supposed to work? I.e. is >validate really supposed to validate anything that can be sent to >? I think we're probably a little loose on this point, since validate really needs a complete config, but edit-config does not. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 09:41:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvAy-0007eh-42 for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 09:41:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBvAx-0006RS-NG for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 09:41:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBv6B-000GG9-92 for netconf-data@psg.com; Wed, 22 Feb 2006 14:36:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBv69-000GFm-Pn for netconf@ops.ietf.org; Wed, 22 Feb 2006 14:36:09 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 984184F000D for ; Wed, 22 Feb 2006 15:36:08 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Feb 2006 15:36:08 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Feb 2006 15:36:08 +0100 Message-ID: <43FC76D7.2010603@ericsson.com> Date: Wed, 22 Feb 2006 15:36:07 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: url clarification - validate inline config References: <200602221416.k1MEGpYE096163@idle.juniper.net> In-Reply-To: <200602221416.k1MEGpYE096163@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 14:36:08.0080 (UTC) FILETIME=[5168B100:01C637BD] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hello, Let me quote a recent letter from Andy. He clearly states that validation of inline configuration is allowed. Andy Bierman wrote: > Balazs Lengyel wrote: > > Hello, > > - The validate operation might contain inline config as well as I > > understand the XSD. In the text only datastore name is mentioned. > > Which is correct ? > > inline also -- this bug was already found > Also the netconf-11 draft was changed to include inline validation. 8.6.4.1. source: Name of the configuration datastore being validated, such as or the element containing the configuration subtree to validate. We intend to use this capability. Balazs Phil Shafer wrote: >> Then in D.1.3, the incoming file (the "all or part" of a >> configuration), is validated. Is this supposed to work? I.e. is >> validate really supposed to validate anything that can be sent to >> ? > > I think we're probably a little loose on this point, since > validate really needs a complete config, but edit-config > does not. > > Thanks, > Phil > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 09:48:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvHb-00081a-Vz for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 09:47:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBvHa-0006iT-JJ for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 09:47:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBvCI-000GoT-L8 for netconf-data@psg.com; Wed, 22 Feb 2006 14:42:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBvCH-000GoF-SS for netconf@ops.ietf.org; Wed, 22 Feb 2006 14:42:30 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D8D148B4 for ; Wed, 22 Feb 2006 15:42:28 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Feb 2006 15:42:28 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Feb 2006 15:42:28 +0100 Message-ID: <43FC7853.5040309@ericsson.com> Date: Wed, 22 Feb 2006 15:42:27 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: url clarification References: <200602221416.k1MEGpYE096163@idle.juniper.net> In-Reply-To: <200602221416.k1MEGpYE096163@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 14:42:28.0297 (UTC) FILETIME=[34093390:01C637BE] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 I believe that copy to a file (copy running -> external-URL) would be a very useful function. It could be used to backup a complete configuration to an external location (or internal). The same way (copy external-URL -> running) would be very useful for reloading a previous backup. Balazs Phil Shafer wrote: > Martin Bjorklund writes: >> So maybe copy-config to a file is just a dumb verbatim copy? > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 10:05:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvY6-0000Tk-02 for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 10:05:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBvY4-0007QS-JZ for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 10:05:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBvTO-000I6S-Nc for netconf-data@psg.com; Wed, 22 Feb 2006 15:00:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBvTN-000I6H-Vw for netconf@ops.ietf.org; Wed, 22 Feb 2006 15:00:10 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 18EAE2D; Wed, 22 Feb 2006 16:00:09 +0100 (CET) Date: Wed, 22 Feb 2006 16:00:01 +0100 (CET) Message-Id: <20060222.160001.34763682.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netconf@ops.ietf.org Subject: Re: url clarification From: Martin Bjorklund In-Reply-To: <43FC7853.5040309@ericsson.com> References: <200602221416.k1MEGpYE096163@idle.juniper.net> <43FC7853.5040309@ericsson.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Balazs Lengyel wrote: > I believe that copy to a file (copy running -> external-URL) would > be a very useful function. This is supported in the protocol. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 12:50:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBy86-0004y0-Jo for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 12:50:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBy85-0006CK-8g for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 12:50:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBy3I-00051Q-Oo for netconf-data@psg.com; Wed, 22 Feb 2006 17:45:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBy3H-00051B-Kt for netconf@ops.ietf.org; Wed, 22 Feb 2006 17:45:24 +0000 Received: (qmail 16865 invoked from network); 22 Feb 2006 17:38:59 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 22 Feb 2006 17:38:59 -0000 Message-ID: <43FCA1B1.9040708@andybierman.com> Date: Wed, 22 Feb 2006 09:38:57 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, netconf@ops.ietf.org, Rob Enns Subject: Re: url clarification References: <43F9E14A.5070703@andybierman.com> <20060220.165410.44984206.mbj@tail-f.com> <43F9E8B1.5090604@andybierman.com> <20060222.144805.35010291.mbj@tail-f.com> In-Reply-To: <20060222.144805.35010291.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Martin Bjorklund wrote: > Hi, > > > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>> It says (8.8.5.1) that must be accepted as an alternative to >>> , i.e. as the "source" of the edit-config command. And it >>> must be a local file (for some reason). The parameter cannot >>> be an url. >>> >>> >>> >> oops -- you're right. >> >> So the text is right and the XSD is wrong. >> The "rpcOperationTargetType" needs to be changed >> to "configNameType" for edit-config, lock, and unlock. >> End of problem. >> > > I still think that allowing a url as "source" to is a > problem, or at least quite limited. If it has to be a local file (as > it is now), this file must be created somehow. D.1.2 shows an example > where the file is created by doing a to the file. Then > in D.1.5 the file is used in . This is a "type-mismatch" > problem. The parameter of is a "complete > configuration datastore", but the parameter of > is not - it's "all or part" of a configuration. > I disagree. This is in there by design to support configuration servers. For example: none test-then-set rollback-on-error https://example.com/config/myConfig.xml *Note to Rob!!* There is a bug in the example at the top of page 92 in prot-11. It shows being used the way it is in every other parameter, as a child node instead of a replacement node. https://example.com/config/myConfig.xml > So maybe copy-config to a file is just a dumb verbatim copy? > > Yes and No -- it depends on the URL scheme and the data models involved. I don't think the spec needs to get too detailed here. There is already plenty of documentation on URL schemes. > Then in D.1.3, the incoming file (the "all or part" of a > configuration), is validated. Is this supposed to work? I.e. is > validate really supposed to validate anything that can be sent to > ? > Yes -- the element just provides the config source and the validate (via edit-config test-then-set) happens after the config input is received. > > /martin > > > > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 13:26:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FByhW-0006G5-KX for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 13:26:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FByhV-0007mu-39 for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 13:26:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FByc4-0007tJ-Ks for netconf-data@psg.com; Wed, 22 Feb 2006 18:21:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FByc3-0007t0-Db for netconf@ops.ietf.org; Wed, 22 Feb 2006 18:21:19 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 427792D; Wed, 22 Feb 2006 19:21:18 +0100 (CET) Date: Wed, 22 Feb 2006 19:21:10 +0100 (CET) Message-Id: <20060222.192110.61268489.mbj@tail-f.com> To: ietf@andybierman.com Cc: phil@juniper.net, netconf@ops.ietf.org, rpe@juniper.net Subject: Re: url clarification From: Martin Bjorklund In-Reply-To: <43FCA1B1.9040708@andybierman.com> References: <43F9E8B1.5090604@andybierman.com> <20060222.144805.35010291.mbj@tail-f.com> <43FCA1B1.9040708@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > > > Andy Bierman wrote: > > > >> Martin Bjorklund wrote: > >> > >>> It says (8.8.5.1) that must be accepted as an alternative to > >>> , i.e. as the "source" of the edit-config command. And it > >>> must be a local file (for some reason). The parameter cannot > >>> be an url. > >>> > >>> > >>> > >> oops -- you're right. > >> > >> So the text is right and the XSD is wrong. > >> The "rpcOperationTargetType" needs to be changed > >> to "configNameType" for edit-config, lock, and unlock. > >> End of problem. > >> > > > > I still think that allowing a url as "source" to is a > > problem, or at least quite limited. If it has to be a local file (as > > it is now), this file must be created somehow. D.1.2 shows an example > > where the file is created by doing a to the file. Then > > in D.1.5 the file is used in . This is a "type-mismatch" > > problem. The parameter of is a "complete > > configuration datastore", but the parameter of > > is not - it's "all or part" of a configuration. > > > > I disagree. > This is in there by design to support configuration servers. > For example: > > > > none > test-then-set > rollback-on-error > https://example.com/config/myConfig.xml > I agree with you that this would be useful. But the text in 8.8.5.1 says that the url should specfiy a local file. Maybe that sentence just should be removed? I don't quite see the point of that restriction. > > So maybe copy-config to a file is just a dumb verbatim copy? > > > > Yes and No -- it depends on the URL scheme and the data models involved. When I wrote "copy-config to a file" I meant "copy-config to a local file as specified by an url with a 'file' scheme". > I don't think the spec needs to get too detailed here. There is already > plenty of documentation on URL schemes. I'm not saying that the draft should be changed, I'm just looking for clarification. However, the way the text is written for copy-config, this behaviour is not very obvious (from 7.3): Create or replace an entire configuration datastore with the contents of another complete configuration datastore. > > Then in D.1.3, the incoming file (the "all or part" of a > > configuration), is validated. Is this supposed to work? I.e. is > > validate really supposed to validate anything that can be sent to > > ? > > > > Yes -- the element just provides the config source > and the validate (via edit-config test-then-set) happens after > the config input is received. The example in D.1.3 uses the command, not edit-config test-then-set: file://incoming.conf Phil's reply was that needs a complete configuration. Are you saying that it doesn't? The text says "... the element containing the configuration subtree to validate." /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 15:37:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0jq-0002ri-Qt for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 15:37:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0jp-00063L-Dr for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 15:37:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC0e8-000Gbu-8p for netconf-data@psg.com; Wed, 22 Feb 2006 20:31:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC0e7-000Gbb-9h for netconf@ops.ietf.org; Wed, 22 Feb 2006 20:31:35 +0000 Received: (qmail 19338 invoked from network); 22 Feb 2006 20:31:25 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 22 Feb 2006 20:31:25 -0000 Message-ID: <43FCCA01.5040904@andybierman.com> Date: Wed, 22 Feb 2006 12:30:57 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, netconf@ops.ietf.org, rpe@juniper.net Subject: Re: url clarification References: <43F9E8B1.5090604@andybierman.com> <20060222.144805.35010291.mbj@tail-f.com> <43FCA1B1.9040708@andybierman.com> <20060222.192110.61268489.mbj@tail-f.com> In-Reply-To: <20060222.192110.61268489.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Martin Bjorklund wrote: > >.... >>> >>> >> I disagree. >> This is in there by design to support configuration servers. >> For example: >> >> >> >> none >> test-then-set >> rollback-on-error >> https://example.com/config/myConfig.xml >> >> > > I agree with you that this would be useful. But the text in 8.8.5.1 > says that the url should specfiy a local file. Maybe that sentence > just should be removed? I don't quite see the point of that > restriction. > To be picky, it says should instead of SHOULD. It really doesn't mean anything normative. It doesn't say you better hope nobody deletes the local or remote file before the edit-config is done either. (Since lock is disallowed, all you can do is hope ;-) > >>> So maybe copy-config to a file is just a dumb verbatim copy? >>> >>> >> Yes and No -- it depends on the URL scheme and the data models involved. >> > > When I wrote "copy-config to a file" I meant "copy-config to a local > file as specified by an url with a 'file' scheme". > > >> I don't think the spec needs to get too detailed here. There is already >> plenty of documentation on URL schemes. >> > > I'm not saying that the draft should be changed, I'm just looking for > clarification. However, the way the text is written for copy-config, > this behaviour is not very obvious (from 7.3): > > Create or replace an entire configuration datastore with the > contents of another complete configuration datastore. > This means "copy-config is a replace (not a merge) edit operation". > > >>> Then in D.1.3, the incoming file (the "all or part" of a >>> configuration), is validated. Is this supposed to work? I.e. is >>> validate really supposed to validate anything that can be sent to >>> ? >>> >>> >> Yes -- the element just provides the config source >> and the validate (via edit-config test-then-set) happens after >> the config input is received. >> > > The example in D.1.3 uses the command, not edit-config > test-then-set: > > > > file://incoming.conf > > > > Phil's reply was that needs a complete configuration. Are > you saying that it doesn't? The text says "... the element > containing the configuration subtree to validate." > I don't think the text says that anywhere. Certainly, the inline config XML does not have to be a complete configuration. I don't think we can really say much (in the prot spec) about the content derived from the URL dereference process. > > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 16:51:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1td-0004LU-AV for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 16:51:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1tb-0004oR-TC for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 16:51:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC1pG-000M3h-P5 for netconf-data@psg.com; Wed, 22 Feb 2006 21:47:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC1pF-000M36-N8 for netconf@ops.ietf.org; Wed, 22 Feb 2006 21:47:09 +0000 Received: (qmail 27694 invoked from network); 22 Feb 2006 21:47:08 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 22 Feb 2006 21:47:08 -0000 Message-ID: <43FCDBB5.1040405@andybierman.com> Date: Wed, 22 Feb 2006 13:46:29 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, netconf@ops.ietf.org, rpe@juniper.net Subject: Re: url clarification References: <43FCA1B1.9040708@andybierman.com> <20060222.192110.61268489.mbj@tail-f.com> <43FCCA01.5040904@andybierman.com> <20060222.222809.89656391.mbj@tail-f.com> In-Reply-To: <20060222.222809.89656391.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Martin Bjorklund wrote: > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>>> .... >>>> >>>>> >>>>> >>>>> >>>> I disagree. >>>> This is in there by design to support configuration servers. >>>> For example: >>>> >>>> >>>> >>>> none >>>> test-then-set >>>> rollback-on-error >>>> https://example.com/config/myConfig.xml >>>> >>>> >>>> >>> I agree with you that this would be useful. But the text in 8.8.5.1 >>> says that the url should specfiy a local file. Maybe that sentence >>> just should be removed? I don't quite see the point of that >>> restriction. >>> >>> >> To be picky, it says should instead of SHOULD. >> It really doesn't mean anything normative. >> > > Yes I noticed that. Ok, so the intention is that the url can be > remote in this case. This makes perfect sense to me. > > >>> Phil's reply was that needs a complete configuration. Are >>> you saying that it doesn't? The text says "... the element >>> containing the configuration subtree to validate." >>> >>> >> I don't think the text says that anywhere. >> > > I should have mentioned the reference, sorry, it's in 8.6.4.1. (My > point here was that the term "configuration subtree" can be > interpreted as a partial config.) > > >> Certainly, the inline config XML does not have to be a complete >> configuration. >> > > Ok. But then the validation doesn't give you much more than syntactic > checks. If you first validate a partial config and then try to apply > it with edit-config, the resulting configuration might be invalid. > It depends on the data model! In my models, there is a conceptual difference between parameter sets and mere complexTypes (unlike XSD BTW). A parameter set can be validated for referential integrity, but not external dependencies. This is more than syntax-check but less than full-config validate. BTW, it doesn't say anywhere in the spec that the agent guarantees the input that passed a will always work in a subsequent or . It is a best-effort feature. > So if you do on the candidate, it will validate the full > config. Yes > And on inline config will validate a partial > config (e.g. it must allow incomplete relations). Yes > Then the question > is what should on a local file do? Should it treat it as a > full config or partial? > IMO, it doesn't really matter where the input comes from. The agent can validate what it gets against what it has, the best it can. To repeat myself -- it doesn't really say anywhere in the spec that URL means MUST be a complete config file, or MUST be same or different format than the representation of the built-in configuration datastores. The feature is just supposed to be input redirection (in this case). > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 16:52:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1uM-0004Ne-V6 for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 16:52:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1uL-0004qa-Lt for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 16:52:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC1ql-000M8L-4x for netconf-data@psg.com; Wed, 22 Feb 2006 21:48:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC1qk-000M87-K8 for netconf@ops.ietf.org; Wed, 22 Feb 2006 21:48:42 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k1MLmdfu007130; Wed, 22 Feb 2006 13:48:39 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <12BYDSGZ>; Wed, 22 Feb 2006 13:48:39 -0800 Message-ID: From: "McDonald, Ira" To: "'Andy Bierman'" , Martin Bjorklund Cc: phil@juniper.net, netconf@ops.ietf.org, rpe@juniper.net Subject: RE: url clarification Date: Wed, 22 Feb 2006 13:48:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > > (snip) > > To be picky, it says should instead of SHOULD. > It really doesn't mean anything normative. > > It doesn't say you better hope nobody deletes the local or remote > file before the edit-config is done either. (Since lock is > disallowed, > all you can do is hope ;-) > To be picky, in IETF LTRU (Language Tag Registry Update) we were eventually strongly encouraged (by IESG members) to remove entirely the use of lowercase must or should as meaningless and confusing. This was done late in the process of working drafts and caused the discovery of a large number of dubious imperatives. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Feb 22 18:26:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1iH-0003D0-IA for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 16:39:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1dW-0003wu-79 for netconf-archive@lists.ietf.org; Wed, 22 Feb 2006 16:35:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC1X1-000KrV-5J for netconf-data@psg.com; Wed, 22 Feb 2006 21:28:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC1X0-000KrJ-7L for netconf@ops.ietf.org; Wed, 22 Feb 2006 21:28:18 +0000 Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 5940C35; Wed, 22 Feb 2006 22:28:17 +0100 (CET) Date: Wed, 22 Feb 2006 22:28:09 +0100 (CET) Message-Id: <20060222.222809.89656391.mbj@tail-f.com> To: ietf@andybierman.com Cc: phil@juniper.net, netconf@ops.ietf.org, rpe@juniper.net Subject: Re: url clarification From: Martin Bjorklund In-Reply-To: <43FCCA01.5040904@andybierman.com> References: <43FCA1B1.9040708@andybierman.com> <20060222.192110.61268489.mbj@tail-f.com> <43FCCA01.5040904@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Andy Bierman wrote: > Martin Bjorklund wrote: > > >.... > >>> > >>> > >> I disagree. > >> This is in there by design to support configuration servers. > >> For example: > >> > >> > >> > >> none > >> test-then-set > >> rollback-on-error > >> https://example.com/config/myConfig.xml > >> > >> > > > > I agree with you that this would be useful. But the text in 8.8.5.1 > > says that the url should specfiy a local file. Maybe that sentence > > just should be removed? I don't quite see the point of that > > restriction. > > > > To be picky, it says should instead of SHOULD. > It really doesn't mean anything normative. Yes I noticed that. Ok, so the intention is that the url can be remote in this case. This makes perfect sense to me. > > Phil's reply was that needs a complete configuration. Are > > you saying that it doesn't? The text says "... the element > > containing the configuration subtree to validate." > > > > I don't think the text says that anywhere. I should have mentioned the reference, sorry, it's in 8.6.4.1. (My point here was that the term "configuration subtree" can be interpreted as a partial config.) > Certainly, the inline config XML does not have to be a complete > configuration. Ok. But then the validation doesn't give you much more than syntactic checks. If you first validate a partial config and then try to apply it with edit-config, the resulting configuration might be invalid. So if you do on the candidate, it will validate the full config. And on inline config will validate a partial config (e.g. it must allow incomplete relations). Then the question is what should on a local file do? Should it treat it as a full config or partial? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Feb 24 08:24:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcw7-0007QR-37 for netconf-archive@lists.ietf.org; Fri, 24 Feb 2006 08:24:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCcw6-0002aa-Bg for netconf-archive@lists.ietf.org; Fri, 24 Feb 2006 08:24:43 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCcny-0001F2-6u for netconf-data@psg.com; Fri, 24 Feb 2006 13:16:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCcnw-0001Eh-HL for netconf@ops.ietf.org; Fri, 24 Feb 2006 13:16:16 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0E0735B8 for ; Fri, 24 Feb 2006 11:14:02 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 11:14:01 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 11:14:01 +0100 Message-ID: <43FEDC68.5040608@ericsson.com> Date: Fri, 24 Feb 2006 11:14:00 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: url clarification References: <43FCA1B1.9040708@andybierman.com> <20060222.192110.61268489.mbj@tail-f.com> <43FCCA01.5040904@andybierman.com> <20060222.222809.89656391.mbj@tail-f.com> <43FCDBB5.1040405@andybierman.com> In-Reply-To: <43FCDBB5.1040405@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 10:14:01.0713 (UTC) FILETIME=[08970610:01C6392B] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Hello Is it possible or allowed in Netconf to send in a partial config in a validate operation and ask the node to validate this subtree in the context of the current running configuration. That would be more then validating just the subtree as we could consider broader dependencies. I would like a validation saying that if I issue these changes will the running config still be valid ? It would be something like an edit-config operation wit h a test-option set to . Is there a standard way to do this ? (I could do a copy-config to candidate; then edit-config on candidate; then validate, but I am looking for a simpler solution without candidate config.) Balazs Andy Bierman wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >> >>> Martin Bjorklund wrote: >>> >>>>> .... >>>>> >>>>>> >>>>> I disagree. >>>>> This is in there by design to support configuration servers. >>>>> For example: >>>>> >>>>> >>>>> >>>>> none >>>>> test-then-set >>>>> rollback-on-error >>>>> https://example.com/config/myConfig.xml >>>>> >>>>> >>>> I agree with you that this would be useful. But the text in 8.8.5.1 >>>> says that the url should specfiy a local file. Maybe that sentence >>>> just should be removed? I don't quite see the point of that >>>> restriction. >>>> >>> To be picky, it says should instead of SHOULD. >>> It really doesn't mean anything normative. >>> >> >> Yes I noticed that. Ok, so the intention is that the url can be >> remote in this case. This makes perfect sense to me. >> >> >>>> Phil's reply was that needs a complete configuration. Are >>>> you saying that it doesn't? The text says "... the element >>>> containing the configuration subtree to validate." >>>> >>> I don't think the text says that anywhere. >>> >> >> I should have mentioned the reference, sorry, it's in 8.6.4.1. (My >> point here was that the term "configuration subtree" can be >> interpreted as a partial config.) >> >> >>> Certainly, the inline config XML does not have to be a complete >>> configuration. >>> >> >> Ok. But then the validation doesn't give you much more than syntactic >> checks. If you first validate a partial config and then try to apply >> it with edit-config, the resulting configuration might be invalid. >> > > It depends on the data model! > In my models, there is a conceptual difference between > parameter sets and mere complexTypes (unlike XSD BTW). > A parameter set can be validated for referential integrity, but > not external dependencies. > This is more than syntax-check but less than full-config validate. > > BTW, it doesn't say anywhere in the spec that the agent guarantees > the input that passed a will always work in a subsequent > or . It is a best-effort feature. > >> So if you do on the candidate, it will validate the full >> config. > > Yes > >> And on inline config will validate a partial >> config (e.g. it must allow incomplete relations). > > Yes > >> Then the question >> is what should on a local file do? Should it treat it as a >> full config or partial? >> > > IMO, it doesn't really matter where the input comes from. > The agent can validate what it gets against what it has, the best it can. > > To repeat myself -- it doesn't really say anywhere in the spec > that URL means MUST be a complete config file, or MUST be > same or different format than the representation of the built-in > configuration datastores. > > The feature is just supposed to be input redirection (in this case). > >> >> /martin >> > > Andy > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 28 04:24:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE15X-0002l8-7z for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 04:24:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE15U-00048X-PP for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 04:24:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE0vh-000CEq-Cl for netconf-data@psg.com; Tue, 28 Feb 2006 09:14:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE0vY-000CD9-Hb for netconf@ops.ietf.org; Tue, 28 Feb 2006 09:13:52 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1S9Dm5b018172; Tue, 28 Feb 2006 03:13:49 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Feb 2006 10:13:47 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550967C047@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rob Enns (E-mail)" Cc: "Netconf (E-mail)" Subject: FW: Evaluation: draft-ietf-netconf-prot-11.txt to Proposed Standa rd [I06-051127-0010] Date: Tue, 28 Feb 2006 10:13:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 The comments in the tracker are: Date and Time: 2006-02-28, 1:27:7 Version: 11 Commented by: Michelle Cotton State before Comment: IESG Evaluation State after Comment: IESG Evaluation Comment: IANA Follow-up comment. We understand the registration rules to have changed from First Come First Serve with Specification to IETF Standards Action. IANA has no further questions. But then Sam noted that we have some inconsistencies still. Bert -----Original Message----- From: iana-drafts@icann.org [mailto:iana-drafts@icann.org] Sent: Tuesday, February 28, 2006 07:33 To: iesg@ietf.org Subject: RE: Evaluation: draft-ietf-netconf-prot-11.txt to Proposed Standard [I06-051127-0010] IANA OK. Comments in tracker. IANA Actions - YES Michelle Cotton (on behalf of IANA) -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org] Sent: Thursday, February 23, 2006 11:58 AM To: Internet Engineering Steering Group Subject: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standard, draft-ietf-netconf-prot-11.txt to Proposed Standard -------- Evaluation for draft-ietf-netconf-ssh-05.txt, draft-ietf-netconf-prot-11.txt can be found at https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=1075 1&rfc_flag=0 Last Call to expire on: 2005-12-07 Please return the full line with your position. Yes No-Objection Discuss Abstain Brian Carpenter [ ] [ ] [ ] [ ] Bill Fenner [ ] [ ] [ ] [ ] Ted Hardie [ ] [ ] [ ] [ ] Sam Hartman [ ] [ ] [ ] [ ] Scott Hollenbeck [ ] [ ] [ ] [ ] Russ Housley [ ] [ ] [ ] [ ] David Kessens [ ] [ ] [ ] [ ] Allison Mankin [ ] [ ] [ ] [ ] Jon Peterson [ ] [ ] [ ] [ ] Mark Townsley [ ] [ ] [ ] [ ] Margaret Wasserman [ ] [ ] [ ] [ ] Bert Wijnen [ X ] [ ] [ ] [ ] Alex Zinin [ ] [ ] [ ] [ ] "Yes" or "No-Objection" positions from 2/3 of non-recused ADs, with no "Discuss" positions, are needed for approval. DISCUSSES AND COMMENTS: ====================== ^L ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, netconf mailing list <netconf@ops.ietf.org>, netconf chair <simon@switch.ch>, netconf chair <ietf@andybierman.com> Subject: Protocol Action: 'NETCONF Configuration Protocol' to Proposed Standard The IESG has approved the following documents: - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH) ' <draft-ietf-netconf-ssh-05.txt> as a Proposed Standard - 'NETCONF Configuration Protocol ' <draft-ietf-netconf-prot-11.txt> as a Proposed Standard These documents are products of the Network Configuration Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-11.txt Technical Summary NETCONF Configuration Protocol The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. Using the NETCONF Configuration Protocol over Secure Shell (SSH) This document describes a method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session as an SSH subsystem. Note: The WG could not decide on a single transport mapping for NETCONF, because different types of programmers want to use the protocol. Therefore, NETCONF defines three transport mappings: SSH, BEEP, and SOAP, where SSH is the mandatory-to-implement protocol. Working Group Summary The NETCONF Working Group has consensus to publish these documents as a Proposed Standard. Protocol Quality It is likely that there are several implementations of these documents in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. An interoperability event (just prior to Paris IETF) was held in which 4 implementations participated and feedback was considered in revisions of these documents. Bert Wijnen reviewed these documents for the IESG. Note to RFC Editor (Insert note to RFC Editor here) IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 28 04:24:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE15X-0002lK-G5 for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 04:24:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE15U-00048Y-Vr for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 04:24:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE0vf-000CEZ-39 for netconf-data@psg.com; Tue, 28 Feb 2006 09:13:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE0vd-000CEK-Vj for netconf@ops.ietf.org; Tue, 28 Feb 2006 09:13:58 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1S9Dmmc018174; Tue, 28 Feb 2006 03:13:49 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Feb 2006 10:13:47 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550967C048@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "IANA (E-mail)" Cc: "Margaret Wasserman (E-mail)" , "Netconf (E-mail)" Subject: FW: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011] Date: Tue, 28 Feb 2006 10:13:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 The question on IETF Last Call from IANA was: Date and Time: 2005-11-27, 17:16:49 Version: 05 Commented by: Michelle Cotton State before Comment: In Last Call State after Comment: In Last Call Comment: IANA Last Call Comments: Upon approval of this document the IANA will assign a TCP port number for NETCONF over SSH in the following registry: http://www.iana.org/assignments/port-numbers Which range should this port be assigned in? The IANA will also assign "netconf" as an SSH Service Name in the following registry: http://www.iana.org/assignments/ssh-parameters We still seem to not be clear on it. But maybe IANA/Michelle did not see the notes to RFC-Editor and IANA: In Section 7 IANA Considerations: OLD: IANA is requested to assign a TCP port number which will be the default port for NETCONF over SSH sessions as defined in this document. NEW: IANA is requested to assign a TCP port number which will be the default port for NETCONF over SSH sessions as defined in this document. IANA has assigned port for this purpose. [RFC Editor, please replace two instances of in Section 3 and one instance of in this section to the port number assigned by IANA.] Michelle, will that be sufficient? Bert -----Original Message----- From: iana-drafts@icann.org [mailto:iana-drafts@icann.org] Sent: Tuesday, February 28, 2006 07:18 To: iesg@ietf.org Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standard [I06-051127-0011] IANA NOT OK. Comments in tracker. IANA Actions - YES Question from Last Call has not yet been answered. Michelle Cotton (on behalf of IANA) -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org] Sent: Thursday, February 23, 2006 11:58 AM To: Internet Engineering Steering Group Subject: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standard, draft-ietf-netconf-prot-11.txt to Proposed Standard -------- Evaluation for draft-ietf-netconf-ssh-05.txt, draft-ietf-netconf-prot-11.txt can be found at https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=1075 1&rfc_flag=0 Last Call to expire on: 2005-12-07 Please return the full line with your position. Yes No-Objection Discuss Abstain Brian Carpenter [ ] [ ] [ ] [ ] Bill Fenner [ ] [ ] [ ] [ ] Ted Hardie [ ] [ ] [ ] [ ] Sam Hartman [ ] [ ] [ ] [ ] Scott Hollenbeck [ ] [ ] [ ] [ ] Russ Housley [ ] [ ] [ ] [ ] David Kessens [ ] [ ] [ ] [ ] Allison Mankin [ ] [ ] [ ] [ ] Jon Peterson [ ] [ ] [ ] [ ] Mark Townsley [ ] [ ] [ ] [ ] Margaret Wasserman [ ] [ ] [ ] [ ] Bert Wijnen [ X ] [ ] [ ] [ ] Alex Zinin [ ] [ ] [ ] [ ] "Yes" or "No-Objection" positions from 2/3 of non-recused ADs, with no "Discuss" positions, are needed for approval. DISCUSSES AND COMMENTS: ====================== ^L ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, netconf mailing list <netconf@ops.ietf.org>, netconf chair <simon@switch.ch>, netconf chair <ietf@andybierman.com> Subject: Protocol Action: 'NETCONF Configuration Protocol' to Proposed Standard The IESG has approved the following documents: - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH) ' <draft-ietf-netconf-ssh-05.txt> as a Proposed Standard - 'NETCONF Configuration Protocol ' <draft-ietf-netconf-prot-11.txt> as a Proposed Standard These documents are products of the Network Configuration Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-11.txt Technical Summary NETCONF Configuration Protocol The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. Using the NETCONF Configuration Protocol over Secure Shell (SSH) This document describes a method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session as an SSH subsystem. Note: The WG could not decide on a single transport mapping for NETCONF, because different types of programmers want to use the protocol. Therefore, NETCONF defines three transport mappings: SSH, BEEP, and SOAP, where SSH is the mandatory-to-implement protocol. Working Group Summary The NETCONF Working Group has consensus to publish these documents as a Proposed Standard. Protocol Quality It is likely that there are several implementations of these documents in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. An interoperability event (just prior to Paris IETF) was held in which 4 implementations participated and feedback was considered in revisions of these documents. Bert Wijnen reviewed these documents for the IESG. Note to RFC Editor (Insert note to RFC Editor here) IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 28 04:24:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE15Y-0002lZ-1j for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 04:24:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE15V-00048Z-IX for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 04:24:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE0vj-000CFA-Pv for netconf-data@psg.com; Tue, 28 Feb 2006 09:14:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE0vi-000CEx-VV for netconf@ops.ietf.org; Tue, 28 Feb 2006 09:14:03 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1S9Dmsu018173; Tue, 28 Feb 2006 03:13:49 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Feb 2006 10:13:47 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550967C045@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Eliot Lear (E-mail)" , ken.crozier@gmail.com Cc: "Netconf (E-mail)" Subject: FW: Evaluation: draft-ietf-netconf-beep-08.txt to Proposed Standa rd [I06-051127-0009] Date: Tue, 28 Feb 2006 10:13:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb The comment on IETF Last Call (revision 7() was: Date and Time: 2005-11-27, 17:31:28 Version: 07 Commented by: Michelle Cotton State before Comment: In Last Call State after Comment: In Last Call Comment: IANA Last Call Comments: Upon approval of this document the IANA will register the beep profile http://iana.org/beep/netconf in the following registry: http://www.iana.org/assignments/beep-parameters A TCP port number for NETCONF will also be registered in the following registry: http://www.iana.org/assignments/port-numbers In which range should this port number be registered? So can you pls answer. Bert -----Original Message----- From: iana-drafts@icann.org [mailto:iana-drafts@icann.org] Sent: Tuesday, February 28, 2006 07:12 To: iesg@ietf.org Subject: RE: Evaluation: draft-ietf-netconf-beep-08.txt to Proposed Standard [I06-051127-0009] IANA NOT OK. Comments in tracker. IANA Actions - YES Question from IANA Last Call comments has not yet been answered. Michelle Cotton (on behalf of IANA) -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org] Sent: Thursday, February 23, 2006 12:02 PM To: Internet Engineering Steering Group Subject: Evaluation: draft-ietf-netconf-beep-08.txt to Proposed Standard -------- Evaluation for draft-ietf-netconf-beep-08.txt can be found at https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=1090 3&rfc_flag=0 Last Call to expire on: 2005-12-07 Please return the full line with your position. Yes No-Objection Discuss Abstain Brian Carpenter [ ] [ ] [ ] [ ] Bill Fenner [ ] [ ] [ ] [ ] Ted Hardie [ ] [ ] [ ] [ ] Sam Hartman [ ] [ ] [ ] [ ] Scott Hollenbeck [ ] [ ] [ ] [ ] Russ Housley [ ] [ ] [ ] [ ] David Kessens [ ] [ ] [ ] [ ] Allison Mankin [ ] [ ] [ ] [ ] Jon Peterson [ ] [ ] [ ] [ ] Mark Townsley [ ] [ ] [ ] [ ] Margaret Wasserman [ ] [ ] [ ] [ ] Bert Wijnen [ X ] [ ] [ ] [ ] Alex Zinin [ ] [ ] [ ] [ ] "Yes" or "No-Objection" positions from 2/3 of non-recused ADs, with no "Discuss" positions, are needed for approval. DISCUSSES AND COMMENTS: ====================== ^L ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, netconf mailing list <netconf@ops.ietf.org>, netconf chair <simon@switch.ch>, netconf chair <ietf@andybierman.com> Subject: Protocol Action: 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard The IESG has approved the following document: - 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) ' <draft-ietf-netconf-beep-07.txt> as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-07.txt Technical Summary This document specifies an transport protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. The WG would like to thank Marshall Rose for his assistance with portions of this document. Bert Wijnen has reviewed this document for the IESG Note to RFC Editor (Insert note to RFC Editor here) IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 28 05:13:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE1r4-0006TQ-LO for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 05:13:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE1r3-0005P9-CI for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 05:13:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE1j8-000F5p-OL for netconf-data@psg.com; Tue, 28 Feb 2006 10:05:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE1j8-000F5V-35 for netconf@ops.ietf.org; Tue, 28 Feb 2006 10:05:06 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2006 02:05:06 -0800 X-IronPort-AV: i="4.02,151,1139212800"; d="scan'208"; a="410696298:sNHT29470328" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1SA55Vb025432; Tue, 28 Feb 2006 02:05:05 -0800 (PST) Received: from [144.254.23.103] (dhcp-data-vlan10-23-103.cisco.com [144.254.23.103]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1SA7OPM006415; Tue, 28 Feb 2006 02:07:25 -0800 Message-ID: <4404204E.8060104@cisco.com> Date: Tue, 28 Feb 2006 11:05:02 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: ken.crozier@gmail.com, "Netconf (E-mail)" Subject: Re: FW: Evaluation: draft-ietf-netconf-beep-08.txt to Proposed Standa rd [I06-051127-0009] References: <7D5D48D2CAA3D84C813F5B154F43B1550967C045@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550967C045@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=55; t=1141121245; x=1141553445; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20FW=3A=20Evaluation=3A=20draft-ietf-netconf-beep-08.txt=20to=20Pr oposed=20Standa=0A=20rd=20[I06-051127-0009] |To:=22Wijnen,=20Bert=20(Bert)=22=20; X=v=3Dmtcc.com=3B=20h=3D+gm9yaQ9szVesUtZK5yzUOnN578=3D; b=P7/9UkBgNM5fPDNsOTcogYQ4mkFkhBnoJ17zZmx1hZwCx4sXSgjg8SFyarR7JBjFwfirDtaX mmXJFj7dngeidpsNy22pMjps966BpsZq9e/mh1q4LgtKyhKySDDrqoS6CsDiTYeCsL71c2IJQS7 m47ZPnBfUoNhaePyWyRuIKVY=; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 We'd like a well known port, please (<1024). Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 28 15:12:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEBDE-0005up-PA for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 15:12:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEBDA-0008Vt-7g for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 15:12:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEB5N-000P8u-D5 for netconf-data@psg.com; Tue, 28 Feb 2006 20:04:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.1.0 Received: from [192.0.35.122] (helo=santee.icann.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE8vK-000GMu-Ji for netconf@ops.ietf.org; Tue, 28 Feb 2006 17:46:10 +0000 Received: from newiana (g35-170.icann.org [192.0.35.170] (may be forged)) by santee.icann.org (8.11.6/8.11.6) with ESMTP id k1SHjvD23190; Tue, 28 Feb 2006 09:45:57 -0800 Message-Id: <200602281745.k1SHjvD23190@santee.icann.org> From: "IANA" To: "'Wijnen, Bert \(Bert\)'" Cc: "'Margaret Wasserman \(E-mail\)'" , "'Netconf \(E-mail\)'" , Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standard [I06-051127-0011] Date: Tue, 28 Feb 2006 09:44:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550967C048@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcY8R02qfrXXYZ67TpqDej76l8qNYQARwkQg Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Bert, I still don't see what range the port needs to go in... User (0-1023) or system (1024-49151) range? Am I missing a note somewhere that give this information? Thanks, Michelle IANA -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, February 28, 2006 1:14 AM To: IANA (E-mail) Cc: Margaret Wasserman (E-mail); Netconf (E-mail) Subject: FW: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standard [I06-051127-0011] The question on IETF Last Call from IANA was: Date and Time: 2005-11-27, 17:16:49 Version: 05 Commented by: Michelle Cotton State before Comment: In Last Call State after Comment: In Last Call Comment: IANA Last Call Comments: Upon approval of this document the IANA will assign a TCP port number for NETCONF over SSH in the following registry: http://www.iana.org/assignments/port-numbers Which range should this port be assigned in? The IANA will also assign "netconf" as an SSH Service Name in the following registry: http://www.iana.org/assignments/ssh-parameters We still seem to not be clear on it. But maybe IANA/Michelle did not see the notes to RFC-Editor and IANA: In Section 7 IANA Considerations: OLD: IANA is requested to assign a TCP port number which will be the default port for NETCONF over SSH sessions as defined in this document. NEW: IANA is requested to assign a TCP port number which will be the default port for NETCONF over SSH sessions as defined in this document. IANA has assigned port for this purpose. [RFC Editor, please replace two instances of in Section 3 and one instance of in this section to the port number assigned by IANA.] Michelle, will that be sufficient? Bert -----Original Message----- From: iana-drafts@icann.org [mailto:iana-drafts@icann.org] Sent: Tuesday, February 28, 2006 07:18 To: iesg@ietf.org Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standard [I06-051127-0011] IANA NOT OK. Comments in tracker. IANA Actions - YES Question from Last Call has not yet been answered. Michelle Cotton (on behalf of IANA) -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org] Sent: Thursday, February 23, 2006 11:58 AM To: Internet Engineering Steering Group Subject: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standard, draft-ietf-netconf-prot-11.txt to Proposed Standard -------- Evaluation for draft-ietf-netconf-ssh-05.txt, draft-ietf-netconf-prot-11.txt can be found at https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=1075 1&rfc_flag=0 Last Call to expire on: 2005-12-07 Please return the full line with your position. Yes No-Objection Discuss Abstain Brian Carpenter [ ] [ ] [ ] [ ] Bill Fenner [ ] [ ] [ ] [ ] Ted Hardie [ ] [ ] [ ] [ ] Sam Hartman [ ] [ ] [ ] [ ] Scott Hollenbeck [ ] [ ] [ ] [ ] Russ Housley [ ] [ ] [ ] [ ] David Kessens [ ] [ ] [ ] [ ] Allison Mankin [ ] [ ] [ ] [ ] Jon Peterson [ ] [ ] [ ] [ ] Mark Townsley [ ] [ ] [ ] [ ] Margaret Wasserman [ ] [ ] [ ] [ ] Bert Wijnen [ X ] [ ] [ ] [ ] Alex Zinin [ ] [ ] [ ] [ ] "Yes" or "No-Objection" positions from 2/3 of non-recused ADs, with no "Discuss" positions, are needed for approval. DISCUSSES AND COMMENTS: ====================== ^L ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, netconf mailing list <netconf@ops.ietf.org>, netconf chair <simon@switch.ch>, netconf chair <ietf@andybierman.com> Subject: Protocol Action: 'NETCONF Configuration Protocol' to Proposed Standard The IESG has approved the following documents: - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH) ' <draft-ietf-netconf-ssh-05.txt> as a Proposed Standard - 'NETCONF Configuration Protocol ' <draft-ietf-netconf-prot-11.txt> as a Proposed Standard These documents are products of the Network Configuration Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-11.txt Technical Summary NETCONF Configuration Protocol The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. Using the NETCONF Configuration Protocol over Secure Shell (SSH) This document describes a method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session as an SSH subsystem. Note: The WG could not decide on a single transport mapping for NETCONF, because different types of programmers want to use the protocol. Therefore, NETCONF defines three transport mappings: SSH, BEEP, and SOAP, where SSH is the mandatory-to-implement protocol. Working Group Summary The NETCONF Working Group has consensus to publish these documents as a Proposed Standard. Protocol Quality It is likely that there are several implementations of these documents in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. An interoperability event (just prior to Paris IETF) was held in which 4 implementations participated and feedback was considered in revisions of these documents. Bert Wijnen reviewed these documents for the IESG. Note to RFC Editor (Insert note to RFC Editor here) IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Feb 28 18:09:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDyK-0001NZ-8h for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 18:09:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEDyJ-0004AU-Pc for netconf-archive@lists.ietf.org; Tue, 28 Feb 2006 18:09:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEDsR-000Aj6-G4 for netconf-data@psg.com; Tue, 28 Feb 2006 23:03:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEDsP-000Ait-Hy for netconf@ops.ietf.org; Tue, 28 Feb 2006 23:03:29 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1SN2jPM017732; Tue, 28 Feb 2006 17:02:46 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 00:02:44 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509721736@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "IANA (E-mail)" , "Iesg (E-mail)" Cc: "Netconf (E-mail)" Subject: RE: Evaluation: draft-ietf-netconf-beep-08.txt to Proposed Standa rd [I06-051127-0009] Date: Wed, 1 Mar 2006 00:02:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c IANA, I have added this Note to IANA in the ID-tracker: IANA Note The port to be assigned (as requested in the IANA considerations] should be in the range <1024. Hope this clears your question. Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Wijnen, Bert (Bert) > Sent: Tuesday, February 28, 2006 10:14 > To: Eliot Lear (E-mail); ken.crozier@gmail.com > Cc: Netconf (E-mail) > Subject: FW: Evaluation: draft-ietf-netconf-beep-08.txt to Proposed > Standa rd [I06-051127-0009] > > > The comment on IETF Last Call (revision 7() was: > > Date and Time: 2005-11-27, 17:31:28 > Version: 07 > Commented by: Michelle Cotton > State before Comment: In Last Call > State after Comment: In Last Call > Comment: IANA Last Call Comments: > Upon approval of this document the IANA will register the > beep profile > http://iana.org/beep/netconf in the following registry: > http://www.iana.org/assignments/beep-parameters > > A TCP port number for NETCONF will also be registered in > the following registry: > http://www.iana.org/assignments/port-numbers > In which range should this port number be registered? > > > So can you pls answer. > > Bert > -----Original Message----- > From: iana-drafts@icann.org [mailto:iana-drafts@icann.org] > Sent: Tuesday, February 28, 2006 07:12 > To: iesg@ietf.org > Subject: RE: Evaluation: draft-ietf-netconf-beep-08.txt to Proposed > Standard [I06-051127-0009] > > > > IANA NOT OK. Comments in tracker. > IANA Actions - YES > > Question from IANA Last Call comments has not yet been answered. > > Michelle Cotton > (on behalf of IANA) > > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary@ietf.org] > Sent: Thursday, February 23, 2006 12:02 PM > To: Internet Engineering Steering Group > Subject: Evaluation: draft-ietf-netconf-beep-08.txt to > Proposed Standard > > -------- > > Evaluation for draft-ietf-netconf-beep-08.txt can be found at > https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=vie > w_id&dTag=1090 > 3&rfc_flag=0 > > Last Call to expire on: 2005-12-07 > > Please return the full line with your position. > > Yes No-Objection Discuss Abstain > Brian Carpenter [ ] [ ] [ ] [ ] > Bill Fenner [ ] [ ] [ ] [ ] > Ted Hardie [ ] [ ] [ ] [ ] > Sam Hartman [ ] [ ] [ ] [ ] > Scott Hollenbeck [ ] [ ] [ ] [ ] > Russ Housley [ ] [ ] [ ] [ ] > David Kessens [ ] [ ] [ ] [ ] > Allison Mankin [ ] [ ] [ ] [ ] > Jon Peterson [ ] [ ] [ ] [ ] > Mark Townsley [ ] [ ] [ ] [ ] > Margaret Wasserman [ ] [ ] [ ] [ ] > Bert Wijnen [ X ] [ ] [ ] [ ] > Alex Zinin [ ] [ ] [ ] [ ] > > "Yes" or "No-Objection" positions from 2/3 of non-recused ADs, > with no "Discuss" positions, are needed for approval. > > DISCUSSES AND COMMENTS: > ====================== > > > > ^L > ---- following is a DRAFT of message to be sent AFTER approval --- > From: The IESG <iesg-secretary@ietf.org> > To: IETF-Announce <ietf-announce@ietf.org> > Cc: Internet Architecture Board <iab@iab.org>, > RFC Editor <rfc-editor@rfc-editor.org>, > netconf mailing list <netconf@ops.ietf.org>, > netconf chair <simon@switch.ch>, > netconf chair <ietf@andybierman.com> > Subject: Protocol Action: 'Using the NETCONF Protocol over Blocks > Extensible Exchange Protocol (BEEP)' to Proposed Standard > > The IESG has approved the following document: > > - 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol > (BEEP) ' > <draft-ietf-netconf-beep-07.txt> as a Proposed Standard > > This document is the product of the Network Configuration > Working Group. > > The IESG contact persons are Bert Wijnen and David Kessens. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-07.txt > > Technical Summary > > This document specifies an transport protocol mapping for the > NETCONF protocol over the Blocks Extensible Exchange > Protocol (BEEP). > > Working Group Summary > > The NETCONF Working Group has consensus to publish this document > as a Proposed Standard. > > Protocol Quality > > It is likely that there are several implementations of this > document in various stages of completion at this time. > Several major equipment vendors have indicated interest in > supporting this document, and some non-commercial > implementations are also expected. The WG would like to > thank Marshall Rose for his assistance with portions > of this document. > > Bert Wijnen has reviewed this document for the IESG > > Note to RFC Editor > > (Insert note to RFC Editor here) > > IESG Note > > (Insert IESG Note here) > > IANA Note > > (Insert IANA Note here) > > > > > > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: