[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 
> >>>>> Jon Saperia writes:
> 
> >> 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.
> 
> Jon> If it is such a minor point, why is it in the document?
> 
> Because some WG members brought this up and the objective is obviously
> not wrong. So here we are.

Juergen. Please see Joel's recent note. He has a good summary point. The
question is not about right or wrong. It is about value of the proposal
and requirements.
> 
> 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.
> 
> [...]
> 
> Jon> Because if it is minor, it is not worth the impact to the
> Jon> community any change would cause.
> 
> There was some sort of agreement in London that the document lists
> objectives and that the next step will be to analyse the cost/benefits
> of addressing them. So there is IMHO no point in discussing whether
> something is "minor" or not.

When we make engineering choices at any stage of the process, even the
beginning, we impact the work further down. I think we should be
exercising a bit more critical judgment at this point in the process.
> 
> Jon> My question was not what the Charter said. My question was what
> Jon> is the current working group consensus?
> 
> Let me try again: The document under last call is written to comply to
> the WG charter. If people think this is wrong, then I believe they are
> saying that the charter is wrong.

The question is again not right or wrong. The question is (if it is a
charter one), is it the right thing at the present time? By adjusting it
now we might save some work. See my last comment that follows your last
statement. 

> 
> Jon> Actually no, I am suggesting that for the majority of the
> Jon> requirements as stated in the document with the exceptions I
> Jon> noted, any solution is more costly than the benefit.
> 
> I accept your opinion, although I disagree with it.
> 
> Jon> I believe what we are properly debating is the cost/benefit of
> Jon> changes. I think the biggest bang for the buck is found in a very
> Jon> small number of changes. Many of the rest are related to sppi/smi
> Jon> merging and parser optimizations. Neither are high priorities in
> Jon> my view.
> 
> My understand from the London meeting was that we get the objectives
> finalized and in the next step, we analyze the costs/benefits. This is
> what Andy proposed in a posting to this list some days ago and which I
> thought we had agreement on in London.
> 
Even though I was not there, Andy's proposal seems workable to me. We
can get done what we need using that technique though it may be more
laborious than if we look back to the beginning and see if we are
operating under the most useful charter. If there is no desire to
change, we can correct most of these things in the next round very much
like you can attempt to work around architectural issues when you move
to implementation, possible, but expensive.
> 

Thanks,
/jon
--

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