Subject: [OPS-NM] Comments on XSDMI BoF proposal

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Jun 2007 10:15:07 -0700

Hi,

Here is the BoF proposal for reference:

XSD for accessing SMIv2 data models (xsdmi) BOF
Status: request submitted including proposed WG charter
Discussions: NETCONF WG list [email-masked]
Responsible AD: Dan Romascanu
BOF Chair: David Harrington ([email-masked])
Internet-Drafts:
draft-romascanu-netconf-datatypes-02 (XSD for SMIv2 Data Types and
Textual Conventions)
draft-li-ngo-access-mib-01 (SMIv2 Data Access for NETCONF)
Summary and Scope: Future WG Formation - The XSDMI WG will undertake the
following work items:
(A) Development of a standard XML Schema Definition [XSD] to specify the
XML encoding of the core SMIv2 data types defined in RFC2578.
(B) Development of a standard XML Schema Definition [XSD] to specify the
XML encoding of some generic and common SMIv2 textual conventions, as
identified at http://www.ops.ietf.org/mib-common-tcs.html.
(C) Definition of a standard set of security requirements for accessing
MIB management data by potentially multiple protocols.
(D) Development of a standard set of algorithms for accessing SMIv2
management information, possibly using the NETCONF <get> operation
and/or <notification> data delivery mechanism.

---------------------------------------

General:

I strongly support the formation of this WG, and think
it should be the "only next step" in NETCONF Data Modeling
standards development.

Trying to standardize too much at once without enough implementation
experience is not going to help.  The most critical DM need is to
figure out how to use the standard NM data definitions we already have.

Nit: The WG acronym is kind of cryptic and I'm not sure what
it supposed to mean.  Also, the WG name only describes work items
(A) and (B).  Security requirements for multi-protocol access
to MIB data is definitely not covered by the title, and (D)
is 'possibly' NETCONF protocol-specific. (?? XSMI ?? SMIX ?? SMINET ??)

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.

(C)
This work item is a bit vague.  I'm not sure if it means
a mapping between an SNMP EngineID to a NETCONF session identity,
or something to do with VACM, or something else undefined.
I think it is a smart idea to understand all the security issues
associated with (D).

(D)
I support a standard algorithmic translation between SMIv2 conceptual
data models and NETCONF configuration databases, which includes
data organization and standard protocol operation mappings.
I think read-only access instead of full access will be easier
to achieve, so it should be done first.  The use case for
write access is not as strong, and the multi-protocol access and
security issues are harder.

I do not support a generic XSD representation of SMIv2 macros,
without consideration of the specific XML-based protocol being used.
The 'embedded' SNMP protocol operations in SMIv2, as well as the explicit
SNMP operations discussed in MIB object DESCRIPTION clauses, RowPointer,
RowStatus, StorageType, etc., all have to be explicitly mapped to the
specific NETCONF (or whatever) protocol operations and
architecture assumptions.

Andy

_______________________________________________
OPS-NM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-nm

---

From: "David Harrington" <[email-masked]>
Date: Tue, 5 Jun 2007 15:49:46 -0400

Hi,

comments inline 

(I am cross-posting to the ops-area mailing list because no official
decision was made to relocate discussion for XSDMI to the ops-nm list.
I will ask Dan to change the BOF page to direct discussion to the
ops-nm list. Interested parties please find XSDMI discussion on the
ops-nm list.)

dbh

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 1:15 PM
> To: Ops-Nm
> Subject: [OPS-NM] Comments on XSDMI BoF proposal
> 
> General:
> 

> figure out how to use the standard NM data definitions we 

My intention is to develop a way to access MIB data via XML-based NM
protocols,
to take advantage of the existing NM data definitions in the MIB. 

This is a migration strategy to move from a mainly-SNMP-and-MIB
management framework to a multi-protocol-and-multi-data-model
management framework. 

