Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
"Douglas Gash (dcmgash)" <dcmgash@cisco.com> Tue, 17 April 2018 14:15 UTC
Return-Path: <dcmgash@cisco.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 F0EF212D94E for <opsawg@ietfa.amsl.com>; Tue, 17 Apr 2018 07:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 NdubCnK2COv6 for <opsawg@ietfa.amsl.com>; Tue, 17 Apr 2018 07:15:54 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4148F12D948 for <opsawg@ietf.org>; Tue, 17 Apr 2018 07:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13256; q=dns/txt; s=iport; t=1523974554; x=1525184154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NyY4c3zBZpT6o2TGp9IP4qJiUHyMoNlFN6hfFDYbF/Y=; b=IBYBE5TPPkleZkTleFbmUNCNgz1Q+x77Qf8KoLXKP+zkbaazsBUDxkUU Zu/qUtDHBJAR2i+ss3/4mQ14HeEFSZD4JyloeFuzLaTpMnghNvquV/aso eMT4jb87HI/FDD5AQ2Jw796N2ukN3c0knn5j2jG1hAacobwxJngxJKus+ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CzAQAyANZa/5hdJa1dGwEBAQEDAQEBCQEBAYNCgVsyg16IAo0WgwOSaBSBZAuEaQIagj4hNBgBAgEBAQEBAQJsKIUjAwMjEUMCEAIBCBoCJgICAjAVEAIEAQ0ZhHmmO4IchFeDaoIlgQmGfYITgTKCaIRAARIBH4MAMIIkAoh5h2mHBggCiCeGEoE0g12HPIcziEkCERMBgSQBHDhhcXAVOyoBghmCHxeOF40lgR+BGAEB
X-IronPort-AV: E=Sophos;i="5.48,463,1517875200"; d="scan'208";a="379508428"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 14:15:53 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3HEFqlA003073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2018 14:15:53 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Apr 2018 09:15:52 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Tue, 17 Apr 2018 09:15:52 -0500
From: "Douglas Gash (dcmgash)" <dcmgash@cisco.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>, "aland@deployingradius.com" <aland@deployingradius.com>
CC: Andrej Ota <aota@google.com>, Thorsten Dahm <thorstendlux@google.com>
Thread-Topic: New Version Notification for draft-ietf-opsawg-tacacs-10.txt
Thread-Index: AQHT1H7Q2+J+Xp+Us0+DREWATIPIOqQBsJiAgAOnaYA=
Date: Tue, 17 Apr 2018 14:15:52 +0000
Message-ID: <BFA0D798-621B-4A81-A92F-8B8EFA100E7B@cisco.com>
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>
In-Reply-To: <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.26.0.170902
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.229.132.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <38993589CDAEA341B9DBD4E04C54757A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/AEVIT6ZTEkEgke0gZCb80MwcHWg>
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 14:15:57 -0000
Hi Alan, I hope that we can address your concerns. I think the main points that you raise the we (the authors) need to address are: 1) The security section 2) Reactivity of the authors 3) Change Tracking 1) The Security Section The starting point is that we know that TACACS+ needs enhancement from security perspective. That was the reason that this process was initiated, the first document being mainly an adaption of the original draft with security features plus some minor cleansing. This plan was evolved into two documents, the first, that we are in process of preparing, that codifies the protocol, to be followed by the version with enhanced security. 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. 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. 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, 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. We have not generally responded to posts regarding procedural matters, and would leave such discussions to more knowledgeable stewards of the lists where possible, 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). 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. Please let us know if there are specific points below that you’d like to address which would not be covered above. Many thanks, Regards, Doug Responding to: “I have some concerns with the document, and with the process by which we've gotten here. Let me recap some history. There's a lot to take in, so I'll present concerns in point form. First, the document. * my "Security Considerations" text was first plagarised in draft-06, * when I pointed this out (May 9, 2017), there was no reply to my message by the authors, and no change was made to the document. * the ADs did respond, and indicated that they had talked to the authors about the issue, and that it was a simple misunderstand and would be fixed. * A year later, I raised the issue again (March 2018). There as no reply to my concerns by the authors, and no change was made to the document. * in all, 4 separate revisions of the document plagarized my text, for over a year, sometimes with minor edits, despite repeated requests to address the issue. Those issues alone are surprising. * The text which was good enough to plagarize was then claimed to have deficiencies * no one in the WG had noted any technical issues with the text * the only issues were with attribution, not with the text in the Security Considerations section * there is now a -10, which has essentially the same points as the previous text, just reworded I should point out that the RFC process is supposed to be about content, not authorship. There are many RFCs issued with text written by multiple people. Where the authors cannot all be acknowledged on the first page, the primary editor can be listed with the (Ed.) suffix, to indicate editorship. Other authors can be named as authors on the first page, or in the Acknowledgements section. Second, concerns with engagement with the WG. It continues. * multiple people in the WG have requested the authors engage with the Working Group. Most notably, many messages in May 2017. * multiple people in the WG have requested the authors explain what's changed in each new revision, or perhaps to acknowlege comments and reviews (May 2017 again, among other times). * This engagement has been minimal, despite multiple revisions of the document being published after these WG requests. * new revisions have most often been "thrown over the wall" with minimal (or no) explanation as to what changed, and why. * this new draft is no different, i.e. it "revised the security section". Why? How? What changed? What were any alleged "deficiencies"? * the author have stated again that they "will endeavor to be much more reactive to comments". * this statement or similar ones have been repeatdly, with little change in observable behavior. * The authors request (again) that the WG review this new document wholesale. Speaking of reviews, let's continue with third, responses to reviews. * I have given multiple line-by-line reviews of the entire document, for multiple revisions of the document. * as noted above, these reviews have generally been ignored. * as noted above, new versions of the document have appeared which may or may not have addressed these reviews. * Given the lack of feedback on the reviews before a new draft is issued, it is unclear whether the review comments have been addressed. * due to these issues, I have stopped reviewing the document, as it is not productive. There are other issues with the larger community. I'll continue. * there was broad support for publication of early revisions of the document, despite it clearly not describing the protocol in a way that permits inter-operable implementations * the people who supported adopting the document as a WG document have generally not reviewed or commented on it * existing implementors of TACACS+ have not reviewed or commented on the document (Alex Clouter's review was done as part of a brand-new implementation) * we have therefore no idea whether or not this document describes anything that anyone has implemented In order for the document to be published, we should have (at the minimum) statements from multiple implementors that the draft matches their implementations. Fourth, there are process issues, too. I'll continue. * the IETF has traditionally started a new WG to standardize new management protocols (i.e. a protocol new to the IETF) * examples include the protocols described in RFC 6632. These protocols have had their own working groups, going back to at least 1996, and continuing to the present * working on a new (and eventually standards track) document in the OPS area is therefore a new step for the IETF * I have raised all of the concerns mentioned herein with the chairs and ADs in private email, public email on the list, and in person at multiple meetings * There does not appear to be any action taken as a result. * Messages to the list raising these issues have largely been unaddressed It is general IETF practice for document authors to interact with the WG. And, to respond to WG reviews and comments. See the many comments in the OPSAWG archives in May 2017 for broad WG support of this position. As the authors have largely ignored the WG comments, the chairs and ADs should have taken steps to address this issue. As of this writing, it appears to be the same "status quo" of the past few years. I don't think these comments are unreasonable. If we truly don't care about the WG opinion, then the chairs and AD can: * make a public statement saying that WG feedback can be ignored * state that that the document can be published in whatever form the authors choose * publish the document even if it does not describe the protocol in sufficient detail to create inter-operable implementations. I don't think that's the right approach, of course. But it's largely what's been happening due to silence and/or inaction of the parties involved. I see no point in further reviewing the document. I again oppose publication of this document until such time as all of the WG issues have been addressed. If we do actually care about what's in the document, then I suggest finally the following steps be taken to address the ongoing concerns: * the document should not be published until such time as multiple implementors have agreed that the specification matches their implementation. * the chairs and ADs should insist that the authors address the outstanding WG concerns about this document * the chairs and ADs should insist that authors follow established practice of *interacting* with the WG, including responding to future reviews and comments. * the chairs and ADs should insist that new revisions of the document are accompanied by an explanation of what changed, and why * that if the authors do not follow these steps (as they have not so far), that the chairs and ADs should replace them with other WG member(s) who will follow the IETF process. Alan DeKok. ”
- Re: [OPSAWG] New Version Notification for draft-i… Douglas Gash (dcmgash)
- Re: [OPSAWG] New Version Notification for draft-i… Douglas Gash (dcmgash)
- Re: [OPSAWG] New Version Notification for draft-i… Alan DeKok
- Re: [OPSAWG] New Version Notification for draft-i… Tianran Zhou
- Re: [OPSAWG] New Version Notification for draft-i… Joe Clarke
- Re: [OPSAWG] New Version Notification for draft-i… Joe Clarke
- Re: [OPSAWG] New Version Notification for draft-i… Andrej Ota
- Re: [OPSAWG] New Version Notification for draft-i… Joe Clarke
- Re: [OPSAWG] New Version Notification for draft-i… Joe Clarke
- Re: [OPSAWG] New Version Notification for draft-i… Andrej Ota
- Re: [OPSAWG] New Version Notification for draft-i… Joe Clarke