[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Minutes from the sming wg interim meeting, June6-8, 2002 in Washington DC
Resending final minutes...
-Dave
-----Original Message-----
From: Durham, David
Sent: Friday, June 28, 2002 9:50 AM
To: 'minutes@ietf.org'
Cc: 'sming@ops.ietf.org'
Subject: Minutes from the sming wg interim meeting, June6-8, 2002 in
Washington DC
Sming interim meeting in Washington DC June 6-8 2002
Minutes reported by David Durham.
Special thanks to those who recorded the minutes: Juergen Schoenwaelder &
Steve Waldbusser.
Attendees:
Joel Halpern
Andy Bierman
Bert Wijnen
Randy Presuhn
David Harrington
Steve Waldbusser
Juergen Schoenwaelder
Chris Elliott
Glenn Waters
David Durham
Wes Hardaker
Rob Fry
June 6, 2002:
* Status and Update:
o Where are the sming documents? They had expired (this is fixed).
o Jeff withdrew smiv3 proposal, supports smi-ds.
o Andreas is not pursing asn1 proposal.
o Latest smi-ds version 00 on web page (actually third revision from
Andy)
o Consensus recap from last IETF meeting:
* N-levels of nesting: Yes
* Hierarchical instance naming: Yes
* Continue using SMI syntax as much as possible: Yes (for
the time being)
Juergen presented for discussion questions related to high-level goals
in an attempt to better understand consensus. Clearly we desire a more
powerful language so that 1. Human readers can understand data models more
easily and 2. Human writers can express their models in a better way. But do
we want to support more than the current SNMP technology? The consensus was
that more is fine, but the primary target is SNMP technology, for both
monitoring and configuration. So retaining compatibility with current SNMP
technology is desired. Attendees wanted the ability to convert from SMIv2 to
SMIng (a requirement), and converting SMIng to SMIv2 only where possible
(not a requirement). The other question concerned the SPPI. As this topic
has been addressed in the past, the chair repeated that this working group
will not be constrained or concerned with backward compatibility with SPPI.
COPS-PR supporters are responsible for writing a translation if they desire
it.
Juergen went on to explain why Frank and himself had reservations to
the SMI-DS approach. People want to improve the SNMP technology for both
monitoring too. SNMP technology is even worse for configuration management.
Frank/Juergen believe that we should not change the things that are working
well enough. Specifically, they believe changing instance naming will break
many applications. The other attendees did not agree. No one who had
applications thought that they would be adversely affected by the SMI-DS
naming scheme. MIB walks will still work, and the advice was not to use old
tools to view new structures anyway. Ideally there shouldn't be any changes
that result the wire protocol, but adding new base types is clearly an
exception. Juergen ended by suggesting that it was the lack of high-level
operations that was the main problem, and using an RPC mechanism would be a
good thing. Andy agrees that having clear elements of procedure/use cases
for those things people typically do would be beneficial. Overall, people
wanted to improve readability and clarify the syntax of the language. Two
clear non-requirements was the idea of making it easier on the tool writers
(who are a minority) as well as providing annotations to the language. It
was felt the latter would be best handled by separate documents, not inline
with the standards (overall, making it hard to add new a syntax clause was
considered a feature and not a bug).
Finally, Juergen strongly believes that the language should be familiar
to the majority of people out there. There is no language out there that has
the concept of a leaf. Randy agrees that what we do in the smi is different
than what most cs students are familiar with since we use different
terminology. Andy doesn't believe that SYNTAX or MAX-ACCESS is the problem,
it is the lack of data modeling and data structure. Clearly, however, OBJECT
in the smi is not what people think it is.
* Terminology:
o Continue to use SMI terminology? Don't change what isn't broken, if it is,
at least take pains to explain why when changing terminology.
o Define delta's from existing SMI terminology for use this week:
* SMIv3 will be the output of this working group.
* Base Types = {Integer, OctetString...}
* Derived Types = Refined Types: TCs. Smi-ds does not have a mechanism to
extend existing structs in the OO sense. Sming has a mechanism to derive
complex types from other complex types.
* Scalar Types = Leaf nodes. Anything that is not an aggregate. Can even be
a pointer.
* Attribute=property=subelement(in XML)=node(smi-ds): The namable elements.
Lot's of discussion, consensus toward the word attribute (aggregates can
also be attributes).
* Structure: Defines a set of attributes.
* Class: Essentially a structure with methods. Neither smi-ds or sming have
classes containing methods.
* Object: ? Will not use this term moving forward, too much baggage.
* N-levels of nesting (tables in tables, arrays in arrays...)=Aggregate
types: Complex data types can be comprised of other complex data types,
including arrays.
* Hierarchical Instance Naming: using oids to name hierarchical instance
data.
* Unions: Choice.
* Index: Instance identifier.
* Row pointer:
* Instance pointer
* Typed Pointers=Constrained Pointers:
* Intermediate Type Definitions
* Name Spaces: Constrained/Scoped universe of identifier names.
* Constraints: Clause that constrains the values an attribute may take.
* Reusable (abstract) Definitions = type definitions
* Leaf Nodes : node which does not contain other nodes. Attribute which does
not contain any other aggregate type. Consensus was to change term to
something more understandable.
* Aggregated Data Object: This term refers to any data object which provides
some sort of containment for other data objects, which is any variable
construct other than LEAF (e.g., ARRAY, UNION, or STRUCT).
* Data Object: This term refers to any SMI Data Structure variable
declaration, at any level of containment.
* MIB Object: This term generically refers to a SMIv2 OBJECT-TYPE macro
definition. It may also refer to an SMI Data Structure definition.
* OID: This is a shorthand term for 'OBJECT IDENTIFIER'.
* LEAF: This term refers to any accessible data object with a syntax that
resolves to a SMI base type.
* Method is basically Elements of Procedure as can be determined from a Use
case.
Next was a discussion about the merits of having a hierarchical oid
namespace. Hierarchical oids provide aggregates and aggregate information
even at a protocol level. They also enable the individual items of the
aggregate to be addressable. The difference between SMI-DS and SMIng
documents is at what stage during the definition process are the oids
associated with the datastructure. Consensus is that we want to explicitly
assign oids within the data structures and not have map them or define
arbitrarily later. Smi-ds provides for reuse of the suboid number as well as
reuse of the data structures themselves, removing at least one level of
indirection. Consensus was to preserve the hierarchical aggregations on the
wire was a valuable thing to do (and not to strictly depend on the syntax
definition).
What followed was a discussion about indexing. SMI-DS keeps the index
portion of the sub-oid on the right. The reason for this is that oid
pointers (eg. Row pointers) expect indices on the right. If they are not,
then old mib definitions will not be able to effectively reference new smiv3
mib definitions. Keeping the index on the right does have the side affect of
making the getnext behavior look even stranger. It was noted that the
protocol will not allow aggregates to be hidden, so you can only skip over
hidden data. Given these issues, there was a suggestion for having two oid
spaces, one with indexing on the right, another with indexing inline,
adjacent to the current level of aggregation.
Randy brought up the issue of unions and getnext. There is a problem
with getting next lexical ordered element with a union because get next may
skip over the union because the index is on the right. It wasn't clear how
bad this problem would actually be, it simply would require the manager to
try and get the possible union values directly. A possible solution would be
to put the union discriminator on the end of the oid, but this will then
mess up the lexical ordering.
June 7, 2002
Indexing was further discussed with Andy's (corrected) slides showing
conceptual mib walk with smi-ds mibs. The main issue was how to determine
where the prefix oid stopped and when the index portion began w/o requiring
the smi-ds mib (some intermediate layers of the snmp stack may need to know
this information, but won't have access to the definitions). It was
suggested to use a .0 between the prefix and index portions to understand
where the break point is. Since .0 is not allowed in mibs today, it could be
used for this purpose. Another suggestion was to simply use meta data that
specified where the prefix and index were for any given oid. Conclusion was
there needs to be sufficient meta data available to figure out where each of
the indicies are. But we should keep the naming the same as it is today. It
was also suggested to use the meta data to encode the oid textual name, and
other mib information so that mibs can be more self-describing (like XML
documents). Other more radical suggestions were to move away from oids
altogther, being that they seem to be the root of all evil. Needless to say,
such a radical step would break backward compatibility. In which case, it
would probably be better just to adopt XML or something else, and not invent
yet another mechanism for network management.
Next Steve presented the TRANSACTION clause concept to let
implementations know what attributes are expected to be part of a
transaction. CREATE-TRANSACTION {ipAddressData, ipAddressFlow, ...}. Needs
to create transaction for an entire row, in the specified order.
CREATE-OPTIONAL ... provides a list of optional transactional parameters.
Most had an issue with forcing ordering. They believed that create and go is
sufficient to perform this functionality w/o ordering constraint. The
consensus was that it wasn't the ordering that matters, its dribbling out
the objects over multiple atomic sets that is the problem currently. Some
also had an issue with forcing some implementations to deal a "must not use"
object in the transaction. The transaction clause appears to be useful vs.
defval because there may be the need to combine variables across tables as
part of the same transaction.
Andy would like per high level object, elements of procedure. He just
wants it clearly specified, it doesn't have to be in machine readable
clause, could be in a description clause. Elements of procedure simply need
to deal with the 90% cases, clearly describing the steps required to achieve
a desired result.
Next was a discussion on conformance. Much of the discussion related
to enforcing conformance. DavidH suggested that we write a conformance test
script at the end of every MIB (coincidently, scripts can be related to, or
used to define, a use case as well).
When applied to different levels of nesting there is an issue with
status. What if deprecated objects exist in a type def? If its use as a
variable is deprecated. What if it is deprecated as a type definition but
its use is still current by some variable? ... The consensus was that this
should simply cause a compiler to issue a warning.
With respect to ACCESS, group consensus was that the equivalent of a
MAX-ACCESS goes in a type definition that can be further constrained in the
variable definition. Where as the C semantic only goes from the first level
down, we want it to apply through all levels of nesting.
There was some discussion on the scope of reuse/amount of reuse. The
old smiv2 pointers don't allow you to point at a particular instance of an
aggregate. How to distinguish between high-level object pointer vs.
low-level instance pointer. Oid based id's currently point at first
accessible column. In an aggregate composition, it is difficult to define
what the first "column is", so we should define smiv3 pointers in a new TC.
Terminating the object tree with a "0" will help describe where the base oid
ends and the index portion starts. Bert mentioned he has seen zero's in the
prefix before, but this is not allowed, so we shouldn't be overly concerned.
This would help to define aggregate pointers. There is value keeping the oid
structure because we can remain backward compatible with the SMI, and old
mibs can point to leafs of new data structures. Though when getting to
aggregate data types, vacm becomes a problem.
Long discussion that the constraints imposed by the current protocol
and charter dilute the possible solutions. David Harrington presented
removing UDP limitation, port 161 restriction, 484 byte limitation, ASN.1,
Security restrictions, Get/Set/oids, no meta objects, no rpcs, no
create/edit/delete. There is the belief that OIDs are a big problem.
For now we can move forward with data aggregation and aggregated
instance naming. Preserve SMI compatible naming and we would like to get an
SMI out the door that will still work with SNMPv3 & v1. Finally, we can add
features into the language that would be useful for future protocol
extensions. We just need to write guidelines that specify when these
features will actually be used. Some things people would like:
* Getting away from global descriptors that have to be less than 64 bytes
long.
* Indices can be longer than they are today
* Allow multiple sets of indices
* Introduce methods and/or elements of procedure
* Support for transactions
* A uniqueness clause that is different from indices
* Remove those annoying little rules: what you are allowed to create, what
you are allowed to change (revisit these). Eg. New conformance mib, once you
identify the version at run time, no need to deprecate a mib. Not allowed to
extend the range of an integer but you can extend enumerations.
June 8, 2002
There was a discussion about allowing anonymous types for adding
columns. People were comfortable with removing anonymous types IF one can
add columns to the named types. Then you have a short binding after the type
declarations. Randy cautioned that it can lead to readability problems, but
the group consensus was that using a type means you will have to know what
the type is.
Next, Juergen lead a detailed discussion about how to merge the
documents and key issues still to be addressed:
General Issues:
===============
- Should we change name of the converged version to SMIv3? The Group
consensus was yes.
- The agreed set of documents & authors:
1. SMIv3 Language Definition: Andy, Juergen, Frank
2. SMIv3 MIB Modules(core types): Juergen by July 1st.
3. SMIv3 Guidelines : Andy
4. Transition from SMIv2 : Andy, Chris
5. Capabilities MIB : Andy, by June 24th.
6. INET Modules (textual conventions) ?
IETF deadline: July 1st for revised documents, June 24th for new
documents.
The list of specific items below were addressed during the meeting and the
group consensus is reflected therein. Any specific objections to the group
consensus items listed below must be sent to the sming mailing list. Keep
objections specific.
draft-ietf-sming-0x.txt:
========================
- Changed the data format from ASN.1 ExtUTCTime to the format `YYYY-MM-DD
HH:MM' or `YYYY-MM-DD'. The group consensus was this is fine, but should
clarify that this is UTC time. Reason for changing: The current smiv2 format
is unreadable to most people.
- The set of SMIng base types is not identical to the set of tagged
types used in the SNMP protocol. SMIng base types:
Integer32, Unsigned32, Integer64, Unsigned64, OctetString,
ObjectIdentifier, Bits, Enumeration, Float*
Consensus was this is OK and base types should not be imported. While
derived types must be imported. The reason for the change: Make the type
system consistent with up-to-date languages, also there should be no spaces
in keywords because they make parsing a pain, and finally this gives us a
consistent syntax for types.
- [1] OctetString vs OCTET STRING and [2] (SIZE (1..20)) vs (1..20) and
[3] '0a0f'h vs 0x0a0f. Group consensus was:
1. Use OctetString? OK
2. Use SIZE and RANGE? NO
2a. Use no SIZE and no RANGE? NO
2b. Use what we have now? OK (not consistent, but not worth fixing)
3. Stay with '0a0f'h : OK (because it is meaningful to BER encodings to
have module 8, where as with c the encoding is fixed/same size.
- Pointer as a base type rather than OBJECT IDENTIFIER. Syntax of Pointer
restrictions. The room consensus was that Pointer should be a derived type
so one has the flexibility to change it later.
Distinction between Pointer and Identifier? (Examples are RowPointer
and TDomain.) Group consensus was YES.
Call Pointer Reference? No agreement. Pointer aligns with RowPointer,
InstancePointer and does not clash with REFERENCE. Consensus was to go with
the word "Pointer"
- [1] ObjectIdentifier vs OBJECT IDENTIFIER and [2] dotted notation for OID
values (including/excluding hexadecimal values) and module namespace
separator. The group consensus was:
1. Use ObjectIdentifier keeping with reasoning discussed for types above.
2. Should we add even more stringified versions of these oid numbers?
Rationale: Cut & paste between MIBs and SNMP implementations.
Keep in addition the { ifIndex 1 }?
Some confusion between { iso foo(2) 3 } and { iso 2 3 } and
{ iso foo 3 } ...
No conclusions on point 2.
- Hexadecimal Integer32/Integer64/Unsigned32/Unsigned64 constants
('0a0f'h vs 0x0a0f). The group was to keep using the quoted ''[hH] format.
- Float32/Float64/Float128.
People wanted to know why so many versions, why not just Float64?
Objectives document says some kind of floating type support is required.
- Enumeration vs INTEGER and syntax of enumerated values. What about things
that have been coming up such as status for enumerated values or
descriptions for enumerated values? Group consensus that using Enumeration
is OK but do not add more stuff for named numbers.
- Bits vs BITS and format of Bits named numbers. The group consensus was to
use the smiv2 { ... } format. This is not broken.
- Display formats are similar to SMIv2. There were however some comments
some months ago to change them. The group consensus was to keep them as they
are - though the usefulness of display hints is questionable - so keep it as
is unless someone comes up with good proposals on the mailing list.
- Comments. Allow // or keep the current -- with the arcane ASN.1 rules?
Group consensus was mixed, rough consensus was to change to // because the
reasoning was that more people are familiar with it (DavidH says -- comments
often confuse readers). Others suggested using # for comments though this
would confuse preprocessors. Given the varied differences of opinion, it is
probably best to leave comments unchanged from the smiv2 style, possibly
with the exception of just making them continue to the end of the line.
- CAPITALIZE all KEYWORDS for improved SMIv2 look & feel? The group
consensus was yes, keeps things similar to smiv2 look & feel.
- Use a consistent syntactic structure "<keyword> <identifier> ..."? Juergen
thinks SMI-DS also has changed into this direction. The group consensus was
yes.
- Where to anchor module meta information? Removed the LAST-UPDATED clause -
use data of last REVISION instead. The group consensus was yes, remove the
clause.
- Multiple import statements?
IMPORT IANAifType
FROM IANAifType-MIB
IMPORT mib-2
FROM SMIv3
IMPORT AutonomousType, Counter32, Counter64, DisplayString255, Gauge32,
PhysAddress, RowStatus, TestAndIncr, TimeStamp, TimeTicks,
TruthValue
FROM SMIv3-TYPES
IMPORT snmpTraps
FROM SNMPv2-MIB
With or without semicolons? The group consensus was to get rid of the
semicolon. The group was also comfortable with having an IMPORT for every
module. This makes cut-copy-paste operations easier.
- Remove the extension statement? The group consensus was YES.
- Change typedef to TYPE? SMIng allows DEFAULT clauses in TYPE definitions
(which can be overwritten in ATTRIBUTE definitions). Do people feel
comfortable with that? The group consensus was YES.
- Change 'type' back to SYNTAX for improved SMIv2 compatibility? Group
consensus was YES.
- OBJECT-IDENTITY vs IDENTITY and late OID assignment.
Change: foo OBJECT-IDENTITY ... => IDENTITY foo ...
The group consensus was this change is OK, it is less verbose.
- CLASS vs. STRUCT? The group consensus was to use STRUCT.
- Should notifications be bound to aggregate types? There was much
discussion, and other worlds have generic notifications such as a status
change which can be applied to various objects (interfaces, physical
entities, ...). People wanted to see the syntax to understand the usefulness
of reuse here:
STRUCT Status {
ATTRIBUTE adminStatus
ATTRIBUTE operStatus
EVENT statusChange
}
STRUCT Interface {
ATTRIBUTE status { SYNTAX Status }
...
}
NOTIFICATION Status.statusChange {} = base.32
Reuse might be useful, but details need to be worked out.
- Discriminated Unions need to be added. The group consensus was strongly
YES, as seen in the smi-ds proposal.
- Arrays need to be added. The group consensus was YES, again as in the
smi-ds proposal.
- Remove inheritance? The group consensus was YES. Reason, adding
aggregate/structured data is sufficient. Inheritance adds unwelcome
complexity.
- Implicit export of everything vs. "static" definitions? No agreement, this
needs to go to the list because it is unclear what the benefit is outside of
code modules.
draft-ietf-sming-modules-0x.txt: ================================
- Modules need to be adapted to reflect the syntactic changes. The group
consensus was yes.
- 'nil' vs. 'zeroDotZero'. The group consensus was to go with what we have.
- Merge contents of IETF-SMING-SNMP from draft-ietf-sming-snmp-0x.txt back
into SMIV3-TYPES. The group consensus was yes.
draft-ietf-sming-snmp-0x.txt:
=============================
- TABLE vs. VAR ARRAY and SCALAR vs. VAR STRUCT?
VAR would be enough in both cases since the presence of an INDEX
in an aggregate allows to distinguish both cases.
1. TABLE vs. ARRAY - The group consensus was to use the word ARRAY because
table already has a different meaning in DB land.
2. INDEX clauses might not always be bound to the aggregate type to allow
index swapping. - the group consensus was yes.
3. VAR ARRAY vs. VAR UNION vs. VAR ... even though the second keyword is
not really needed? The group consensus was that it may help the reader to
see the second keyword.
Side step: What is a VAR UNION?
UNION Foo {
ATTRIBUTE a { ... INDEX {} ... }
ATTRIBUTE b
}
VAR UNION c { SYNTAX Foo INDEX {b} }
This probably needs more thought.
The group consensus was to syntactically go with the VAR <aggtype>
notation for now. Also INDEX clauses (and similar beasts) are only allowed
in ARRAYs.
- Allow anonymous aggregated types? The group consensus was No.
- Move revised version of introduction text from this document back
into the main SMIng document. The group consensus was YES.
- Other text needs also to be merged. Everything needs to be merged.
YES
- Define the rules for legal OID values? There has been ongoing confusion
what the restrictions on the first two subidentifier are. The group
consensus was YES, people wanted to cut & place into applications, define
what is a legal subid. Should also clarify we are not using ASN.1 notation
here.
- Move mapping to today's SNMPv3 back to the main SMIng document. The group
consensus was YES.
- The notification statement probably needs some work (see above).
Yes, see above.
- SMIng does not distinguish anymore between OBJECT-GROUPs and
NOTIFICATION-GROUPs. They are just GROUPs. Is this useful? The group
consensus was that the distinction is not useful.
- SMIng removes the common
MODULE -- this module
construction as the same effect can be achieved in other ways.
Seems to be an odd construction, the group consensus was to either require
the module name or get rid of it, making it optional helps nothing.
- Would be nice to be able to define GROUPs for foreign definitions imported
from other modules.
- Would be nice to have simpler compliance statements. The group consensus
was yes, this would be nice, but someone has to provide proposals.
- The keywords EXTENDS and EXPANDS sound too similar and are thus a
bit confusing.
Use SPARSE-AUGMENTS since CISCO uses it in comments.
SMI-DS does not provide EXTENDS anymore. Need to think about it.
draft-ietf-sming-inet-modules-0x.txt:
=====================================
- Definitions need to be adapted to new syntax. Yes.
- Definitions must be aligned with recent changes in other
MIBs. Perhaps the INET-ADDRESS stuff should not be done here but
rather in a revision of the INET-ADDRESS-MIB since this is now
actually being used? Yes.