I do not think MIB access is enough. A binary data-based approach like
the MIB is fine for automated management, but it is not good for
operator-interactive management, and it fails to take advantage of
advances in computer networking technology like WWW technologies.

For operator-interactice NM, I think we need task-based NM interfaces.
The CLI is one approach, and standardizing it would probably be
helpful, but the engineering departments of vendors are not very
cooperative on doing that; it is easier for engineers to use freeform
text when developing CLIs and syslog-style reporting than to use
standardized content. 

XML-based management leverages lessons learned from the WWW. While
document-based rather than command-based, tasks can often be grouped
into a document-type interface, such as a web page. With automated
translation from XML into HTML (and related technologies), we can work
on developing task-based-document NM interfaces. 

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. 

While I would like to see the reuse of existing standards, such as
XSD, we need to support programmatic interfaces to allow (incremental)
automation of repetitive tasks. That means we need to provide
machine-readable "clues" about the meta-nature of management
information. Maybe that can be done in XML using attributes, or
namespaces, or hierarchical organization. Maybe it will require a new
SMI with all the special fields found in SMIv2 - and more. 

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. 

That work can advance while we work on developing support for one or
more XML-based interfaces to SMIv2 data models, as a migratory step
toward multi-protocol management.

> is 'possibly' NETCONF protocol-specific. (?? XSMI ?? SMIX ?? 

I deliberately avoided the use of SMI. As somebody pointed out (you?),
this work (A and B) is not developing a new SMI, it is merely
translating elements of SMIv2 from one language to another.

> a couple years, and it is very much needed, and ready, for 

Yan will be publishing a base datatype translation document, based on
libsmi translations. Since this has been defined and used(?) fo
ryears, I expect this should be fast - in IETF terms, we can probably
finish in seven or eight years ;-). Seriously, I hope this can be done
in six months or so, if there is enough interest to work on it.

That will be supplemented by the (romascanu) TC translations document.
We need to decide whether XSD can express the restrictions adequately
to support machine-validation, and whether the amount of
machine-validation supported justifies having an XSD for the TC.
Having TC translations might be helpful for netconf to go read existng
MIB data, without having to also parse SMIv2 MIB documents to
understand what the values mean. I think the bigger benefit is
defining TCs that can be used by multiple protocols to support
consistent semantics across protocols, and XML is the preferred
language for most new protocols.

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 think it is a smart idea to understand all the security issues

I'm looking at the bigger picture of multi-protocol management. There
are lots of protocols being developed, both inside and outside IETF,
to perform management functionality. As Bob Natale pointed out, the
MIB is the "crown jewel" of IETF Management (I think SNMP is as well,
when used for what it is good at). I think lots of WGs and lots of
other SDOs are going to look at the MIB and say "gee, we should
leverage that!"

I think we need to set some guidelines about how protocols should deal
with the MIB, so that it is not ruined by unconstrained access by
multiple protocols, especially write access.

But even read-access can be problematic. Security is a process, not a
product. The IETF needs to decide how to "balance" security in an
environment of multi-protocol management. It makes no sense to protect
your house with a front door that has multiple deadbolt locks, if your
back door has no locks. 

It makes no sense to expect operators to go to the trouble of
configuring VACM to protect the data in the MIB when using SNMP, if
the operator's VACM configuration will just be ignored by netconf and
other protocols accessing the MIB. I think we need some guidelines
that provide for a more consistent approach to multi-protocol MIB
access, than VACM-for-SNMP and nothing-for-others. 

Personally, I would like to see VACM not be mandatory-to-implement for
SNMP, if there is no corresponding mandatory-to-implement access
control for other protocols. I don't think the operator community is
actually ready for standardized cross-protocol access control, and if
it isn't balanced across protocols, then we shouldn't require any NM
protocol standards to have a mandatory-to-implement access control
model.

> security issues are harder.

I agree that read-only access would probably be sufficient for netconf
to gather state information, statistical information, and
notifications. I do not see a lot of reason to support write access to
the MIB via netconf.

