RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
"David Harrington" <ietfdbh@comcast.net> Wed, 06 June 2007 15:47 UTC
Return-path: <ops-nm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvxjb-0000Qj-9B; Wed, 06 Jun 2007 11:47:43 -0400
Received: from ops-nm by megatron.ietf.org with local (Exim 4.43) id 1Hvxja-0000QW-7y for ops-nm-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 11:47:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxjZ-0000QD-T8 for ops-nm@ietf.org; Wed, 06 Jun 2007 11:47:41 -0400
Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvxjY-0004ng-GI for ops-nm@ietf.org; Wed, 06 Jun 2007 11:47:41 -0400
Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007060615474001100i00dbe>; Wed, 6 Jun 2007 15:47:40 +0000
From: David Harrington <ietfdbh@comcast.net>
To: 'Ops-Nm' <ops-nm@ietf.org>
References: <4664489B.1000406@andybierman.com> <02c901c7a7aa$ab924fc0$0600a8c0@china.huawei.com> <EDC652A26FB23C4EB6384A4584434A040D7E8D@307622ANEX5.global.avaya.com>
Subject: RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
Date: Wed, 06 Jun 2007 11:47:30 -0400
Message-ID: <039501c7a851$fe245600$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
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A040D7E8D@307622ANEX5.global.avaya.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AcemzA59oB5ulVZRR7W5+F6lyv4NKQAzMFkAABh/jXAAEC8R0A==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a743e34ab8eb08259de9a7307caed594
X-BeenThere: ops-nm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OPS Area NM e-mail list <ops-nm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ops-nm>, <mailto:ops-nm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ops-nm>
List-Post: <mailto:ops-nm@ietf.org>
List-Help: <mailto:ops-nm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ops-nm>, <mailto:ops-nm-request@ietf.org?subject=subscribe>
Errors-To: ops-nm-bounces@ietf.org
Hi, Dan, Thanks for changing the list. > See in-line a few comments from a contributor perspective. > > Dan > > I think we need to spend more time thinking about operator > > use-cases, not just technical designs of SMIs. I think it > > would help to start thinking in terms of modular data models > > similar to MIB modules, not just a <running> config, but we > > need to develop an SMI that helps to differentiate config and > > state info, which SMIv2 doesn't do, Maybe all we need to do > > is recommend that MIB modules have separate subtrees for > > config and for state, much as we now recommend separate > > subtrees for objects and notifications. > > Maybe, but at this point in time all the base of standard MIB > modules is > not designed this way. What are we going to do, re-write these MIB > modules, or part of them? This does not seem an achievable task. SMIv1 MIB modules did not organize notifications in a separate subtree, and it wasn't even done in the earlier SMIv2 MIB modules. Over time (about twelve years), we have migrated MIB design in that direction. There has been strong demand from operators for a distinction between config and state data. >From operator requirements documented in RFC3535: 3. It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices. Now would seem a good time to establish new guidelines about how to differentiate these, so over time, existing MIB modules can be migrated in that direction. Or we could just provide guidelines for XML-based representations, and migrate away from SMIv2 to the XML-based schemas for SNMP as well. Now is the time when we have a "destructive technology shift" under way from ASN.1 to XML, that could provide a good opportunity for starting the gradual re-definition of existing MIB modules, based on the lessons learned over the past twenty years. So I think the separation is an achievable task, just not a short-term task. We could try to define some guidelines as a short-term task, but that is not part of this BOF. > > I think one of the big questions we need to address is > > whether a new SMI should be developed that is an > > extension/superset of SMIv2, or is distinct from SMIv2. I > > think that work involves getting operator feedback of how > > they work, so we can understand whether we should be trying > > to merge the existing NM protocols, or should keep them (and > > their data) distinct. I think we should be considering how to > > componentize existing standards work, so we can reuse some > > parts, such as secure transport, while keeping other parts > distinct. > > I somehow like the paradigm - SNMP for performance monitoring and > alerts, Netconf for configuration and status retrieval. Could we > consider that the current standard MIB modules based would be used for > read configuration operations, like declare it as the status branch in > each MIB, ignoring the configuration objects and build atop of it what > is needed for configuration, even if this means duplication of some > objects. Simple or too simplistic? We could separate the config and state in MIB modules, by declaring a new subtree (iso.org.dod.internet.config(7), or iso.org.dod.internet.<mgmt>.<config>, and then deprecate the configuration-specific objects that exist in current MIB modules and redefine them in the new subtree (if there is any demand to keep them.) If SNMP is just for performance monitoring and alerts, would you recommend we remove the SET capability from SNMP? or make it an optional "capability" of SNMP? That might be more reflective of real world implementations. I don't necessarily favor that idea, but it is something to consider. This is not part of this BOF, however. > > > Milestones: Any idea how long you think it will take to do > > all this > > > work? > > > > > > Work items: > > > > > > (A)(B) > > > The XSD for SMIv2 data types and TCs draft has been reviewed and > > > refined over a couple years, and it is very much needed, > and ready, > > > for standardization. > > > > Yan will be publishing a base datatype translation document, [..] > > That will be supplemented by the (romascanu) TC > translations document. > > > > This will require case-by-case analysis, and might take time > > to reach consensus. Of course, not every contentious TC must > > be included in this document, so if we cut out the > > contentious ones, this should be able to be wrapped up within > > a year, I hope. > > I would try to push for a more aggressive schedule, even if it's a > smaller set of TCs. It's not that all needs to be standardized in RFC > form, but it is better to have this in a stable format for > other work to > re-use it including proprietary implementations to deploy this. > > > > (C) > > > This work item is a bit vague. [...] > > > I think it is a smart idea to understand all the security issues > > > associated with (D). > > > I confess that this is confuse for me too. I am not sure that I > understand what is the deliverable here, or whether the problem can be > solved within the context of this working group. A few years ago, as IP became recognized as the IETF's crown jewel, there were many layer2 protocols whose proponents wanted IP to run over their layer2 protocol. Rather than having the IETF do the work to make IP work with every layer 2 protocol requested, the IETF created guidelines on how layer 2 protocols should interface to IP, so others could define how their layer 2 protocol could be used with IP, within those guidelines. I would like to see a similar approach for the MIB - define guidelines about how protocols from various sources can work well with the MIB, rather than being tied down doing the translations to use the MIB with protocols from many different sources, such as netconf and RDML. Since we are providing a base set of SMIv2-to-XSD translations to allow MIB access, it would seem to be in scope of the BOF to discuss the guidelines for MIB access. The MIB Access over Netconf document is a (useful) pilot project to test that the concepts in the guidelines are viable. -- I don't have a clear proposal for (C). I see the issue; I don't favor a specific answer; there are multiple approaches with tradeoffs, and different people will prefer different approaches depending on their own motivations. I think we as a community need to discuss how we want this issue approached, what guidelines we agree upon, and then we need to document the guidelines. Call them crappy BIG rules ;-) I see a variety of potential solutions (not all mutually exclusive): 1) Separate databases: other protocols go directly to the instrumentation, ignoring anything related to SNMP or the MIB, using their own virtual database, i.e. not using the MIB. 2) shared databases: other protocols go directly to the instrumentation, ignoring anything related to SNMP, but using the same virtual database (the MIB), e.g., using similar hierarchal addressing for the data, and, if they want, the same access routine libraries as SNMP. 3) shared databases and access controls: other protocols are required to authenticate the <user>, and check authorization via SNMP-compatible access control models, such as VACM, to access the MIB. 4) shared databases and different required access controls: other protocols are required to authenticate the <user>, and required to check authorization, but they can use their own access control approach, e.g. task-based rather than data-based, which may or may not be compatible with, and provide the same access control strength as, existing SNMP access control models. and so on ... -- SNMPv3 got into trouble for not leveraging existing security functionality, which forced operators to deal with an additional methodology for configuring security. SNMP defined VACM, the only IETF standard for access control to MIB data at this point. ISMS is discussing how to define a RADIUS-based access control model for MIB management information. And vendors have their own ideas about how to provide access control to management information, often specific to their CLI system but applied to MIB data as well. Should MIB access be required to utilize some type of access control? Should the access control model be protocol-specific, which would require operators to configure yet-another access control protocol? Should it be MIB-specific, e.g., VACM? Should it be a new MIB-specific access control standard, such as RADIUS/ISMS? Should it be a new access control standard that could provide fairly-consistent access controls for different virtual databases of management information (e.g., draft-nelson-radius-management-authorization-04.txt)? Should access control be implementation-specific? What does the community, especially the operator community, want to see here? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ OPS-NM mailing list OPS-NM@ietf.org https://www1.ietf.org/mailman/listinfo/ops-nm
- [OPS-NM] Comments on XSDMI BoF proposal Andy Bierman
- RE: [OPS-NM] Comments on XSDMI BoF proposal David Harrington
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Romascanu, Dan (Dan)
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Jon Saperia
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Romascanu, Dan (Dan)
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Jon Saperia
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… David Harrington
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… David Harrington
- Re: [OPS-NM] Comments on XSDMI BoF proposal Andy Bierman
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Andy Bierman
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Jon Saperia
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Andy Bierman
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Jon Saperia
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Romascanu, Dan (Dan)