On May 12, 2017, at 2:40 PM, Douglas Gash (dcmgash) <[email protected]> wrote: > 1) Regarding the use of uncredited text from Alan DeKok: > > It is certainly the case that Alan has spent time actively engaged in the > process of critiquing this document to improve it, and provided numerous > proposed textual suggestions,. We would be very happy to acknowledge > Alan¹s contribution to the document by adding wording that is agreeable to > Alan, in the next draft. In fact not having this acknowledgement for > Alan¹s contribution so far was an oversight, for which we apologise to > Alan.
Thank you. > However at this time we do not have plans to change the list of authors. I will note that document authors serve at the discretion of the WG / chairs / AD. > Alan: if you feel that we have exploited your suggestions too fully, such > that an acknowledgement in the document would be unsatisfactory > recompense, then we are happy to consider removing all text that you > identify, that you feel is derived too closely from your work. It would generally seem to be better to acknowledge people who have contributed substantially to the draft, instead of removing and re-writing their text. The point of the draft is to have a documented protocol, not to artificially limit the set of authors. > 2) Definition of Done > > We note that there is still comments along the lines that the document is > not ready, in that the protocol is still not adequately described. We > would like to make sure that the next version does adequately describe the > protocol. > > Rather than to chase a cycle of comment/response, we¹d like to see if we > can determine what the ³Definition of Done² checklist and metrics would > be, by which we can measure that the content is be acceptable for the WG > for such a protocol as TACACS+. As I've suggested and others have agreed, what people want is a response to reviews. > For example, as a start point for this, I think we can define: Since drafts proceed to RFC via WG consensus, I would suggest that not responding to reviews is a de facto admission that the draft does not have WG consensus. > 1. The packet formats: defining fields and their constraints > 2. Identification of fields whose values have meaning for protocol flow. > This will include error and fail fields. The way that these fields > influence the flow must be documented. > 3. Identification of the fields which have a common meaning, but are not > intended to direct protocol flow. > 4. Identification of fields whose values have meaning in terms of the > deployment, which would simply be listed. All of these topics and more are addressed in my reviews. > If there are other aspects of the protocol, whose absence would mean that > the protocol is not fully described, we would welcome input to help us. I've given you input, which has largely been ignored. > 3) Next Steps: > > We have two next steps: > > 3.1) We will produce a new revision correcting the issues such as the > email address of Lol Grant and the above mentioned acknowledgement of > Alan, and incorporate lessons from 2) above. > 3.2) We will provide a summary of the changes between the original draft > spec from 1998 and the new draft. i.e. you won't bother to respond to reviews, you want the WG to read the draft again to see if the comments have been addressed. Again, drafts get published based on WG consensus. Ignoring WG consensus is just bad practice, and unproductive. At this point, I'm done. I oppose any and all publication of this draft until such time as the authors can demonstrate that they've addressed concerns raised here. I will continue to respond to Q&A about my reviews, but I see no benefit in reviewing new versions of the draft. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