> architecture assumptions.

I think these need to be supported to understand the values of certain
fields that might be read from the MIB. 

RowStatus reflects the operational state of the row, and if netconf is
accessing the MIB to determine operational state of the thing
represented by that row, it is an important piece of information. But
if netconf has no write capability to the MIB, it does not need to
know how to manipulate the values.

StorageType is also state information about a row that might be
important for a netconf client to understand; it might be helpful to
know that the MIB representation (or the underlying instrumentation)
is in ROM. But if it has no write capability, it does not need to know
how to manipulate the row within the constraints of StorageType. 

The MIB is more or less a relational database, where the relations
between rows is important information. If netconf reads a row that has
a relationship to another row via a RowPointer, netconf better know
how to interpret a RowPointer.

(It is important to understand that I make no assumptions that a
netconf-client will have a direct connection to an SNMP manager that
knows how to parse this information from an SMIv2  MIB module
document.)

I think we need to walk through these TCs on a case-by-case basis to
decide whether we need each one for use with netconf, and what XSD
restrictions apply.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 Jun 2007 07:56:29 +0200

See in-line a few comments from a contributor perspective. 

Dan

> From: David Harrington [mailto:[email-masked]] 
> > 
> > I strongly support the formation of this WG, and think it should be 
> > the "only next step" in NETCONF Data Modeling standards development.
> 
> My intention is to develop a way to access MIB data via 
> XML-based NM protocols, to take advantage of the existing NM 
> data definitions in the MIB. 
> 
> This is a migration strategy to move from a 
> mainly-SNMP-and-MIB management framework to a 
> multi-protocol-and-multi-data-model
> management framework. 
> 
> I do not think MIB access is enough. A binary data-based 
> approach like the MIB is fine for automated management, but 
> it is not good for operator-interactive management, and it 
> fails to take advantage of advances in computer networking 
> technology like WWW technologies.
> 
> The CLI is one approach, and standardizing it would probably 
> be helpful, but the engineering departments of vendors are 
> not very cooperative on doing that; it is easier for 
> engineers to use freeform text when developing CLIs and 
> syslog-style reporting than to use standardized content. 

I do not believe that a standard CLI is achievable in the IETF. By now
we should assume this is not going to happen. 

> 
> XML-based management leverages lessons learned from the WWW. 
> While document-based rather than command-based, tasks can 
> often be grouped into a document-type interface, such as a 
> web page. With automated translation from XML into HTML (and 
> related technologies), we can work on developing 
> task-based-document NM interfaces. 
> 
> 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. 

> 
> While I would like to see the reuse of existing standards, 
> such as XSD, we need to support programmatic interfaces to 
> allow (incremental) automation of repetitive tasks. That 
> means we need to provide machine-readable "clues" about the 
> meta-nature of management information. Maybe that can be done 
> in XML using attributes, or namespaces, or hierarchical 
> organization. Maybe it will require a new SMI with all the 
> special fields found in SMIv2 - and more. 
> 
> 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 
> 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? 

