Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt

Alan DeKok <aland@deployingradius.com> Tue, 17 April 2018 15:07 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1820D1242F7 for <opsawg@ietfa.amsl.com>; Tue, 17 Apr 2018 08:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHc6DesWw5ie for <opsawg@ietfa.amsl.com>; Tue, 17 Apr 2018 08:07:12 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE551200C5 for <opsawg@ietf.org>; Tue, 17 Apr 2018 08:07:12 -0700 (PDT)
Received: from [192.168.20.43] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id 6CFED480; Tue, 17 Apr 2018 15:07:11 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <BFA0D798-621B-4A81-A92F-8B8EFA100E7B@cisco.com>
Date: Tue, 17 Apr 2018 11:07:09 -0400
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, Andrej Ota <aota@google.com>, Thorsten Dahm <thorstendlux@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <75CA4B77-5606-4C39-ACB7-F1BE0BD1962A@deployingradius.com>
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com> <BFA0D798-621B-4A81-A92F-8B8EFA100E7B@cisco.com>
To: "Douglas Gash (dcmgash)" <dcmgash@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/CYP2GYzoWZhSV6oYLN9vgwmWCKk>
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2018 15:07:15 -0000

On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash) <dcmgash@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.

> Subsequently we interpreted your proposal more accurately (as just a suggestion of the points to cover), and so we made sure that these were covered, but without verbatim reuse of the text.  We hope that we have covered the thrust of your issues (and others), but without the plagiarism.

  I have no idea.  Because at this point, I'm pretty much done reviewing the document.

> 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.

  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".

> We have not generally responded to posts regarding procedural matters, and would leave such discussions to more knowledgeable stewards of the lists where possible,

  You haven't responded to posts where I ask about the plagiarism.  A simple reply of "oops, sorry, I'll fix it ASAP" has taken over a year to write.

> 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.

  Alan DeKok.