Dear Working Group, We wanted to respond to recent posts regarding the TACACS+ informational draft, and update on status and intent:
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. However at this time we do not have plans to change the list of authors. 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. 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+. For example, as a start point for this, I think we can define: 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. 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. 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. If this status/plan is not in order, please let us know. Many thanks! Best Regards. The authors. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