> 
> That work can advance while we work on developing support for 
> one or more XML-based interfaces to SMIv2 data models, as a 
> migratory step toward multi-protocol management.
> 
> > 
> > Nit: The WG acronym is kind of cryptic and I'm not sure what it 
> > supposed to mean.  Also, the WG name only describes work items
> > (A) and (B).  Security requirements for multi-protocol 
> access to MIB 
> > data is definitely not covered by the title, and (D) is 'possibly' 
> > NETCONF protocol-specific. (?? XSMI ?? SMIX ??
> > SMINET ??)
> 
> I deliberately avoided the use of SMI. As somebody pointed 
> out (you?), this work (A and B) is not developing a new SMI, 
> it is merely translating elements of SMIv2 from one language 
> to another.
> 
> > 
> all this 
> > work?
> > 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, 
> based on libsmi translations. Since this has been defined and 
> used(?) fo ryears, I expect this should be fast - in IETF 
> terms, we can probably finish in seven or eight years ;-). 
> Seriously, I hope this can be done in six months or so, if 
> there is enough interest to work on it.
> 
> We need to decide whether XSD can express the restrictions 
> adequately to support machine-validation, and whether the 
> amount of machine-validation supported justifies having an 
> XSD for the TC.
> Having TC translations might be helpful for netconf to go 
> read existng MIB data, without having to also parse SMIv2 MIB 
> documents to understand what the values mean. I think the 
> bigger benefit is defining TCs that can be used by multiple 
> protocols to support consistent semantics across protocols, 
> and XML is the preferred language for most new protocols.
> 
> 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'm not sure if it means a mapping 
> > between an SNMP EngineID to a NETCONF session identity, or 
> something 
> > to do with VACM, or something else undefined.
> I'm looking at the bigger picture of multi-protocol 
> management. There are lots of protocols being developed, both 
> inside and outside IETF, to perform management functionality. 
> As Bob Natale pointed out, the MIB is the "crown jewel" of 
> IETF Management (I think SNMP is as well, when used for what 
> it is good at). I think lots of WGs and lots of other SDOs 
> are going to look at the MIB and say "gee, we should leverage that!"
> 
> I think we need to set some guidelines about how protocols 
> should deal with the MIB, so that it is not ruined by 
> unconstrained access by multiple protocols, especially write access.
> 
> But even read-access can be problematic. Security is a 
> process, not a product. The IETF needs to decide how to 
> "balance" security in an environment of multi-protocol 
> management. It makes no sense to protect your house with a 
> front door that has multiple deadbolt locks, if your back 
> door has no locks. 
> 
> configuring VACM to protect the data in the MIB when using 
> SNMP, if the operator's VACM configuration will just be 
> ignored by netconf and other protocols accessing the MIB. I 
> think we need some guidelines that provide for a more 
> consistent approach to multi-protocol MIB access, than 
> VACM-for-SNMP and nothing-for-others. 
> 
> Personally, I would like to see VACM not be 
> mandatory-to-implement for SNMP, if there is no corresponding 
> mandatory-to-implement access control for other protocols. I 
> don't think the operator community is actually ready for 
> standardized cross-protocol access control, and if it isn't 
> balanced across protocols, then we shouldn't require any NM 
> protocol standards to have a mandatory-to-implement access 
> control model.

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. 

> > data models and NETCONF configuration databases, which 
> includes data 
> > organization and standard protocol operation mappings.
> > I think read-only access instead of full access will be easier to 
> > achieve, so it should be done first.  The use case for 
> write access is 
> > not as strong, and the multi-protocol access and security 
> issues are 
> > harder.
> 
> I agree that read-only access would probably be sufficient 
> for netconf to gather state information, statistical 
> information, and notifications. I do not see a lot of reason 
> to support write access to the MIB via netconf.

Yes, see the above.

> 
> > 
> > I do not support a generic XSD representation of SMIv2 
> macros, without 
> > consideration of the specific XML-based protocol being used.
> > The 'embedded' SNMP protocol operations in SMIv2, as well as the 
> > explicit SNMP operations discussed in MIB object 
> DESCRIPTION clauses, 
> > RowPointer, RowStatus, StorageType, etc., all have to be explicitly 
> > mapped to
> the
> > specific NETCONF (or whatever) protocol operations and architecture 
> > assumptions.
> 
> I think these need to be supported to understand the values 
> of certain fields that might be read from the MIB. 
> 
> RowStatus reflects the operational state of the row, and if 
> netconf is accessing the MIB to determine operational state 
> of the thing represented by that row, it is an important 
> piece of information. But if netconf has no write capability 
> to the MIB, it does not need to know how to manipulate the values.
> 
> StorageType is also state information about a row that might 
> be important for a netconf client to understand; it might be 
> helpful to know that the MIB representation (or the 
> underlying instrumentation) is in ROM. But if it has no write 
> capability, it does not need to know how to manipulate the 
> row within the constraints of StorageType. 
> 
> The MIB is more or less a relational database, where the 
> relations between rows is important information. If netconf 
> reads a row that has a relationship to another row via a 
> RowPointer, netconf better know how to interpret a RowPointer.
> 
> (It is important to understand that I make no assumptions 
> that a netconf-client will have a direct connection to an 
> SNMP manager that knows how to parse this information from an 
> SMIv2  MIB module
> document.)
> 
> I think we need to walk through these TCs on a case-by-case 
> basis to decide whether we need each one for use with 
> netconf, and what XSD restrictions apply.

