I can't help but see the conflicts of three/four QA ideas in action:
"Who moved my Cheese?"
"Getting it right... the first time!"
"Customers are always right!" including the follow up
"Customers are always right .... sometimes."
Improvement come by taking risk and don't settle with just old way of
doing things. We try to do work with maximum quality, minimum cost
and strive to avoid future problems or revisiting old one so that all
parties are winners. Customers are satisfied, yet, there is a point
where you can't satisfy all.
Its a balance. IMV, as long as the the new two maturity level process
does not change the IETF "QA process" negatively, I don't see a
problem with it but it does sound it will necessitate a higher, more
rigorous document reviews.
SM wrote:
At 13:17 30-08-2011, Jari Arkko wrote:
There were a number of smaller details raised in the discussion. But I
did not see an overwhelming consensus on any specific issue to make
changes. But I will ask Russ to take a look at the issue raised by
Scott, whether he wants to add an informative reference to RFC 5657.
I read draft-housley-two-maturity-levels-09. I read the messages which
might be interpreted as statements of support. Mr Burger offered that
we are moving a baby step forward. Mr Resnick asked "A baby step
toward what exactly" to which Mr Saint-Andre pointed out that "we are
more closely aligning our documentation with our organizational running
code". The organizational running code actually sets a higher bar than
what is documented in RFC 2026 for the publication of a Proposed
Standard. The draft does not even discuss about that.
Mr Carpenter believes that "the present situation is confusing both to
IETF newcomers (who may falsely believe that the IETF actually follows
the 3 stage process) and, worse, confusing to users of IETF standards
(who may falsely believe that a document isn't useful until it's
advanced). We, and those users, gain by reducing the confusion". In
terms of document clarity, RFC 2026 taken together with
draft-housley-two-maturity-levels-09 only reinforces the confusion for
anyone who takes the time to read BCP 9.
Mr Atkinson pointed out that a change in perception alone is sufficient
to increase [his] own motivation. Mr Burger confirmed that the intent
of the proposal is to change the perception.
Mr Halpern mentioned that the draft tries to align what we document with
what we do. In a response, Mr Klensin mentioned that the draft
addresses one provision of our processes in which documentation and
practice don't align, a provision about which there is no subtlety or
confusion within the community at all (even though new participants may
be confused)".
Mr Housley in response to one of my comments mentioned that the argument
I raised was for the status quo and added that "We have decades of
experience with that not working. That is essentially an argument for a
single maturity level; that is how the process is really working
today". As a note to the reader, I may have quoted Mr Housley out of
context. I presume that members of the IESG have followed the
discussions surrounding this draft to understand the context.
The Sponsoring Area Director mentioned that the opposing opinions were
more about a desire to do something else than specific objections about
this proposal. An Area Director generally sponsors documents that he or
she believes in. I would like to point out that even if a desire to do
something else was tabled as a proposal, my perception is that it would
be difficult to have such a proposal sponsored by the relevant Area
Director.
Mr Crocker and Mr Housley are listed as authors of STD 71 and STD 70
respectively. It would be informative if they could comment on the
impediments they came across in advancing their documents to Full
Standard. Mr Gellens and Mr Klensin might also be able to comment on
the impediments given that they are listed as the authors of a soon to
be published STD.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf