Draft minutes of the sming meeting...

["Durham, David" <david.durham@intel.com>]

Sorry about the delay on these. Please provide any corrections by EOD Monday
8/27/01.
-Dave


SMING meeting minutes 8/6/2001

Chair: David Durham
Special thanks to Steve Moulton and David Harrington for taking minutes
during the meeting.
Reported by: David Durham

The SMIng working group meeting took place on Monday, August 6, 2001 at the
51st IETF (London).  The meeting was chaired by David Durham.  Steve Moulton
and David Harrington were the minute takers. 

The agenda consisted of the usual agenda bashing, a document status review,
review document changes since last call on the requirements I-D, and
reviewing conformance of the current documents to the requirements document.
There were no calls to change the agenda as proposed.

An interim meeting was held in Seattle in May, 2001, in conjunction with the
IM2001 meeting held the same week.  This meeting dealt primarily with the
requirements document.  This document has since gone through working group
last call.


There are six documents in progress.  

draft-ietf-sming-modules-02.txt
draft-ietf-sming-02.txt
draft-ietf-sming-inet-modules-02.txt
draft-ietf-sming-copspr-01.txt
draft-ietf-sming-snmp-02.txt
draft-ietf-sming-reqs-03.txt

All documents except the SMIng mappings to COPS-PR (01) and SMIng
requirement (03) are at second revision.  The requirements document will
soon be available as revision 04.

Note also the requirements document that resulted from the operations and
management interim meeting held in conjunction with NANOG:
draft-ops-operator-req-mgmt-00.txt


Summary of issues brought up during the last call period:

.  Too many requirements
.  Avoid egregious syntax changes
.  Map directly to protocols, v.s. to SMIv2
.  Why address COPS-PR at all?
.  Why isn't there better collaboration with EOS?


Jamie Jason reviews list of changes incorporated since last call was issued.
See the slides for the complete list.

A lively discussion followed.

A query was made from the floor regarding the state of internationalization
in the SMIng effort. Bert Wijnen responded that you would not be allowed to
write a standards track MIB using a national language, as English is the
defined language for IETF documents.  However, there is no limitation on
writing enterprise specific MIBs or MIBs in other organizations in other
languages than English.

Joel Harplen noted that the requirements as written imply that the goal of
merging SMI and SPPI and the goal of a more expressive language are somewhat
inconsistent.  Either we are trying to improve the state of the art, or we
are trying build the smallest possible superset of SPPI or SMI that will
deploy easily.  It is difficult to have it both ways.  He would prefer to
focus on advancing the state of the art.

David Durham asked for a discussion of issue priorities.  Should our primary
task be improvements for SNMP/SMI, with a secondary goal usability for
COPS/PR? The room consensus, as described later was clearly in favor of
prioritizing advancing the state of the art first.

The goal is to address some of the issues we have had in SMI for some time
(Integer64, etc), and get SMI and SPPI converging, and to advance the
language to make it more usable. Those are the three goals.  What should be
avoided is evolving requirements that are not reasonably achievable.
Feedback from Andy Bierman is that we need to evaluate the costs of meeting
these requirements vs. the benefits.

There was a specific objection to requirement 43 (changing the instance
naming so that SMI and SPPI would be similar).  Redoing instance naming is a
change that would be detrimental to both SNMP and COPS and doesn't seem
productive.  Low hanging fruit (UNIQUENESS, etc) are reasonable.  Instance
naming, and separating protocol dependent and independent parts are hard.
In requirement 45, split those things out that are bad. Andy Bierman would
like to remove requirements 43 and 45.

On the other hand, Walter Weiss stated that he is a little puzzled by the
justification for removing arrays, since they can be done in both MIBs and
PIBs.  Yet they're awkward to do currently.  He'd like to make their use
more elegant in sming.  It was responded that the requirement for arrays was
somewhat unclear, e.g. whether or not you could get atomic access to arrays
was not clearly stated.  Walter stated that this would be an area ripe for
improvement, and Dave noted that arrays are still currently listed as "nice
to have" in the requirements I-D.

