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

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



This email responds to several issues, I'll try to quote
people where relevant and otherwise just summarize...

Jon Saperia wrote:
> peoples wish list, I would not object. If it as an rfc,
> even an informational one, and it has the words requirements 
> and sming in it, then I think it is way bloated and will not 
> serve the purpose of advancing management. 

I think the term objectives replaced requirements because
of the feedback of the meeting in London.  With the change of
requirements to objectives, does this satisfy the concern
raised above?


On the issue of ASN.1's availability, suitability, etc., it
really seems like we wasting time arguing about solutions.
ASN.1 is relevant in the context of the human and machine
readability objectives.  When we get past objectives, we
should have some good discussions about whether the cost of
ASN.1 (in terms of human readability, for instance) is worth
the benefit (in terms of continuity).  Everyone will have 
their own opinions of the cost/benefit of ASN.1, both in
terms of human readability and machine readability.  I know
I can look at ASN.1 and make a judgement about human 
readability.   I can do the same thing about Mike Ayer's
"bninhgfbjkbgfxjlxbt", about C++, and about a Faulkner novel.
Each has a different level of human readability.  To me, and 
I suspect to many of the participants in SMIng, human 
readability is a valid and a valuable objective.


Mike Ayers wrote in reference to machine readability:
>	We cannot specify our way out of bad implementations - "what" and
>"how" are different questions.  This requirement is also meaningless (of
>COURSE it must be machine readable, or else parsers can't exist) and should
>be lost.

This really seems counterintuitive to me.  SMIv1 _clearly_ had 
problems with machine readability.  A mistake was made in this 
space before - having an objective that urges us to avoid 
repeating the error is relevant and should not be excised.  
It really seems like self-contradiction to say,  "of COURSE 
it must be machine reable" in the same breath as "This 
[machine readability objective] should be lost".  I agree 
with the first clause - of COURSE it must be machine
readable - so lets say so as an objective. Keep it.


Jon Saperia wrote:
>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. 

If the questions are charter questions then I think the wrong questions
are being asked.  We have a charter that went through the IETF approval
process. It was proposed, discussed, and finally approved by the IESG.
We now have a working group and a charter to guide us.  The objectives
document seems to be very much in line with the charter. If it isn't in
line with the charter, let's fix it.  If it is in line with the charter,
lets proceed onto the real engineering work and stop trying to change
the charter.

Cheers,
David Putzolu