ietf
[Top] [All Lists]

Re: Conclusion of the last call on draft-housley-two-maturity-levels

2011-09-06 10:05:14
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf



--
Sincerely

Hector Santos
http://www.santronics.com



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf