[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sming wg meeting minutes from 52nd IETF...
I'm still editing these to be a bit more compact, but people are asking for
them now. So let me know if you have comments or corrections thus far.
Thanks,
-Dave
SMIng WG Meeting Minutes from the 52nd IETF:
Minute Recorders: Ravi Sahita and Sharon Chisholm
Chair: David Durham
SMIng wg first session minutes (Thursday - 3:30pm -5:30pm)
Minutes from Ravi Sahita.
* Agenda bashing, status
The chair presented the agenda for Thursday and Friday,
Thursday agenda - listed draft proposals docs under discussion and informed
the wg that the requirements/objectives draft has completed last call to
become an informational RFC.
The objective was to submit the proposals based on the objectives document,
and the proposals are to be discussed at this IETF.
* Juergen -nmrg proposal, status update
Implementation attempts from France - sming front end parser has been
written in java, and is available as downloadable code. It has an HTML
generator backend, and is available at jsman.com.
Alexandros Zachos is extending libsmi, written in C, with SMIv2/SPPI
back-ends, and a sming core front-end parser. A first prototype is working
and it will be integrated into libsmi; he has sent some draft links on the
mailing list which maps the DiffServ SMIng MIB - mapping that to the
DiffServ MIB and PIB.
Juergen proceeds to discuss the sming's compliance with accepted objectives,
objective by objective. Objectives not yet completely supported by SMIng:
* Accessibility - SMIng: SNMP uses non-accessible for index objects, while
conceptually we don't need that - it causes confusion. Hence access state in
sming is just readable or writable.
* Special char syntax has been an objective for chars in description clauses
- it's not there but should not be hard to do.
* Namespace control - currently sming uses module names to make sure there
are no collisions, but there is no namespace control in current sming
proposal, we need to just say we need infrastructure (like IANA).
* Module conformance - will start on this after the other stuff gets stable.
* Discriminated Unions - have to work on this.
* Instance Pointers - not in proposals because when mapping to both SNMP and
SPPI, the instance identification is a problem.
* Reusable vs. attribute groups - attribute groups that you want to mark as
instantiateable vs. non-instantiateable data structures - we don't
distinguish between these.
* Extension rules - we didn't consider these at this point of time.
* Deprecate IMPLIED - SNMP still has it, we haven't used it, probably we
want to reformulate by adding text that you shouldn't use it etc. to remain
backward compatible.
* Methods - didn't work.
* Ref Tagged rows - doesn't exist in the sming proposal.
* I18n - currently ASCII still.
Questions:
Chair asked the question - who uses IMPLIED in SNMP? Ans: Notification Log
MIB. 2573 applications MIB has implied, proxy MIB, target MIB, notification
MIB has it as well.
Chair asked if the diffserv SMIng mapping takes advantage of sming features
such as reuse & structured data. Juergen: yes.
* Andy Bierman discusses his SMI-DS proposal:
The SMI-DS design goals were to improve the data modeling capability, make
MIBs easier to read and write, make set operations easy o implement, to
provide better reuse of data definitions as well as the reuse of associated
manager and agent code. SMI-DS optimizes the instance naming (different than
SMIv2) for containment and SNMP get next. SMI-DS is SMIv2 with its naming
changed to allow C-like data structures: array, struct and UNION are the 3
base types. You can nest these in arbitrary ways. SMI-DS naming allows
arrays within arrays and other complex containment.
- Ease of use is a very important topic and should be the wg's design
ideology... We are currently trying to optimize for the MIB compiler writers
and that's wrong, we really need to decide: do we need these kinds of syntax
elements like a semicolon after every statement. Also, remove redundant text
which simply causes more mistakes. ASN1 sequence: mapping with syntax clause
object causes errors, so removed sequence clause.
- Currently the SMI does not allow any thing other that scalars, we can use
augments, sparse augments, shared indices and clones of shared indices but
the relationship between these objects is not maintained. We should be able
to map the natural, nested data structures we use every day to the data
model. But we can't do this today. Eg. If they are writable objects, I have
multiple row status, we have serious complications to deal with if they are
collapsed back together.
- We want code reuse in the agents so SMI-DS maintains the object
relationship in the naming. We want nested handlers - not just one handle.
Today we simply don't give any capability for data nor code reuse.
- Also, SMI-DS extends the augment concept to data objects, because
currently cut and paste is the only possibility to achieve reuse.
- For SMI-DS unions, only one item is returned. Which item is determined
thru the naming, the oid is the discriminator (don't need extra type
discriminator attributes as in SMIv2).
- Mapping smiv2 to smi-ds, aggregate types map to sequence, SCALARs map to
scalar. There are corner cases that deal with limitation due to smiv2 hacks,
but it is possible to create a smiv2 definition from the smi-ds... not the
same naming, but same semantics, e.g. a sequence is an array in the reverse
direction.
- SMI-DS does away with all those needless rules in the SMI that simply make
it hard to use. BCPs should address potential misuse problems, not a huge
number of language rules.
Open issues:
Descriptors for array index - there are none - since not accessible. Mapping
to SPPI is not done. But it should be easy to map back to SPPI naming where
anything is simply an integer index. There are going to need to be
descriptors. For the array index there is no notion of by reference vs. by
copy of. There is no uniqueness clause. There is no ABNF syntax.
Summary: We need to advance data modeling caps. But we should optimize for
readers first, then writers, and last come the compiler writers. When there
are tradeoffs between readability and parseability - we should lean towards
readability. Finally, we need to provide trans to smiv2 for trans, but we
should optimize for the features we want moving forward, just like we want
fort smiv1 to v2. If you can never use the thing because its features are
not in the old one, then that's no value. Yes we have a transition period,
but not lose the value.
Questions:
randy - you can still get the reuse today - there is more than one way to do
your code generation. Knowing there is a shared index, you can share code.
It's the cloned index, which is a problem. Andy: the only way is to read the
MIB at the agent.
randy - is the augment really applied globally or for that typedef, if used
in 10 diff places? the aug will be inappropriate for one of the usages?
Andy-then you would need sparse augments. Does the augment apply to the
typedef or usage to typedef? Andy-applies to the typedef.
dp - Are the current SNMP protocol operations supported? Yes - do you have
ideas for new proto operations? ab - smiv2 is totally untouched, since I
don't believe it's broken, there is no need to change syntax things. In SNMP
you do a get next on the table, it's only the accessible objects that is
something you get/set, and also those same accessible objects that go in the
module compliance we don't say not-accessible there.
dp-so the current protocol ops support this? Ab - we need new protocol ops
to support aggregate objects which is a transport change, but current
protocol ops will still work even with the new naming scheme.
wes -Like it. Any effort to reduce the amount of text needed for reordering
relationships? ab-There are not that many places where reordering happens,
but this would be a great optimization, right now what we do is another
mapping and have other glue in the descriptions that says this is not the
real obj that's that one.
rp - subid usage is unique, that's kind of neat. However, the order in which
objects come out changes and vacm instance views are formulated with
variable length indexing, for example, restrict access to an object with
variable length indexing you wont be able do that with a simple vacm policy.
ab - haven't given enough thought to VACM.
js - The typedef is where you define the index which means you can't do
reordering any more, since its associated with that typedef. Once you define
the index as a,b, you cant re-define this complex type somewhere else where
index is just a. That's why NMRG moved the indexing to the instantiation. ab
- But that seems to make it harder to use for humans, I don't want to go
through the rest of the docs to understand things.
rp- There is a distinction between reuse of defined data type vs. the actual
use of the data type in the identification of a variable in an actual object
instance, this is where different network management models differ widely.
At what stage do you put constraints on naming? In cmip object definition
doesn't say anything since there is a separate name binding. In smi there is
the other extreme where all naming is nailed down in the object definition.
Therefore, cloning is the only way to get reuse in the smi. ab - The naming
scheme is coupled with the data definition, I don't see the reason for
separating the mapping. js - Instance naming in c is the memory address, the
struct doesn't have define the instance naming scheme. ab-I think it'll be
hard for humans to use it if the instance naming is defined somewhere else.
Randy is going to take his point on the mailing list about the issue 'to
define the binding of the index information within the class definition' to
the mailing list.
* ASN.1 for SMIng - A Triglia leads the discussion:
Believes ASN1 is a good base for a language like SMIng. The main concern was
to meet the objectives that were stated for the SMIng. The design goals were
to specify a new language that complies with the objectives, and enable mib
writers to define complex data structures like combining arrays, structures,
and unions in arbitrary ways. To separate the reusable classes, the ASN1
proposal has the concepts of entity class and entry instance.
This proposal provides a flexible instance naming scheme, for smi flat
tables and for more complex data structures. Proposal took into account all
work that had been done in the other proposals. Proposing as an option two
different naming schemes, traditional smi naming scheme (tabular), and then
a hierarchical naming scheme. The last goal was to provide a data model for
both SNMP and COPS-PR.
The first example (slide 2) shows this proposal hasn't changed much from the
existing smi. There are slight diffs in specific cases, there are some
braces but otherwise the meaning is the same. The biggest change is that
there is no oid is associated with a definition. The last example is of the
compliance statement the syntax is very similar to the old smi syntax
without any additional macros.
The Proposal features separation between entity classes and entity
instances. Types can be reused as multiple objects of the same constrained
or unconstrained data types, and multiple complex data structures, where you
define a structure and another where the previous one appears as a
component. Entity classes names each subordinate components by relative
oids, entry classes don't specify the instance names (subids) but do specify
parts of the name. When instantiating a table as an object, every component
below the base oid gets assigned the relative oids, SNMP will have
visibility of only atomic data items, that are often leaf level components.
cops-pr has visibility only of structures that consist entirely of atomic
items.
Questions:
js - What is the diff between your hierarchical naming scheme and Andy's
naming scheme? at - for me extensibility is an option, then you have a zero,
otherwise it is the same.
s1- The same SMI-DS problem with vacm would exist in this proposal then. at
- here you can choose what type of table you want: traditional or
hierarchical.
dp: Do union elements have to be same of the same type? at: No.
* Jeff Case - Proposal SMIv3:
There are several kinds of changes we might make changes to the SMI and
SPPI. 1. The required maintenance, this has a good cost vs. benefit ratio,
so we should make changes only if there is a favorable c/b ratio. My
proposal has some changes of additional data types and some things that
SPPI/COPS-PR has.
2. Advancing the state of the art - some such changes may be controversial,
may have poor c/b ratio. My favorites are - aggregate objects with multiple
indices on table and all that implies. My prop to the list was
misunderstood, there is much but not 100% overlap with smi-ds. Also we
should be closely coupled with eos. I started looking at the c data
structures in the protocol, while Andy was looking at adding them to the
mib. In my proposal we don't have reordering of indices. Instead of a row
identifier I have a chunk identifier, and a subchunk identifier. But I
didn't put those changes in my proposal, so that we can base those changes
on a cost benefit ratio
Jeff questions anything that the SPPI requires for compatibility that
doesn't provide value to the SMI. Comparison with CMIP: the .1 row entry
identifier that was put there in the SMI for compatibility with CMIP. And
CMIP is not around in many places today. Don't want to repeat such quirks
simply for the sake of compatibility.
Other issues: Should we merge SMI and SPPI to familiar look and feel, OR
throw everything out? We should apply the state of art, take the good ideas
from SPPI into smiv2, drop extra .1, but keep the same look and feel. We
should not make changes for sake to it, only change if they make things
better. When faced with conflicting requirements of readers, writers,
toolers - we should get rid of all those CLRs (Crummy little rules). The
docs and actions should follow good engineering principles. Also our work
should be constrained on protocol and eos changes, the smi is the glue
between the mib and the protocol, I believe these two parts have evolved
together and should continue to do so.
SMIng - session two, minutes From: Sharon Chisholm
Minutes of panel discussion. Panel included representative authors of all
proposals except Jeff Case. Panelists were Andy Bierman, Juergen
Schoenwaelder, Alessandro Triglia. Chair David Durham.
Overview of discussion topics:
1) Differentiating the Proposals
2) Naming Space/OID Allocation
3) Look and Feel
4) Compliance Statements
5) Fix SMI a bit or a lot?
6) The SPPI Question
7) Mapping back to transport
8) Accessible Table Indices
9) Instance Naming
10) Partial vs. Total Data Retrieval
11) Case
12) Language Extensibility
13) Actions
14) Most Cited Objectives
1) Differentiating the Proposals
--------------------------------
Conclusion:
SMI-DS provides a hierarchical naming scheme, closely resembles the SMI, and
ties instance naming to the data type definitions. The NMRG proposal changes
the syntax to something more commonly familiar, and separates the data
definitions from instance naming while preserving tables. Alessandro allows
complies ASN.1 and allows the writer to choose their naming methodology. The
action item was to investigate whether indexing needs to always be decoupled
from data structure definitions to maximize reuse, or whether it can always
be defined relative to data structure definitions for reasons of
simplification.
Discussion:
ASN.1 Proposal's key features:
- The strongest feature is the full re-usability of every definition. Able
the reuse any definition ... atomic types, unions, arrays to both define
higher level structures as well as define instances of these things.
- For example, when we defined a row class .. entity class bases on a
structure that will be used as a row ... we can then define two different
row classes that use the same definition, but can use different indices.
- In response to yesterday's question about extensibility. I had said we
did things similar to Andy's proposal ... somewhat true ... extra zero
inserted ... but extensibility actually is implemented at the instance
level, not at the class level. More similar to the NMRG proposal in this
way.
- A table can be instantiated that is of a particular entity class.
Dave D - Andy, is there any structure you can't re-use?
Andy - No, in both Juergen's and my proposal you have full reuse.
Randy - The difference here is in the derivation process if the instance
information is bound to the type. That is, if the index is bound to the
struct or if it is bound to the next level of definition (how you decide to
use the struct).
Alessandro - I would say that in Andy's proposal, when he defines an array,
the definition of the two is inside the definition of the array, so he is
going to have to redefine the definition of the array sometimes in order to
reuse it.
2) Naming Space OID Allocation
------------------------------
Conclusion:
Continue to investigate the hierarchical OID space data structure naming
concept. Look to see if there are any serious problems with the concept for
existing implementations.
Discussion:
Dave - Another key differentiator is whether the name space nesting of data
structures is also preserved in the OID mapping and, thus, over the wire.
Andy - Instance naming ordering is being preserved on the wire in SMI-DS,
this has also been called adhoc hierarchical naming.
Dave - Does everyone understand the difference? We have either manually
assigned OIDs or adhoc hierarchical naming. The advantage of what Juergen
has done is it preserves the existing table concepts. Andy simplifies things
by removing this level of indirection, allowing data structures to be
expressed hierarchally in the oid space. Alessandro's proposal allows the
writer to choose between these.
Randy - There are two aspects: Assignment of sub identifier and also the
structure of the resulting OIDs. The asn.1 proposal allows you to choose how
this is done.
Alex - the user can specify what naming structure they want. Either existing
or complex. ASN.1 proposal allows both. Either traditional tables or the
hierarchical one.
Sharon - Are non-manually assigned OIDs predictable?
Andy - Yes, they are predictable. Nothing ever renumbers even if people
leave stuff out.
Dave - question to Alessandro who can do both ... when you do hierarchical
naming, is it the same as in Andy's proposal?
Alex - Andy adds a zero before the attribute id ... I only add the id by
default and the zero if optional. Otherwise the same.
Andy - How would an snmp engine know that it is getting an extended oid if
the 0 is optional?
Alex - An agent will know this. It knows when there is an additional 0
because it should know the MIB.
Dave - Did Juergen want to add anything about SMIng that deals with naming?
Juergen - We started with the mapping SMI/SPPI and that is why we have a
flat numbering scheme. At one point we had something more dynamic and
people thought it might be difficult to define arrays (some question).
Dave - what concerns me about allowing both techniques, and the writer
choosing either or, is that it adds complexity ...
Randy - I think the question is, whether it is really necessary to change
how we change OID constructor methods in order to accomplish the varying
data definition. It might not be necessary. The part that worries me is the
two different ways of building OIDs in a runtime system. I'm saying that the
specific mapping between the hierarchical naming and OID might not be the
only way to do this.
Randy - A question, when you came up with the SMI-DS way ... why?
Andy - I wanted to be able to preserve the naming so imbedded objects would
be named the same no matter how they were imbedded. I can then have
cascading method routines because the naming is going to be the same for
that structure, no matter where it appears.
Randy - In c++ you can overload the method, another way is that you have a
container class that defines instances of the things it contains.
Andy - Engineering is about tradeoffs - flexibility vs. ease of use
I think my proposal makes a good trade-off. Too much flexibility in
standards is bad. It makes things more complicated. Ease of use and
leveraging existing technologies is what I would like to achieve.
Dave - Should we move away from just tables into more hierarchical data
structures?
General agreement from audience.
Dave - converse question ... who thinks bad?
Result is that this looks like something we should continue to look into.
3) Look and Feel
--------------
Conclusion:
Ease of use is the goal here. The priority order is that it should be easy
for MIB readers to understand the syntax. Anything that can be done to
improve ease of use should be the first objective. We should not try to fix
things that aren't broken without good reason. It makes sense to merge the
best features of each proposal into one.
Discussion:
Dave - Next question relates to the SMI look and feel. Jeff's proposal is
the most like the existing SMI, then Andy is the next most similar. Andy,
did you want to explain why you stayed with the basic SMI syntax?
Andy - I was trying to bring some of the basic concepts of c into SMI.
I was not trying to make things look like C. I left out pointers ... we
don't have pointers so there is no need for them. The data modeling concepts
of C are well understood so we should bring them into the SMI. The typdef of
a scalar is close to what we have, but there is a bit of extra stuff
allowed. The struct and union thing is just a wrapper. They have a
description clause that is extra. The protocol only allows us to get to
accessible objects anyways.
Dave - Why did you want to preserve the SMI look and feel?
Andy - People (customers) are used to it.
Dave - Same question to Juergen: Why did you change from the SMI syntax?
Juergen - First thing to note is we have defined something new, conceptually
different. People might get confused if we make it look like something we
already did. There are also people who have not used what we already have.
Our syntax looks more like normal programming languages to get rid of
learning curve for new people.
Dave - Alex, do you claim that the existing SMI is ASN.1 .. so that you have
preserved the SMI syntax?
Alex - I tried to preserve as much as I could. Use the same arrangements.
Example compliance statements. I introduced a few things. As far as the most
important things are concerned ... definitions for new data models,
I had to move away from the old. Wherever I could, I tried to keep the
syntax the same. When you see differences '{' '|', that was done to make
notation compatible with current SMI.
Dave - What are the benefits to using ASN.1?
Alex - I believe the main purpose was to create a SMIng language according
to objects. We chose to do this in ASN.1 because we know ASN.1. One benefit
is that the syntax of the language itself is standard and can be checked by
freely available tools.
Dave p - So, I believe the approach you are trying to take is .. anytime you
come up with new language, you can have tools to verify the language.
But, once you said "here is what the syntax looks like" a compiler would
have to do semantic checks. So verifying the language in comparison is just
simply a bootstrap process.
Alex - yes. I was thinking of the scenario of possible implementations.
Randy - I'm going to start channeling Jeff. One of the items in this
proposal ... understand whether you want to maintain look and feel of SMI or
because ASN.1 forced you to do this ... We have a sequence and then the
definitions. Yesterday Jeff went on about the problem with this distinction.
Some MIB tables will have 20 or more columns. The only tie between them is
positional. Was this for compatibility or because ASN.1 forced you to do
this?
Alex - It is easy in ASN.1 to define a sequence. If you want to use this
method, you have the power of re-using definitions. Why do you want to have
a table with 50 attributes? In a traditional design, it's not meaningful.
If you can nest the definitions, it's much better ... then you won't have 50
attributes.
Randy - My question is within a modern ASN.1 definition, would it be
possible to do the attribute definitions in-line, instead of simply have it
positional.
Andy - I find the ASN.1 proposal very difficult to read for this reason.
Randy - In C/C++ definitions are done inline.
Alex - This difficulty in ASN.1 is counter balanced by the fact that you
already have an existing notation to define things. ... I don't have ready
answer to your question, whether or not it is possible to do it differently.
Randy - Being able to do it inline would make the ASN.1 proposal much more
attractive.
Alex - This was my first solution. It might be possible to it in line.
Dave - quick consensus poll
1. don't want to change from existing SMI.
2. fix and improve the SMI, don't change what is not broken.
3. move to something completely different (easier for new people).
Juergen - I believe we are all in the same group.
comment - I agree that all three proposals make changes for good reason.
Randy - discontinuity ... ASN.1 changes introduced are because it isn't
ASN.1 as opposed to being required because something is broken in the
existing SMI.
Juergen - Take SMIng ... remove extensive ... remove case changes ....
ASN.1 uses scalars .... if you make these changes the core syntax looks
remarkably the same. You just have to pick one.
Dave - Then the conclusion is that all of these prop are going in the right
direction. I'd like to start merging these proposals taking the best
features from each.
4) Compliance Statements
------------------------
Conclusion: Existing compliance statements are awkward and will likely need
to change as a result of changes to the SMI.
Discussion:
Juergen - You need to change things, like the compliance statement.
Andy - Only accessible objects. Descriptors that are for accessible objects
would be listed in compliance.
Randy - If you have something that is used two different places, the
compliance needs to be able describe these two different objects' usage.
Andy - If I have type foo ... and I use it in another table?
Randy - If foo has an element named bar and bar is used in another table. If
the usage is different, we need to be able to talk about both usages in
compliance.
Andy - foo1.bar foo2.bar ... good point.
Randy - And this is a change to syntax.
Juergen - we generally talk about conformance of an instance. We probably
want conformance on objects.
Randy - If something does not work in SMI, we may want to fix it. I've
always found the conformance hard to use.
Andy - I agree ... compliance section is an issue.
5) Fix SMI a bit at a time or a lot at once?
----------------------------------------------
Conclusion: There was rough consensus to make one big change to the SMI
instead of patching the existing SMI piece by piece (i.e. just adding
Integer64 base type).
Discussion:
Dave P - There two ways to get the end result. There is the "let's go and
put in maintenance stuff right now" vs. a full-blown SMIng. Maintenance
includes support for additional base types.
Juergen - Addition of types is a protocol problem.
Randy - I disagree. Some of it could be considered a transport mapping. 64
bit integer. It's kludgy, but could work.
Andy - I do not want to have multiple roll outs. It is expensive to do
(vendors will have to change everything anyway just to get a minor roll-out)
and is fundamentally poor engineering practice. Also, ease of use is not
just readability. It is also minimizing the number of ways there are to get
things wrong. I find that just adding more knobs is not good engineering.
Same with adding more rules.
Dave H - I think we have two problems to solve 1. maintenance But, people
don't want to change and learn new tools. We need to do enough to make the
changes worthwhile.
2. Marketing problem, people don't like SMI. I think we may need to change
that. We hear from people that they don't like to have to read through this
arcane language.
6) The SPPI Question
------------------
Conclusion: There was rough consensus that SMIng should be optimized for SMI
and SNMP first, and extra complexity should not be added to the language to
achieve compatibility.
Discussion:
Andy - I would be quite happy with the NMRG syntax. I like parts of their
proposal, I like their augments. My issues with that document are with
protocol mappings and complexity to deal with SPPI. I think if we relax the
SPPI thing and optimize for SNMP, then I'd like that proposal. First I want
to keep the SMI, but then my second choice is a language syntax like what
people are already using.
Dave h - Optimizing for both COPS-PR and SNMP makes things more complex.
Dave - We said at last meeting that we would focus on mapping to SNMP.
Dave h - Separating the mapping makes it more complicated.
Dave - We need a SNMP mapping. I don't think anything should be done in the
language itself to support others. So a new mapping should not affect the
way the language looks. So, I assume you don't want to see things like the
extra 1 added to the OID for mapping to CMIP?
Dave h - That's it.
Andy - When things are spread out it increases the chance of error.
Self-contained definitions are a better approach. ASN.1 spreads it out a lot
already. SMIng spreads it out more to deal with SPPI.
Juergen - There is a difference between defining data structure that can be
reused and instances that can be used. SMIng did things the way it does not
just because of SMI and SPPI, but to gain reuse of the data structures.
7) Mapping back to Transport
-------------------------
Conclusion: Just basing language on ASN.1 does not provide a ready mapping
to SNMP. One could not simply use existing ASN.1 tools to do this.
Discussion:
Juergen - What ASN.1 is missing is a mapping back to SNMP.
Randy - At the BER level an asn.1 enumeration is different than an integer.
A different tag at the protocol level. Juergen's point is between what the
ASN.1 says and what would happen if you ran it through BER and what would
have to happen at the protocol level.
Alex - I wanted to separate SMI issues from what the transport would do. It
probably needs more text to describe it.
Andy - Juergen: Could the protocol mapping be put together with the thing it
is a mapping off? Nothing to prevent that?
Juergen - No.
Andy - That would make things easier.
Randy - Actually, there is a little value to the sequence, it gives concise
list of what is in the table.
8) Accessible Table Indices
-------------------------
Conclusion: Table indices in SMIng should be made accessible again.
Discussion:
Andy - Yes, we should put non-accessible things in conformance.
Sharon - But I had asked to make indices accessible again on the mailing
list and people agreed.
Andy - True.
9) Instance Naming
---------------------
Conclusion: Keeping instance information on the right has value in that it
will be easier for existing implementations to deal with it.
Discussion:
Andy - I had a long talk with Jeff about naming. He might have a trick to
shoe horn things to get instance names all on the right, but we would
require new protocol operations. We are chartered to use the existing SNMP.
Randy - The mapping to the transport is part of the SMI.
Andy - What Jeff was talking about would not be compatible with row
pointers. What is in the MIB is not the same as what is in the wire.
Dave - Why did Jeff want to do this?
Andy - He wants to instance information that is not on the right.
Randy - If we allow instance information to be scattered, it would allow
dynamic location of instance information and would make things difficult.
Randy - It's once you are in the sub-agent ... received request ... need to
find method for this instance ... to find that method, you need to match up
an OID against methods. If all the information is scattered in this OID,
then this is trouble.
Andy - If they are all at the right, don't you need the MIB?
Randy - You don't need to crack the types until you get to the class. You do
need to do a match on the OID to find the class.
Andy - There is always an object that is anchored. You can't just register a
method routine at that point?
Randy - the difference is that instead of doing all of your level of nesting
in one swoop, you need to do it all in the method.
Andy - agree we require some code changes to deal with numbering changes.
Randy - If contiguous, we don't need the changes ...
Andy - I disagree ... if you are defining data structures .... now we are
diving into implementation choices.
Alex - I think what you have proposed can be done. It may work. You just
lose the ability to reference the row. But, otherwise, you still have the
ability to define complex data structures.
Alex - PL1 language does something similar.
Andy - Not stuck on naming scheme. If it's a show stopper, we can do
something hacky to get things on the right.
Randy - What it does is pass data structures in platforms native data
format.
Dave - Andy - you also have the option to map to table for transition?
Andy - yes, but there are some corner cases where the algorithm gets hard.
It could expand to multiple tables ... most is straightforward. If
everything is pushed to the right, then the translation becomes easier.
Randy - shoving to right has some appeal. It does not allow rows.
10) Partial vs. Total Data Retrieval
------------------------------------
Conclusion: There was consensus that even with the new data structures in
SMI, we needed to be able to retrieve both all and part of the data,
depending on the situation.
Discussion:
Sharon - 90 % of the time, you only want 30 % of the attributes.
Juergen - If you have complicated aggregate objects, you want the entire
object instance together.
Andy - A well-established application is multiple interfaces statistic
retrieval. In this case you want most of the object.
Andy - Just like when you can select columns to dive down on, now you can
create instances to dive down into.
Randy - but if you are using getnext or getbulk, and an attribute has a
table, you will get that if you want it or not.
Randy - had to provide developers with an API object, provide attributes and
do the get bulk and fix things for them.
Juergen - Jeff wants to keep ordering as now, he wants to EOS to provide
support for other ordering.
Randy - <describing API in product>
Sharon - I don't want to rely on magical APIs to overcome problems in the
protocol & SMI.
Sharon - I appreciate being able to get entire object, but need either EOS
or something to provide a way to retrieve all efficiently as well as a way
to get partial information.
11) Case
---------------------
Conclusion: General consensus to keep case as it is in the SMI unless there
is good reason to change.
Discussion:
Andy - I guess resolution on look and feel .. all in same category and any
of the syntaxes could meet look and feel requirement. We are going to have
to decide what the syntax looks like. I'd move towards Juergen's syntax. I
like the derived classes, instead of augments. There will be a
discontinuity. All the existing work won't disappear, so people coming into
the field will still need to read all the MIBs.
Andy - If you look at making changes only when they are necessary. Why
change the strings READ-ONLY?
Randy - I think that argument also applies to the capitalization rules. The
visual impact needs to be respected. If we have cases where there is no
technical reason to change something, some changes may not be worth making.
Andy - I agree.
Dave h - Is lower case more readable.
Randy - yes.
Dave h - Do we care?
Randy - We should not change it. Those keywords are upper case.
Dave P - if you say that keywords can be upper case, and then say that names
can be the same as keywords ... this would make it difficult for reading and
compilers.
Juergen - C doesn't have uppercase rules.
Dave P - I have no problem with upper case.
Juergen - Rather talk about language extensibility features. Case isn't a
big issue.
Andy - Juergen, if you changed your keywords to upper, your innovations
would not be lost.
12) Language Extensibility
-----------------------
Conclusion: Language extensibility will likely require something like the
semicolon in the SMIng proposal. Many arguments were made against allowing
language extensibility. Some people like the idea of an extensible SMI, some
don't.
Discussion:
Andy - Juergen, people could get used to the ';' but why do we need it?
Juergen - It has to do with language extensibility. If we drop that
objective, then they can go away.
Andy - I don't want to give MIB developers the ability to do their own SMI.
Only want to working group to be able to add stuff.
Dave h - What benefit does the ';' give you.
Juergen - It allows you to skip well-formed statements that you don't
understand.
Bert - If we keep the ';' and decide to use it in the future ....
Dave - Does anyone want extensibility?
Andy - I'm in favor of methods only if WG can use it.
Dave H - could be useful to write our keywords in upper case and not allow
other people to use upper case, so we can reserve the name space.
Randy - do we want modification of the language to change the base SMI?
comment - does not think there is a way to extend it without preventing
people from using it.
Andy - Then I'd like it taken out, and we can just update the SMI using the
normal process.
Randy - when you are generating code from MIBs, you need some hints, the
question arises as to whether you want to do those hints inline or with some
separate stuff. MIB writers like to decorate their definitions with extra
stuff. Need to separate hints from implementation specific MIB.
Extensibility to do hints, it is counterproductive.
Andy - At Cisco we had to undo importing unsigned 32 from a Cisco TC.
Dave - Other working groups could require new clauses. Bert ... what do you
think. We want IETF to have this ability ... but then others can abuse it.
Bert - we will be limiting ourselves. Need to carefully evaluate.
Andy - need to differentiate between a MIB compiler to skip stuff versus
people using the stuff where important information is not understandable.
The syntax is fine, but we miss the semantics.
Andy - Why don't we come up with an SMI that will last 10 years instead of
making it extensible. Don't like making optimizations for unknown products.
Juergen - could provide a way to point to extra documents ... make things
extensible.
comment - People will find a way to extend it even if don't have the ';'
Randy - boils down to a willingness to put a limit the grammar.
Dave H - I don't see the need to have the extensions.
Randy - Do we want to permit the addition of these additions without revving
the SMI?
Andy - I don't want extensible mechanisms at all.
Dave - Take this discussion to the list. We don't want extensibility for
vendors, but want to investigate whether we want to do it for the IETF.
13) Actions
-----------
Action Proposal Authors/Editors: Come up with integrated proposal that takes
the best features of all the existing proposals.
14) Most Cited Objectives
--------------------------
* Composite/Nested Data Structures
* Reuse of Defined Data Structures
* Addition of new base data types (ie. Integer64)