Bob,
>
> There are two related, but distinct dimensions of "scope"
> that have tended to get run together in these NIM discussions:
>
> 1. Data modeling / data representation: MIBs, PIBs, CORBA,
> LDAP, GDMO, etc.
> 2. Domain being modeled: Diffserv, Intserv, IPsec, storage,
> telephony, etc.
>
> I think that most of the early discussions of "scope" were
> centered on (2) - for example, Andrea's questions about the
> scope of what NIM would be modeling. This is also what
> people meant when they talked about helping different WGs
> model common elements in a common way. (It's clear that
> this is what they meant because they contrasted this goal
> with what happened with SNMP: many WGs, all using SMI as
> their data representation, came up with divergent ways of
> modeling the same things.)
>
> Recently, though, much of the discussion has shifted
> to (1), where "scope" now means which data modeling
> technologies will be unified by NIM. We haven't left
> (2) behind entirely, though, because as several people
> (starting with Randy Bush) have observed, what we model
> is not independent of the technology we use for modeling
> it.
>
> I think that (1) and (2) are both legitimate scoping
> questions, which need to be discussed. We should be
> clear, though, which one we're discussing at any point.
>
I would agree with your points. However, I would clarify (1) to consider first and foremost my earlier question. Specifically, if we say that this work is applicable to only data structures we don't really leverage all the OO concepts, but the results will be readily applicable to current IETF protocols such as SNMP, COPS, and LDAP. In contrast, if we broaden the scope to include the remaining OO concepts, we expand the applicability beyond the IETF and data oriented protocols. The price for this expanded scope is greater challanges in proving the value to IETF protocols (more complex mappings and algorithmic mappings), and a lower probability of success as gauged by interest amoung the IETF participants at the BOF. We have to ask the question: do we want to shoot for the ideal risking that it will never be used (n+1), or do we want to shoot for more consistency with what we have risking obsolesence when(if) non-data driven management interfaces become the rage in the IETF.
I would much rather work on the ideal, but only if we have some assurance within the IETF community that it will be used at least by one technology (n) and preferably two (n-1). In lue of that, I would still prefer to see us working on something that is less then ideal but that does have an (n-1 or more) impact.
> On a related note, I was surprised when Walter said:
>
> At the last IETF, there was a strong desire to
> see SMI and SPPI converge. If this happens, we
> still have to question where the data
> structures are developed that can be used
> commonly across both COPS and SNMP.
>
> I think the question of where the common MIB / PIB
> data structures would get defined is one of the few
> easy questions in this whole discussion. Given the
> (relatively) long-standing practice of having MIBs
> defined in the subject-matter WGs, and the more recent
> practice of handling PIB definitions in the same way,
> it's obvious where the common MIB / PIB structures
> would be defined: in the subject-matter WGs. The
> question becomes hard only if we slide over from
> (1) (convergence of MIBs & PIBs for a given domain)
> into (2) (convergence of MIB / PIB definitions
> across multiple domains).
I can see why that text is somewhat ambiguous. Let me clarify. It is all well and good for SMI and SPPI to converge. However, if the PIBs and MIBs are still developed independently, we still have the painful excercise of converging the two models. Specifically, if each specify parameters for a scheduler, and each uses different names or has different definitions for the parameters, then we have an interpretation and translation problem. Even if they share a subset of common attributes, there is still the problem of evolution and extension that will drive the two data definitions apart. A very useful discussion that needs to take place somewhere is how a single data definition can be specified that meets the needs of both Policy and Device management. Some of the work done in SNMPCONF is a good start in this direction.
regards,
-Walter