[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-bierman-sming-ds-02.txt
>>>>> Andy Bierman writes:
>>>> 6. We are not sure whether the goal of 100% forward and backward
>>>> compatibility has been reached or to what extend. The SMI-DS
>>>> translation to SMIv2 is not really defined in Appendix A and thus
>>>> it is hard to judge how much is in fact translatable (and what
>>>> the compatibility implication on the wire will be).
>>
Andy> I agree this appendix isn't finished and should have more
Andy> detail. Keep in mind that the SMI is a description of object
Andy> semantics. It does not specify on-the-wire encoding.
>> I agree - on the wire encoding is the wrong phrase. What we meant
>> is the assumptions that existing applications and tools have how
>> OIDs are stuctured.
Andy> I don't agree. The OID semantics are localized. Only the code
Andy> for the FOO-MIB needs to know how the OIDs for the FOO-MIB are
Andy> structured. Since there are zero MIBs at this time that use
Andy> hierarchical naming, there is no impacted code. If and when a
Andy> MIB exists with nest level > 1, the applications and agent code
Andy> for that MIB will need to know its structure. Not 1 line of code
Andy> for MIBs with nest level <= 1 will be impacted whatsoever.
It is interesting that we worry more about transition than you do.
Who is going to define SMI-DS modules with complex data types if there
are no ways to implement and use them with existing fielded tools? The
Diffserv MIB is the first IETF MIB which only uses Counter64 - 8 years
after their invention. (!)
Andy> I agree with you that ConformanceINfo can be just more MIB
Andy> objects. I agree with you that the changes I made to the INDEX
Andy> clause are not that important, and the old INDEX clause will
Andy> work just fine. I do not agree about OID naming. It's not just
Andy> the manual mapping. Jeff Case has some great ideas for protocol
Andy> enhancements to move aggregates and sub-aggregates. These
Andy> powerful new ProtoOps will not work if flat SMIv2 naming is
Andy> used. I don't think anybody will be able to design powerful new
Andy> ProtoOps if we use flat naming.
I have always said that hierarchical naming requires protocol support
to be useful. I just do not see the benefit with our current protocol
operations. My assumption at this point in time is that we work under
a charter which requires use to map to SNMP and COPS-PR as they exist
today.
Andy> The naming will not be the same for such translations.
Andy> Flattening out structs and unions is trivial -- the nodes are
Andy> just flattened out into a table (or set of scalars) and text is
Andy> added to the DESCRIPTION clauses that defines the relationship
Andy> between the nodes (like we do today. An array becomes a table,
Andy> perhaps an associated table if the outside containere was itself
Andy> an array.
<polemic>
How is this trivial but the SMIng mapping to SNMP is not?
</polemic>
Andy> Remember that the official SMIv2 to SMIv1 translation for a
Andy> Counter64 is to leave it out completely. In practice, we define
Andy> 2 Counter32s instead. There is enough room in the OID namespace
Andy> to allow for complex data structures and associated SMIv2 tables
Andy> to exist for a given MIB. This is not a hard problem.
Which means you have two naming systems to deal with in the agent.
Sometimes you are worried about code size - sometimes not...
Andy> The $64 question is whether we want to advance the state of the
Andy> art and move forward, or design for the same inefficient,
Andy> cumbersome technology we already have. I think the WG has
Andy> already expressed a preference for advancing the SMI technology.
Andy> I personally think it would be a total waste of time to redo the
Andy> entire SMI if it doesn't translate to real benefits in the SW
Andy> that uses the SMI.
SMIng advances the state of the art quite a bit. The question is
whether the advancement works reasonably well with all the existing
infrastructure or whether it in fact requires new protocol operations
and applications/tools to play off the power. The software reuse you
get depends primarily on the data structures we can define and less on
the naming. SMIng and SMI-DS are not that much different in this
respect. The naming is more important for accessing the instances
which has to deal mostly with protocol issues. And that is why I said
many times before: With the existing SNMP operations, which do not
allow to manipulate aggregates, I fail to see the benefits of
hierarchical naming.
>>>> 7. It is unclear whether compatibility on the wire between
>>>> engines that use SMIv2 style definitions and engines that use
>>>> SMIng style definitions (and naming) is still a design objective.
>>
Andy> Please explain what on-the-wire problems exist
>> See above. We meant compatibility of how existing applications and
>> tools expect OIDs to be formed.
>>
>>>> 8. The proposed new naming touches both the language and the
>>>> protocol, at least in the sense that no existing implementation
>>>> we are aware of will be able to handle hierarchically named
>>>> variables in a meaningful way. We would expect that 100%
>>>> forward/backward compatibility implies that I can use existing
>>>> tools to look at data implemented by an agent whose
>>>> implementation is based on an SMI-DS MIB module.
>>
Andy> The new hierarchical naming is identical to SMIv2 for all the
Andy> constructs currently available in SMIv2. For generic
Andy> applications which have no knowledge of the objects they are
Andy> manipulating (e.g. mibwalk), all the protoOps work exactly as
Andy> before, and they still work. For applications that need to
Andy> understand the objects they use, the semantics of the object and
Andy> the structure of the instance portion of the OID need to be
Andy> known. This is no different than the current situation with
Andy> SMIv2.
The SMIv2 has the notion of conceptual tables and many many tools and
applications have this notion build into code. They will just not work
with hierarchical names.
>> Does this mean a struct which contains another struct, a union and
>> an array will just not exist in the SMIv2 mapping? I do not think
>> you mean this since it conflicts with the stated requirement in
>> SMI-DS:
>>
>> - Maintain 100% forward and backward translation compatibility with
>> SMIv2. [...]
Andy> This means that any SMIv2 construct can be translated to SMIv3
Andy> and back to SMIv2 in a transparent way. Just as with SMIv2 ->
Andy> SMIv1, SMIv3 -> SMIv2 will have some features that can be
Andy> translated, but not transparently.
OK. I see what you mean. How many years to you expect does it take
from the publication of SMIv3 until we have the first WG defining a
MIB which uses complex data types if they can't be mapped to SMIv2
naming? See above for the Counter64 example.
>>>> 9. We believe that a syntax which looks close to SMIv2 but means
>>>> sometimes something different is worse than a syntax which looks
>>>> different to SMIv2 and means something different. People who do
>>>> not understand the differences will merge SMIv2/SMI-DS in
>>>> arbitrary ways. This has happened with SMIv1/SMIv2.
>>
Andy> Please provide examples where this is the case in SMI-DS. It
Andy> was certainly my intent to maintain semantics and syntax as much
Andy> as possible. I think it would be more confusing to MIB readers
Andy> and writers to transition to SMIng syntax, in which absolutely
Andy> every macro and clause in changed.
>> Frank provided examples. SMIng as well as SMI-DS are trying to
>> make a big step forward on how we describe management data. Trying
>> to give the impression that this did not happen has more potential
>> to mislead users about what they are doing. You obviously noticed
>> while working on SMI-DS some some syntactic constructs show be
>> harmonized and so you changed some SMIv2 constructs which I am sure
>> others will regard as unnecessary change. I guess we can debate
>> this endlessly.
Andy> There have been many people that characterize the SMIng syntax
Andy> changes as purely gratuitous changes. If we decide to completely
Andy> change the syntax of every construct, then I think we should use
Andy> XML Schema, not a new syntax. I don't care about the syntax
Andy> nearly as much as the ability to reuse semantics and move
Andy> aggregates and sub-aggregates on the wire.
I just wanted to make the observation that what one regards as
"gratuitous change" the more time you spend on the language issues.
<soap>
If you have a recent copy of libsmi, then type "smidump -f xsl IF-MIB"
and you will get a translation of an SMIv2 MIB into an XML schema. A
student is working seriously on the details and believe me or not,
there are interesting subtle issues with doing this. And doing it
the other way, ...
</soap>
>>>> 13. We believe that an array should be similar to an ASN.1
>>>> SEQUENCE OF, that is the array feature should work with an
>>>> arbitrary type. The SMI-DS ARRAY mixes containment and
>>>> multi-valuedness in one construct. Programming languages such as
>>>> C and even ASN.1 do not do this. Arrays do not yet exist in
>>>> SMIng (only in the form of tables in the protocol mappings).
>>
Andy> Programming languages such as C allow both types of constructs.
>> No.
Andy> typedef struct { int foo[12]; char name[30]; } example_t;
Andy> struct { int foo[12]; char name[30]; } example;
You missed the point. Both examples are structs which contains arrays
(or SEQUENCEs which contains SEQUENCE OFs). In SMI-DS, the ARRAY mixes
containment and multi-valuedness in one construct. The SMI-DS ARRAY
does not only say there are multiple values of the same type, but it
also allows to define the members of the type which has multiple
values. I can't write it down in C since it does not exist. I guess
I am bad at explaining this.
I will try an example:
VAR ARRAY ifTable {
-- ...
SCALAR ifDescr {
}
SCALAR ifType {
-- ...
}
}
In C, you would have (very much oversimplified):
typedef struct {
char *ifDescr;
int ifType;
} ifEntry_t;
ifEntry_t ifTable[];
There is no way to combine the struct definition (containment) with
the array definition (multi-valuedness). You can syntactically combine
things, but it is still a struct and an array.
struct {
char *ifDescr;
int ifType;
} ifTable2[1];
We prefer to keep different concepts (containment, multi-valuedness)
separated rather than mixing them together.
/js
--
Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/>