[OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans

["Douglas Gash (dcmgash)" <[e-mail]>]

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.