Alan, T+ authors, and opsawg, Sorry for the noticeable absence from this thread. I've been focused on some dayjob projects these past couple of weeks.
I have followed the threads, though. I want to hopefully bring some things to closure and get us all to move forward to come to consensus on this doc. On 4/17/18 11:07, Alan DeKok wrote: > On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash) <dcmg...@cisco.com> > wrote: >> Initially (up to around version 5) we included just a very simple security >> section admitting that T+ was insecure and that the second document would >> address the issue. This was deemed to be insufficient, and instead the WG >> collectively determined that more detail should be added to enumerate some >> of the issues, you kindly catalogued some of these, providing a proposed >> text which we took to be a genuine suggestion for text for the document. > > Which it was. > > The point I've been trying to make for over a year is apparently still > unclear. > > There was no excuse for plagiarizing the text in the first place. Using it > verbatim was fine, so long as attribution was given. > > There was no excuse for ignoring every single email I made to the list > asking about this issue. > > There was no excuse for *continuing* to plagiarize the text for over a > year, across four separate revisions of the document. I agree this was not handled well on many fronts, but we can only learn and move forward. As a co-chair, I take responsibility for our part and apologize it took this long to get sorted. The authors have added attribution to your excellent contribution and apologized. I would like to consider the matter, albeit belatedly, closed. >> 2) Reactivity of the Authors. >> >> As far as I know, we have responded to most posts regarding the content of >> the document, with point-by-point replies, > > No. > > See the list archives, especially May 2017. There are multiple people > suggesting that you have *not* done this, and that you *should* do this. I for one have asked for a summary of changes when I did my last review. I did not see it. There was a subsequent revision that did seem to absorb my comments, but there wasn't a response to me email. Typically, when authors receive feedback, they respond in line to either ack or discuss points (typos notwithstanding). > > See line-by-line reviews done by me, which were generally ignored. Despite > that, I did *multiple* such reviews, until such time as it became clear that > such reviews were entirely unproductive. > >> but there has been, for various logistic reasons, long delays in submitting >> the resulting new documents. Hopefully this has been addresses in last >> versions and we will continue with more rapid uploads until process >> completes one way or other. > > The issue isn't rapid uploads. The issue is engagement. It's not > productive to ignore the messages on the mailing list for 6 months, and then > to issue a new release saying "we fixed stuff". Spot on. One needs to engage. I am pleased with the authors' attempts to do better these past couple of weeks. I want to see this momentum continue. >> 3) Change Tracking >> >> The uploads have generally had extensive changes relating to comments (which >> should generally have been summarized by previous email responses to >> comments). > > Which I admit did happen sometimes, but not nearly as often as it should > have. Again, see mailing list archives from May 2017. I'm not the only > person who holds this opinion. I'm just the main one pushing the point. > >> Because of this, unless the updates have been for specific purposes (such as >> the recent update of the security section) then I would leave the changes to >> the diff tool which works pretty effectively. > > The diff tool lets us know what changed in the document. It doesn't let us > know if those changes addressed issues raise on the mailing list. > > To summarize: > > * we have no idea if this revision of the document addresses multiple WG > reviews > > * we have no idea if the document even describes TACACS+ as currently > implemented > > As such, it should not be put into working group last call, or much less > published until such time as those issues are addressed. I'm not sure what line-item changes are still outstanding. Authors, I'm sure you could look back at your revisions and spot anything that needs to be addressed here. I will be submitting an individual review of the new security requirements soon, and I would like to see this renewed sense of engagement on the list. Joe _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg