[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-sming-reqs-03.txt
> > -----Original Message-----
> > From: Jon Saperia [mailto:email@example.com]
> > 1. I agree with your points about learning from our past
> > and keeping that
> > in mind as we evolve the SMI. We are in danger of adding significant
> > cruft/complexity to something that novice engineers already find more
> > complicated than necessary. Novice engineers are the ones
> > that most often do a
> > lot of this work. I observe that much of this cruft and
> > complexity existed
> > prior to the desire to merge SMI and SPPI.
> [Dave] Absolutely, simplifying the language is an important goal. Would not
> enabling reuse and removing some of the weirdness and arcane rules of the
> SMI help achieve this?
Dave, I believe that could be done without creating an new syntax.
> > 2. One of the points that I made several times before the
> > WG formed, and
> > since at WG meetings is that some of the changes (you listed
> > some) seem to
> > offer little practical value and will be disruptive. If I
> > thought that adding
> > semicolons at the end of each line or changing the
> > capitolization rules would
> > advance the state of management, I would be be all for them.
> > I just have not
> > been convinced that they will.
> [Dave] Please note that the requirements do not require semicolons nor
> specify capitalization rules. It sounds like you are ready to start
> discussing the current language proposal, not the requirements.
If we were only discussing requirements we would not have started with the
nmrg document as the baseline. Something I was never particularly fond of. You
and I have had several conversations about 'improvements' to the SMI. I have
given some examples in my previous notes. None of which require a significant
change of syntax but which would yield results which I think we all would
want, e.g, inheritance improvements etc.
I think we can agree to a very short list of improvements. That should be the
Jon Saperia firstname.lastname@example.org