From ngo-bounces@ietf.org Tue Jan 02 14:31:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1pLz-0002xG-Jm; Tue, 02 Jan 2007 14:31:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1pLy-0002x3-4w; Tue, 02 Jan 2007 14:31:18 -0500 Received: from smtpproxy1.mitre.org ([192.160.51.76] helo=smtp-bedford.mitre.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1pLu-0007w2-Hj; Tue, 02 Jan 2007 14:31:18 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l02JVAlN010309; Tue, 2 Jan 2007 14:31:10 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 0E8EFBF7B; Tue, 2 Jan 2007 14:31:10 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l02JV9hl010301; Tue, 2 Jan 2007 14:31:09 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 14:31:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Jan 2007 14:31:07 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F017E22BA@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS-AREA Prague BOF Proposal: SNMP MIB to Ontology translation Thread-Index: AccupIzz+Ehy2S0vSCOVHe02z6sCJA== From: "Natale, Bob" To: X-OriginalArrivalTime: 02 Jan 2007 19:31:09.0716 (UTC) FILETIME=[8E1D7D40:01C72EA4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: NETCONF Goes On Subject: [NGO] OPS-AREA Prague BOF Proposal: SNMP MIB to Ontology translation X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0463464013==" Errors-To: ngo-bounces@ietf.org This is a multi-part message in MIME format. --===============0463464013== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72EA4.8D5F3D3F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72EA4.8D5F3D3F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Sending this proposal to both OPS-AREA and NGO lists, per guidance from Dan. I was worried that it might be a bit too far out there, but Dan convinced me to stick my neck out anyway. :) =20 - - - - - A WG to define standard methods for converting the body of existing SNMP MIBs to OWL-based ontolologies, and standard methods for validating the resulting ontologies. =20 - IETF standard MIBs are the prime target; compliant vendor-specific enterprise MIBs would naturally follow. =20 - Such a mechanism could be an accelerant for the new breed of "SOA Management" vendors who are not well-versed in IETF=20 application, systems, and network management. =20 - This WG would examine the viability of starting from or building off the existing (non-standard) methods of converting SNMP MIBs to XML schema and documents. =20 - This WG would examine the viability of extending the NETCONF protocol to work with such ontologies. =20 - This WG would then examine the viability of build-time extensibility and run-time composability mechanisms associated with compliant ontologies. =20 - At the end of this process, compliant ontologies developed independently of pre-existing SNMP MIBs would be indistinguishable from those developed from such MIBs, enabling a more modern and SOA-aware method (OWL-S) of managed object data model construction.=20 =20 - At the end of this process, compliant ontologies might be extensible in ways that are incompatible with reverse translation back into SNMP MIBs. Such reverse translation is not a goal of this effort. =20 The underlying predicates are: - The body of SNMP MIBs comprises management knowledge and artifacts of incalculable value to the industry, irrespective of instrumentation mechanisms, access methods, and protocol(s) used to manipulate MIB data. - The nascent "SOA Management" industry could be relatively quickly enriched, even if via WS-to/from-SNMP proxies, via more SOA-friendly management data models. The expectation here is that ontology-based management data models will be more accessible to and usable by "SOA Management" tools than ASN.1 MIBs are. =20 "SOA Management" in quotes throughout because, while this label is being used by a dozen or so significant vendors, I'm not sure it's accurately descriptive or that it will stick long-term. - - - - - =20 Personally, I see a clear and near-term real-world need for such standard methods in my own work, and I believe that the emerging "SOA Management" industry desperately needs it (but might not know it yet) -- but I admit that most of that is purely subjective assessment at this time. I have the impression that earlier MIB-to-XML undertaken by some thought-leaders among us was good work that did not get widely deployed ("commercialized" is what I really mean). If that is accurate, we should consider the causes and whether they will have a similar effect wrt this proposal. =20 Lastly, if anyone feels that this might be a good idea but is not as well-expressed as it could be above, please revise as appropriate. Another MITRE reviewer has commented that specifying OWL and OWL-S at this stage might be premature. That's probably a good point, but my own research has really not turned up a viable alternative (based on my limited knowledge/judgment). =20 Cheers, BobN Principal Engineer, GIG NetOps Enterprise Services Systems Engineering www.mitre.org =20 =20 ------_=_NextPart_001_01C72EA4.8D5F3D3F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Sending this proposal to both OPS-AREA and = NGO lists,=20 per guidance from Dan.  I was worried that it might be a bit too = far out=20 there, but Dan convinced me to stick my neck out anyway. = :)
 
- -=20 - - -
A WG to = define standard=20 methods for converting the body of existing SNMP MIBs to OWL-based=20 ontolologies, and standard methods for = validating=20 the resulting ontologies.
 
- IETF standard MIBs = are the prime=20 target; compliant vendor-specific enterprise MIBs would naturally=20 follow.
 
- Such a mechanism = could be an=20 accelerant for the new breed of "SOA Management" vendors who are not = well-versed=20 in IETF
application, systems, and network management.
  =
- This=20 WG would examine the viability of starting from or building off the = existing=20 (non-standard) methods of converting SNMP MIBs to XML schema and=20 documents.
 
- This WG would = examine the=20 viability of extending the NETCONF protocol to work with such=20 ontologies.
 
- This WG would then = examine the=20 viability of build-time extensibility and run-time composability = mechanisms=20 associated with compliant ontologies.
 
- At the end of this = process,=20 compliant ontologies developed independently of pre-existing SNMP MIBs = would be=20 indistinguishable from those developed from such MIBs, enabling a more = modern=20 and SOA-aware method (OWL-S) of managed object data model construction.=20
 
- At=20 the end of this process, compliant ontologies might be extensible in = ways that=20 are incompatible with reverse translation back into SNMP MIBs.  = Such=20 reverse translation is not a goal of this effort.
 
The=20 underlying predicates are:
-=20 The body of SNMP MIBs comprises management knowledge and artifacts of=20 incalculable value to the industry, irrespective of instrumentation = mechanisms,=20 access methods, and protocol(s) used to manipulate MIB=20 data.
-=20 The nascent "SOA Management" industry could be relatively quickly = enriched, even=20 if via WS<whatever>-to/from-SNMP proxies, via more SOA-friendly = management=20 data models.  The expectation here is that ontology-based = management data=20 models will be more accessible to and usable by "SOA Management" tools = than=20 ASN.1 MIBs are.
 
"SOA=20 Management" in quotes throughout because, while this label is being used = by a=20 dozen or so significant vendors, I'm not sure it's accurately = descriptive or=20 that it will stick long-term.
- -=20 - - -
 
Personally, I see a clear and near-term real-world need for=20 such standard methods in my own work, and I believe that the = emerging=20 "SOA Management" industry desperately needs it (but might not know it = yet) --=20 but I admit that most of that is purely subjective assessment at this=20 time.  I have the impression that earlier MIB-to-XML undertaken by = some=20 thought-leaders among us was good work that did not get widely deployed=20 ("commercialized" is what I really mean).  If that is accurate, we = should=20 consider the causes and whether they will have a similar effect wrt this = proposal.
 
Lastly, if anyone feels that this might be a good idea but is = not as=20 well-expressed as it could be above, please revise as appropriate.  = Another=20 MITRE reviewer has commented that specifying OWL and OWL-S at this stage = might=20 be premature.  That's probably a good point, but my own research = has really=20 not turned up a viable alternative (based on my limited=20 knowledge/judgment).
 
Cheers,
BobN
Principal Engineer, GIG NetOps
Enterprise Services Systems Engineering
www.mitre.org
 
 
------_=_NextPart_001_01C72EA4.8D5F3D3F-- --===============0463464013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo --===============0463464013==-- From ngo-bounces@ietf.org Tue Jan 02 15:24:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qBX-000698-Pu; Tue, 02 Jan 2007 15:24:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qBW-00068t-I3 for ngo@ietf.org; Tue, 02 Jan 2007 15:24:34 -0500 Received: from omr5.networksolutionsemail.com ([205.178.146.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1qBU-0007GS-Jz for ngo@ietf.org; Tue, 02 Jan 2007 15:24:34 -0500 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l02KOUZx013214 for ; Tue, 2 Jan 2007 15:24:30 -0500 Received: (qmail 3281 invoked by uid 78); 2 Jan 2007 20:24:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 2 Jan 2007 20:24:29 -0000 Message-ID: <459ABF71.60004@andybierman.com> Date: Tue, 02 Jan 2007 12:24:17 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Natale, Bob" Subject: Re: [NGO] OPS-AREA Prague BOF Proposal: SNMP MIB to Ontology translation References: <4915F014FDD99049A9C3A8C1B832004F017E22BA@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F017E22BA@IMCSRV2.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: NETCONF Goes On , ops-area@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi Bob, > Hi, > > Sending this proposal to both OPS-AREA and NGO lists, per guidance from > Dan. I was worried that it might be a bit too far out there, but Dan > convinced me to stick my neck out anyway. :) This sounds great to me, especially if you are willing to Chair the WG. ;-) I think NETCONF can support a service-oriented API, with service-specific RPC methods and notifications. IMO, the CLI model (config service, show service, etc.) is already closer to an SOA than SNMP/SMIv2, and this is how a lot of NE devices are currently being managed. However, high-level procedures to manage specific services, using standard MIB objects as parameters, should be possible. In am very much in favor of abandoning the "raw data operation" API mindset of SNMP (and NETCONF edit-config!), and viewing the API as a collection of services, each with their own set of procedures and notification definitions. The fly in the ointment is the startup config file which represents the entire configuration upon reboot -- the 'document-oriented' APIs (e.g., CLI, NETCONF standard operations) assume the entire desired state of the NE device can be represented in text commands, and any box of the same device-type can consume this startup config file at boot-time and function correctly within the network. Operators usually want visibility (i.e., human readability) of this file. Any SOA-based API, whether SNMP or CLI based, will need to be compatible with this important feature. Andy > > - - - - - > A WG to define standard methods for converting the body of existing SNMP > MIBs to OWL-based ontolologies, and standard methods for validating the > resulting ontologies. > > - IETF standard MIBs are the prime target; compliant vendor-specific > enterprise MIBs would naturally follow. > > - Such a mechanism could be an accelerant for the new breed of "SOA > Management" vendors who are not well-versed in IETF > application, systems, and network management. > > - This WG would examine the viability of starting from or building off > the existing (non-standard) methods of converting SNMP MIBs to XML > schema and documents. > > - This WG would examine the viability of extending the NETCONF protocol > to work with such ontologies. > > - This WG would then examine the viability of build-time extensibility > and run-time composability mechanisms associated with compliant ontologies. > > - At the end of this process, compliant ontologies developed > independently of pre-existing SNMP MIBs would be indistinguishable from > those developed from such MIBs, enabling a more modern and SOA-aware > method (OWL-S) of managed object data model construction. > > - At the end of this process, compliant ontologies might be extensible > in ways that are incompatible with reverse translation back into SNMP > MIBs. Such reverse translation is not a goal of this effort. > > The underlying predicates are: > - The body of SNMP MIBs comprises management knowledge and artifacts of > incalculable value to the industry, irrespective of instrumentation > mechanisms, access methods, and protocol(s) used to manipulate MIB data. > - The nascent "SOA Management" industry could be relatively quickly > enriched, even if via WS-to/from-SNMP proxies, via more > SOA-friendly management data models. The expectation here is that > ontology-based management data models will be more accessible to and > usable by "SOA Management" tools than ASN.1 MIBs are. > > "SOA Management" in quotes throughout because, while this label is being > used by a dozen or so significant vendors, I'm not sure it's accurately > descriptive or that it will stick long-term. > - - - - - > > Personally, I see a clear and near-term real-world need for > such standard methods in my own work, and I believe that the emerging > "SOA Management" industry desperately needs it (but might not know it > yet) -- but I admit that most of that is purely subjective assessment at > this time. I have the impression that earlier MIB-to-XML undertaken by > some thought-leaders among us was good work that did not get widely > deployed ("commercialized" is what I really mean). If that is accurate, > we should consider the causes and whether they will have a similar > effect wrt this proposal. > > Lastly, if anyone feels that this might be a good idea but is not as > well-expressed as it could be above, please revise as appropriate. > Another MITRE reviewer has commented that specifying OWL and OWL-S at > this stage might be premature. That's probably a good point, but my own > research has really not turned up a viable alternative (based on my > limited knowledge/judgment). > > Cheers, > BobN > Principal Engineer, GIG NetOps > Enterprise Services Systems Engineering > www.mitre.org > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Fri Jan 05 01:20:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iQg-0004NM-Df; Fri, 05 Jan 2007 01:19:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iQe-0004NE-Q6 for ngo@ietf.org; Fri, 05 Jan 2007 01:19:48 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2iQd-0004b0-GR for ngo@ietf.org; Fri, 05 Jan 2007 01:19:48 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l056JjSu008542 for ; Fri, 5 Jan 2007 01:19:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C73091.7E8419AB" Date: Fri, 5 Jan 2007 08:19:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-li-ngo-access-mib-00.txt Thread-Index: AccwW+lSeEyCHO3UQBGVsW2zXuPd5wANYNdA From: "Romascanu, Dan \(Dan\)" To: "NETCONF Goes On" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C73091.7E8419AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, January 05, 2007 1:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-li-ngo-access-mib-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Accessing MIBs using NETCONF Author(s) : Y. Li, D. Harrington Filename : draft-li-ngo-access-mib-00.txt Pages : 21 Date : 2006-1-4 =09 This memo describes a simple mechanism for accessing the Management Information Base (MIB), using the existing NETCONF RPC infrastructure. It defines a set of specific operations for accessing the MIB as a capability of NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-li-ngo-access-mib-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-li-ngo-access-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-li-ngo-access-mib-00.txt". =09 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_001_01C73091.7E8419AB Content-Type: application/octet-stream; name="ATT145316.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT145316.TXT Content-Disposition: attachment; filename="ATT145316.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0xLTQxNTIxNTYuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktbmdvLWFjY2Vzcy1taWIt MDAudHh0DQo= ------_=_NextPart_001_01C73091.7E8419AB Content-Type: application/octet-stream; name="draft-li-ngo-access-mib-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-li-ngo-access-mib-00.URL Content-Disposition: attachment; filename="draft-li-ngo-access-mib-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saS1uZ28tYWNjZXNzLW1pYi0wMC50eHQNCg== ------_=_NextPart_001_01C73091.7E8419AB Content-Type: text/plain; name="ATT145316.txt" Content-Transfer-Encoding: base64 Content-Description: ATT145316.txt Content-Disposition: attachment; filename="ATT145316.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C73091.7E8419AB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo ------_=_NextPart_001_01C73091.7E8419AB-- From ngo-bounces@ietf.org Fri Jan 05 12:52:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tEP-0004Vn-OQ; Fri, 05 Jan 2007 12:51:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tEO-0004Vb-4w for ngo@ietf.org; Fri, 05 Jan 2007 12:51:52 -0500 Received: from omr3.networksolutionsemail.com ([205.178.146.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tEL-0002ZO-UH for ngo@ietf.org; Fri, 05 Jan 2007 12:51:52 -0500 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l05HpmlQ025133 for ; Fri, 5 Jan 2007 12:51:48 -0500 Received: (qmail 22307 invoked by uid 78); 5 Jan 2007 17:51:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 5 Jan 2007 17:51:48 -0000 Message-ID: <459E902D.9040806@andybierman.com> Date: Fri, 05 Jan 2007 09:51:41 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" Subject: Re: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: NETCONF Goes On X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi, > Title : Accessing MIBs using NETCONF Although I agree with the intentions of this document (as I understand them), I do not see any additional value in the special RPCs and . They seem to be the same as the and operations. All of the value seems to be in the data model element, and actual MIB-to-XSD conversion algorithms, which are not documented here. Section 3 describes some requirements for SNMP, but it doesn't actually map those requirements into the NETCONF protocol in any way. I was expecting to see how all these requirements are mapped to the RPC methods, or maybe the data model wrapper element. The examples have a lot of XML attributes and underlying data model assumptions that are not explained. These are the missing details that implementors need to support this proposal in running code. Isn't 'max-repetitions' used in SNMP to deal with UDP limitations? Introducing it in NETCONF as a new control in subtree filtering, and embellishing subtree filtering instead of using Xpath, does not seem like a good idea to me. Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Mon Jan 08 11:43:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xaq-0000Lb-Tf; Mon, 08 Jan 2007 11:43:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xap-0000Km-CN for ngo@ietf.org; Mon, 08 Jan 2007 11:43:27 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3xal-00017O-27 for ngo@ietf.org; Mon, 08 Jan 2007 11:43:27 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20070108164321b1100k187ae>; Mon, 8 Jan 2007 16:43:21 +0000 From: "David Harrington" To: Date: Mon, 8 Jan 2007 11:40:00 -0500 Message-ID: <264901c73343$a419fb20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_264A_01C73319.BB43F320" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcczQvNRU4RkRQeOSHakBMzwl7CYLg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 70b171c0ed4d06f269383c4ae15bcea6 Subject: [NGO] Draft-li-ngo-access-mib-00-unofficial X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_264A_01C73319.BB43F320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Since a problem has occurred during the publication of this document, here is an unofficial copy that people can peruse until the official copy becomes available. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_264A_01C73319.BB43F320 Content-Type: text/plain; name="draft-li-ngo-access-mib-00-070104.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-li-ngo-access-mib-00-070104.txt" netconf Y. Li Internet-Draft Huawei Technologies Intended status: Experimental D. Harrington Expires: July 8, 2007 Huawei Technologies (USA) January 4, 2007 Accessing MIBs using NETCONF draft-li-ngo-access-mib-00 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This memo describes a simple mechanism for accessing the Management Information Base (MIB), using the existing NETCONF RPC infrastructure. It defines a set of specific operations for accessing the MIB as a capability of NETCONF. Li & Harrington Expires July 8, 2007 [Page 1] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. XML schemas for MIB definitions . . . . . . . . . . . . . . . 4 3. How This Capability Fits with the SNMP Architecture . . . . . 5 3.1. Data Addressing . . . . . . . . . . . . . . . . . . . . . 6 3.2. Access Control . . . . . . . . . . . . . . . . . . . . . . 6 4. Accessing MIB Capability . . . . . . . . . . . . . . . . . . . 7 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Capability Identifier . . . . . . . . . . . . . . . . . . 7 4.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 8 4.4.1. . . . . . . . . . . . . . . . . . . . . . . 8 4.4.2. . . . . . . . . . . . . . . . . . . . . . . 12 5. Schema for Accessing-mib Capability . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Previous Work . . . . . . . . . . . . . . . . . . . . 19 Li & Harrington Expires July 8, 2007 [Page 2] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 1. Introduction This memo describes a simple mechanism for accessing the Management Information Base (MIB), using the existing NETCONF RPC infrastructure. It defines a set of specific operations for accessing the MIB as a capability of NETCONF. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.1. Motivation NETCONF [RFC4741] conceptually partitions its design into four layers: Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ Transport Protocol, RPC and Operations layers have already been standardized to a degree, while the Content Layer has not been standardized yet. Device vendors have been asked to support NETCONF in their products, but there is no standard data definition language or standard content for NETCONF at this time. SMIv2 [RFC2578] is the IETF-standard for network management data modeling, and the MIB is the IETF standard for organizing MIB modules. There are many standard MIB modules, and these have been supplemented by many proprietary MIB modules defined by device vendors. Many devices already support a wide range of MIB modules, and many network management applications already utilize the information modeled in the available MIB modules. Li & Harrington Expires July 8, 2007 [Page 3] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 MIB objects are generally accessed through the Simple Network Management Protocol (SNMP), but RFC1052 [RFC1052] documents the IAB decision to use the MIB as the IETF standard for data modeling, and the intention of the IETF to permit the MIB to be utilized by multiple protocols. The netconf community wants to develop a data modeling language with structures more complex than SMIv2 permits, and to have the netconf protocol support task-oriented RPCs to perform operations, rather than a data-oriented protocol, such as SNMP, that has a small number of verbs that are designed to directly manipulate data elements. While the netconf community works on developing its data modeling language and data models, the netconf community has recommended that vendors simply use their own proprietary data models, written in an XML format. This approach is a problem for device vendors. They do not know what configuration data they should provide; if they use proprietary data, the customer desire for interoperability between devices and applications from different vendors cannot be met. If the IETF standardizes an XML-based data model in the near future, then there will be little return on the investment for developing a proprietary XML-based data model. The MIB is a standard data model that most internetworking device vendors already support to provide interoperable management for their products. Vendors could use the MIB, expressed in XML, as one type of data model for NETCONF. The libsmi tools already have an option to convert MIB modules into corresponding XML Schemas, so this will make it easier to use MIB data with netconf. This memo proposes a set of RPCs, packaged as a capability, for NETCONF to access MIB objects. 2. XML schemas for MIB definitions MIB modules are written using an adapted subset of Abstract Syntax Notation One, ASN.1 [refs.asn1] (1988), which is called the Structure of Management Information (SMI). NETCONF encodes configuration data in XML [refs.xml], and the data model of NETCONF should be described using XML DTD or XML schema [refs.schema] or other XML schema language. At the time of this writing, XML schema is preferred. Those MIB modules to be used with NETCONF should be rewritten in XSD, and for interoperability the resulting XML schema written by different people should have the same format. The libsmi toolkit contains an smidump tool, which can transform a MIB module into various formats, including an XML schema. The libsmi toolkit has been available for many years, and a number of Li & Harrington Expires July 8, 2007 [Page 4] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 applications already use the smidump XML schemas. For the sake of compatibility, this memo also uses XML schemas generated by smidump. 3. How This Capability Fits with the SNMP Architecture RFC3411 provides an architecture for describing SNMP frameworks. There are similarities between the netconf architecture and the RFC3411 architecture. +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ | | | | | Transport | | | | | | Subsystem | | | | | +------------+ | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ The Netconf Protocol describes the message format for netconf, which is similar to a model in the message processing subsystem described in RFC3412 [RFC3412]. The transport/application mappings of netconf are similar to transport models in the Transport Subsystem for SNMP, Li & Harrington Expires July 8, 2007 [Page 5] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 as described in [I-D.ietf-isms-tmsm]. Having the ability to access the MIB data is similar to an SNMP application, as described in RFC3413 [RFC3413]. However, an "application" in the SNMP architecture requires input parameters, for data addressing, and for access control purposes. 3.1. Data Addressing Within SNMPv3, an individual item of information within an administrative domain is addressed by a four-tuple consisting of a contextEngineID, a contextName, an object type, and an object instance. The last two elements are typically encoded in an object identifier (OID) value. As of this writing, Netconf does not provide the equivalent of this four-tuple. This memo uses an XML-based address that encodes the object type and object instance, derived from the equivalent Object Identifier. An SNMP version 3 message [RFC3412] carries a scopedPDU - a data structure containing a contextEngineID, a contextName, and a protocol data unit (PDU) which contains MIB data. The smidump schemas always have a element that includes mandatory attributes to identify the SNMP context of the MIB data. 3.2. Access Control Within SNMPv3, an access control model determines who is allowed to perform which operations to different data sets of information. The RFC3411 architecture describes a series of parameters that are provided to the isAccessAllowed() service primitive to make this determination. The parameters include a securityModel and securityName to identify the (possibly-authenticated) principal statusInformation =3D -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object ) A securityModel is the model within the SNMP security subsystem that will provide authentication, integrity checking, encryption, and other security services for SNMP response messages. Netconf provides these services through its transport/application mappings. Netconf Li & Harrington Expires July 8, 2007 [Page 6] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 does not provide an indicator of which transport mapping will be utilized to secure the response message. The securityLevel identifies whether authentication and encryption services will be used on the response message. Netconf leaves the configuration of authentication and encryption services to the human administrator, and does not provide a mechanism-independent indicator for the security services provided during transport. Implicit in this design is the assumption that a transport mapping provides a constant level of security. Without an indicator of the services provided, access control for netconf cannot be determined based on the security properties of the message transport. A securityName is a mechanism-independent identifier of the "who" on whose behalf SNMP services are provided or processing takes place. Netconf provides for the authentication of the "who" on whose behalf services are provided or processing takes place, but does not provide a mechanism-independent identifier to pass the identity to an access control mechanism. The viewType is an abstraction for a class of operation; SNMP supports read, write, and notify types of operations. Netconf does not yet have a clear description of the types of operations that may be supported in the future. When accessing MIB data with the operations described in this memo, a read/write/notify classification of operations can be used. As described above, the smidump schemas provide mechanisms to identify the contextName (context) and instance identifier (variableName). 4. Accessing MIB Capability 4.1. Description The :accessing-mib capability indicates that the server supports MIB definitions as data models, and supports retrieving and modifying MIB objects in the configuration through the operations specified in this memo. 4.2. Dependencies none. 4.3. Capability Identifier The :accessing-mib capability is identified by the following capability string: Li & Harrington Expires July 8, 2007 [Page 7] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 urn:ietf:params:netconf:capability:accessing-mib:1.0 4.4. New Operations 4.4.1. Description: Retrieve MIB objects from the configuration datastore. Attributes: max-repetitions: The attribute is only applied to subtree filtering. Entry elements in the subtree, such as and , may contain a "max-repetitions" attribute that indicates the maximum number of element instances that the client wants to retrieve. Starting with the given index of the entry, the server retrieves an entry instance in lexicographical order until either of following conditions occurs: + The retrieved number of the entry element instances has reached the value of "max-repetitions" attribute. + No more entry element instances are available. Parameters: filter: This parameter specifies the portion of the MIB objects to retrieve. If this parameter is empty, all MIB objects are returned. The filter element may optionally contain a 'type' attribute. This attribute indicates the type of filtering syntax used within the filter element. The default filtering mechanism in this memo is referred to as subtree filtering and is described in [RFC4741] Section 6. The value 'subtree' explicitly identifies this type of filtering. If the NETCONF peer supports the :xpath capability ([RFC4741] Section 8.9), the value 'xpath' may be used to indicate that the filter element contains an XPath expression. Positive Response: If the device was able to satisfy the request, an is sent. The section contains the appropriate subset. Li & Harrington Expires July 8, 2007 [Page 8] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 Negative Response: An element is included in the if the request cannot be completed for any reason. [todo: detail the error conditions, and the rpc-error codes that might be returned.] Example: Li & Harrington Expires July 8, 2007 [Page 9] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 Get the value of ifNumber, ifMtu.1 and ifSpeed.1. 10 ethernetCsmacd 1500 Li & Harrington Expires July 8, 2007 [Page 10] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 Get the values of ifMtu and ifSpeed of first three ifEntries. ethernetCsmacd 1500 ethernetCsmacd 1500 ppp 1800 Li & Harrington Expires July 8, 2007 [Page 11] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 4.4.2. Description: Set MIB objects in the configuration datastore. Attributes: operation: Elements in the subtree may contain an "operation" attribute. The attribute specifies that MIB objects in the subtree whose root is identified by the element containing this attribute perform the operation. The attribute MAY appear on multiple elements throughout the subtree. If a MIB object locates in multiple overlapped subtrees, which are specified different operations, the MIB object perform the operation of the smallest subtree. If the operation attribute doesn't appear in the subtree, all MIB objects in the subtree perform replace operation. The operation attribute has one of the following values: replace: The MIB objects in the subtree whose root is identified by the element containing this attribute replaces any related MIB objects in the configuration datastore. This is the default behavior. create: This value is only applied for an entry element. It indicates that create an entry instance as the entry element described. delete: This value is only applied for an entry element. It indicates that delete an entry instance as the entry element described. Parameters: test-option: The test-option element may be specified only if the device advertises the :validate capability (Section 8.6). The test-option element has one of the following values: test-then-set: Perform a validation test before attempting to set. If validation errors occur, do not perform the operation. This is the default test-option. set: Perform a set without a validation test first. error-option: The error-option element has one of the following values: Li & Harrington Expires July 8, 2007 [Page 12] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 stop-on-error: Abort the edit-config operation on first error. This is the default error-option. continue-on-error: Continue to process MIB objects on error; error is recorded and negative response is generated if any errors occur. rollback-on-error: If an error condition occurs such that an error severity element is generated, the server will stop processing the edit-config operation and restore the specified configuration to its complete state at the start of this edit-config operation. This option requires the server to support the :rollback-on-error capability described in [RFC4741] Section 8.5. config: A portion of the MIB tree as defined by a MIB module in XML schema. The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate MIB module. Positive Response: If the device was able to satisfy the request, an is sent containing an element. Negative Response: An response is sent if the request cannot be completed for any reason. Example: Li & Harrington Expires July 8, 2007 [Page 13] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 Set ifLinkUpDownTrapEnable.1 to "enable" and ifAlias.2 to "Beijing". enable Beijing Li & Harrington Expires July 8, 2007 [Page 14] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 Create an ifStackEntry instance. 5. Schema for Accessing-mib Capability This schema defines elements for accessing-mib capability. Li & Harrington Expires July 8, 2007 [Page 15] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 Use of the test-option element requires the :validate capability. 6. Security Considerations Although this document provides Netconf RPCs to emulate SNMP operations to access MIBs, the Netconf protocol does not currently have a way to provide the necessary parameters to apply SNMP-based access controls. These parameters are discussed in Section 3.2. If implementations are based on implementations of SNMP, then these parameters could be provided in an implementation-dependent manner. For compatibility, and balanced security, it is RECOMMENDED that such implementations provide MIB data access control comparable to the View-based Access Control model defined in [RFC3415]. 7. IANA Considerations 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [refs.xml] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [refs.schema] Fallside, D., Walmsley, P., Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema 1.0", W3C XML Schema, October 2004, . [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [refs.libsmi] Strauss, F. and T. Klie, "Integrating SNMP Agents with XML-based Management Systems", July 2004, . [refs.asn1] International Organization for Standardization, "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", December 1987. Li & Harrington Expires July 8, 2007 [Page 17] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol (SNMP)", draft-ietf-isms-tmsm-02 (work in progress), May 2006. 8.2. Informative References [RFC1052] Cerf, V., "IAB recommendations for the development of Internet network management standards", RFC 1052, April 1988. [refs.RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework", RFC 3410, December 2002. Appendix A. Open Issues o do we need max-repetitions? It was not kept in the RFC 4088 URI format. Max-repetitions could be useful when retrieving a table that contains numerous entries. The whole table can be retrieved by multiple requests. Otherwise, the size of response message will be huge, and it will take a long time to transport the message. o Can I xpath filter on arbitrary content? I assume this is the case but that should probably be spelled out (e.g. retrieve all interfaces where the name starts with a given prefix - something operators find useful). If this is the case, what is the Li & Harrington Expires July 8, 2007 [Page 18] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 semantics of max-repetitions? an interface is identified by an ifIndex in MIBs, not by an interface's name. so it is hard to filter interfaces by name or a given prefix. max-repetitions is an instruction, not an attribute of data. It is really a problem when it is used in xpath filter. o To complete this work, someone must write a specification how smidump actually converts MIB modules to XML schemas so that there is agreement how to exchange MIB data. o Appendix B. Previous Work Research was done in the 1990s into integrating SNMP agents with XML- based management systems. The paper [refs.libsmi] discusses some of the research that was done. The "mibdump" tool is an implementation of the SMI to XML conversion, and something that could be connected to a netconf front-end. There was a fancy Web wrapper which used xpath to actually select MIB data. $ lynx -dump 'http://www.ibr.cs.tu-bs.de/snmp-xml-gw?\ get=3D/snmp-data/context[@hostname=3D"talisker.ibr.cs.tu-bs.de"]\ /ifEntry[ifOperStatus=3D"up" and (ifOutOctets > 0 or ifInOctets > 0)]/ifDescr' See the minutes from the 12th NMRG meeting in Colorado Springs where Frank and Torsten discussed the SMI to XML mapping in some more details. Authors' Addresses Yan Li Huawei Technologies No.3 Xinxi Road, Shangdi Information Industry Base Beijing, HaiDian District 100085 P.R.China Phone: +86 10 8288 2008 EMail: liyan_77@huawei.com Li & Harrington Expires July 8, 2007 [Page 19] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: dharrington@huawei.com Li & Harrington Expires July 8, 2007 [Page 20] =0C Internet-Draft Accessing MIBs using NETCONF January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Li & Harrington Expires July 8, 2007 [Page 21] =0C ------=_NextPart_000_264A_01C73319.BB43F320 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo ------=_NextPart_000_264A_01C73319.BB43F320-- From ngo-bounces@ietf.org Mon Jan 08 12:12:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3y2W-0006zJ-PV; Mon, 08 Jan 2007 12:12:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xJq-0001Oy-4M for ngo@ietf.org; Mon, 08 Jan 2007 11:25:54 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3xJn-0007f5-MH for ngo@ietf.org; Mon, 08 Jan 2007 11:25:54 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBK000TK5HTOH@usaga01-in.huawei.com> for ngo@ietf.org; Mon, 08 Jan 2007 08:22:41 -0800 (PST) Received: from Harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net [24.128.104.207]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBK00J2L5HN09@usaga01-in.huawei.com> for ngo@ietf.org; Mon, 08 Jan 2007 08:22:41 -0800 (PST) Date: Mon, 08 Jan 2007 11:19:19 -0500 From: David Harrington Subject: RE: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt In-reply-to: <4915F014FDD99049A9C3A8C1B832004F017E2968@IMCSRV2.MITRE.ORG> To: "'Natale, Bob'" , "'Romascanu, Dan (Dan)'" Message-id: <263701c73340$c0790a70$0600a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccwW+lSeEyCHO3UQBGVsW2zXuPd5wANYNdAAKtmFxAAAC55UA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-Mailman-Approved-At: Mon, 08 Jan 2007 12:12:03 -0500 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi, Juergen made the internet-drafts editor (and me) aware of this, last week. I believe the submitted document had the correct dates; the problem seems to be in the internet-drafts database. Since no action has yet been taken, this morning I sent another request to internet-drafts to have this fixed. dbh > -----Original Message----- > From: Natale, Bob [mailto:RNATALE@mitre.org] > Sent: Monday, January 08, 2007 11:09 AM > To: Romascanu, Dan (Dan); dharrington@huawei.com > Subject: RE: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt > > Hi Dan and David, > > Note that this I-D appears to have an incorrect date (2006 vs 2007) on > it and, therefore, is shown as "Expired" by the I-D database search > tool. > > Cheers, > BobN > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Friday, January 05, 2007 1:20 AM > To: NETCONF Goes On > Subject: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt > > > > > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, January 05, 2007 1:50 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-li-ngo-access-mib-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Accessing MIBs using NETCONF > Author(s) : Y. Li, D. Harrington > Filename : draft-li-ngo-access-mib-00.txt > Pages : 21 > Date : 2006-1-4 > > This memo describes a simple mechanism for accessing the Management > Information Base (MIB), using the existing NETCONF RPC > infrastructure. It defines a set of specific operations for > accessing the MIB as a capability of NETCONF. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-li-ngo-access-mib-00.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-li-ngo-access-mib-00.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-li-ngo-access-mib-00.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. > > _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Mon Jan 08 16:54:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42Rr-0004HV-Bj; Mon, 08 Jan 2007 16:54:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42Rp-00042r-SM for ngo@ietf.org; Mon, 08 Jan 2007 16:54:29 -0500 Received: from mail.tail-f.com ([213.180.94.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H42Ro-0005RQ-JF for ngo@ietf.org; Mon, 08 Jan 2007 16:54:29 -0500 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 7D1D71B80C3 for ; Mon, 8 Jan 2007 22:54:24 +0100 (CET) Date: Mon, 08 Jan 2007 22:54:22 +0100 (CET) Message-Id: <20070108.225422.124671848.mbj@tail-f.com> To: ngo@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [NGO] comments on draft-li-ngo-access-mib-00 X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi, I don't understand why a new rpc method is needed. Why can't the normal method be used? I could possibly understand, but not the way it's defined. Specifically, how is the operation attribute supposed to be used in combination with RowStatus objects? In general I think that these MIB request can be done using the normal netconf operations, as long as the XML mapping is well-defined. I.e. given a standard MIB, what will the XML look like (namespace URI, element structure, attribute uses, datatype represention). This part isn't covered in the draft (just a reference to smidump). /martin _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Mon Jan 08 21:35:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H46pm-0005FN-DJ; Mon, 08 Jan 2007 21:35:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H46pl-0005FI-AW for ngo@ietf.org; Mon, 08 Jan 2007 21:35:29 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H46pk-0000QT-1L for ngo@ietf.org; Mon, 08 Jan 2007 21:35:29 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070109023527b1400mit2re>; Tue, 9 Jan 2007 02:35:27 +0000 From: "David Harrington" To: "'Andy Bierman'" , "'Romascanu, Dan \(Dan\)'" Subject: RE: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt Date: Mon, 8 Jan 2007 21:32:06 -0500 Message-ID: <276701c73396$5b92d950$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Accw8jafyZjmxH+0SqaFDYGqRVs6tgCn2dSA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <459E902D.9040806@andybierman.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 'NETCONF Goes On' X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi, > > Title : Accessing MIBs using NETCONF > > Although I agree with the intentions of this document (as I > understand them), > I do not see any additional value in the special RPCs > and . > They seem to be the same as the and operations. > All of the value seems to be in the data model element, > and actual MIB-to-XSD conversion algorithms, which are not > documented here. As currently written, that is true. As described, the current document only deals with the data addressing issue of accessing MIB data, by using the smidump output. > > Section 3 describes some requirements for SNMP, but it doesn't > actually map those requirements into the NETCONF protocol in any way. > I was expecting to see how all these requirements are mapped to > the RPC methods, or maybe the data model wrapper element. The main issue is how to map from netconf parameters to SNMP access control. Netconf does not provide the necessary parameters to do this, and the document points out that these parameters are necessary if the operator-defined MIB access control rules will be honored by netconf. In ISMS, as in netconf, we are depending on a secure transport layer to provide user authentication and message security. The difference between ISMS (SNMPv3) and netconf is that netconf provides no mapping from its transport-specific SSH/BEEP/SOAP security parameters to transport-independent parameters (securityname/level/model) that can then be passed in an RPC for purposes of access control. Is there additional value in and over and ? Yes. They provide a specialized RPC interface that is specially designed to use an XSD-to-MIB data mapping, and can be extended to support the SNMP-specific access control interface, without forcing and and other netconf operations to use the same XSD data models or the same access control interface. Of course, if the netconf community wants to redefine and to take securityName/level/model parameters for access control for and , then there would be no additional value in the / specialized RPCs. I have not seen much indication that the netconf community wants to do this, so we have suggested the use of specialized RPCs to "contain" this extra functionality. If the netconf community is interested in seeing mappings from the transport-security-specific authentication mechanisms to transport-security-independent parameters (which for consistency with SNMP I would call securityName, securityLevel, and securityModel), I can certainly help specify those mappings, working with the netconf-transport document authors, and then work with Yan to extend the and RPCs (or and ) to include them. > > The examples have a lot of XML attributes and underlying data model > assumptions that are not explained. These are the missing details > that implementors need to support this proposal in running code. Agreed. Hopefully, the SMI-to-XSD translation will be documented by Thorsten and Frank, and we can clean up any text with other assumptions. > > Isn't 'max-repetitions' used in SNMP to deal with UDP limitations? > Introducing it in NETCONF as a new control in subtree filtering, > and embellishing subtree filtering instead of using Xpath, > does not seem like a good idea to me. Eliminating max-repetitions from the proposal has been under discussion, but has not been removed yet. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Mon Jan 08 21:59:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47DG-0005yR-GQ; Mon, 08 Jan 2007 21:59:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47DF-0005yD-LC for ngo@ietf.org; Mon, 08 Jan 2007 21:59:45 -0500 Received: from omr1.networksolutionsemail.com ([205.178.146.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H47DE-00050l-Ay for ngo@ietf.org; Mon, 08 Jan 2007 21:59:45 -0500 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l092xgiq025063 for ; Mon, 8 Jan 2007 21:59:42 -0500 Received: (qmail 8450 invoked by uid 78); 9 Jan 2007 02:59:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 9 Jan 2007 02:59:41 -0000 Message-ID: <45A3050B.2070201@andybierman.com> Date: Mon, 08 Jan 2007 18:59:23 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: David Harrington Subject: Re: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt References: <276701c73396$5b92d950$0600a8c0@china.huawei.com> In-Reply-To: <276701c73396$5b92d950$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 'NETCONF Goes On' X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org David Harrington wrote: > Hi, > >>> Title : Accessing MIBs using NETCONF >> Although I agree with the intentions of this document (as I >> understand them), >> I do not see any additional value in the special RPCs >> and . >> They seem to be the same as the and operations. >> All of the value seems to be in the data model element, >> and actual MIB-to-XSD conversion algorithms, which are not >> documented here. > > As currently written, that is true. As described, the current document > only deals with the data addressing issue of accessing MIB data, by > using the smidump output. > >> Section 3 describes some requirements for SNMP, but it doesn't >> actually map those requirements into the NETCONF protocol in any > way. >> I was expecting to see how all these requirements are mapped to >> the RPC methods, or maybe the data model wrapper > element. > > The main issue is how to map from netconf parameters to SNMP access > control. Netconf does not provide the necessary parameters to do this, > and the document points out that these parameters are necessary if the > operator-defined MIB access control rules will be honored by netconf. > > In ISMS, as in netconf, we are depending on a secure transport layer > to provide user authentication and message security. The difference > between ISMS (SNMPv3) and netconf is that netconf provides no mapping > from its transport-specific SSH/BEEP/SOAP security parameters to > transport-independent parameters (securityname/level/model) that can > then be passed in an RPC for purposes of access control. > > Is there additional value in and over and > ? Yes. They provide a specialized RPC interface that is > specially designed to use an XSD-to-MIB data mapping, and can be > extended to support the SNMP-specific access control interface, > without forcing and and other netconf operations > to use the same XSD data models or the same access control interface. > As Martin pointed out, the regular can be used because the element is in a specific namespace, and it doesn't interfere with anything else. This element is just another data model root, like the element we've seen in many examples. The NETCONF interface to the SNMP Set PDU (mib-set RPC in your draft) is problematic, since RowStatus and the operation attribute do not mix. It might be possible to use edit-config by treating 'merge' and 'replace' operations as just a 'write' operation in SNMP, and leaving out RowStatus completely. Either that, or use RowStatus and leave the operation attribute out completely (i.e., use a special RPC, not ). > Of course, if the netconf community wants to redefine and > to take securityName/level/model parameters for access > control for and , then there would be no additional > value in the / specialized RPCs. I have not seen > much indication that the netconf community wants to do this, so we > have suggested the use of specialized RPCs to "contain" this extra > functionality. > > If the netconf community is interested in seeing mappings from the > transport-security-specific authentication mechanisms to > transport-security-independent parameters (which for consistency with > SNMP I would call securityName, securityLevel, and securityModel), I > can certainly help specify those mappings, working with the > netconf-transport document authors, and then work with Yan to extend > the and RPCs (or and ) to > include them. > >> The examples have a lot of XML attributes and underlying data model >> assumptions that are not explained. These are the missing details >> that implementors need to support this proposal in running code. > > Agreed. Hopefully, the SMI-to-XSD translation will be documented by > Thorsten and Frank, and we can clean up any text with other > assumptions. > >> Isn't 'max-repetitions' used in SNMP to deal with UDP limitations? >> Introducing it in NETCONF as a new control in subtree filtering, >> and embellishing subtree filtering instead of using Xpath, >> does not seem like a good idea to me. > > Eliminating max-repetitions from the proposal has been under > discussion, but has not been removed yet. How is get-next accomplished? This is the data model discovery mechanism in SNMP. Is a on the entire agent (or subtree) the only mechanism needed? > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 03:25:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4CI2-0001K0-Lu; Tue, 09 Jan 2007 03:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4CI1-0001GM-Lb for ngo@ietf.org; Tue, 09 Jan 2007 03:25:01 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4CHz-00049g-BB for ngo@ietf.org; Tue, 09 Jan 2007 03:25:01 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6C5F857A0A; Tue, 9 Jan 2007 09:24:56 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08156-08; Tue, 9 Jan 2007 09:24:53 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 24A1957417; Tue, 9 Jan 2007 09:24:53 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 64F10961A07; Tue, 9 Jan 2007 09:24:51 +0100 (CET) Date: Tue, 9 Jan 2007 09:24:50 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt Message-ID: <20070109082450.GA4233@noname> References: <276701c73396$5b92d950$0600a8c0@china.huawei.com> <45A3050B.2070201@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45A3050B.2070201@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'NETCONF Goes On' X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org On Mon, Jan 08, 2007 at 06:59:23PM -0800, Andy Bierman wrote: > The NETCONF interface to the SNMP Set PDU (mib-set RPC in your draft) > is problematic, since RowStatus and the operation attribute do not mix. > It might be possible to use edit-config by treating 'merge' and 'replace' > operations as just a 'write' operation in SNMP, and leaving out RowStatus > completely. Either that, or use RowStatus and leave the operation attribute > out completely (i.e., use a special RPC, not ). Tweaking semantics is broken and I guess this is why the ID suggests new operations ( and ). Some CLIs of some of our devices has similar primitives... > How is get-next accomplished? > This is the data model discovery mechanism in SNMP. > Is a on the entire agent (or subtree) the only mechanism needed? The question is whether it is really needed since we have more powerful filtering mechanisms in netconf. If someone insists in using SNMP primitives, he/she should probably best talk SNMP. (And hence I am also not convinced of keeping the max-repetitions idea.) /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 04:56:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4DiU-0005nV-D0; Tue, 09 Jan 2007 04:56:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4DiS-0005mr-NN for ngo@ietf.org; Tue, 09 Jan 2007 04:56:24 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4DiM-0001Hz-U0 for ngo@ietf.org; Tue, 09 Jan 2007 04:56:24 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBL004JSHQK3S@szxga02-in.huawei.com> for ngo@ietf.org; Tue, 09 Jan 2007 17:44:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JBL005GXHQKBE@szxga02-in.huawei.com> for ngo@ietf.org; Tue, 09 Jan 2007 17:44:44 +0800 (CST) Received: from l48181 ([10.111.12.59]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBL000HWHQG4I@szxml03-in.huawei.com> for ngo@ietf.org; Tue, 09 Jan 2007 17:44:44 +0800 (CST) Date: Tue, 09 Jan 2007 17:44:40 +0800 From: Li Yan Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00 In-reply-to: <20070108.225422.124671848.mbj@tail-f.com> To: 'Martin Bjorklund' , ngo@ietf.org Message-id: <000c01c733d2$c8f02ac0$3b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acczb54W8ER+1d/MSAKiD4JXqiv3DAAYWjBw X-Spam-Score: 0.5 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi martin, I consider that the MIB data and the NETCONF data should be separated. Because MIBs and NETCONF data model are two different data models, they = are independent each other, their content may overlap. Therefore, = can only retrieve the MIB data=A3=ACwhile can only retrieve the true = NETCONF data. Otherwise, when a NETCONF client want to retrieve all NETCONF data = by a operation, a parameter must be used to exclude all MIB data. >From the point of view of implementation, the mechanisms of retrieving = the MIB data and the NETCONF data are totally different. So I use operations instead of the parameter to determine which mechanism of = retrieving data should be adopted. RowStatus object should be ignored. The 'create' value of operation attribute is treated as 'createAndGo', and the 'delete' value of = operation attribute is treated as 'destroy'. Thanks for your comments. Yan > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, January 09, 2007 5:54 AM > To: ngo@ietf.org > Subject: [NGO] comments on draft-li-ngo-access-mib-00 >=20 > Hi, >=20 > I don't understand why a new rpc method is needed. Why = can't > the normal method be used? >=20 > I could possibly understand, but not the way it's defined. > Specifically, how is the operation attribute supposed to be used in > combination with RowStatus objects? >=20 > In general I think that these MIB request can be done using the normal > netconf operations, as long as the XML mapping is well-defined. > I.e. given a standard MIB, what will the XML look like (namespace URI, > element structure, attribute uses, datatype represention). This part > isn't covered in the draft (just a reference to smidump). >=20 >=20 > /martin >=20 _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 08:09:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4GjM-0000s4-02; Tue, 09 Jan 2007 08:09:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4GjL-0000rz-OM for ngo@ietf.org; Tue, 09 Jan 2007 08:09:31 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Gj9-0007zT-O9 for ngo@ietf.org; Tue, 09 Jan 2007 08:09:31 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBL00KPNQIIWS@szxga02-in.huawei.com> for ngo@ietf.org; Tue, 09 Jan 2007 20:54:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JBL00AY8QIIWP@szxga02-in.huawei.com> for ngo@ietf.org; Tue, 09 Jan 2007 20:54:18 +0800 (CST) Received: from l48181 ([10.111.12.59]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBL00888QIFMK@szxml03-in.huawei.com> for ngo@ietf.org; Tue, 09 Jan 2007 20:54:18 +0800 (CST) Date: Tue, 09 Jan 2007 20:54:15 +0800 From: Li Yan Subject: RE: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt In-reply-to: <45A3050B.2070201@andybierman.com> To: 'Andy Bierman' Message-id: <001b01c733ed$4496fcc0$3b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcczmkptLLcLNYZ8RxeO1c9nB9hjDQAQKj2w X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'NETCONF Goes On' X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi Andy, There are multiple data model roots in both NETCONF data model and XML-formatted MIBs. If I need to retrieve entire NETCONF data or entire MIB data from a device, I have to enumerate all root elements of data model that are supported by the device in the parameter. It is a trouble. So the separation of NETCONF data and MIB data is meaningful. Yan > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Tuesday, January 09, 2007 10:59 AM > To: David Harrington > Cc: 'NETCONF Goes On' > Subject: Re: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt > > [...] > As Martin pointed out, the regular can be used > because the element is in a specific namespace, > and it doesn't interfere with anything else. This element > is just another data model root, like the element > we've seen in many examples. > [...] > > Andy > > _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 08:17:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4GrK-0004kn-RL; Tue, 09 Jan 2007 08:17:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4GrI-0004ki-TL for ngo@ietf.org; Tue, 09 Jan 2007 08:17:44 -0500 Received: from omr9.networksolutionsemail.com ([205.178.146.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4GrH-00024A-Jr for ngo@ietf.org; Tue, 09 Jan 2007 08:17:44 -0500 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l09DHe1M003277 for ; Tue, 9 Jan 2007 08:17:41 -0500 Received: (qmail 16146 invoked by uid 78); 9 Jan 2007 13:17:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 9 Jan 2007 13:17:40 -0000 Message-ID: <45A395D6.3040907@andybierman.com> Date: Tue, 09 Jan 2007 05:17:10 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Li Yan Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00 References: <000c01c733d2$c8f02ac0$3b0c6f0a@china.huawei.com> In-Reply-To: <000c01c733d2$c8f02ac0$3b0c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by omr9.networksolutionsemail.com id l09DHe1M003277 X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Li Yan wrote: > Hi martin, > I consider that the MIB data and the NETCONF data should be separated. > Because MIBs and NETCONF data model are two different data models, they= are > independent each other, their content may overlap. Therefore, = can > only retrieve the MIB data=A3=ACwhile can only retrieve the true = NETCONF > data. Otherwise, when a NETCONF client want to retrieve all NETCONF dat= a by > a operation, a parameter must be used to exclude all MIB > data. >>From the point of view of implementation, the mechanisms of retrieving = the > MIB data and the NETCONF data are totally different. So I use operation= s > instead of the parameter to determine which mechanism of retri= eving > data should be adopted. I disagree with this POV. We should not have SNMP data, SYSLOG data, and NETCONF data, all with their own special access functions. We just have data, which happens to be traditionally delivered with a particular protocol. Juergen has pointed out in the past that our operation is just another filter, so we don't really need it. We kept it because it is a very important filter to operators. But the distinction between and is not the same as . The filter applies to all namespaces and all data. It is a filter based on the characteristics of the data being retrieved, not the characteristics of a protocol that traditionally carries the data. Since the element defines a namespace and data root for "MIB data", the special RPC is totally redundant. The real issue is "what problem are you trying to solve"? Is this supposed to be a mechanism to manipulate XML/MIB data (derived from SMI-based schema) with NETCONF operations, or is it a mechanism to tunnel SNMP protocol operations through the NETCONF protocol? I think it is supposed to be the former, and therefore several decisions have to be made (e.g., how to move RowStatus and StorageType data to NETCONF operations, how to encode INDEX clauses, how to deal with data in different contexts). MaxRepetitions and even GetNext/GetBulk operations are not relevant to NETCONF. We need a standard which specifies the details of "smidump --format=3Dxsd", and not much else (ignoring VACM for the moment ;-). Ideally, there would not need to even be an wrapper, and could be just another data model in just another namespace, and not be treated special. This is probably not possible though, without moving the attributes to the RPC method as parameters. >=20 > RowStatus object should be ignored. The 'create' value of operation > attribute is treated as 'createAndGo', and the 'delete' value of operat= ion > attribute is treated as 'destroy'. >=20 Yes -- but a standard needs to detail how this is accomplished. > Thanks for your comments. >=20 > Yan Andy >> -----Original Message----- >> From: Martin Bjorklund [mailto:mbj@tail-f.com] >> Sent: Tuesday, January 09, 2007 5:54 AM >> To: ngo@ietf.org >> Subject: [NGO] comments on draft-li-ngo-access-mib-00 >> >> Hi, >> >> I don't understand why a new rpc method is needed. Why can'= t >> the normal method be used? >> >> I could possibly understand, but not the way it's defined. >> Specifically, how is the operation attribute supposed to be used in >> combination with RowStatus objects? >> >> In general I think that these MIB request can be done using the normal >> netconf operations, as long as the XML mapping is well-defined. >> I.e. given a standard MIB, what will the XML look like (namespace URI, >> element structure, attribute uses, datatype represention). This part >> isn't covered in the draft (just a reference to smidump). >> >> >> /martin >> >=20 >=20 >=20 > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo >=20 >=20 _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 08:26:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4GzW-0007yA-Un; Tue, 09 Jan 2007 08:26:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4GzV-0007xb-8g for ngo@ietf.org; Tue, 09 Jan 2007 08:26:13 -0500 Received: from omr9.networksolutionsemail.com ([205.178.146.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4GzT-0005N8-Ur for ngo@ietf.org; Tue, 09 Jan 2007 08:26:13 -0500 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l09DQBjV010109 for ; Tue, 9 Jan 2007 08:26:11 -0500 Received: (qmail 19867 invoked by uid 78); 9 Jan 2007 13:26:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 9 Jan 2007 13:26:10 -0000 Message-ID: <45A397D5.5060409@andybierman.com> Date: Tue, 09 Jan 2007 05:25:41 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Li Yan Subject: Re: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt References: <001b01c733ed$4496fcc0$3b0c6f0a@china.huawei.com> In-Reply-To: <001b01c733ed$4496fcc0$3b0c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'NETCONF Goes On' X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Li Yan wrote: > Hi Andy, > There are multiple data model roots in both NETCONF data model and > XML-formatted MIBs. If I need to retrieve entire NETCONF data or entire MIB > data from a device, I have to enumerate all root elements of data model that > are supported by the device in the parameter. It is a trouble. So > the separation of NETCONF data and MIB data is meaningful. > I don't think it is a long-term useful feature. If I have a NETCONF application that manages bandwidth rate limiting, what do I care if the "number of bytes received on the interface" came from "ifInOctets" or some other variable that does not have an origin in MIBs? What if the data model had an object called "bytes-received"? Why is it useful to have this MIB data filter, so I can receive "ifInOctets" but not the "bytes-received" element? IMO, this is not an important distinction to maintain in the NETCONF API. > Yan Andy > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Tuesday, January 09, 2007 10:59 AM >> To: David Harrington >> Cc: 'NETCONF Goes On' >> Subject: Re: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt >> >> [...] >> As Martin pointed out, the regular can be used >> because the element is in a specific namespace, >> and it doesn't interfere with anything else. This element >> is just another data model root, like the element >> we've seen in many examples. >> [...] >> >> Andy >> >> > > > > _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 08:39:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4HC5-0005Qr-Ip; Tue, 09 Jan 2007 08:39:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4HC4-0005Qf-ER for ngo@ietf.org; Tue, 09 Jan 2007 08:39:12 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4HC2-00080a-3R for ngo@ietf.org; Tue, 09 Jan 2007 08:39:12 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l09Dd2kW028313 for ; Tue, 9 Jan 2007 08:39:03 -0500 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: [NGO] comments on draft-li-ngo-access-mib-00 Date: Tue, 9 Jan 2007 15:39:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NGO] comments on draft-li-ngo-access-mib-00 Thread-Index: Accz8OVbZ87SiphRT0uQkQ+dMFhT4gAAaItg From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Li Yan" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org =20 =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > The real issue is "what problem are you trying to solve"? >=20 > Is this supposed to be a mechanism to manipulate XML/MIB data=20 > (derived from SMI-based schema) with NETCONF operations, or=20 > is it a mechanism to tunnel SNMP protocol operations through=20 > the NETCONF protocol? >=20 > I think it is supposed to be the former, and therefore=20 > several decisions have to be made (e.g., how to move=20 > RowStatus and StorageType data to NETCONF operations, how to=20 > encode INDEX clauses, how to deal with data in different contexts). > MaxRepetitions and even GetNext/GetBulk operations are not=20 > relevant to NETCONF. >=20 This is coming close to a discussion that we should have sooner or later about what will be the operational model in networks that run NETCONF and how other protocols fit in this model. I believe that we vaguely agree that the model will be multi-protocol, but there are yet many aspects of what kind of data models support each, and if a common data model will support only data or also protocol operations. To some extent I believe that this proposal adopts the later approach, which is probably necessary in a transitional phase, but not necessarily long term.=20 > We need a standard which specifies the details of "smidump=20 > --format=3Dxsd", and not much else (ignoring VACM for the=20 > moment ;-). Ideally, there would not need to even be an=20 > wrapper, and could be just another data=20 > model in just another namespace, and not be treated special. > This is probably not possible though, without moving the=20 > attributes to the RPC method as parameters. >=20 >=20 Dan _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 11:47:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4K8K-00040Z-TJ; Tue, 09 Jan 2007 11:47:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4K8J-00040U-Ne for ngo@ietf.org; Tue, 09 Jan 2007 11:47:31 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4K8F-00046S-57 for ngo@ietf.org; Tue, 09 Jan 2007 11:47:31 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 58B3FF3A; Tue, 9 Jan 2007 17:47:20 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 17:47:20 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 17:47:19 +0100 Message-ID: <45A3C716.2040306@ericsson.com> Date: Tue, 09 Jan 2007 17:47:18 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Li Yan Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00 References: <000c01c733d2$c8f02ac0$3b0c6f0a@china.huawei.com> In-Reply-To: <000c01c733d2$c8f02ac0$3b0c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 X-OriginalArrivalTime: 09 Jan 2007 16:47:19.0324 (UTC) FILETIME=[D3A2F5C0:01C7340D] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hello Li, Could you please explain somewhat why did you leave out merge and none fr= om your draft. In my experience network operators like to see the device as having just = one configuration and want to see all configuration data on all it's interfaces. If we start pa= rtitioning the configuration data: this data can only be seen with method/protocol A tha= t data can only be manipulated with method B, they will hate us. Due to this customer requirement on me I dream of a world where we have o= ne data model and a number of interfaces/methods that all see the same thing. Separating MIB = data and Netconf data doesn't go in this direction. Balazs Li Yan wrote: > Hi martin, > I consider that the MIB data and the NETCONF data should be separated. > Because MIBs and NETCONF data model are two different data models, they= are > independent each other, their content may overlap. Therefore, = can > only retrieve the MIB data=A3=ACwhile can only retrieve the true = NETCONF > data. Otherwise, when a NETCONF client want to retrieve all NETCONF dat= a by > a operation, a parameter must be used to exclude all MIB > data. >>From the point of view of implementation, the mechanisms of retrieving = the > MIB data and the NETCONF data are totally different. So I use operation= s > instead of the parameter to determine which mechanism of retri= eving > data should be adopted. >=20 > RowStatus object should be ignored. The 'create' value of operation > attribute is treated as 'createAndGo', and the 'delete' value of operat= ion > attribute is treated as 'destroy'. >=20 > Thanks for your comments. >=20 > Yan _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 22:12:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Tsz-0008Gi-69; Tue, 09 Jan 2007 22:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Tsx-0008Gc-6D for ngo@ietf.org; Tue, 09 Jan 2007 22:12:19 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Tsi-0001AD-96 for ngo@ietf.org; Tue, 09 Jan 2007 22:12:19 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBM001N1TWMZA@szxga04-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 11:05:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBM008ZMTWMVM@szxga04-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 11:05:10 +0800 (CST) Received: from m03573B ([10.111.12.130]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBM000IBTWI3J@szxml04-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 11:05:10 +0800 (CST) Date: Wed, 10 Jan 2007 11:05:06 +0800 From: Ma Yuzhi Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00 In-reply-to: To: "'Romascanu, Dan (Dan)'" , 'Andy Bierman' Message-id: <007e01c73464$2176db80$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Accz8OVbZ87SiphRT0uQkQ+dMFhT4gAAaItgABjnIJA= X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi, smidump Transitional Phase: SMIv1/v2 MIB ---------------------> XSD MIB \ \ \ Long term target: -------------> New MIB for multi-protocol Base on the above assumption, here are some considerations: 1. If the XSD MIB and New MIB are quite distinct from each other, then there maybe need another transition which is a terrible thing. 2. Is it necessary to keep the compatibility (just like SMIv1 and SMIv2 MIB) between these two MIBs? Is this a possibility work? 3. Maybe a more powerful tool "smidump++" could help us to achieve middle term target which can keep balance between above targets. Thanks Yuzhi > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, January 09, 2007 9:39 PM > To: Andy Bierman; Li Yan > Cc: ngo@ietf.org > Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00 > > > > > > > > -----Original Message----- > > From: Andy Bierman [mailto:ietf@andybierman.com] The real issue is > > "what problem are you trying to solve"? > > > > Is this supposed to be a mechanism to manipulate XML/MIB > data (derived > > from SMI-based schema) with NETCONF operations, or is it a > mechanism > > to tunnel SNMP protocol operations through the NETCONF protocol? > > > > I think it is supposed to be the former, and therefore several > > decisions have to be made (e.g., how to move RowStatus and > StorageType > > data to NETCONF operations, how to encode INDEX clauses, > how to deal > > with data in different contexts). > > MaxRepetitions and even GetNext/GetBulk operations are not > relevant to > > NETCONF. > > > > This is coming close to a discussion that we should have > sooner or later about what will be the operational model in > networks that run NETCONF and how other protocols fit in this > model. I believe that we vaguely agree that the model will be > multi-protocol, but there are yet many aspects of what kind > of data models support each, and if a common data model will > support only data or also protocol operations. To some extent > I believe that this proposal adopts the later approach, which > is probably necessary in a transitional phase, but not > necessarily long term. > > > We need a standard which specifies the details of "smidump > > --format=xsd", and not much else (ignoring VACM for the > moment ;-). > > Ideally, there would not need to even be an > wrapper, and > > could be just another data model in just another > namespace, > > and not be treated special. > > This is probably not possible though, without moving the > > > attributes to the RPC method as parameters. > > > > > > Dan > > > > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo > _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 23:06:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UjT-0005EV-VJ; Tue, 09 Jan 2007 23:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UjS-0005EQ-QY for ngo@ietf.org; Tue, 09 Jan 2007 23:06:34 -0500 Received: from omr4.networksolutionsemail.com ([205.178.146.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4UjR-0006UX-EV for ngo@ietf.org; Tue, 09 Jan 2007 23:06:34 -0500 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l0A46Wt2016454 for ; Tue, 9 Jan 2007 23:06:33 -0500 Received: (qmail 24560 invoked by uid 78); 10 Jan 2007 04:06:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 10 Jan 2007 04:06:32 -0000 Message-ID: <45A46645.3010806@andybierman.com> Date: Tue, 09 Jan 2007 20:06:29 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Ma Yuzhi Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00 References: <007e01c73464$2176db80$820c6f0a@china.huawei.com> In-Reply-To: <007e01c73464$2176db80$820c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Ma Yuzhi wrote: > Hi, > > smidump > Transitional Phase: SMIv1/v2 MIB ---------------------> XSD MIB > > \ > > \ > > \ > Long term target: > -------------> New MIB for multi-protocol > > > Base on the above assumption, here are some considerations: > 1. If the XSD MIB and New MIB are quite distinct from each other, then there > maybe need another transition which is a terrible thing. > 2. Is it necessary to keep the compatibility (just like SMIv1 and SMIv2 MIB) > between these two MIBs? Is this a possibility work? > 3. Maybe a more powerful tool "smidump++" could help us to achieve middle > term target which can keep balance between above targets. > I'm not sure we have much consensus on what the "New MIB" looks like, or that the "MIB" is even the focus of the new programmatic interface. We should keep hammering on the Interfaces MIB examples, because that is one of the most important feature of an NE device. IMO, the "new" Interfaces MIB would not strictly follow the IF*-MIB. For example, why split the ifTable and ifXTable? They are only separate because they were created years apart. Why not use a real tree instead of the ifStackTable? How about some standard methods for interface services, like install, uninstall, start, stop, restart, status, etc? How about a mechanism to determine what parameters are actually configurable on a particular interface instance? The smidump++ program can't figure out how to make these sorts of changes. As a transition mechanism, the existing smidump translation is good enough for "direct" access with the NETCONF protocol. As for the edit-config operation attribute, I have always said it is a data model specific matter whether all of the enumerations were supported. It would be ideal if these operations were always supported the same way on every object, but some data models (e.g., CLI and SNMP transition data models) do not use those operations, and "merge" is always assumed instead. (Not pretty but it works.) Note that if the default-operation is left alone (default is 'merge'), then the complete absence of the 'operation' attribute in the element will have the same (correct) outcome. For the transition model, the standard operations can be used (without the operation attribute), and RowStatus used to create and delete rows. > Thanks > Yuzhi Andy > >> -----Original Message----- >> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >> Sent: Tuesday, January 09, 2007 9:39 PM >> To: Andy Bierman; Li Yan >> Cc: ngo@ietf.org >> Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00 >> >> >> >> >> >> >>> -----Original Message----- >>> From: Andy Bierman [mailto:ietf@andybierman.com] The real issue is >>> "what problem are you trying to solve"? >>> >>> Is this supposed to be a mechanism to manipulate XML/MIB >> data (derived >>> from SMI-based schema) with NETCONF operations, or is it a >> mechanism >>> to tunnel SNMP protocol operations through the NETCONF protocol? >>> >>> I think it is supposed to be the former, and therefore several >>> decisions have to be made (e.g., how to move RowStatus and >> StorageType >>> data to NETCONF operations, how to encode INDEX clauses, >> how to deal >>> with data in different contexts). >>> MaxRepetitions and even GetNext/GetBulk operations are not >> relevant to >>> NETCONF. >>> >> This is coming close to a discussion that we should have >> sooner or later about what will be the operational model in >> networks that run NETCONF and how other protocols fit in this >> model. I believe that we vaguely agree that the model will be >> multi-protocol, but there are yet many aspects of what kind >> of data models support each, and if a common data model will >> support only data or also protocol operations. To some extent >> I believe that this proposal adopts the later approach, which >> is probably necessary in a transitional phase, but not >> necessarily long term. >> >>> We need a standard which specifies the details of "smidump >>> --format=xsd", and not much else (ignoring VACM for the >> moment ;-). >>> Ideally, there would not need to even be an >> wrapper, and >>> could be just another data model in just another >> namespace, >>> and not be treated special. >>> This is probably not possible though, without moving the >> >>> attributes to the RPC method as parameters. >>> >>> >> Dan >> >> >> >> _______________________________________________ >> NGO mailing list >> NGO@ietf.org >> https://www1.ietf.org/mailman/listinfo/ngo >> > > > > _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Jan 09 23:10:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UnZ-00068D-JD; Tue, 09 Jan 2007 23:10:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UnY-000683-5u for ngo@ietf.org; Tue, 09 Jan 2007 23:10:48 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4UnR-0007lR-P7 for ngo@ietf.org; Tue, 09 Jan 2007 23:10:48 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBM00IN0WND7H@szxga02-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 12:04:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JBM001YPWNB04@szxga02-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 12:04:25 +0800 (CST) Received: from m03573B ([10.111.12.130]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBM000FSWN7UJ@szxml04-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 12:04:23 +0800 (CST) Date: Wed, 10 Jan 2007 12:04:19 +0800 From: Ma Yuzhi Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00 In-reply-to: <007e01c73464$2176db80$820c6f0a@china.huawei.com> To: "'Romascanu, Dan (Dan)'" , 'Andy Bierman' Message-id: <008c01c7346c$679f1660$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: Accz8OVbZ87SiphRT0uQkQ+dMFhT4gAAaItgABjnIJAABHPAkA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992995536==" Errors-To: ngo-bounces@ietf.org This is a multi-part message in MIME format. --===============0992995536== Content-type: multipart/alternative; boundary="Boundary_(ID_ONfAJvdjzvXPNK8j0R6Oyw)" This is a multi-part message in MIME format. --Boundary_(ID_ONfAJvdjzvXPNK8j0R6Oyw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Sorry,the chart of previous email have some problems, I convert it to HTML formal smidump Transitional Phase: SMIv1/v2 MIB ---------------------> XSD MIB \ \ \ Long term target: -------------> New MIB for multi-protocol Base on the above assumption, here are some considerations: 1. If the XSD MIB and New MIB are quite distinct from each other, then there maybe need another transition which is a terrible thing. 2. Is it necessary to keep the compatibility (just like SMIv1 and SMIv2 MIB) between these two MIBs? Is this a possibility work? 3. Maybe a more powerful tool "smidump++" could help us to achieve middle term target which can keep balance between above targets. Thanks Yuzhi > -----Original Message----- > From: Ma Yuzhi [mailto:myz@huawei.com] > Sent: Wednesday, January 10, 2007 11:05 AM > To: 'Romascanu, Dan (Dan)'; 'Andy Bierman' > Cc: ngo@ietf.org > Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00 > > Hi, > > > smidump Transitional Phase: SMIv1/v2 MIB > ---------------------> XSD MIB > > \ > > \ > > \ > Long term target: > -------------> New MIB for multi-protocol > > > Base on the above assumption, here are some considerations: > 1. If the XSD MIB and New MIB are quite distinct from each > other, then there maybe need another transition which is a > terrible thing. > 2. Is it necessary to keep the compatibility (just like SMIv1 > and SMIv2 MIB) between these two MIBs? Is this a possibility work? > 3. Maybe a more powerful tool "smidump++" could help us to > achieve middle term target which can keep balance between > above targets. > > Thanks > Yuzhi > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, January 09, 2007 9:39 PM > > To: Andy Bierman; Li Yan > > Cc: ngo@ietf.org > > Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Andy Bierman [mailto:ietf@andybierman.com] The real > issue is > > > "what problem are you trying to solve"? > > > > > > Is this supposed to be a mechanism to manipulate XML/MIB > > data (derived > > > from SMI-based schema) with NETCONF operations, or is it a > > mechanism > > > to tunnel SNMP protocol operations through the NETCONF protocol? > > > > > > I think it is supposed to be the former, and therefore several > > > decisions have to be made (e.g., how to move RowStatus and > > StorageType > > > data to NETCONF operations, how to encode INDEX clauses, > > how to deal > > > with data in different contexts). > > > MaxRepetitions and even GetNext/GetBulk operations are not > > relevant to > > > NETCONF. > > > > > > > This is coming close to a discussion that we should have sooner or > > later about what will be the operational model in networks that run > > NETCONF and how other protocols fit in this model. I > believe that we > > vaguely agree that the model will be multi-protocol, but > there are yet > > many aspects of what kind of data models support each, and > if a common > > data model will support only data or also protocol > operations. To some > > extent I believe that this proposal adopts the later > approach, which > > is probably necessary in a transitional phase, but not necessarily > > long term. > > > > > We need a standard which specifies the details of "smidump > > > --format=xsd", and not much else (ignoring VACM for the > > moment ;-). > > > Ideally, there would not need to even be an > > wrapper, and > > > could be just another data model in just another > > namespace, > > > and not be treated special. > > > This is probably not possible though, without moving the > > > > > attributes to the RPC method as parameters. > > > > > > > > > > Dan > > > > > > > > _______________________________________________ > > NGO mailing list > > NGO@ietf.org > > https://www1.ietf.org/mailman/listinfo/ngo > > > > > > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo > --Boundary_(ID_ONfAJvdjzvXPNK8j0R6Oyw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

Sorry,the chart of previous email=20 have some problems, I convert it to HTML formal 

         &nb= sp;           &nbs= p;            = ;   =20 smidump

Transitional Phase:  SMIv1/v2=20 MIB ---------------------> XSD=20 MIB
           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  \
         =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     \
      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        =20 \  
Long term=20 target:           =             &= nbsp;=20 -------------> New MIB for = multi-protocol


 

Base on the above = assumption, here are some=20 considerations:
1. If the XSD MIB and New MIB are quite distinct from = each=20 other, then there maybe need another transition which is a terrible = thing.
2.=20 Is it necessary to keep the compatibility (just like SMIv1 and SMIv2 = MIB)=20 between these two MIBs?  Is this a possibility work?
3. Maybe a = more=20 powerful tool "smidump++" could help us to  achieve middle term = target=20 which can keep balance between above targets.

Thanks
Yuzhi


>=20 -----Original Message-----
> From: Ma Yuzhi [mailto:myz@huawei.com]
> Sent: = Wednesday,=20 January 10, 2007 11:05 AM
> To: 'Romascanu, Dan (Dan)'; 'Andy=20 Bierman'
> Cc: ngo@ietf.org
> Subject: RE: [NGO] comments on = draft-li-ngo-access-mib-00
>
>=20 Hi,
>
>         =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;    
>    =20 smidump Transitional Phase:  SMIv1/v2 MIB
> = --------------------->=20 XSD MIB
> 
> \
> 
> = \
> 
>=20 \  
> Long term target:
> -------------> New = MIB for=20 multi-protocol
>
>
> Base on the above assumption, = here are=20 some considerations:
> 1. If the XSD MIB and New MIB are quite = distinct=20 from each
> other, then there maybe need another transition which = is=20 a
> terrible thing.
> 2. Is it necessary to keep the = compatibility=20 (just like SMIv1
> and SMIv2 MIB) between these two MIBs?  Is = this a=20 possibility work?
> 3. Maybe a more powerful tool "smidump++" = could help=20 us to 
> achieve middle term target which can keep balance=20 between
> above targets.
>
> Thanks
>=20 Yuzhi
>
> > -----Original Message-----
> > From: = Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
>= >=20 Sent: Tuesday, January 09, 2007 9:39 PM
> > To: Andy Bierman; = Li=20 Yan
> > Cc: ngo@ietf.org
> > Subject: RE: [NGO] = comments on=20 draft-li-ngo-access-mib-00
> >
> >
> = >
>=20 > 
> > 
> >
> > > = -----Original=20 Message-----
> > > From: Andy Bierman [mailto:ietf@andybierman.com] = The=20 real
> issue is
> > > "what problem are you trying to=20 solve"?
> > >
> > > Is this supposed to be a = mechanism=20 to manipulate XML/MIB
> > data (derived
> > > from=20 SMI-based schema) with NETCONF operations, or is it a
> >=20 mechanism
> > > to tunnel SNMP protocol operations through = the=20 NETCONF protocol?
> > >
> > > I think it is = supposed to=20 be the former, and therefore several
> > > decisions have to = be made=20 (e.g., how to move RowStatus and
> > StorageType
> > = > data=20 to NETCONF operations, how to encode INDEX clauses,
> > how to=20 deal
> > > with data in different contexts).
> > = >=20 MaxRepetitions and even GetNext/GetBulk operations are not
> > = relevant=20 to
> > > NETCONF.
> > >
> >
> = > This=20 is coming close to a discussion that we should have sooner or
> = > later=20 about what will be the operational model in networks that run
> = >=20 NETCONF and how other protocols fit in this model. I
> believe = that=20 we
> > vaguely agree that the model will be multi-protocol, = but
>=20 there are yet
> > many aspects of what kind of data models = support=20 each, and
> if a common
> > data model will support only = data or=20 also protocol
> operations. To some
> > extent I believe = that=20 this proposal adopts the later
> approach, which
> > is = probably=20 necessary in a transitional phase, but not necessarily
> > long = term.
> >
> > > We need a standard which specifies = the=20 details of "smidump
> > > --format=3Dxsd", and not much else = (ignoring=20 VACM for the
> > moment ;-). 
> > > Ideally, = there=20 would not need to even be an <snmp-data>
> > wrapper, = and
>=20 > > <ifTable> could be just another data model in just=20 another
> > namespace,
> > > and not be treated=20 special.
> > > This is probably not possible though, without = moving=20 the
> > <snmp-data>
> > > attributes to the = RPC=20 method as parameters.
> > >
> > >
> = >
>=20 > Dan
> >
> >
> >
> >=20 _______________________________________________
> > NGO mailing = list
> > NGO@ietf.org
> > https://www1.ietf.org= /mailman/listinfo/ngo
>=20 >
>
>
>
>=20 _______________________________________________
> NGO mailing = list
>=20 NGO@ietf.org
> https://www1.ietf.org= /mailman/listinfo/ngo
>=20

--Boundary_(ID_ONfAJvdjzvXPNK8j0R6Oyw)-- --===============0992995536== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo --===============0992995536==-- From ngo-bounces@ietf.org Wed Jan 10 04:11:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ZU1-00016K-E6; Wed, 10 Jan 2007 04:10:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ZU0-00015u-7S for ngo@ietf.org; Wed, 10 Jan 2007 04:10:56 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4ZTm-0004Kh-5K for ngo@ietf.org; Wed, 10 Jan 2007 04:10:56 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBN00KUUAHVTQ@szxga02-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 17:03:32 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JBN000QHAHVAA@szxga02-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 17:03:31 +0800 (CST) Received: from l48181 ([10.111.12.59]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBN00BS6AHRGL@szxml03-in.huawei.com> for ngo@ietf.org; Wed, 10 Jan 2007 17:03:31 +0800 (CST) Date: Wed, 10 Jan 2007 17:03:27 +0800 From: Li Yan Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00 In-reply-to: <45A3C716.2040306@ericsson.com> To: 'Balazs Lengyel' Message-id: <003501c73496$31440ab0$3b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acc0Dd2TABkQriddS1u7uCB7kB/X5wAW8hIg X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi Balazs, I think that SNMP set operation has 3 senses: 1) Ordinarily set a value to a MIB object, it is equivalent to replace = an old value by a new value. 2) Set 'createAndGo' or 'createAndWait' to a RowStatus object, it is equivalent to create an entry instance. 3) Set 'destroy' to a RowStatus object, it is equivalent to delete an = entry instance. It seems 'merge' and 'replace' have the same meaning in SNMP world. I constrain 'delete 'to be applied for an entry element only. It = indicates explicitly the entry element to be deleted. So unintentionally deleting = the parent hierarchy of the element will not happen. Yan > -----Original Message----- > From: Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Wednesday, January 10, 2007 12:47 AM > To: Li Yan > Cc: 'Martin Bjorklund'; ngo@ietf.org > Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00 >=20 > Hello Li, > Could you please explain somewhat why did you leave out merge and none from > your draft. >=20 > In my experience network operators like to see the device as having = just one > configuration and > want to see all configuration data on all it's interfaces. If we start > partitioning the > configuration data: this data can only be seen with method/protocol A = that data > can only be > manipulated with method B, they will hate us. > Due to this customer requirement on me I dream of a world where we = have one > data model and a > number of interfaces/methods that all see the same thing. Separating = MIB data > and Netconf data > doesn't go in this direction. > Balazs >=20 > Li Yan wrote: > > Hi martin, > > I consider that the MIB data and the NETCONF data should be = separated. > > Because MIBs and NETCONF data model are two different data models, = they are > > independent each other, their content may overlap. Therefore, = can > > only retrieve the MIB data=A3=ACwhile can only retrieve the = true NETCONF > > data. Otherwise, when a NETCONF client want to retrieve all NETCONF = data by > > a operation, a parameter must be used to exclude all = MIB > > data. > >>From the point of view of implementation, the mechanisms of = retrieving the > > MIB data and the NETCONF data are totally different. So I use = operations > > instead of the parameter to determine which mechanism of retrieving > > data should be adopted. > > > > RowStatus object should be ignored. The 'create' value of operation > > attribute is treated as 'createAndGo', and the 'delete' value of operation > > attribute is treated as 'destroy'. > > > > Thanks for your comments. > > > > Yan _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Wed Jan 10 08:03:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4d6q-0000AM-I0; Wed, 10 Jan 2007 08:03:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4d6p-0000AE-4I for ngo@ietf.org; Wed, 10 Jan 2007 08:03:15 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4d6Y-0004TZ-42 for ngo@ietf.org; Wed, 10 Jan 2007 08:03:15 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0AD2uvx014683 for ; Wed, 10 Jan 2007 08:02:57 -0500 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: [NGO] comments on draft-li-ngo-access-mib-00 Date: Wed, 10 Jan 2007 15:02:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NGO] comments on draft-li-ngo-access-mib-00 Thread-Index: Acc0gtc923T/84TxTpmGHkdOiqT3awANDthQ From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Ma Yuzhi" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org =20 =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 >=20 > IMO, the "new" Interfaces MIB would not strictly follow the IF*-MIB. > For example, why split the ifTable and ifXTable? They are=20 > only separate because they were created years apart. Why not=20 > use a real tree instead of the ifStackTable? How about some=20 > standard methods for interface services, like install,=20 > uninstall, start, stop, restart, status, etc? How about a=20 > mechanism to determine what parameters are actually=20 > configurable on a particular interface instance? >=20 Sure. Without these or most of these we would have missed one of the principal reasons of doing NETCONF.=20 Now, how do we get from here to there? It is allowed to rock the boat I believe, but we cannot afford drying up the whole ocean.=20 Dan _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Wed Jan 10 12:57:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hhJ-0006sy-11; Wed, 10 Jan 2007 12:57:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hhH-0006ss-7Q for ngo@ietf.org; Wed, 10 Jan 2007 12:57:11 -0500 Received: from omr9.networksolutionsemail.com ([205.178.146.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hhF-0001bE-VU for ngo@ietf.org; Wed, 10 Jan 2007 12:57:11 -0500 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l0AHv9d9019783 for ; Wed, 10 Jan 2007 12:57:09 -0500 Received: (qmail 7508 invoked by uid 78); 10 Jan 2007 17:57:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 10 Jan 2007 17:57:08 -0000 Message-ID: <45A528F5.3070303@andybierman.com> Date: Wed, 10 Jan 2007 09:57:09 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Romascanu, Dan (Dan) wrote: > > > > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> >> IMO, the "new" Interfaces MIB would not strictly follow the IF*-MIB. >> For example, why split the ifTable and ifXTable? They are >> only separate because they were created years apart. Why not >> use a real tree instead of the ifStackTable? How about some >> standard methods for interface services, like install, >> uninstall, start, stop, restart, status, etc? How about a >> mechanism to determine what parameters are actually >> configurable on a particular interface instance? >> > > Sure. Without these or most of these we would have missed one of the > principal reasons of doing NETCONF. > > Now, how do we get from here to there? It is allowed to rock the boat I > believe, but we cannot afford drying up the whole ocean. I'm not sure how your mixed metaphors map to standards-based configuration, or if there is common understanding of the problem space. IMO, the new API has no need to support anything from the SNMP world except the ability to reuse the semantics of SMI data types, some TEXTUAL-CONVENTIONs, and perhaps some OBJECT-TYPE and NOTIFICATION-TYPE macros. The data structures and RPC methods that use them should not be constrained by how someone using SNMP would approach a solution. IMO, special RPCs serve 3 critical functions, that SNMP can't touch: 1) Ability to extend the standard verb set (e.g., start, stop, reset, ping) 2) Ability to encapsulate complex and multi-step procedures, and hide variances in the low-level details (e.g. create-vlan, add-bgp-peer, create-loopback). If the agent provided these high-level procedures, the NMS would not have to manage the dozens or even 100s of little differences in PDU order, acceptable value sets, error-codes, etc., in order to provide the same high-level procedures across all devices. 3) Ability to model actions and a "Set PDU with a return value". RPCs allow one to say "I don't care what the values of index X or parameter Y are; just return the values you picked in the response." I don't think the IETF would (or should) move in this direction unless and until vendors do the groundwork by creating new models that utilize this approach. I am concerned that the Ultimate Goal (everybody uses the same exact config-file/CLI/XML data models) is not going to be achievable, and therefore will not have a lot of standards-based configuration data to work on. I do not think this is a show-stopper. If we could agree on some high-level verbs (and their parameters), then it is less problematic if the XML blob saved in the element is not the same every time for every agent. Perhaps a combination of common standard parameters, standard verbs, and vendor extensions to both of them would be possible. If writable standard MIB objects already exist for a particular data model, then they should be used somehow, but not necessarily in the same MIB table form. > > Dan > > > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Wed Jan 10 13:18:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4i24-0000ov-1Q; Wed, 10 Jan 2007 13:18:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4i22-0000og-JA for ngo@ietf.org; Wed, 10 Jan 2007 13:18:38 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4i21-00040q-5C for ngo@ietf.org; Wed, 10 Jan 2007 13:18:38 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0AIIOBV004742 for ; Wed, 10 Jan 2007 13:18:25 -0500 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: [NGO] comments on draft-li-ngo-access-mib-00 Date: Wed, 10 Jan 2007 20:18:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NGO] comments on draft-li-ngo-access-mib-00 Thread-Index: Acc04M5RE+GrauRpS5G88QYls7fdTQAAj2tw From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org =20 =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Wednesday, January 10, 2007 7:57 PM > To: Romascanu, Dan (Dan) > Cc: Ma Yuzhi; ngo@ietf.org > Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00 >=20 > Romascanu, Dan (Dan) wrote: > >=20 > > =20 > > =20 > >=20 > >> -----Original Message----- > >> From: Andy Bierman [mailto:ietf@andybierman.com] > >> > >> IMO, the "new" Interfaces MIB would not strictly follow=20 > the IF*-MIB. > >> For example, why split the ifTable and ifXTable? They are only=20 > >> separate because they were created years apart. Why not=20 > use a real=20 > >> tree instead of the ifStackTable? How about some standard methods=20 > >> for interface services, like install, uninstall, start, stop,=20 > >> restart, status, etc? How about a mechanism to determine what=20 > >> parameters are actually configurable on a particular interface=20 > >> instance? > >> > >=20 > > Sure. Without these or most of these we would have missed=20 > one of the=20 > > principal reasons of doing NETCONF. > >=20 > > Now, how do we get from here to there? It is allowed to=20 > rock the boat=20 > > I believe, but we cannot afford drying up the whole ocean. >=20 > I'm not sure how your mixed metaphors map to standards-based=20 > configuration, or if there is common understanding of the=20 > problem space. IMO, the new API has no need to support=20 > anything from the SNMP world except the ability to reuse the=20 > semantics of SMI data types, some TEXTUAL-CONVENTIONs, and=20 > perhaps some OBJECT-TYPE and NOTIFICATION-TYPE macros. >=20 > The data structures and RPC methods that use them should not=20 > be constrained by how someone using SNMP would approach a solution. >=20 > IMO, special RPCs serve 3 critical functions, that SNMP can't touch: >=20 > 1) Ability to extend the standard verb set (e.g., start,=20 > stop, reset, ping) >=20 > 2) Ability to encapsulate complex and multi-step procedures, and hide > variances in the low-level details (e.g. create-vlan,=20 > add-bgp-peer, create-loopback). > If the agent provided these high-level procedures, the=20 > NMS would not > have to manage the dozens or even 100s of little=20 > differences in PDU order, > acceptable value sets, error-codes, etc., in order to=20 > provide the same > high-level procedures across all devices. >=20 > 3) Ability to model actions and a "Set PDU with a return value". > RPCs allow one to say "I don't care what the values > of index X or parameter Y are; just return the values you picked > in the response." >=20 > I don't think the IETF would (or should) move in this=20 > direction unless and until vendors do the groundwork by=20 > creating new models that utilize this approach. >=20 > I am concerned that the Ultimate Goal (everybody uses the=20 > same exact config-file/CLI/XML data models) is not going to=20 > be achievable, and therefore will not have a=20 > lot of standards-based configuration data to work on. I do=20 > not think this is a show-stopper. >=20 > If we could agree on some high-level verbs (and their=20 > parameters), then it is less problematic if the XML blob=20 > saved in the element is not the same every time for=20 > every agent. Perhaps a combination of common standard=20 > parameters, standard verbs, and vendor extensions to both of=20 > them would be possible. If writable standard MIB objects=20 > already exist for a particular data model, then they should=20 > be used somehow, but not necessarily in the same MIB table form. >=20 >=20 >=20 > >=20 > > Dan > >=20 > >=20 > >=20 >=20 > Andy >=20 So, in your view, what should the IETF do next?=20 - do work on the 'a combination of common standard parameters, standard verbs'? and/or - provide guidance and example to vendors about how to 'do the groundwork by creating new models that utilize this approach'? or - none of the above?=20 Dan _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Wed Jan 10 13:40:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iNC-0001rJ-Ij; Wed, 10 Jan 2007 13:40:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iNB-0001r8-F6 for ngo@ietf.org; Wed, 10 Jan 2007 13:40:29 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4iN5-0006uy-PV for ngo@ietf.org; Wed, 10 Jan 2007 13:40:29 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id E74F957D5A; Wed, 10 Jan 2007 19:40:22 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28688-08; Wed, 10 Jan 2007 19:40:19 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A57FE5627E; Wed, 10 Jan 2007 19:40:19 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id D8062996CF3; Wed, 10 Jan 2007 19:40:18 +0100 (CET) Date: Wed, 10 Jan 2007 19:40:18 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00 Message-ID: <20070110184018.GB19151@boskop.local> References: <000c01c733d2$c8f02ac0$3b0c6f0a@china.huawei.com> <45A395D6.3040907@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45A395D6.3040907@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org On Tue, Jan 09, 2007 at 05:17:10AM -0800, Andy Bierman wrote: > I think it is supposed to be the former, and therefore several > decisions have to be made (e.g., how to move RowStatus > and StorageType data to NETCONF operations, how to encode > INDEX clauses, how to deal with data in different contexts). > MaxRepetitions and even GetNext/GetBulk operations are not relevant > to NETCONF. Using to access SNMP instrumentation might be made to work. Using to write SNMP instrumentation is going to be a nightmare since the semantics of SNMP sets and do not align well. Even if one were to define an "snmp" data store which allows for the special SNMP semantics (persistency, create/delete, ...), this special datastore will essentially change so much that I believe a new operation would be a much cleaner way. Since I believe we need a operation, I do not mind having a operation as well to easily access _existing_ SNMP based instrumentation via NETCONF. In the future, we _may_ have a uniform data modeling approach (but we know already this will be very difficult to achieve and perhaps this is not worth the effort). Anyway, for the many existing MIBs out there, we (a) either provide a mechanism to access them via NETCONF (RPCs) or (b) we state that to access SNMP instrumentation, you better use SNMP (with all its pros and cons) and use NETCONF for NETCONF data models only (which still need to be defined), or (c) we leave this to proprietary extensions (which I am sure will be developed). It is a fundamental decision in which direction we want to go in terms of coexistance with SNMP. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Wed Jan 10 13:57:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4idQ-0002bC-L6; Wed, 10 Jan 2007 13:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4idP-0002b6-MP for ngo@ietf.org; Wed, 10 Jan 2007 13:57:15 -0500 Received: from omr5.networksolutionsemail.com ([205.178.146.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4idN-00012X-Ki for ngo@ietf.org; Wed, 10 Jan 2007 13:57:15 -0500 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l0AIvBsf032757 for ; Wed, 10 Jan 2007 13:57:12 -0500 Received: (qmail 31644 invoked by uid 78); 10 Jan 2007 18:45:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 10 Jan 2007 18:45:02 -0000 Message-ID: <45A5342F.5020209@andybierman.com> Date: Wed, 10 Jan 2007 10:45:03 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi Dan, > > So, in your view, what should the IETF do next? > > - do work on the 'a combination of common standard parameters, standard > verbs'? and/or > - provide guidance and example to vendors about how to 'do the > groundwork by creating new models that utilize this approach'? or > - none of the above? 1) Finish, publish, and use draft-romascanu-netconf-datatypes-xx, so we can converge on encodings for IETF-related data types. 2) Standardize a direct encoding of SMIv2 modules, based on the output of smidump --format=xsd. The application of NETCONF verbs to this data is helpful, but not critical. (E.g., if we have a simpleType or element definition for 'ifMtu', then it can be used by reference anywhere we want -- like an RPC parameter, a new data model, or a notification.) 3) Explore (by design team or individual I-D) the creation of a NETCONF management interface for the Interface MIB modules and possibly the REMOPS-MIB module as well. Interfaces are important and special in that they have their own config section (i.e., each interface instance effectively has a nested sub-root). The output would be verbs and data models, and hopefully some implementation experience, which could then be considered for standardization. It is possible that multiple teams and solution approaches would need to be considered. > > Dan > > > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Wed Jan 10 14:19:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iyx-0004q2-Nl; Wed, 10 Jan 2007 14:19:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iyw-0004px-LM for ngo@ietf.org; Wed, 10 Jan 2007 14:19:30 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4iyu-0003fK-Cj for ngo@ietf.org; Wed, 10 Jan 2007 14:19:30 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0AJJGql009097 for ; Wed, 10 Jan 2007 14:19:17 -0500 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: [NGO] comments on draft-li-ngo-access-mib-00 Date: Wed, 10 Jan 2007 21:19:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NGO] comments on draft-li-ngo-access-mib-00 Thread-Index: Acc06TscbxRy1ru7SVus8YiIt8UHQAAAl+tQ From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org =20 =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 >=20 > 1) Finish, publish, and use draft-romascanu-netconf-datatypes-xx, > so we can converge on encodings for IETF-related data types. >=20 Any resemblance with real persons is purely coincidental, etc. :-)=20 Well, this is not completely true, but as the principal was re-directed to other activities we need a taker to own this work to completion if people believe it'd be useful to finish and publish it.=20 Dan _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo