How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? Only Owners/shareholders can question managers and staff. IMO, the meeting/list discussions on any issue without an I-D written is the staff talking/working.
If you write an I-D and to update the procedure related to the subject, you should consider many issues and I think will need many years of discussions, but then better effort result. IMHO, writing an I-D and getting back up by community discussion (with rough consensus) is in the top level and is the owner talking. I hope that when I review and comment on an I-D, it should be considered as one owner is talking, but seems like editors think they are the only owners. When IESG comment on the I-D it is managers/excutives talking. All parts are important to the best of output. AB On Fri, Apr 12, 2013 at 10:33 AM, Abdussalam Baryun < abdussalambar...@gmail.com> wrote: > Reply to below message > The subject SHOULD be: Evaluating Review Process Performance > I prefer the Subject is: Evaluating WG input, the WG review process, > and the WG output, NOT IESG review. > > ------------------------------------------------------------------------------------------------ > > Hi Joe, > > My comments mostly is on your message, but I comment also on I-Ds or > RFCs related to IETF (including joky RFCs). > > I don't think it is write to evaluate the review of an IESG as long as > when we created the I-D and adopted it into IETF SYSTEM, it is already > agreeing on the methods of process that I-D is going through. So the > problem is to evaluate three things not one: 1) the input, 2) the > process review, 3) the output. > > We may make different input methods that go to another body than IESG, > but if you decided to make I-D under IETF current procedure, it will > have to go to IESG. > > I think the IESG are doing an excellent job, but it is best them to > evaluate their performance not the community. Or it is better to find > a body that evaluates the IESG performance not on this list. > > I consider your input on the list as a complain about the process, so > I ask you to notice that your input has an error that needs evaluation > befor going to process evaluation. You may evaluate output, but I > remind you to evaluate input of WGs and inputs of individuals. > > I think the BIG problem of delay in I-Ds or RFC, is the cause of the > WG not the IESG, if you do an excellent WG processes you will get > quick results at IESG. > > AB > +++++++++++++ > Hi, all, > > > As an author who has had (and has) multiple documents in IESG review, > I've noticed an increasing trend of this step to go beyond (IMO) its > documented and original intent (BCP 9, currently RFC 2026): > The IESG shall determine whether or not a specification submitted to > it according to section 6.1.1 satisfies the applicable criteria for > the recommended action (see sections 4.1 and 4.2), and shall in > addition determine whether or not the technical quality and clarity > of the specification is consistent with that expected for the > maturity level to which the specification is recommended. > > > Although I appreciate that IESG members are often overloaded, and the > IESG Review step is often the first time many see these documents, I > believe they should be expected to more clearly differentiate their > "IESG Review" (based on the above criteria) - and its accompanying > Position ballot, with their personal review. > > My concern is that by conflating their IESG position with their > personal review, the document process is inappropriately delayed and > that documents are modified to appease a small community that does not > justify its position as representative. > How do others feel about this? > > Joe >