Mike Ayers asked what art are we trying to advance here.  Many of the
requirements have nothing to do with consolidating SPPI and SMI.  He can't
tell if the requirements are good without more justification.  He asked that
if he goes in and reads the charter, if a requirement is not in the charter,
should it not be in the requirements?  The answer was that advancing the
state of the art is a goal of the charter, and the primary goal of the WG
given the consensus of the room. The requirements document is simply a very
detailed listing of items that achieve the goals of the charter.

It was noted that the requirements posted by the operators in the Scottsdale
meeting were very interesting in seeing what they want to do.  There were no
requirements for improved MIB readability or even use of MIBs at all.  Bert
observed that while we should all be concerned about the operators'
document, it doesn't represent everyone. Joel also commented that the
operators who expressed their opinions were very clear, but there was a
question of whether they represented a representative set of operators.
Walter Weiss noted that their point in that document is that they had to be
able to work directly with a device sooner or later.  The ones who were
there were very clear about where and how they wanted to function.

Joel Halpern said that we have a number of requirements that are not
directed towards unification and are very protocol specific.  He can't get a
handle about what is sensible to include. Dave Durham responded that there
are those who think Integer64 and a few other needed fixes are advancing the
art and that the requirements are likewise very detailed listing each of
these prescribed fixes.

Jeff Case addressed requirements 3, 4, and 45 (human readability, machine
parsability, and SMIng not assigning OIDs).  He stated that he had made a
general comment on the list that 45 requirements are too many to focus on.
Having that many requirements is the antithesis of finishing in finite time.
He went on to note that requirement 45 conflicts with requirement 4, and
requirement 3 also conflicts with requirement 4. Making it easier for humans
to read and write MIBs conflicts with making parsers easier to write. These
three goals show that you cannot optimize 45 goals simultaneously.  

Addressing the machine parsability requirement, Walter Weiss stated that we
want to make sure that the grammar generated is unambiguous, and that we
allow it to be ambiguous in the future. Randy Presuhn agreed, stating that
it is much more important that the grammar be rigorously defined than easy
to parse, since few will be writing parsers, but the language must be clear.

The point was also raised that it must be easy to distinguish objects that
have security implications.

Dave Durham asked if it would it be OK to replace the requirement that
states the syntax is to be easy to parse and replace it with a requirement
for a rigorously defined syntax?  Jeff Case favors human readability over
ease of machine parseability in any case. It was pointed out that making
both machine & human readability objectives will force the WG to balance the
two appropriately.

Another speaker observed that he finds this whole conflicting requirements
discussion a bit baffling.  It would be sufficient to require that the
language be written in LALR(1).  This it makes it easy to write parsers.
There is plenty of room to work with the resulting syntax to make it human
readable. So what's the conflict? There was no further discussion on this
point. 

The chair attempted to determine if there was sufficient consensus that the
requirements are good enough.  To this some express that they think we have
enjoyed the requirements document about as much as we can.  Being torn
between "good enough, ship it" and "we need to work on this thing some more,
as we are going to use it to guide our future work".  Jeff for one doesn't
completely agree with it, but he doesn't want to work on it any more.  He'd
like to move on.

David Harrington said that he made the suggestion after we originally did
the requirements that the goals are not laid out.  We have two different
problems and sets of requirements (advancing state of the art, and SMI/SPPI
merge), and we ought to be looking at it as such.

Dave Durham asked the question: Should we move the requirements document
forward as an informational RFC?  The room consensus was that we should.

Wes Hardaker stated that in Seattle, we started with 75 requirements.  After
10 hours of not eating, we whittled it down to 45.  It is clear that there
are a lot of people that want these 45.  Now, if we stamp this an
informational RFC, then it seems like we need to meet all of the
requirements.  At this point, we need to solicit proposals to meet these
requirements.  We ought to put words at the top of the requirements to
translate "requirement" to SHOULD, not MUST.  This moves the document from
list of requirements to a list of features.