Agree with David on this one. 

> OPS-AREA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ops-area
>

---

From: Jon Saperia <[email-masked]>
Date: Wed, 06 Jun 2007 06:05:51 -0400

One comment/question in line below:

Romascanu, Dan (Dan) wrote:

Dan

-----Original Message-----

Trying to standardize too much at once without enough

implementation

experience is not going to help. The most critical DM need is to
figure out how to use the standard NM data definitions we already
have.

I have seen a couple of references in the discussion to State and
netconf.  Can we be more specific about what we mean by state here.
Configuration state?  When I think of other types of state such as
operational state or quality state I think of either read MIB objects
or notifications (traps/informs).

The suggestion of using subtrees for functional (e.g., FCAPS)
separation has worked well in some cases (we use 0 for notifications
right).

access to MIB

all this

work?

Work items:

(A)(B)

(C)

something

(D)
I support a standard algorithmic translation between SMIv2

conceptual

includes data

write access is

issues are

harder.

Yes, see the above.

macros, without

DESCRIPTION clauses,

the

David Harrington
[email-masked]
[email-masked]
[email-masked]

--
Jon Saperia
(cell) 617-201-2655
(Eve.) 978-461-0264

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 Jun 2007 14:47:28 +0200

________________________________

	From: Jon Saperia [mailto:[email-masked]] 

			XML-based management leverages lessons learned
from the WWW. 
			While document-based rather than command-based,
tasks can 
			often be grouped into a document-type interface,
such as a 
			web page. With automated translation from XML
into HTML (and 
			related technologies), we can work on developing

			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. 

	I have seen a couple of references in the discussion to State
and netconf.  Can we be more specific about what we mean by state here.
Configuration state?  When I think of other types of state such as
operational state or quality state I think of either read MIB objects or
notifications (traps/informs).
	[DR]  
	[DR] My interpretation was state as in state of the system which
is the super-set of configuration state, but not limited to
configuration state. It is David however who introduced the term in the
thread, so I would rather have him answer. 
	 
	Dan

---

From: Jon Saperia <[email-masked]>
Date: Wed, 06 Jun 2007 08:52:05 -0400

Thanks for the clarification, lets see what Dave says.  If it is as you 
say, then I would say what is the justification for introducing 
duplication of information?
/jon

-- 
Jon Saperia
(cell) 617-201-2655
(Eve.) 978-461-0264

---

From: "David Harrington" <[email-masked]>
Date: Wed, 6 Jun 2007 09:07:43 -0400

Hi,

I was referring to the separation of config and state data, as
described in RFC4741.
I do think the distinction made in rfc4741 is not very clear, so work
would need to be done.

Would this result in duplication of information? Without a draft
making a specific proposal for this, I cannot say. It might.

dbh

> Sent: Wednesday, June 06, 2007 8:52 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Andy Bierman; Ops-Nm
> Subject: Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 6 Jun 2007 11:47:30 -0400

Hi,

Dan, Thanks for changing the list.

> 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.

> 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.

> > Yan will be publishing a base datatype translation document, 
[..]

> > > (C)
> > > This work item is a bit vague.  [...]

