Re: WG Last Call draft-ietf-sming-reqs-04.txt

[Jon Saperia <saperia@jdscons.com>]

> 
> >>>>> Jon Saperia writes:
> 
> Jon> 4.1.3 Human Readability.  This requirement is not specific. Which
> Jon> people do you mean? And for whome do you wish to solve a problem?
> Jon> I do not think this is a major problem that merits they type of
> Jon> change implied.
> 
> 4.1.3 only says that SMIng must be human readable. What is wrong with
> that? Note that the objectives document does not specify the syntax
> of the solution.

If it is such a minor point, why is it in the document?
> 
> Jon> 4.1.4. Machine Readability I think the motiviation for making
> Jon> easy to implement SMIng parsers is misplaced. As stated
> Jon> previously this does not seem to be a major issue.
> 
> I am not going to debate whether this is a major or minor issue.
> But I do not understrand what is wrong with simplifying parser
> implementations in general. Especially since I know too many SMI
> parsers that are just broken.

Because if it is minor, it is not worth the impact to the community any
change would cause. 

> 
> Jon> 4.1.5 This seems based again on the need to optimize for
> Jon> parsers. A non problem in the companies that I am familiar with.
> 
> I frequently answer questions because people are not able to figure
> out from the SMIv2 documents what the precise syntax is. Providing an
> ABNF grammar for whatever syntax SMIng will use is thus useful not
> only for parser implementors but also for people who use this language
> to write MIB modules.
> 
> Jon> 4.1.6 Is it still the working group consensus to align SPPI and
> Jon> SMI? At an open area meeting (the ietf before the London IETF). I
> Jon> got the impression from our ADs that these two would be allowed
> Jon> to grow independently. This general goal seems counter to that
> Jon> position.
> 
> This is what the charter says. During the WG meeting, people were
> asked what the preferences are between (a) merging SMIv2/SPPI and (b)
> enhancing the state of art in network management data modeling.  The
> outcome of this discussion is reflected in the current objectives
> document on page 4:
>
 
My question was not what the Charter said. My question was what is the
current working group consensus? 

>    It has been recognized that the two main goals of (a) merging
>    SMIv2/SPPI and (b) enhancing the state of art in network management
>    data modeling can lead to conflicts.  In such cases, the SMIng
>    working group's consensus is to focus on enhancing the state of art
>    in network management data modeling.
> 
> Jon> The requirements as currently stated will have a large
> Jon> implementation and training cost and will distract vendors from
> Jon> producing better management software and confuse customers.
> 
> You are obviously arguing about a certain solution - not the
> objectives per se.
> 
Actually no, I am suggesting that for the majority of the requirements as
stated in the document with the exceptions I noted, any solution is more
costly than the benefit.

If, on the other hand, we want to get rid of everything and start
over and make a quantum leap forward without a concern for backward
compatibility, training and development costs, then we could look at
more alternatives. I recall a working group discussion where this
approach was rejected - which is fine. I believe what we are properly
debating is the cost/benefit of changes. I think the biggest bang for
the buck is found in a very small number of changes. Many of the rest
are related to sppi/smi merging and parser optimizations. Neither are
high priorities in my view.

> /js
> 
> -- 
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> 
> 
> 

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/