Room consensus is to change from 'requirements' to 'objectives' to address
this point, and also to recognize that a costs vs. benefits analysis will
need to be applied to the objectives once we get to looking at proposals.

The minutes of the discussion that follows was specifically to determine the
priority order of the different WG's tasks as specified by the charter
(merge the SMI/SPPI and advancing the state of the art). 

Dave Durham's suggestion is to focus on one goal or the other first, and
thus avoid any conflicts between the two.  The requirements don't change if
you do one or the other, you just address the relevant requirements for the
primary goal first.

It was noted that we can roll 64 bit integers into the SPPI/SMI merge
requirement, as it is in the SPPI and also improves the state of the art.

Andy Bierman noted that he is all for merging things where the result is an
advancement.  He is much more interested in using the new class definitions
rather than some of the constructs that seem less interesting out of the
SPPI.  We don't spend a lot of time nailing the requirements, because that
implies that we know exactly what we are going to do before we can do a cost
vs. benefits analysis given a proposal. The requirements are specified well
enough for us to continue. He is much more concerned about changing
instancing than about changing upper vs. lower case. Andy is in favor of
advancement, with the proviso that we instruct the EOS working group not to
hack it.

Glenn Waters said that SMING is constrained and EOS is constrained to the
current framework.  We should change both of the charters to deal with this,
or say we are going to do something simple or quick.

The issue of goals of the WG was then readdressed. Bert Wijnen said that we
want to advance the state of the art within bounds.  Once we get this
language, He doesn't want working groups to have to write both MIBS and
PIBS.  So this stays in the charter.

Steve Waldbusser noted that there are some move forward things that he would
call required maintenance.  Advancing the state of the art in network
management may not involve advancing the state of the art of SMI.  One of
the things that we feel pain over is that people are not using SNMP for
configuration.  The reason that vendors don't use the tools we create is
that it is hard to do.  Adding more state of the art may make it harder.  We
need to be careful and balance these things.

So Dave Durham called the question: Do we want as the primary goal to
advance the state of the art of this language or simply merge SMI/SPPI?  The
room consensus was clearly in favor of advancing the state of the art of the
SMI as the primary goal of the WG.


Dave Durham stated that the work product from the NMRG has been put forward
as a proposed syntax for SMIng.  He asked what other syntax proposals people
have for the next generation SMI.

Harrie Hazewinkel noted that the NMRG syntax has been worked on for 
a long time.  Do you expect a proposal to be of similar quality?

Dave Durham said that there are already several popular syntaxes that exist
to choose from. So no one should be inventing something completely new.
ASN.1, NMRG, and a possible XML proposal were all proposed.  There would be
a syntax comparison between proposals.

Several questions and statements arose around the process, such as

.  What is the time frame for these grammar proposals? 
   (Chair: at least one month from the time an announcement 
    is made on the mailing list.)

.  Does the language have to be written in ABNF?
   (Chair: The proposal is for a "rigorous grammar".)

.  Juergen observed that the grammar isn't the issue. The interesting 
   part is what we do with the data that comes out. Andy agreed; he 
   didn't want to have the discussions about the minutiae, but wanted 
   get on with what the constructs are. The chair commented that it's
   the results of what you achieve, not the grammar.

.  Is it in the charter to consider existing technologies such as SOAP?
   (Chair: We are considering data description, not communication  
    protocols. Or goal is to advance the SMI.)

.  Randy Presuhn observed that some of us remember a number 
   of other information models; To what extent are we interested in 
   revisiting some of these concepts? 
   (Answer: We are only interested in the concepts that were considered
    during the requirements process, some of which were derived from 
    these models as well, e.g. DMI->CIM, GDMO etc.)
 
Chair: The chair will address on the mailing list what is the exact
mechanism and time frame for submitting proposals.

Meeting was closed at 530 PM.