> 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
[email-masked] 
[email-masked]
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Jun 2007 08:55:03 -0700

> comments inline 

ditto

> to take advantage of the existing NM data definitions in the MIB. 

This is fine, but it should be based on use cases, as you say later on.
IMO, there is a use case to read MIB data via a NETCONF session.
The goal can be abstract, but the solutions has to be specific,
in order to have an inter-operable standard.

> advances in computer networking technology like WWW technologies.

I am not interested in an SNMP-like interface to SMI data, encoded in XML.
IMO, via NETCONF <get>, the access should be per-row-instance, via subtree
and Xpath filters, not per-column-instance, via lexi-next (getnext).

Other protocols will have completely different requirements and
retrieval operations, and the solution might not be the same.

> translating elements of SMIv2 from one language to another.

I do not think this limited and generalized translation (D) is very useful,
or realistically possible to do well in the IETF, in finite time.

I prefer to view the Network Management problem in specific terms, e.g.,
understanding how conceptual data defined in SMIv2 can be mapped
into a NETCONF Configuration Database, and accessed with NETCONF
protocol operations.

Abstracting the NM problem as if there was nothing going on beyond
editing the XML instance document itself does not really help.

> protocol standards to have a mandatory-to-implement access control

Previous discussions wrt/ NETCONF access control have indicated
that a simple solution allowed just 2 access levels (read and write)
is favored.  Perhaps as a backlash to VACM.

> decide whether we need each one for use with netconf, and what XSD

I was pointing these complexities out as a reason not to deal
with write access.  If there are products used by operators someday,
that have some sort of XML-based "set" operation for MIB data,
then maybe it would be interesting to standardize it.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Jun 2007 09:05:39 -0700

> duplication of information?

What duplication are you talking about?

BTW, I do not agree with the RFC 4741 definition of config
because it is incomplete.

I use a very NETCONF-centric definition, with 3 states:

   config: Persistent Configuration
           * saved in NV-storage
           * included in <get-config>, <edit-config>, <copy-config>

   tconfig: Transient Configuration (e.g., per-session configuration)
           * not saved in NV-storage
           * included in <get-config>, <edit-config>, <copy-config>

   state: Non-Configuration Data
           * not saved in NV-storage
           * not included in <get-config>, <edit-config>, <copy-config>

Andy

---

From: Jon Saperia <[email-masked]>
Date: Wed, 06 Jun 2007 13:10:59 -0400

Andy Bierman wrote:
> Jon Saperia wrote:
>> Thanks for the clarification, lets see what Dave says.  If it is as 
>> you say, then I would say what is the justification for introducing 

A reasonable interpretation of the last would be that it includes 
counters of various things, gauges , etc. Right?

-- 
Jon Saperia
(cell) 617-201-2655
(Eve.) 978-461-0264

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Jun 2007 10:28:30 -0700

> counters of various things, gauges , etc. Right?

right.
counters, ifOperStatus, timestamps, etc.

However, there are corner-cases which could be used to argue
that MAX-ACCESS of read-only does not always mean the object
is classified as 'state' (e.g., agent-generated key or row index
could be saved in NV-storage).

Andy

---

From: Jon Saperia <[email-masked]>
Date: Wed, 06 Jun 2007 13:32:16 -0400

Again thanks for the clarification.  I was less concerned about the 
finer point of what to represent than with the larger implication of 
doing all this via netconf instead of netconf and snmp.
/jon

-- 
Jon Saperia
(cell) 617-201-2655
(Eve.) 978-461-0264

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 Jun 2007 20:16:06 +0200

> Sent: Wednesday, June 06, 2007 6:48 PM
> To: 'Ops-Nm'
> Subject: RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
> 
> 
>  Hi,
> 
> 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 
> 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.
>    3.  It is required to be able to fetch separately 
> configuration data,
> 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.

Sure, if we are talking about a mid-long term task we are in agreement. 

Dan