From nobody Mon Feb 1 01:26:19 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471461B2F24 for ; Mon, 1 Feb 2016 01:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 SDGfOEMyJ5YQ for ; Mon, 1 Feb 2016 01:26:16 -0800 (PST) Received: from mail.tpip.net (mail.tpip.net [92.43.49.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E858B1B2F1C for ; Mon, 1 Feb 2016 01:26:15 -0800 (PST) Received: from office.tpip.net (office.tpip.net [92.43.51.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tpip.net (Postfix) with ESMTPS id 8CF214F403 for ; Mon, 1 Feb 2016 09:25:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by office.tpip.net (Postfix) with ESMTP id 1A5D5A3050 for ; Mon, 1 Feb 2016 10:26:27 +0100 (CET) Received: from office.tpip.net ([127.0.0.1]) by localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id g9mfhW94nAI5 for ; Mon, 1 Feb 2016 10:26:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by office.tpip.net (Postfix) with ESMTP id B4CBCA3056 for ; Mon, 1 Feb 2016 10:26:26 +0100 (CET) X-Virus-Scanned: amavisd-new at tpip.net Received: from office.tpip.net ([127.0.0.1]) by localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4_aUAbgsYIDp for ; Mon, 1 Feb 2016 10:26:26 +0100 (CET) Received: from [192.168.13.53] (unknown [192.168.13.53]) by office.tpip.net (Postfix) with ESMTPSA id 82DE1A3050 for ; Mon, 1 Feb 2016 10:26:26 +0100 (CET) To: opsawg@ietf.org From: Andreas Schultz Message-ID: <56AF2496.1080601@tpip.net> Date: Mon, 1 Feb 2016 10:25:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] Feedback on draft-ietf-opsawg-capwap-alt-tunnel-06 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 09:26:18 -0000 Hi, * Supported Alternate Tunnel Encapsulations The Num_Tunnels field is redundant. This value can be derived from the IEs length since the Tunnel-Type is a fixed length value. * Alternate Tunnel Encapsulations Type Is differencing between GRE-IPv4 and GRE-IPv6 really needed? The transport protocol can be derived from the type of the address IE. On the other hand, we might want to support GRE tunnels with fall back to the other transport protocol (i.e. prefer IPv6 endpoint but fall back to IPv4). I would suggest to simply calling it GRE and derive the transport protocol from the address IE and/or the resolved IP in case a FQDN was specified. * Alternate Tunnel Encapsulations Type Information Element The IE format is quite different from the other IE's used in CAPWAP. The content of any other CAPWAP IE only depends on the IE type. For this IE the content depends on the IE type *and* the tunnel type. I would much prefer to keep this IE in line with the others and have one IE for the alternate tunnel type and additional IE's to specify the tunnel parameters. This would also better suite tunnel protocols where you have optional arguments. * AR FQDN List Element No other CAPWAP IE does use FQDN's to specify IP endpoints. I don't see why we need to start here, the AC can always resolve FQDN's to IP's and provision those. * Alternate Tunnel Encapsulation Type Reserving encapsulation types without specifying them completely seems a bit strange. But as long we do that, could we also reserve a type for GTPv1-U (3GPP TS 29.281: http://www.3gpp.org/DynaReport/29281.htm) Mobile networks use GTP already and 3GPP already defines mobile network to WiFi handover procedures. Supporting GTP alternate tunnels on CAPWAP based WiFi AP would fit nicely into that. Regards, Andreas From nobody Mon Feb 1 23:20:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AF01A88D8 for ; Mon, 1 Feb 2016 23:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 L8xKmx2468ww for ; Mon, 1 Feb 2016 23:19:34 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF261A88D7 for ; Mon, 1 Feb 2016 23:19:33 -0800 (PST) Received: from mb-2.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u127JFrd029035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Feb 2016 07:19:17 GMT (envelope-from joelja@bogus.com) To: "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56B0586D.1070506@bogus.com> Date: Mon, 1 Feb 2016 23:19:09 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u7c0BdPpdPT87m2UDMMAG9NjjB1XdbT9u" Archived-At: Subject: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 07:19:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u7c0BdPpdPT87m2UDMMAG9NjjB1XdbT9u Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, First, I want to thank everyone who volunteered. The enthusiasm and depth of field present in the pool of volunteers who indicated interest in serving as co-chair is truly humbling. I talked to several of you over the course of this deliberation in addition to my co-ad and the present chairs. My expectation is we will have three chairs until Scott steps down following IETF 95. On to Business. Zhou Tianran has agreed to take on the role of opsawg chair. He joins Warren Kumari and Scott Bradner in this role. He has experience in the IETF as a contributor and in ONF and BBF as well as the OpenDaylight, OPNFV, OpenStack communities. I welcome the experience the he will bring with SDN and NETCONF/YANG to the opsawg chair role, I think we will be well served in addressing that part of our constituency. Thanks joel --u7c0BdPpdPT87m2UDMMAG9NjjB1XdbT9u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlawWG0ACgkQ8AA1q7Z/VrICAgCfdMkrR+6hMOB88NNcav+D7wUi 6dQAn1BMdc479BOKaK9QeKFllw9Hb6BI =rpG8 -----END PGP SIGNATURE----- --u7c0BdPpdPT87m2UDMMAG9NjjB1XdbT9u-- From nobody Tue Feb 2 05:23:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AD41B2ABA for ; Tue, 2 Feb 2016 05:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GEoXukKrKit4 for ; Tue, 2 Feb 2016 05:23:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976A11B2AB3 for ; Tue, 2 Feb 2016 05:23:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDV48699; Tue, 02 Feb 2016 13:23:40 +0000 (GMT) Received: from lhreml704-cah.china.huawei.com (10.201.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 2 Feb 2016 13:23:39 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 2 Feb 2016 13:23:38 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Tue, 2 Feb 2016 21:23:33 +0800 From: Zhuangshunwan To: joel jaeggli , "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Please welcome our new chair! Thread-Index: AQHRXYo6ApweuV/HrE2/Q0RIIZ6z6Z8YvjZg Date: Tue, 2 Feb 2016 13:23:31 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858AA190FCC@NKGEML515-MBX.china.huawei.com> References: <56B0586D.1070506@bogus.com> In-Reply-To: <56B0586D.1070506@bogus.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56B0ADDC.02A9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 808d0619b8ecd538f3074310a1c4f866 Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 13:23:46 -0000 V2VsY29tZSBUaWFucmFuIQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IE9Q U0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSDku6Pooaggam9lbCBqYWVnZ2xp DQrlj5HpgIHml7bpl7Q6IDIwMTblubQy5pyIMuaXpSAxNToxOQ0K5pS25Lu25Lq6OiBvcHNhd2ct Y2hhaXJzQHRvb2xzLmlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmcNCuS4u+mimDogW09QU0FXR10g UGxlYXNlIHdlbGNvbWUgb3VyIG5ldyBjaGFpciENCg0KR3JlZXRpbmdzLA0KDQpGaXJzdCwgSSB3 YW50IHRvIHRoYW5rIGV2ZXJ5b25lIHdobyB2b2x1bnRlZXJlZC4gVGhlIGVudGh1c2lhc20gYW5k IGRlcHRoIG9mIGZpZWxkIHByZXNlbnQgaW4gdGhlIHBvb2wgb2Ygdm9sdW50ZWVycyB3aG8gaW5k aWNhdGVkIGludGVyZXN0IGluIHNlcnZpbmcgYXMgY28tY2hhaXIgaXMgdHJ1bHkgaHVtYmxpbmcu IEkgdGFsa2VkIHRvIHNldmVyYWwgb2YgeW91IG92ZXIgdGhlIGNvdXJzZSBvZiB0aGlzIGRlbGli ZXJhdGlvbiBpbiBhZGRpdGlvbiB0byBteSBjby1hZCBhbmQgdGhlIHByZXNlbnQgY2hhaXJzLiBN eSBleHBlY3RhdGlvbiBpcyB3ZSB3aWxsIGhhdmUgdGhyZWUgY2hhaXJzIHVudGlsIFNjb3R0IHN0 ZXBzIGRvd24gZm9sbG93aW5nIElFVEYgOTUuDQoNCk9uIHRvIEJ1c2luZXNzLg0KDQpaaG91IFRp YW5yYW4gaGFzIGFncmVlZCB0byAgdGFrZSBvbiB0aGUgcm9sZSBvZiBvcHNhd2cgY2hhaXIuIEhl IGpvaW5zIFdhcnJlbiBLdW1hcmkgYW5kIFNjb3R0IEJyYWRuZXIgaW4gdGhpcyByb2xlLiBIZSBo YXMgZXhwZXJpZW5jZSBpbiB0aGUgSUVURiBhcyBhIGNvbnRyaWJ1dG9yIGFuZCBpbiBPTkYgYW5k IEJCRiBhcyB3ZWxsIGFzIHRoZSBPcGVuRGF5bGlnaHQsIE9QTkZWLCBPcGVuU3RhY2sgY29tbXVu aXRpZXMuIEkgd2VsY29tZSB0aGUgZXhwZXJpZW5jZSB0aGUgaGUgd2lsbCBicmluZyB3aXRoIFNE TiBhbmQgTkVUQ09ORi9ZQU5HIHRvIHRoZSBvcHNhd2cgY2hhaXIgcm9sZSwgSSB0aGluayB3ZSB3 aWxsIGJlIHdlbGwgc2VydmVkIGluIGFkZHJlc3NpbmcgdGhhdCBwYXJ0IG9mIG91ciBjb25zdGl0 dWVuY3kuDQoNClRoYW5rcw0Kam9lbA0KDQo= From nobody Wed Feb 3 00:25:37 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBB81B3393 for ; Wed, 3 Feb 2016 00:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0OTEZPR-XGN3 for ; Wed, 3 Feb 2016 00:25:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DFD1B3386 for ; Wed, 3 Feb 2016 00:25:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHW83091; Wed, 03 Feb 2016 08:25:23 +0000 (GMT) Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 3 Feb 2016 08:25:22 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 3 Feb 2016 08:25:22 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Wed, 3 Feb 2016 16:25:10 +0800 From: Duzongpeng To: "sgundave@cisco.com" , "rpazhyan@cisco.com" Thread-Topic: About GRE tunnel type in draft-ietf-opsawg-capwap-alt-tunnel-06 Thread-Index: AdFeXF761QwMjZ2gSMSXMGpp0vtzXA== Date: Wed, 3 Feb 2016 08:25:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: multipart/alternative; boundary="_000_BAFEC9523F57BC48A51C20226A5589575FDE7624nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56B1B974.00ED, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 46ab1008d53e373c50caf25ed4b3ccf0 Archived-At: Cc: "zhen.cao@gmail.com" , "276076389@qq.com" <276076389@qq.com>, "caozhen@chinamobile.com" , "denghui@chinamobile.com" , "opsawg@ietf.org" Subject: [OPSAWG] About GRE tunnel type in draft-ietf-opsawg-capwap-alt-tunnel-06 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 08:25:33 -0000 --_000_BAFEC9523F57BC48A51C20226A5589575FDE7624nkgeml514mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Sri I have some commons about the GRE tunnel type in this alt-tunnel d= raft. In the current draft, several kinds of tunnel types are listed: Tunnel-Type Type Value Reference CAPWAP 0 [RFC5415],[RFC5416] L2TP 1 [RFC2661] L2TPv3 2 [RFC3931] IP-IP 3 [RFC2003] PMIPv6 4 [RFC5213] GRE-IPv4 5 [RFC2784] GRE-IPv6 6 [RFC2784] And it is said that This specification provides details for this elements for CAPWAP and PMIPv6. What I suggest is that this specification should also refer to GRE= -IPv4/v6. I think not too many modifications are needed. Just add a new sess= ion: 3.6. GRE based Alternate Tunnel GRE can also be used for alternate tunnel encapsulation between the WTP and the AR. o Access Router Information: IP address or Fully Qualified Domain Name (FQDN) for the alternate tunnel endpoint. o GRE Key: optional, defined in rfc2890. The message element structure for GRE encapsulation is shown in Figure 11: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel-Type=3D5 or 6 | Info Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Access Router Information Element . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . GRE Key Element . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Alternate Tunnel Encapsulation - GRE Fortunately, we do not need to explain what the GRE key element is= because there is already this explanation in the current draft "3.6.6. GR= E Key Element". I used to join in the work of this draft. I think we have taken th= is GRE type into consideration, but I do not know why it is missing now. What I means is that GRE type should not be considered in other dr= afts as L2TP or IP-IP, because GRE is a widely used and important tunnel ty= pe in WiFi network. So I suggest to add GRE tunnel type into this draft just as the CA= PWAP and PMIP tunnel type. Best wishes Zongpeng Du --_000_BAFEC9523F57BC48A51C20226A5589575FDE7624nkgeml514mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Sri

 

     &= nbsp;   I have some commons about the GRE tunnel type in this alt= -tunnel draft.

 

     &= nbsp;   In the current draft, several kinds of tunnel types are l= isted:

 

        Tunnel-T=
ype           Type Value&=
nbsp;  Reference
        CAPWAP&n=
bsp;            =
;   0          =
  [RFC5415],[RFC5416]
        L2TP&nbs=
p;            &=
nbsp;    1        &n=
bsp;   [RFC2661]

        L2TPv3&n=
bsp;            =
;   2          =
  [RFC3931]


        IP-IP&nb=
sp;            =
    3         &=
nbsp;  [RFC2003]


        PMIPv6&n=
bsp;            =
;   4          =
  [RFC5213]


        GRE-IPv4=
            &nb=
sp; 5            [RFC2784]


        GRE-IPv6=
            &nb=
sp; 6            [RFC2784]


 


     &=
nbsp;   And it is said that 


This


      sp=
ecification provides details for this elements for CAPWAP and


      PM=
IPv6.


 


     &=
nbsp;   What I suggest is that this specification should also ref=
er to GRE-IPv4/v6.


 


     &=
nbsp;   I think not too many modifications are needed. Just add a=
 new session:


 



3.6. 
 GRE based Alternate Tunnel


 


 


   GRE can also be used=



   for alternate tunnel=
 encapsulation between the WTP and the AR. 



 


   o  Access Route=
r  Information: IP address or Fully


      Qu=
alified Domain Name (FQDN) for the alternate tunnel endpoint.


 


   o  GRE Key: opt=
ional, defined in
rfc2890.<=
o:p>


 


   The message element =
structure for GRE encapsulation is shown in


   Figure 11:


 


     0 &=
nbsp;           &nbs=
p;     1        =
;           2  =
            &nb=
sp;    3


     0 1 2 3 =
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+


    |  &=
nbsp;  Tunnel-Type=3D5 or  6       =
 |   Info Element Length      =
   |


    +-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+


    .  &=
nbsp;          Access Router I=
nformation Element          &n=
bsp;     .


    +-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+


    .  &=
nbsp;          GRE Key Element=
            &nb=
sp;            =
   .


    +-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+


 


 


     &nb=
sp;      Figure 11: Alternate Tunnel Encapsulation
̵=
1; GRE


 


     &=
nbsp;   Fortunately, we do not need to explain what the GRE key e=
lement is because there is already this explanation in the current draft &#=
8220;3.6.6.  GRE Key Element”.


 


     &=
nbsp;   I used to join in the work of this draft. I think we have=
 taken this GRE type into consideration, but I do not know why it is missin=
g now.


 


     &=
nbsp;   What I means is that GRE type should not be considered in=
 other drafts as L2TP or IP-IP, because GRE is a widely used and important =
tunnel type in WiFi network.


 


     &=
nbsp;   So I suggest to add GRE tunnel type into this draft just =
as the CAPWAP and PMIP tunnel type.


 


 


 


Best wishes

Zongpeng Du
--_000_BAFEC9523F57BC48A51C20226A5589575FDE7624nkgeml514mbxchi_-- From nobody Wed Feb 3 21:34:01 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2501A905B for ; Wed, 3 Feb 2016 21:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Coa56o8qgO0u for ; Wed, 3 Feb 2016 21:33:56 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B3E1A9057 for ; Wed, 3 Feb 2016 21:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25076; q=dns/txt; s=iport; t=1454564035; x=1455773635; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kJtaWSn8U8zhg1AgkFFMHtslIlh23lX8dHJuCpc3SEk=; b=CTDKI898fS8Q4UE48Mj9w/SXOUkodSBpcN5P90onoAsXROG3qzMyDKrZ pKF5JtB3Kzrv3QUavwCLjMMFM7v3xh8NGjGmXMepH6aD9Rt8e2PIQM6X/ gytqgVZCLyE9AhwtzeJGMjwhyujy9StL5UrpqDbuaqinXD4YqmiZj2qEn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCM4rJW/4kNJK1egm5MUm0GiFWxB?= =?us-ascii?q?AENgWYjhWoCgTc4FAEBAQEBAQGBCoRBAQEBBC1MEAIBCBEDAQIhBwchERQJCAI?= =?us-ascii?q?EAQ0FiAYDEg68GQ0NhDIBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYShDeCN4IbD?= =?us-ascii?q?QmEBAWNJTiFD4QFAYVIhhGBc45xXIYjh0ABHgEBQoIDGYFIagGHLXwBAQE?= X-IronPort-AV: E=Sophos; i="5.22,393,1449532800"; d="scan'208,217"; a="68113304" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2016 05:33:47 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u145XjH4029575 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 05:33:47 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 23:33:45 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Wed, 3 Feb 2016 23:33:45 -0600 From: "Sri Gundavelli (sgundave)" To: Duzongpeng , "Rajesh Pazhyannur (rpazhyan)" Thread-Topic: About GRE tunnel type in draft-ietf-opsawg-capwap-alt-tunnel-06 Thread-Index: AQHRXw2dOYjrSF7fRESdYCVtOFCzbw== Date: Thu, 4 Feb 2016 05:33:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.213] Content-Type: multipart/alternative; boundary="_000_D2D8210D205DBDsgundaveciscocom_" MIME-Version: 1.0 Archived-At: Cc: "zhen.cao@gmail.com" , "276076389@qq.com" <276076389@qq.com>, "caozhen@chinamobile.com" , "denghui@chinamobile.com" , "opsawg@ietf.org" Subject: Re: [OPSAWG] About GRE tunnel type in draft-ietf-opsawg-capwap-alt-tunnel-06 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 05:33:59 -0000 --_000_D2D8210D205DBDsgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Du Zongpeng, This spec does support different encap types as listed in the tunnel types = enumeration. I think some text is missing; should be similar to section 3.5= . We can address in the next rev. Sri From: Duzongpeng > Date: Wednesday, February 3, 2016 at 12:25 AM To: Sri Gundavelli >, "Rajesh= Pazhyannur (rpazhyan)" > Cc: "opsawg@ietf.org" >, Youjianjie >, Zhoutianran >, "= 276076389@qq.com" <276076389@qq.com>, "xueli_jas@163.com" >, "denghui@chinamobile.com" >, "z= hen.cao@gmail.com" >, "caozhen@chinamobile.com" >, "zhangr@gsta.= com" >, And= reas Schultz >, "warren@kumari.= net" = > Subject: About GRE tunnel type in draft-ietf-opsawg-capwap-alt-tunnel-06 Hi, Sri I have some commons about the GRE tunnel type in this alt-tunnel d= raft. In the current draft, several kinds of tunnel types are listed: Tunnel-Type Type Value Reference CAPWAP 0 [RFC5415],[RFC5416] L2TP 1 [RFC2661] L2TPv3 2 [RFC3931] IP-IP 3 [RFC2003] PMIPv6 4 [RFC5213] GRE-IPv4 5 [RFC2784] GRE-IPv6 6 [RFC2784] And it is said that This specification provides details for this elements for CAPWAP and PMIPv6. What I suggest is that this specification should also refer to GRE= -IPv4/v6. I think not too many modifications are needed. Just add a new sess= ion: 3.6. GRE based Alternate Tunnel GRE can also be used for alternate tunnel encapsulation between the WTP and the AR. o Access Router Information: IP address or Fully Qualified Domain Name (FQDN) for the alternate tunnel endpoint. o GRE Key: optional, defined inrfc2890. The message element structure for GRE encapsulation is shown in Figure 11: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel-Type=3D5 or 6 | Info Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Access Router Information Element . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . GRE Key Element . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Alternate Tunnel Encapsulation - GRE Fortunately, we do not need to explain what the GRE key element is= because there is already this explanation in the current draft "3.6.6. GR= E Key Element". I used to join in the work of this draft. I think we have taken th= is GRE type into consideration, but I do not know why it is missing now. What I means is that GRE type should not be considered in other dr= afts as L2TP or IP-IP, because GRE is a widely used and important tunnel ty= pe in WiFi network. So I suggest to add GRE tunnel type into this draft just as the CA= PWAP and PMIP tunnel type. Best wishes Zongpeng Du --_000_D2D8210D205DBDsgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9E769A4BB321C743BE208E9EFF8A534A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
HI Du Zongpeng,

This spec does support different encap types as listed in the tunnel t= ypes enumeration. I think some text is missing; should be similar to sectio= n 3.5. We can address in the next rev.


Sri

From: Duzongpeng <duzongpeng@huawei.com>
Date: Wednesday, February 3, 2016 a= t 12:25 AM
To: Sri Gundavelli <sgundave@cisco.com>, "Rajesh Pazhyann= ur (rpazhyan)" <rpazhyan@cisc= o.com>
Cc: "opsawg@ietf.org" <= opsawg@ietf.org>, Youjianjie <youjianjie@huawei.com>, Zhoutianran <zhoutianran@huawei.com>, "276076389@qq.com" <<= a href=3D"mailto:276076389@qq.com">276076389@qq.com>, "xueli_jas@163.com" <xueli_jas@163.com>, "denghui@chinamobile.com" <denghui@chinamobile.com= >, "zhen.cao@gmail.com&qu= ot; <zhen.cao@gmail.com>, &= quot;caozhen@chinamobile.com= " <caozhen@chinamobile.com= >, "zhangr@gsta.com" &l= t;zhangr@gsta.com>, Andreas Schul= tz <aschultz@tpip.net>, "warren@kumari.net" <= ;warren@kumari.net>
Subject: About GRE tunnel type in d= raft-ietf-opsawg-capwap-alt-tunnel-06

Hi, Sri

 

     &= nbsp;   I have some commons about the GRE tunnel type in this alt= -tunnel draft.

 

     &= nbsp;   In the current draft, several kinds of tunnel types are l= isted:

 

        Tunnel-T=
ype           Type Value&=
nbsp;  Reference
        CAPWAP&n=
bsp;            =
;   0          =
  [RFC5415],[RFC5416]
        L2TP&nbs=
p;            &=
nbsp;    1        &n=
bsp;   [RFC2661]

        L2TPv3&n=
bsp;            =
;   2          =
  [RFC3931]


        IP-IP&nb=
sp;            =
    3         &=
nbsp;  [RFC2003]


        PMIPv6&n=
bsp;            =
;   4          =
  [RFC5213]


        GRE-IPv4=
            &nb=
sp; 5            [RFC2784]


        GRE-IPv6=
            &nb=
sp; 6            [RFC2784]


 


     &=
nbsp;   And it is said that 


This


      sp=
ecification provides details for this elements for CAPWAP and


      PM=
IPv6.


 


     &=
nbsp;   What I suggest is that this specification should also ref=
er to GRE-IPv4/v6.


 


     &=
nbsp;   I think not too many modifications are needed. Just add a=
 new session:


 



3.6. 
 GRE based Alternate Tunnel


 


 


   GRE can also be used=



   for alternate tunnel=
 encapsulation between the WTP and the AR. 



 


   o  Access Route=
r  Information: IP address or Fully


      Qu=
alified Domain Name (FQDN) for the alternate tunnel endpoint.


 


   o  GRE Key: opt=
ional, defined inrfc2890.


 


   The message element =
structure for GRE encapsulation is shown in


   Figure 11:


 


     0 &=
nbsp;           &nbs=
p;     1        =
;           2  =
            &nb=
sp;    3


     0 1 2 3 =
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+


    |  &=
nbsp;  Tunnel-Type=3D5 or  6       =
 |   Info Element Length      =
   |


    +-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+


    .  &=
nbsp;          Access Router I=
nformation Element          &n=
bsp;     .


    +-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+


    .  &=
nbsp;          GRE Key Element=
            &nb=
sp;            =
   .


    +-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+


 


 


     &nb=
sp;      Figure 11: Alternate Tunnel Encapsulation
̵=
1; GRE


 


     &=
nbsp;   Fortunately, we do not need to explain what the GRE key e=
lement is because there is already this explanation in the current draft &#=
8220;3.6.6.  GRE Key Element”.


 


     &=
nbsp;   I used to join in the work of this draft. I think we have=
 taken this GRE type into consideration, but I do not know why it is missin=
g now.


 


     &=
nbsp;   What I means is that GRE type should not be considered in=
 other drafts as L2TP or IP-IP, because GRE is a widely used and important =
tunnel type in WiFi network.


 


     &=
nbsp;   So I suggest to add GRE tunnel type into this draft just =
as the CAPWAP and PMIP tunnel type.


 


 


 


Best wishes

Zongpeng Du
--_000_D2D8210D205DBDsgundaveciscocom_-- From nobody Thu Feb 4 00:16:20 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2A01A1AF0 for ; Thu, 4 Feb 2016 00:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 wv0hlboVhcHo for ; Thu, 4 Feb 2016 00:16:17 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66EB1A1AE6 for ; Thu, 4 Feb 2016 00:16:16 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud2.xs4all.net with ESMTP id E8GB1s00H3vXPcr018GCE0; Thu, 04 Feb 2016 09:16:14 +0100 To: joel jaeggli , "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" References: <56B0586D.1070506@bogus.com> From: "Bert Wijnen (IETF)" Message-ID: <56B308CB.8080406@bwijnen.net> Date: Thu, 4 Feb 2016 09:16:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B0586D.1070506@bogus.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 08:16:19 -0000 Welcome Tianran, and a big THANKS to Scott for his many years of service. Bert On 02/02/16 08:19, joel jaeggli wrote: > Greetings, > > First, I want to thank everyone who volunteered. The enthusiasm and > depth of field present in the pool of volunteers who indicated interest > in serving as co-chair is truly humbling. I talked to several of you > over the course of this deliberation in addition to my co-ad and the > present chairs. My expectation is we will have three chairs until Scott > steps down following IETF 95. > > On to Business. > > Zhou Tianran has agreed to take on the role of opsawg chair. He joins > Warren Kumari and Scott Bradner in this role. He has experience in the > IETF as a contributor and in ONF and BBF as well as the OpenDaylight, > OPNFV, OpenStack communities. I welcome the experience the he will bring > with SDN and NETCONF/YANG to the opsawg chair role, I think we will be > well served in addressing that part of our constituency. > > Thanks > joel > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Thu Feb 4 09:25:11 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C4A1A1A62 for ; Thu, 4 Feb 2016 09:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 3U6h2u2FAlwn for ; Thu, 4 Feb 2016 09:25:07 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0F51A1A42 for ; Thu, 4 Feb 2016 09:25:06 -0800 (PST) Received: from muimrel001.emea.nsn-intra.net ([10.159.32.132]) by demumfd001.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id u14HOvem028656 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Feb 2016 17:24:57 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by muimrel001.emea.nsn-intra.net (8.14.3/8.14.3) with ESMTP id u14HOtS3030003 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 17:24:57 GMT Received: from DEMUMBX005.nsn-intra.net ([169.254.5.234]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0248.002; Thu, 4 Feb 2016 18:24:55 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "EXT Bert Wijnen (IETF)" , joel jaeggli , "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Please welcome our new chair! Thread-Index: AQHRXyRYQtYFjEFxKEiYHwpsC/OcIJ8cI5rQ Date: Thu, 4 Feb 2016 17:24:54 +0000 Message-ID: References: <56B0586D.1070506@bogus.com> <56B308CB.8080406@bwijnen.net> In-Reply-To: <56B308CB.8080406@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1636 X-purgate-ID: 151667::1454606698-00001C0B-7707DD1A/0/0 Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 17:25:09 -0000 +1 Cheers,=20 Mehmet=20 -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of EXT Bert Wijnen = (IETF) Sent: Thursday, February 04, 2016 9:16 AM To: joel jaeggli ; opsawg-chairs@tools.ietf.org; opsawg@i= etf.org Subject: Re: [OPSAWG] Please welcome our new chair! Welcome Tianran, and a big THANKS to Scott for his many years of service. Bert On 02/02/16 08:19, joel jaeggli wrote: > Greetings, > > First, I want to thank everyone who volunteered. The enthusiasm and > depth of field present in the pool of volunteers who indicated interest > in serving as co-chair is truly humbling. I talked to several of you > over the course of this deliberation in addition to my co-ad and the > present chairs. My expectation is we will have three chairs until Scott > steps down following IETF 95. > > On to Business. > > Zhou Tianran has agreed to take on the role of opsawg chair. He joins > Warren Kumari and Scott Bradner in this role. He has experience in the > IETF as a contributor and in ONF and BBF as well as the OpenDaylight, > OPNFV, OpenStack communities. I welcome the experience the he will bring > with SDN and NETCONF/YANG to the opsawg chair role, I think we will be > well served in addressing that part of our constituency. > > Thanks > joel > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Feb 4 16:51:18 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E681B1B2B25 for ; Thu, 4 Feb 2016 16:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RrTzUsSgoOeI for ; Thu, 4 Feb 2016 16:51:15 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2D21B2B27 for ; Thu, 4 Feb 2016 16:51:14 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id hb3so3744274igb.0 for ; Thu, 04 Feb 2016 16:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=5iDgxFHnWPgGcpW4j2hR+N5jQRFdakHyMIhExgkuxX4=; b=hyGZaukl2CHkPYbss8UElgBFTpuL6hnSeNmFSnCF3NoRJFcoJ5WV97u7w4mdkzbV0s fqk/eR7lay5p/uQ8HZVtFOClSroJFx2e0akmt19GBYrcOhV3MbVSPB91ZDLLboE0MAmb 0M5iVufl0QpQbvBLLV9c78PRIet3TKjkeCxP7kbaeDzcj3JiveEf0dWciOrc449wgd2x dg+aoP4zwYPyrYPMNiOI4erVMD9GWjDBk+skDwv4nliW2OMCitMfgBsoqO2vHXBuFMfD YE27umWRhVo0uovD/vOcQnXUJ7IZ+tsw0yHCmUeH+FYtpJPGQzbvCp9Appxc3NKPUDVX 0rIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=5iDgxFHnWPgGcpW4j2hR+N5jQRFdakHyMIhExgkuxX4=; b=YcYRhv07C1KHWyNS5va3DGJKcbUOcCjP0aTTt76cajDds7IW/4k8X+GQoLZ1WD0KoS t42TNMHU1m+BiQo6NA0im8ISCGx4drh2KE+TVf3TajNYsbztuAXGweP+pdZF7Jb+OtKd 97/roti2ckBj3DyvcreIOQTzoT9yAsco6HEdEeuq9jcn3VJiNGEs95PDGuNL7Bu72/EZ vLzFpcmR0UKezneDxC3+KG8qZi87AsDY03/pUqOc4PH6BMpsaPZOUj6Cf+gReWgwC++C etSOoi7O4Lf2i3hLGCWgUHrutP8JeF9vEeZOIbmat625QckjcI0/cmmtMHLogq1tycuU VZcQ== X-Gm-Message-State: AG10YOSQikoaRQ26jaxt74SPgh6Qw6XS5t8AcGvwgZZON5tK98mv9Y6wZlX8rxRWdoD9Sg== X-Received: by 10.50.40.8 with SMTP id t8mr12928804igk.26.1454633473937; Thu, 04 Feb 2016 16:51:13 -0800 (PST) Received: from still.local (50-121-215-241.drr03.clbg.wv.frontiernet.net. [50.121.215.241]) by smtp.googlemail.com with ESMTPSA id p8sm5818701ioe.38.2016.02.04.16.51.12 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 16:51:12 -0800 (PST) To: opsawg@ietf.org References: <56B0586D.1070506@bogus.com> From: Tim Wicinski Message-ID: <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> Date: Thu, 4 Feb 2016 19:51:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Thunderbird/46.0a2 MIME-Version: 1.0 In-Reply-To: <56B0586D.1070506@bogus.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 00:51:17 -0000 Welcome Zhou! If you need any help managing Warren, just speak up. Many of us are quite skilled at this. tim On 2/2/16 2:19 AM, joel jaeggli wrote: > Greetings, > > First, I want to thank everyone who volunteered. The enthusiasm and > depth of field present in the pool of volunteers who indicated interest > in serving as co-chair is truly humbling. I talked to several of you > over the course of this deliberation in addition to my co-ad and the > present chairs. My expectation is we will have three chairs until Scott > steps down following IETF 95. > > On to Business. > > Zhou Tianran has agreed to take on the role of opsawg chair. He joins > Warren Kumari and Scott Bradner in this role. He has experience in the > IETF as a contributor and in ONF and BBF as well as the OpenDaylight, > OPNFV, OpenStack communities. I welcome the experience the he will bring > with SDN and NETCONF/YANG to the opsawg chair role, I think we will be > well served in addressing that part of our constituency. > > Thanks > joel > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Thu Feb 4 17:23:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B7F1B2C0F for ; Thu, 4 Feb 2016 17:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 qtLpL5Un6BWa for ; Thu, 4 Feb 2016 17:23:12 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9571B2C0D for ; Thu, 4 Feb 2016 17:23:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 9813A14DEDFD; Thu, 4 Feb 2016 20:23:11 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MrSAj8C4vbQ; Thu, 4 Feb 2016 20:23:11 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 0610114DEDEC; Thu, 4 Feb 2016 20:23:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Scott O. Bradner" In-Reply-To: <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> Date: Thu, 4 Feb 2016 20:23:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B0586D.1070506@bogus.com> <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> To: Tim Wicinski X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 01:23:14 -0000 I wish I had known that :-) Scott > On Feb 4, 2016, at 7:51 PM, Tim Wicinski wrote: >=20 >=20 > Welcome Zhou! >=20 > If you need any help managing Warren, just speak up. Many of us are = quite skilled at this. >=20 > tim >=20 >=20 > On 2/2/16 2:19 AM, joel jaeggli wrote: >> Greetings, >>=20 >> First, I want to thank everyone who volunteered. The enthusiasm and >> depth of field present in the pool of volunteers who indicated = interest >> in serving as co-chair is truly humbling. I talked to several of you >> over the course of this deliberation in addition to my co-ad and the >> present chairs. My expectation is we will have three chairs until = Scott >> steps down following IETF 95. >>=20 >> On to Business. >>=20 >> Zhou Tianran has agreed to take on the role of opsawg chair. He = joins >> Warren Kumari and Scott Bradner in this role. He has experience in = the >> IETF as a contributor and in ONF and BBF as well as the OpenDaylight, >> OPNFV, OpenStack communities. I welcome the experience the he will = bring >> with SDN and NETCONF/YANG to the opsawg chair role, I think we will = be >> well served in addressing that part of our constituency. >>=20 >> Thanks >> joel >>=20 >>=20 >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Feb 4 17:58:17 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E781B2C86 for ; Thu, 4 Feb 2016 17:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 LX9FS1orrGqj for ; Thu, 4 Feb 2016 17:58:13 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE34F1B2C82 for ; Thu, 4 Feb 2016 17:58:12 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 44633206A64; Fri, 5 Feb 2016 02:58:08 +0100 (CET) References: <20160205005807.8180.65511.idtracker@ietfa.amsl.com> To: "opsawg@ietf.org" From: Fernando Gont X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <20160205005807.8180.65511.idtracker@ietfa.amsl.com> Message-ID: <56B401AE.2030105@si6networks.com> Date: Thu, 4 Feb 2016 22:58:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160205005807.8180.65511.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 01:58:15 -0000 Folks, We have posted a revision of our firewalls document. The revised I-D is available at: Among the changes are: * We have rewritten the intro. * The document clearly states what the goals of this document are. * The document has now a more clear definition of what we mean by "firewall", and is agnostic regarding the specific layer at which the firewall operates (in most of the discussion about firewalls). * Some sections have been augmented. * Minor editorial changes. Your feedback will be appreciated (on the opsawg@ietf.org mailing-list). Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsawg-firewalls-analysis-02.txt Date: Thu, 04 Feb 2016 16:58:07 -0800 From: internet-drafts@ietf.org To: Fred Baker , Fernando Gont A new version of I-D, draft-gont-opsawg-firewalls-analysis-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsawg-firewalls-analysis Revision: 02 Title: On Firewalls in Network Security Document date: 2016-02-04 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-gont-opsawg-firewalls-analysis-02.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsawg-firewalls-analysis/ Htmlized: https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-opsawg-firewalls-analysis-02 Abstract: This document analyzes the role of firewalls in network security, and recognizes their role in the internet architecture. It suggests a line of reasoning about their usage, and analyzes common kinds of firewalls and the claims made for them. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Feb 4 23:24:49 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEDC1B38E1 for ; Thu, 4 Feb 2016 23:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 4oY_PupkbTZ9 for ; Thu, 4 Feb 2016 23:24:46 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E131B3896 for ; Thu, 4 Feb 2016 23:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6637; q=dns/txt; s=iport; t=1454657085; x=1455866685; h=to:from:subject:message-id:date:mime-version; bh=gKRWPT+8HpXp/dt45jsLszqT76W64zv1M3M39U4u2nM=; b=Pg1sITfFE65v0xlYzJ5yImLCtnjdx7JfheqSzAuGLmYiZu+va4GB6/YZ bZ7F/I3Ip4Zb2gUwRq1oPimMkipxlHVMHkLokwK9u43vXRCbzrbSq4VQi xZgnB9ZRn1HOyXBeRueEcmgUR2AlB/xI6Jn8SDCj43vptuetmstmJX0mB A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAwD6TLRW/xbLJq1ejVSxDA6BZod+F?= =?us-ascii?q?AEBAQEBAQGBCkEOAYQbVSAdFgsCCwMCAQIBWAgBAYgXoSmPW48RCI5WgyWBOgW?= =?us-ascii?q?HWI8bgn6BZIhugVuEQ4MDhVKKbYNSHgFDgX6BZzuGbYIFgTgBAQE?= X-IronPort-AV: E=Sophos;i="5.22,399,1449532800"; d="asc'?scan'208,217";a="632185129" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2016 07:24:43 +0000 Received: from [10.61.222.230] ([10.61.222.230]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u157Oh1b017245 for ; Fri, 5 Feb 2016 07:24:43 GMT To: opsawg@ietf.org From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <56B44E3A.9020501@cisco.com> Date: Fri, 5 Feb 2016 08:24:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5FGDcokFu6AbhgVDUQCkQlNWdP2ub1kot" Archived-At: Subject: [OPSAWG] Here's MUD in your eye! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 07:24:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5FGDcokFu6AbhgVDUQCkQlNWdP2ub1kot Content-Type: multipart/alternative; boundary="------------060004010606040209040309" This is a multi-part message in MIME format. --------------060004010606040209040309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, For the last few months I've been working on a little effort which I call MUD. It stands for Manufacturer Usage Descriptions, and it focuses on the security of Things. There are already quite a lot things and more on the way (Cisco estimates 50 billion by 2020, and others say more). And there will be many developers/manufacturers of these things. It will be impossible for anyone to really keep track of all of these Things on their own. Developers/manufacturers will be in a good position to tell network administrators what sort of network access these Things require, and as importantly, what sort of network access these things are not intended to have. Consider this simple example : a networked rheostat is unlikely to want to browse CNN. That same rheostat may have a bug. It's also possible for the network to limit who can attack it, so long as the rheostat manufacturer has a means to tell the network what access is needed and what is not. So... what's necessary for all of this to work? 1. A standard way to indicate where a description is stored; 2. A way for the thing to tell the network what it is in such a way that the network can retrieve a description; 3. A schema for the description itself; and optionally 4. Some abstractions that can permit/deny access to certain classes of devices. As an entr=C3=A9e, I've specified a URI as a means to indicate where the desription is (1), IEEE 802.1AR certificates with 802.1X as well as DHCP for getting it from the device (2), and YANG-based XML for (3) and (4). In IETFeze that translates to the following drafts: * draft-lear-mud-framework (a few more lines of text describing the abo= ve) * draft-lear-ietf-netmod-mud (the YANG model and the URI specification)= * draft-lear-ietf-pkix-mud-extension (a non-critical constraint for the MUD URI); and * draft-lear-ietf-dhc-mud-option (a way to communicate the URI via DHCP= ) I think you'll find one or two open issues with these drafts (to say the very least), but hopefully you might like the concept. I'm seeking feedback, discussion, collaborators, and perhaps some co-authors on this work. At the very least, I'm sure some people can contribute a humorous pun or two. And please! No mud slinging! ;-) Eliot --------------060004010606040209040309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone,

For the last few months I've been working on a little effort which I call MUD.=C2=A0 It stands for Manufacturer Usage Descriptions, and it= focuses on the security of Things.=C2=A0 There are already quite a lo= t things and more on the way (Cisco estimates 50 billion by 2020, and others say more).=C2=A0 And there will be many developers/manufacture= rs of these things.=C2=A0 It will be impossible for anyone to really kee= p track of all of these Things on their own.=C2=A0 Developers/manufactu= rers will be in a good position to tell network administrators what sort of network access these Things require, and as importantly, what sort of network access these things are not intended to have.=C2=A0 Consider this simple example : a networked rheostat is unlikely to want to browse CNN.=C2=A0 That same rheostat may have a bug.=C2=A0 It= 's also possible for the network to limit who can attack it, so long as the rheostat manufacturer has a means to tell the network what access is needed and what is not.

So... what's necessary for all of this to work?
  1. A standard way to indicate where a description is stored;
  2. A way for the thing to tell the network what it is in such a way that the network can retrieve a description;
  3. A schema for the description itself; and optionally
  4. Some abstractions that can permit/deny access to certain classes of devices.

As an entr=C3=A9e, I've specified a URI as a means to indicate whe= re the desription is (1),=C2=A0 IEEE 802.1AR certificates with 802.1X = as well as DHCP for getting it from the device (2), and YANG-based XML for (3) and (4).=C2=A0 In IETFeze that translates to the follow= ing drafts:

  • draft-lear-mud-framework (a few more lines of text describing the above)
  • draft-lear-ietf-netmod-mud (the YANG model and the URI specification)
  • draft-lear-ietf-pkix-mud-extension (a non-critical constraint for the MUD URI); and
  • draft-lear-ietf-dhc-mud-option (a way to communicate the URI via DHCP)

I think you'll find one or two open issues with these drafts (to say the very least), but hopefully you might like the concept. I'm seeking feedback, discussion, collaborators, and perhaps some co-authors on this work.=C2=A0 At the very least, I'm sure some peo= ple can contribute a humorous pun or two.

And please!=C2=A0 No mud slinging!

;-)

Eliot

--------------060004010606040209040309-- --5FGDcokFu6AbhgVDUQCkQlNWdP2ub1kot Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWtE47AAoJEIe2a0bZ0noz3b4H/ixOr+qwroZAuWCVZiG7CsNT F3ZBd5MP4Jvh1Fz4/dj/L39wFKagSIlBgx1gmc8FO3gtEJBi8I49Qd5gGEkqrTcJ zBJ+o85CHOlRATUyV+jEfX/TNDknV5CdTeQJ/Evnl3U04oYITA+f+nC9Vew/PwTw QfCi+/fM99SXoM1EpcWkk4p1Jjlhskl9A4jiD/1M0BVbrWu0aD4XRq0WWlRKni0N USbSKDsmod1zazmk6okG/F7xz7QC7Asr1quaCQ1az2Z/A2nSOY67Lh+T5BSOcVqy /X8tErFY3ZJR5glZd69zK95OObHvVObnwQywmrs4X6DWyj5yG8KuOHktSInfdrk= =cC45 -----END PGP SIGNATURE----- --5FGDcokFu6AbhgVDUQCkQlNWdP2ub1kot-- From nobody Thu Feb 4 23:53:16 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D001A00E4 for ; Thu, 4 Feb 2016 23:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 weM9PZ9DoEno for ; Thu, 4 Feb 2016 23:53:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD151A00E3 for ; Thu, 4 Feb 2016 23:53:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIC27701; Fri, 05 Feb 2016 07:53:10 +0000 (GMT) Received: from LHREML705-CAH.china.huawei.com (10.201.5.168) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 5 Feb 2016 07:53:08 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 5 Feb 2016 07:53:08 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Fri, 5 Feb 2016 15:53:02 +0800 From: Zhoutianran To: Tim Wicinski , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Please welcome our new chair! Thread-Index: AQHRXYoRBNTAckiVpEaF4toUHhMg4J8cHW0AgAD6d3A= Date: Fri, 5 Feb 2016 07:53:02 +0000 Message-ID: References: <56B0586D.1070506@bogus.com> <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> In-Reply-To: <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56B454E6.0073, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 44e50b1653e97d2bfbf6be1eee2b25fd Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 07:53:15 -0000 Oh, really? I would like to know. Could you please send a private message to me :-) Happy the new monkey year to all you guys! Best, Tianran > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tim Wicinski > Sent: Friday, February 05, 2016 8:51 AM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] Please welcome our new chair! >=20 >=20 > Welcome Zhou! >=20 > If you need any help managing Warren, just speak up. Many of us are quite > skilled at this. >=20 > tim >=20 >=20 > On 2/2/16 2:19 AM, joel jaeggli wrote: > > Greetings, > > > > First, I want to thank everyone who volunteered. The enthusiasm and > > depth of field present in the pool of volunteers who indicated > > interest in serving as co-chair is truly humbling. I talked to several > > of you over the course of this deliberation in addition to my co-ad > > and the present chairs. My expectation is we will have three chairs > > until Scott steps down following IETF 95. > > > > On to Business. > > > > Zhou Tianran has agreed to take on the role of opsawg chair. He joins > > Warren Kumari and Scott Bradner in this role. He has experience in the > > IETF as a contributor and in ONF and BBF as well as the OpenDaylight, > > OPNFV, OpenStack communities. I welcome the experience the he will > > bring with SDN and NETCONF/YANG to the opsawg chair role, I think we > > will be well served in addressing that part of our constituency. > > > > Thanks > > joel > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Sun Feb 7 02:08:54 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91E1B384E for ; Sun, 7 Feb 2016 02:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 wDZTtxOYp-ay for ; Sun, 7 Feb 2016 02:08:52 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD6B1A8722 for ; Sun, 7 Feb 2016 02:08:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DyAQAZF7dW/xUHmMZeGQEBAQEPAQEBAYJfK4E/BohVrnSCEwENgWaGDQKBHjgUAQEBAQEBAYEKhEEBAQEBAxIoSwQCAQgNBAQBAQEKFAkHMhQJCAIEARIIGod5AaRhmQcBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhhSENYQygyuBDwWWdQGPKoRDgxqFO44+HgEBQoNkaodXAXsBAQE X-IPAS-Result: A2DyAQAZF7dW/xUHmMZeGQEBAQEPAQEBAYJfK4E/BohVrnSCEwENgWaGDQKBHjgUAQEBAQEBAYEKhEEBAQEBAxIoSwQCAQgNBAQBAQEKFAkHMhQJCAIEARIIGod5AaRhmQcBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhhSENYQygyuBDwWWdQGPKoRDgxqFO44+HgEBQoNkaodXAXsBAQE X-IronPort-AV: E=Sophos;i="5.22,410,1449550800"; d="scan'208";a="165691273" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 07 Feb 2016 05:08:50 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 07 Feb 2016 05:08:49 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Sun, 7 Feb 2016 11:08:47 +0100 From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (Nokia - DE/Munich)" , "EXT Bert Wijnen (IETF)" , joel jaeggli , "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Please welcome our new chair! Thread-Index: AQHRXyRcXRiB6cK1ZE+hsgFTF8lcQJ8cEt8AgARNpAA= Date: Sun, 7 Feb 2016 10:08:46 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF0C98A@AZ-FFEXMB04.global.avaya.com> References: <56B0586D.1070506@bogus.com> <56B308CB.8080406@bwijnen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 10:08:53 -0000 Congratulations and good luck, Tianran! Regards, Dan > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Ersue, > Mehmet (Nokia - DE/Munich) > Sent: Thursday, February 04, 2016 7:25 PM > To: EXT Bert Wijnen (IETF); joel jaeggli; opsawg-chairs@tools.ietf.org; > opsawg@ietf.org > Subject: Re: [OPSAWG] Please welcome our new chair! >=20 > +1 >=20 > Cheers, > Mehmet >=20 >=20 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of EXT Bert > Wijnen (IETF) > Sent: Thursday, February 04, 2016 9:16 AM > To: joel jaeggli ; opsawg-chairs@tools.ietf.org; > opsawg@ietf.org > Subject: Re: [OPSAWG] Please welcome our new chair! >=20 > Welcome Tianran, and a big THANKS to Scott for his many years > of service. >=20 > Bert > On 02/02/16 08:19, joel jaeggli wrote: > > Greetings, > > > > First, I want to thank everyone who volunteered. The enthusiasm and > > depth of field present in the pool of volunteers who indicated interest > > in serving as co-chair is truly humbling. I talked to several of you > > over the course of this deliberation in addition to my co-ad and the > > present chairs. My expectation is we will have three chairs until Scott > > steps down following IETF 95. > > > > On to Business. > > > > Zhou Tianran has agreed to take on the role of opsawg chair. He joins > > Warren Kumari and Scott Bradner in this role. He has experience in the > > IETF as a contributor and in ONF and BBF as well as the OpenDaylight, > > OPNFV, OpenStack communities. I welcome the experience the he will > bring > > with SDN and NETCONF/YANG to the opsawg chair role, I think we will be > > well served in addressing that part of our constituency. > > > > Thanks > > joel > > From nobody Sun Feb 7 12:18:35 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9EE1A1BED for ; Sun, 7 Feb 2016 12:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 3NmRg4ylqk_7 for ; Sun, 7 Feb 2016 12:18:31 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65471A1BCF for ; Sun, 7 Feb 2016 12:18:31 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id u9so80169875ykd.1 for ; Sun, 07 Feb 2016 12:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P0pIxCiyMuOIr85M8LM3RoZtcV9KfTLa+eodY6Si9xc=; b=f6NkfHAFTeM/Mtkgm68Cn+3H9cCE+/osHQG59cVEBFwL8K6zSWbMs02GGjTsPUAij2 OtZgLWEumv3HCuTqz151GsTadFpc6M99n6fC3KwMa5ml4fLccWvTKqBaPzPgZDc7/hae K7ZOH8T+zgd1HBmHop0lQHeL/Ko7Zrq7mkIIuVB1xTMs1es0Uqoh93C7nhcM3VawLZO9 tC0w35l6BrorEBD0PlSVmlq8b/7Bc/5UduMla073TqZtC+1TJY4bM/iz+T3nCgmfQIL/ gffqqrEhsZuCwG86q98GHbIUFkzge+OIZv2ZOXi5I/w9zdd103T/QGSNEXbccJYBJ1TV J+5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=P0pIxCiyMuOIr85M8LM3RoZtcV9KfTLa+eodY6Si9xc=; b=VftAV1zYZu9MBK4rXoReDEaK53T5SG2+sKUElB26h+JZV1V8hVVHgg/60nw0yXhEir 04gWQWTBUCy2JG+cNKpuN/bIH5XxH1TgN6QzIof0I4MD9+ql+SI10eThi3msek+lqaq0 wCj9wDGiTZdz1vlm/xoDxRte7ldGDHgjVtgB5qhi4o98kPUzqXiPbi1qNqdhWYADU5M8 1SGR+BVHTaKklHPqKd4uTCiUz8FPNNmPm5B/mLJ5cEJ+ibH8++oNluZ0EAMymFnPnUQb 2xukS5etO78m/sQSn6G4GFHQdLKSgfjFvZ17XpBpuZzpyTkakHuggMTy4KjWpavIrX+W DqTw== X-Gm-Message-State: AG10YOQ1Imbg0eP1twb9u8o4FAVQNSsbKLkxeLlzFKB4xuflVn2Fx5Adyu4TgdAI5Ljqn21tmgBVFxVa3TK/1DBg MIME-Version: 1.0 X-Received: by 10.37.77.131 with SMTP id a125mr13169443ybb.174.1454876310799; Sun, 07 Feb 2016 12:18:30 -0800 (PST) Received: by 10.37.109.134 with HTTP; Sun, 7 Feb 2016 12:18:30 -0800 (PST) In-Reply-To: References: <56B0586D.1070506@bogus.com> <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> Date: Sun, 7 Feb 2016 12:18:30 -0800 Message-ID: From: Warren Kumari To: Zhoutianran Content-Type: multipart/alternative; boundary=001a113c5fc0b2b9c4052b33c940 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 20:18:33 -0000 --001a113c5fc0b2b9c4052b33c940 Content-Type: text/plain; charset=UTF-8 On Friday, February 5, 2016, Zhoutianran wrote: > Oh, really? I would like to know. > Bribery with cookies usually works well, for really big things, bribery with a funny hat... W > Could you please send a private message to me :-) > > Happy the new monkey year to all you guys! > > Best, > Tianran > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org ] On Behalf > Of Tim Wicinski > > Sent: Friday, February 05, 2016 8:51 AM > > To: opsawg@ietf.org > > Subject: Re: [OPSAWG] Please welcome our new chair! > > > > > > Welcome Zhou! > > > > If you need any help managing Warren, just speak up. Many of us are quite > > skilled at this. > > > > tim > > > > > > On 2/2/16 2:19 AM, joel jaeggli wrote: > > > Greetings, > > > > > > First, I want to thank everyone who volunteered. The enthusiasm and > > > depth of field present in the pool of volunteers who indicated > > > interest in serving as co-chair is truly humbling. I talked to several > > > of you over the course of this deliberation in addition to my co-ad > > > and the present chairs. My expectation is we will have three chairs > > > until Scott steps down following IETF 95. > > > > > > On to Business. > > > > > > Zhou Tianran has agreed to take on the role of opsawg chair. He joins > > > Warren Kumari and Scott Bradner in this role. He has experience in the > > > IETF as a contributor and in ONF and BBF as well as the OpenDaylight, > > > OPNFV, OpenStack communities. I welcome the experience the he will > > > bring with SDN and NETCONF/YANG to the opsawg chair role, I think we > > > will be well served in addressing that part of our constituency. > > > > > > Thanks > > > joel > > > > > > > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a113c5fc0b2b9c4052b33c940 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Friday, February 5, 2016, Zhoutianran <zhoutianran@huawei.com> wrote:
Oh, really? I would like to know.
Bribery with cookies usually works well, for really big things,= bribery with a funny hat...

W

=C2=A0
Could you please send a private message to me :-)

Happy the new monkey year to all you guys!

Best,
Tianran

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tim Wicinski
> Sent: Friday, February 05, 2016 8:51 AM
> To: opsawg@ietf.org
> Subject: Re: [OPSAWG] Please welcome our new chair!
>
>
> Welcome Zhou!
>
> If you need any help managing Warren, just speak up. Many of us are qu= ite
> skilled at this.
>
> tim
>
>
> On 2/2/16 2:19 AM, joel jaeggli wrote:
> > Greetings,
> >
> > First, I want to thank everyone who volunteered. The enthusiasm a= nd
> > depth of field present in the pool of volunteers who indicated > > interest in serving as co-chair is truly humbling. I talked to se= veral
> > of you over the course of this deliberation in addition to my co-= ad
> > and the present chairs. My expectation is we will have three chai= rs
> > until Scott steps down following IETF 95.
> >
> > On to Business.
> >
> > Zhou Tianran has agreed to=C2=A0 take on the role of opsawg chair= . He joins
> > Warren Kumari and Scott Bradner in this role. He has experience i= n the
> > IETF as a contributor and in ONF and BBF as well as the OpenDayli= ght,
> > OPNFV, OpenStack communities. I welcome the experience the he wil= l
> > bring with SDN and NETCONF/YANG to the opsawg chair role, I think= we
> > will be well served in addressing that part of our constituency.<= br> > >
> > Thanks
> > joel
> >
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg


--
I don't think the execution is relevant whe= n it was obviously a bad idea in the first place.
This is like putting r= abid weasels in your pants, and later expressing regret at having chosen th= ose particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf=
--001a113c5fc0b2b9c4052b33c940-- From nobody Sun Feb 7 13:47:24 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726371A88E7 for ; Sun, 7 Feb 2016 13:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7-twWbx1-RcV for ; Sun, 7 Feb 2016 13:47:21 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCEB11A88E2 for ; Sun, 7 Feb 2016 13:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3181; q=dns/txt; s=iport; t=1454881640; x=1456091240; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YHH2VnkBSkQ3oiTlWy84iMwpnFaNIWi+GxF0TmnlX4g=; b=aSvZ4+LXotLsmxI6lxY1KJ9uatYTI5VtCcRsitwD9CxIJox5RvS2o8en 8lQawJ1iLHYEjXCh3POLCAqoxmxjU8xHbIJ5D4pGFUKsfm8dTkuRHeFx+ 4D7ogqe/Famw9Bd28YAIBnb7Lr/deNlnGlBt3oN+Dn/llmHvW7Oholanm w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgAPu7dW/5tdJa1egzpSbQaIVbEIA?= =?us-ascii?q?Q2BZhcKhSJKAoEgOBQBAQEBAQEBfwuEQQEBAQQBAQFLIAsSARkDAQINSQoBHQo?= =?us-ascii?q?EDgUYBQSHeg68YAEBAQEBAQEBAQEBAQEBAQEBAQEXjksRAYRYBYVNggaLG4QHA?= =?us-ascii?q?YVLhU+CNYFbSoN5iFMCimyDUQEeAQFCg2RqAQEBhyA0fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,412,1449532800"; d="scan'208";a="235802554" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2016 21:47:19 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u17LlJIj001520 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 7 Feb 2016 21:47:19 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 7 Feb 2016 15:47:19 -0600 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.1104.009; Sun, 7 Feb 2016 15:47:19 -0600 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: TACACS+ New Version with AI extensions for playing Go. Thread-Index: AQHRYfEeqb8PHlengEOjh7oVXWZ0Uw== Date: Sun, 7 Feb 2016 21:47:19 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.7] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9123201080FF5F4C9AFBEE5D2C5E1C4F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Andrej Ota , Thorsten Dahm Subject: [OPSAWG] TACACS+ New Version with AI extensions for playing Go. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 21:47:22 -0000 =8A Apologies, just an attention grabbing headline. No specific AI support has been added to T+ protocol to help play go, but the new version has been uploaded with corrections after first round of comments. TACACS+ still restricted to plain AAA at this time! The author collective would be grateful for any further feedback. Many thanks! On 16/12/2015 13:34, "OPSAWG on behalf of opsawg-request@ietf.org" wrote: >Send OPSAWG mailing list submissions to > opsawg@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsawg >or, via email, send a message with subject or body 'help' to > opsawg-request@ietf.org > >You can reach the person managing the list at > opsawg-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OPSAWG digest..." > > >Today's Topics: > > 1. I-D Action: draft-ietf-opsawg-tacacs-00.txt > (internet-drafts@ietf.org) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 16 Dec 2015 05:34:08 -0800 >From: internet-drafts@ietf.org >To: >Cc: opsawg@ietf.org >Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-00.txt >Message-ID: <20151216133408.20608.13192.idtracker@ietfa.amsl.com> >Content-Type: text/plain; charset=3D"utf-8" > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Operations and Management Area Working >Group Working Group of the IETF. > > Title : The TACACS+ Protocol > Authors : Thorsten Dahm > Andrej Ota > Douglas C. Medway Gash > David Carrel > Lol Grant > Filename : draft-ietf-opsawg-tacacs-00.txt > Pages : 36 > Date : 2015-12-16 > >Abstract: > TACACS+ provides access control for routers, network access servers > and other networked computing devices via one or more centralized > servers. TACACS+ provides separate authentication, authorization and > accounting services. This document describes the protocol that is > used by TACACS+. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 103, Issue 11 >*************************************** From nobody Sun Feb 7 22:50:25 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0623F1AC3CA for ; Sun, 7 Feb 2016 22:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 moZXcMEB6N5D for ; Sun, 7 Feb 2016 22:50:21 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7C01AC3C7 for ; Sun, 7 Feb 2016 22:50:20 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.176.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 82A2518014F3; Mon, 8 Feb 2016 07:50:17 +0100 (CET) To: opsawg@ietf.org, Warren Kumari References: <56B0586D.1070506@bogus.com> <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> From: Loa Andersson Message-ID: <56B83A92.8080001@pi.nu> Date: Mon, 8 Feb 2016 14:49:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 06:50:24 -0000 Warren, On 2016-02-08 04:18, Warren Kumari wrote: > > > On Friday, February 5, 2016, Zhoutianran > wrote: > > Oh, really? I would like to know. > > > Bribery with cookies usually works well, for really big things, bribery > with a funny hat... do I read this right if I understand it like this - small things I give one or more cookies - big big things, I wear a funny hat when I give you the cookies right? /Loa PS Remember that we have runnig cookie code, ask ekr :) > > W > > Could you please send a private message to me :-) > > Happy the new monkey year to all you guys! > > Best, > Tianran > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org ] On > Behalf Of Tim Wicinski > > Sent: Friday, February 05, 2016 8:51 AM > > To: opsawg@ietf.org > > Subject: Re: [OPSAWG] Please welcome our new chair! > > > > > > Welcome Zhou! > > > > If you need any help managing Warren, just speak up. Many of us > are quite > > skilled at this. > > > > tim > > > > > > On 2/2/16 2:19 AM, joel jaeggli wrote: > > > Greetings, > > > > > > First, I want to thank everyone who volunteered. The enthusiasm and > > > depth of field present in the pool of volunteers who indicated > > > interest in serving as co-chair is truly humbling. I talked to > several > > > of you over the course of this deliberation in addition to my co-ad > > > and the present chairs. My expectation is we will have three chairs > > > until Scott steps down following IETF 95. > > > > > > On to Business. > > > > > > Zhou Tianran has agreed to take on the role of opsawg chair. > He joins > > > Warren Kumari and Scott Bradner in this role. He has experience > in the > > > IETF as a contributor and in ONF and BBF as well as the > OpenDaylight, > > > OPNFV, OpenStack communities. I welcome the experience the he will > > > bring with SDN and NETCONF/YANG to the opsawg chair role, I > think we > > > will be well served in addressing that part of our constituency. > > > > > > Thanks > > > joel > > > > > > > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > > -- > I don't think the execution is relevant when it was obviously a bad idea > in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Mon Feb 8 08:50:27 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09A91B2F3A for ; Mon, 8 Feb 2016 08:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 4Bt-Hc1EdvMa for ; Mon, 8 Feb 2016 08:50:12 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F66E1B2F34 for ; Mon, 8 Feb 2016 08:50:12 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id h129so106490416ywb.1 for ; Mon, 08 Feb 2016 08:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=aMA6/xqB0qzhtMCRCn5AU14aYxtdbENuvHhBiUZXx+I=; b=WqIh4zipD+h9mSXlJmQhXziORaoZF4Vl69Lib4Ers6NX44TPFCOmR+i9qNLXsVhApL D8NmXcE2kIyzenl8Nu36LE3P2iLGdKNqjJyYWsCOwYjG8K25AjAmdIZkMOzUcoZF3x/U 7rTJvkxTdxckr5+m43AW146IsCVdlPy4o9Q8rSSsttOdlZXcOk1HmmxAQJAWsW3vZciM v5Mh2eZ2LlsUWxY2+o7rqTZtirvnHUhE5QGXiB1/NuupGclEbWTMPTO3oearmxkn8syU 6ZpWXk66OTY1V/14lVLcAyn8pzyXPY+7wx7Bc0TMr3gro3nedbA4wMNZvd4lByK8yru4 dJXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=aMA6/xqB0qzhtMCRCn5AU14aYxtdbENuvHhBiUZXx+I=; b=ibboog4F7o1AujqZVPhzDIo7Pp5MmblP2cn6AXrKRwX+FaENFVUXM4gGwIHUBbA3b0 eN+/co55xIJa3yItZ4BlNGMrajQAHI6Tt+LkN0jqehV4Ta6PoX/nkM4eFwp5blvTJrA9 dhXJWtYVwszi3EvkTSctrYdLKvnEwV1+DJjOjj0orRyk5PKJE4BHBsroDaAfm5qvg1Io fj+WBDlEjp2F6buNLHi+BCvxOQuXeexpgByX8I5YPGbP43tdCjduT3em0ElIWALKLmAU VlG5c47WMHzq52BCxAbovElQygZSNdadc4s0mpdp89k6KT4eivLof+Xa9bm7ct1GNcB0 SWbA== X-Gm-Message-State: AG10YOTe4YppI50BOTpUXzxufg6uR8HFCGMaIcwfjYS4tTGxFIGCJUrw/mFZqKHf4SXOqkkNIL64CIQaqI8rMEip X-Received: by 10.13.231.132 with SMTP id q126mr14443755ywe.203.1454950211757; Mon, 08 Feb 2016 08:50:11 -0800 (PST) MIME-Version: 1.0 References: <56B0586D.1070506@bogus.com> <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> <56B83A92.8080001@pi.nu> In-Reply-To: <56B83A92.8080001@pi.nu> From: Warren Kumari Date: Mon, 08 Feb 2016 16:50:02 +0000 Message-ID: To: Loa Andersson , opsawg@ietf.org Content-Type: multipart/alternative; boundary=94eb2c088c1e89d6aa052b44fe6c Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:50:14 -0000 --94eb2c088c1e89d6aa052b44fe6c Content-Type: text/plain; charset=UTF-8 On Sun, Feb 7, 2016 at 10:50 PM Loa Andersson wrote: > Warren, > > > > On 2016-02-08 04:18, Warren Kumari wrote: > > > > > > On Friday, February 5, 2016, Zhoutianran > > wrote: > > > > Oh, really? I would like to know. > > > > > > Bribery with cookies usually works well, for really big things, bribery > > with a funny hat... > > do I read this right if I understand it like this > > - small things I give one or more cookies > Yes. > - big big things, I wear a funny hat when I give you the cookies > right? > No no no no no no no... You *bring* me a funny hat - for example, Jim Martin and I found this one in Amsterdam: https://twitter.com/danyork/status/623142046031720449 The bigger the ask, the sillier the hat needs to be. W P.S: Yes, I *did* just use "ask" as a noun. I wanted to try it, and it was oddly thrilling.... > > /Loa > > PS > Remember that we have runnig cookie code, ask ekr :) > > > > W > > > > Could you please send a private message to me :-) > > > > Happy the new monkey year to all you guys! > > > > Best, > > Tianran > > > > > -----Original Message----- > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org ] On > > Behalf Of Tim Wicinski > > > Sent: Friday, February 05, 2016 8:51 AM > > > To: opsawg@ietf.org > > > Subject: Re: [OPSAWG] Please welcome our new chair! > > > > > > > > > Welcome Zhou! > > > > > > If you need any help managing Warren, just speak up. Many of us > > are quite > > > skilled at this. > > > > > > tim > > > > > > > > > On 2/2/16 2:19 AM, joel jaeggli wrote: > > > > Greetings, > > > > > > > > First, I want to thank everyone who volunteered. The enthusiasm > and > > > > depth of field present in the pool of volunteers who indicated > > > > interest in serving as co-chair is truly humbling. I talked to > > several > > > > of you over the course of this deliberation in addition to my > co-ad > > > > and the present chairs. My expectation is we will have three > chairs > > > > until Scott steps down following IETF 95. > > > > > > > > On to Business. > > > > > > > > Zhou Tianran has agreed to take on the role of opsawg chair. > > He joins > > > > Warren Kumari and Scott Bradner in this role. He has experience > > in the > > > > IETF as a contributor and in ONF and BBF as well as the > > OpenDaylight, > > > > OPNFV, OpenStack communities. I welcome the experience the he > will > > > > bring with SDN and NETCONF/YANG to the opsawg chair role, I > > think we > > > > will be well served in addressing that part of our constituency. > > > > > > > > Thanks > > > > joel > > > > > > > > > > > > > > > > _______________________________________________ > > > > OPSAWG mailing list > > > > OPSAWG@ietf.org > > > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad idea > > in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair of > > pants. > > ---maf > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > --94eb2c088c1e89d6aa052b44fe6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun= , Feb 7, 2016 at 10:50 PM Loa Andersson <lo= a@pi.nu> wrote:
Warren,



On 2016-02-08 04:18, Warren Kumari wrote:
>
>
> On Friday, February 5, 2016, Zhoutianran <zhoutianran@huawei.com
> <mailto:zhoutianran@huawei.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Oh, really? I would like to know.
>
>
> Bribery with cookies usually works well, for really big things, briber= y
> with a funny hat...

do I read this right if I understand it like this

- small things I give one or more cookies

Yes.
=C2=A0
- big big things, I wear a funny hat when I give you the cookies
right?

No no no no no no no...
You *bring* me a funny hat - for example, Jim Martin and I found this one= in Amsterdam:=C2=A0https://twitter.com/danyork/status/623142046031720449
<= div>The bigger the ask, the sillier the hat needs to be.=C2=A0

W
P.S: Yes, I *did* just use "ask" as = a noun. I wanted to try it, and it was oddly thrilling....

=C2=A0

/Loa

PS
Remember that we have runnig cookie code, ask ekr :)
>
> W
>
>=C2=A0 =C2=A0 =C2=A0Could you please send a private message to me :-) >
>=C2=A0 =C2=A0 =C2=A0Happy the new monkey year to all you guys!
>
>=C2=A0 =C2=A0 =C2=A0Best,
>=C2=A0 =C2=A0 =C2=A0Tianran
>
>=C2=A0 =C2=A0 =C2=A0 > -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0 > From: OPSAWG [mailto:opsawg-bounces@ietf.org <javasc= ript:;>] On
>=C2=A0 =C2=A0 =C2=A0Behalf Of Tim Wicinski
>=C2=A0 =C2=A0 =C2=A0 > Sent: Friday, February 05, 2016 8:51 AM
>=C2=A0 =C2=A0 =C2=A0 > To: opsawg@ietf.org <javascript:;>
>=C2=A0 =C2=A0 =C2=A0 > Subject: Re: [OPSAWG] Please welcome our new = chair!
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Welcome Zhou!
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > If you need any help managing Warren, just sp= eak up. Many of us
>=C2=A0 =C2=A0 =C2=A0are quite
>=C2=A0 =C2=A0 =C2=A0 > skilled at this.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > tim
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On 2/2/16 2:19 AM, joel jaeggli wrote:
>=C2=A0 =C2=A0 =C2=A0 > > Greetings,
>=C2=A0 =C2=A0 =C2=A0 > >
>=C2=A0 =C2=A0 =C2=A0 > > First, I want to thank everyone who volu= nteered. The enthusiasm and
>=C2=A0 =C2=A0 =C2=A0 > > depth of field present in the pool of vo= lunteers who indicated
>=C2=A0 =C2=A0 =C2=A0 > > interest in serving as co-chair is truly= humbling. I talked to
>=C2=A0 =C2=A0 =C2=A0several
>=C2=A0 =C2=A0 =C2=A0 > > of you over the course of this deliberat= ion in addition to my co-ad
>=C2=A0 =C2=A0 =C2=A0 > > and the present chairs. My expectation i= s we will have three chairs
>=C2=A0 =C2=A0 =C2=A0 > > until Scott steps down following IETF 95= .
>=C2=A0 =C2=A0 =C2=A0 > >
>=C2=A0 =C2=A0 =C2=A0 > > On to Business.
>=C2=A0 =C2=A0 =C2=A0 > >
>=C2=A0 =C2=A0 =C2=A0 > > Zhou Tianran has agreed to=C2=A0 take on= the role of opsawg chair.
>=C2=A0 =C2=A0 =C2=A0He joins
>=C2=A0 =C2=A0 =C2=A0 > > Warren Kumari and Scott Bradner in this = role. He has experience
>=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0 > > IETF as a contributor and in ONF and BBF= as well as the
>=C2=A0 =C2=A0 =C2=A0OpenDaylight,
>=C2=A0 =C2=A0 =C2=A0 > > OPNFV, OpenStack communities. I welcome = the experience the he will
>=C2=A0 =C2=A0 =C2=A0 > > bring with SDN and NETCONF/YANG to the o= psawg chair role, I
>=C2=A0 =C2=A0 =C2=A0think we
>=C2=A0 =C2=A0 =C2=A0 > > will be well served in addressing that p= art of our constituency.
>=C2=A0 =C2=A0 =C2=A0 > >
>=C2=A0 =C2=A0 =C2=A0 > > Thanks
>=C2=A0 =C2=A0 =C2=A0 > > joel
>=C2=A0 =C2=A0 =C2=A0 > >
>=C2=A0 =C2=A0 =C2=A0 > >
>=C2=A0 =C2=A0 =C2=A0 > >
>=C2=A0 =C2=A0 =C2=A0 > > ________________________________________= _______
>=C2=A0 =C2=A0 =C2=A0 > > OPSAWG mailing list
>=C2=A0 =C2=A0 =C2=A0 > > OPSAWG@ietf.org <javascript:;>
>=C2=A0 =C2=A0 =C2=A0 > > https://www.ietf.org/= mailman/listinfo/opsawg
>=C2=A0 =C2=A0 =C2=A0 > >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > OPSAWG mailing list
>=C2=A0 =C2=A0 =C2=A0 > OPSAWG@ietf.org <javascript:;>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailm= an/listinfo/opsawg
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0OPSAWG mailing list
>=C2=A0 =C2=A0 =C2=A0OPSAWG@ietf.org <javascript:;>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/opsawg
>
>
>
> --
> I don't think the execution is relevant when it was obviously a ba= d idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing=
> regret at having chosen those particular rabid weasels and that pair o= f
> pants.
>=C2=A0 =C2=A0 =C2=A0---maf
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg >
--94eb2c088c1e89d6aa052b44fe6c-- From nobody Mon Feb 8 22:16:21 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2100F1A1AE8 for ; Mon, 8 Feb 2016 22:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 XH_b526fxaK3 for ; Mon, 8 Feb 2016 22:16:17 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547D41A1ADB for ; Mon, 8 Feb 2016 22:16:16 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.176.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1EA7318013CB; Tue, 9 Feb 2016 07:16:13 +0100 (CET) To: Warren Kumari , opsawg@ietf.org References: <56B0586D.1070506@bogus.com> <71147126-14c4-7023-dd14-fb88cb5fa39d@gmail.com> <56B83A92.8080001@pi.nu> From: Loa Andersson Message-ID: <56B98416.1050509@pi.nu> Date: Tue, 9 Feb 2016 14:15:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Please welcome our new chair! X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 06:16:20 -0000 On 2016-02-09 00:50, Warren Kumari wrote: > > > On Sun, Feb 7, 2016 at 10:50 PM Loa Andersson > wrote: > > Warren, > > > > On 2016-02-08 04:18, Warren Kumari wrote: > > > > > > On Friday, February 5, 2016, Zhoutianran > > >> > wrote: > > > > Oh, really? I would like to know. > > > > > > Bribery with cookies usually works well, for really big things, > bribery > > with a funny hat... > > do I read this right if I understand it like this > > - small things I give one or more cookies > > > Yes. > > - big big things, I wear a funny hat when I give you the cookies > right? > > > No no no no no no no... > You *bring* me a funny hat - for example, Jim Martin and I found this > one in Amsterdam: https://twitter.com/danyork/status/623142046031720449 > The bigger the ask, the sillier the hat needs to be. Damm it! I never get to wear the funny hat! /Loa > > W > P.S: Yes, I *did* just use "ask" as a noun. I wanted to try it, and it > was oddly thrilling.... > > > /Loa > > PS > Remember that we have runnig cookie code, ask ekr :) > > > > W > > > > Could you please send a private message to me :-) > > > > Happy the new monkey year to all you guys! > > > > Best, > > Tianran > > > > > -----Original Message----- > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org > ] On > > Behalf Of Tim Wicinski > > > Sent: Friday, February 05, 2016 8:51 AM > > > To: opsawg@ietf.org > > > Subject: Re: [OPSAWG] Please welcome our new chair! > > > > > > > > > Welcome Zhou! > > > > > > If you need any help managing Warren, just speak up. Many > of us > > are quite > > > skilled at this. > > > > > > tim > > > > > > > > > On 2/2/16 2:19 AM, joel jaeggli wrote: > > > > Greetings, > > > > > > > > First, I want to thank everyone who volunteered. The > enthusiasm and > > > > depth of field present in the pool of volunteers who > indicated > > > > interest in serving as co-chair is truly humbling. I > talked to > > several > > > > of you over the course of this deliberation in addition > to my co-ad > > > > and the present chairs. My expectation is we will have > three chairs > > > > until Scott steps down following IETF 95. > > > > > > > > On to Business. > > > > > > > > Zhou Tianran has agreed to take on the role of opsawg > chair. > > He joins > > > > Warren Kumari and Scott Bradner in this role. He has > experience > > in the > > > > IETF as a contributor and in ONF and BBF as well as the > > OpenDaylight, > > > > OPNFV, OpenStack communities. I welcome the experience > the he will > > > > bring with SDN and NETCONF/YANG to the opsawg chair role, I > > think we > > > > will be well served in addressing that part of our > constituency. > > > > > > > > Thanks > > > > joel > > > > > > > > > > > > > > > > _______________________________________________ > > > > OPSAWG mailing list > > > > OPSAWG@ietf.org > > > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a > bad idea > > in the first place. > > This is like putting rabid weasels in your pants, and later > expressing > > regret at having chosen those particular rabid weasels and that > pair of > > pants. > > ---maf > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > From nobody Tue Feb 9 13:01:34 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6657E1B29B7 for ; Tue, 9 Feb 2016 13:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 CG-42ph4dcta for ; Tue, 9 Feb 2016 13:01:31 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436611B29B6 for ; Tue, 9 Feb 2016 13:01:31 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u200so57946930ywf.0 for ; Tue, 09 Feb 2016 13:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=ddGtnPFELRlML5S5y5GYtTTMirFaLsYs2Y6AOgwrMjo=; b=Fr60N9J3g3Loud8OR5baxvJwW6mDN3QYNn2rfffUGBn0x14wrQpuCJQEBnP1/iLYyK yXe1maJSpacmtqdsH3B7peogp8loQ8Ia+C3qoaY8KfVq6mHClaDwxK530NUX1MIlZnSO otLFqijWXwzQ7HGvp6XAMq8loWKa2RtEyUCEEhobvxoO1kljjUg8hB9GR35TK1HWFp4Y 6GV/KjejiblvkxHD/yi9mOiD5e2mSEWauTRjNcyxFOWmWm7XpwosMrhlsQK1TiZt/jo/ 3fAxw9IpCd1YeTR7ed3YVlk2aBSvu0LBPm49EQgZHFoNnB5E/FY5MX7ocvgTIaL1L2Qo iTAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=ddGtnPFELRlML5S5y5GYtTTMirFaLsYs2Y6AOgwrMjo=; b=SnmjTOF/ywRvZggj3INJ1+7WxznO1d0jIS4hbSo4Gr31QvO4mQ482cssr52MUajOqM GBQgdYRpsfG0IlMtowPxdLqGjEEO8xhMqeeDNO/kiZ4eKYz220gfbe4evoGfOPyUDkLt FRAySanoD2Dr9PHc4QN3ewFwaTcvHhkHSF/5WQ2Zs8QwgrX7K82OPlNfCCce+haoo6Mf HqubwZiq/0oJKOt8Ycv0/5qXYf/S4KIi6eELAD11fHm6k37FD2T+NDElQUxWAnd/zHkA XX4ocnfVUUIAhtUOFtI4Lwdk/Y4tfTRNubalqrTYA0rx4HPrbkt+BCjrfajG8bjqm1ZS r+Xg== X-Gm-Message-State: AG10YOTqR7Z5gNPytAT6AOWo3EKBkP9k6h680Ha8iNkJBVKgkWPJSzzuRE6pJRwsg7u6POuv1bGdyXmuPIxyC9t/ X-Received: by 10.129.145.82 with SMTP id i79mr18175905ywg.345.1455051690420; Tue, 09 Feb 2016 13:01:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Tue, 09 Feb 2016 21:01:20 +0000 Message-ID: To: "Douglas Gash (dcmgash)" , "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c093a3e235e64052b5c9f77 Archived-At: Cc: Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ New Version with AI extensions for playing Go. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 21:01:33 -0000 --94eb2c093a3e235e64052b5c9f77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Feb 7, 2016 at 1:47 PM Douglas Gash (dcmgash) wrote: > =C5=A0 Apologies, just an attention grabbing headline. No specific AI sup= port > has been added to T+ protocol to help play go, ... but, some AI support may have been added for other purposes -- and the only way you'll know for sure is if you go read the draft. > but the new version has > been uploaded with corrections after first round of comments. TACACS+ > still restricted to plain AAA at this time! > > The author collective would be grateful for any further feedback. > As would the chairs... and I'm assuming any security conscious network engineer. Please review and provide feedback... W > > Many thanks! > > On 16/12/2015 13:34, "OPSAWG on behalf of opsawg-request@ietf.org" > wrote: > > >Send OPSAWG mailing list submissions to > > opsawg@ietf.org > > > >To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/opsawg > >or, via email, send a message with subject or body 'help' to > > opsawg-request@ietf.org > > > >You can reach the person managing the list at > > opsawg-owner@ietf.org > > > >When replying, please edit your Subject line so it is more specific > >than "Re: Contents of OPSAWG digest..." > > > > > >Today's Topics: > > > > 1. I-D Action: draft-ietf-opsawg-tacacs-00.txt > > (internet-drafts@ietf.org) > > > > > >---------------------------------------------------------------------- > > > >Message: 1 > >Date: Wed, 16 Dec 2015 05:34:08 -0800 > >From: internet-drafts@ietf.org > >To: > >Cc: opsawg@ietf.org > >Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-00.txt > >Message-ID: <20151216133408.20608.13192.idtracker@ietfa.amsl.com> > >Content-Type: text/plain; charset=3D"utf-8" > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Operations and Management Area Working > >Group Working Group of the IETF. > > > > Title : The TACACS+ Protocol > > Authors : Thorsten Dahm > > Andrej Ota > > Douglas C. Medway Gash > > David Carrel > > Lol Grant > > Filename : draft-ietf-opsawg-tacacs-00.txt > > Pages : 36 > > Date : 2015-12-16 > > > >Abstract: > > TACACS+ provides access control for routers, network access servers > > and other networked computing devices via one or more centralized > > servers. TACACS+ provides separate authentication, authorization and > > accounting services. This document describes the protocol that is > > used by TACACS+. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ > > > >There's also a htmlized version available at: > >https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-00 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > > > > > >------------------------------ > > > >Subject: Digest Footer > > > >_______________________________________________ > >OPSAWG mailing list > >OPSAWG@ietf.org > >https://www.ietf.org/mailman/listinfo/opsawg > > > > > >------------------------------ > > > >End of OPSAWG Digest, Vol 103, Issue 11 > >*************************************** > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --94eb2c093a3e235e64052b5c9f77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun= , Feb 7, 2016 at 1:47 PM Douglas Gash (dcmgash) <dcmgash@cisco.com> wrote:
=C5=A0 Apologies, just an attention grabbing headline. No spe= cific AI support
has been added to T+ protocol to help play go,

=
... but, some AI support may have been added for other purposes -- and= the only way you'll know for sure is if you go read the draft.

=C2=A0
but the = new version has
been uploaded with corrections after first round of comments. TACACS+
still restricted to plain AAA at this time!

The author collective would be grateful for any further feedback.

As would the chairs... and I'm assuming any = security conscious network engineer.
Please review and provide fe= edback...

W
=C2=A0

Many thanks!

On 16/12/2015 13:34, "OPSAWG on behalf of opsawg-request@ietf.org"
<opsawg-bou= nces@ietf.org on behalf of opsawg-request@ietf.org> wrote:

>Send OPSAWG mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0opsawg@ietf.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mail= man/listinfo/opsawg
>or, via email, send a message with subject or body 'help' to >=C2=A0 =C2=A0 =C2=A0 =C2=A0opsawg-request@ietf.org
>
>You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0opsawg-owner@ietf.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of OPSAWG digest..."
>
>
>Today's Topics:
>
>=C2=A0 =C2=A01.=C2=A0 I-D Action: draft-ietf-opsawg-tacacs-00.txt
>=C2=A0 =C2=A0 =C2=A0 (internet-drafts@ietf.org)
>
>
>----------------------------------------------------------------------<= br> >
>Message: 1
>Date: Wed, 16 Dec 2015 05:34:08 -0800
>From: int= ernet-drafts@ietf.org
>To: <i-d-= announce@ietf.org>
>Cc: opsawg@ietf.or= g
>Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-00.txt
>Message-ID: <20151216133408.20608.13192.idtracker@ietf= a.amsl.com>
>Content-Type: text/plain; charset=3D"utf-8"
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Operations and Management Area Workin= g
>Group Working Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: The TACACS+ Protocol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Thorsten Dahm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Andrej Ota
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Douglas C. Medway Gash
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 David Carrel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Lol Grant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-opsawg-tacacs-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 36
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-12-16
>
>Abstract:
>=C2=A0 =C2=A0TACACS+ provides access control for routers, network acces= s servers
>=C2=A0 =C2=A0and other networked computing devices via one or more cent= ralized
>=C2=A0 =C2=A0servers.=C2=A0 TACACS+ provides separate authentication, a= uthorization and
>=C2=A0 =C2=A0accounting services.=C2=A0 This document describes the pro= tocol that is
>=C2=A0 =C2=A0used by TACACS+.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft= -ietf-opsawg-tacacs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-op= sawg-tacacs-00
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org. >
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>OPSAWG mailing list
>OPSAWG@ietf.org
>https://www.ietf.org/mailman/listinfo/opsawg
>
>
>------------------------------
>
>End of OPSAWG Digest, Vol 103, Issue 11
>***************************************

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
--94eb2c093a3e235e64052b5c9f77-- From nobody Wed Feb 10 08:31:58 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 617AD1B2C7B; Wed, 10 Feb 2016 08:31:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160210163156.26461.33487.idtracker@ietfa.amsl.com> Date: Wed, 10 Feb 2016 08:31:56 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org Subject: [OPSAWG] opsawg - New Meeting Session Request for IETF 95 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 16:31:56 -0000 A new meeting session request has just been submitted by Warren Kumari, a Chair of the opsawg working group. --------------------------------------------------------- Working Group Name: Operations and Management Area Working Group Area Name: Operations and Management Area Session Requester: Warren Kumari Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: capport dane dprive Second Priority: dnsop v6ops Special Requests: PLEASE NOTE: Combined OpsAWG / OpsAREA. Feel free to merge / cancel / whatever. --------------------------------------------------------- From nobody Wed Feb 10 12:20:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E00C1AD0A7 for ; Wed, 10 Feb 2016 12:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 g8w_Ksf3_ObE for ; Wed, 10 Feb 2016 12:20:02 -0800 (PST) Received: from atl4mhob20.myregisteredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) by ietfa.amsl.com (Postfix) with ESMTP id EA7F71ACEDE for ; Wed, 10 Feb 2016 12:20:01 -0800 (PST) Received: from mailpod1.hostingplatform.com (atl4obmail02pod1.mgt.hosting.qts.netsol.com [10.30.71.114]) by atl4mhob20.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1AKJxRW009423 for ; Wed, 10 Feb 2016 15:19:59 -0500 Received: (qmail 30432 invoked by uid 0); 10 Feb 2016 20:19:59 -0000 X-TCPREMOTEIP: 74.125.82.43 X-Authenticated-UID: rob@tacacs.net Received: from unknown (HELO mail-wm0-f43.google.com) (rob@tacacs.net@74.125.82.43) by 0 with ESMTPA; 10 Feb 2016 20:19:59 -0000 Received: by mail-wm0-f43.google.com with SMTP id g62so42636023wme.0 for ; Wed, 10 Feb 2016 12:19:59 -0800 (PST) X-Gm-Message-State: AG10YOQ2RRGMk0rZI4mK6wdZ3pA/H1o8OQxxQVkLjz4CcsKSUBNkvBZKeMRACp1Hq1KH5Jl7Y/QjODNuPYG0qQ== MIME-Version: 1.0 X-Received: by 10.28.137.213 with SMTP id l204mr13821138wmd.100.1455135598238; Wed, 10 Feb 2016 12:19:58 -0800 (PST) Received: by 10.194.121.166 with HTTP; Wed, 10 Feb 2016 12:19:58 -0800 (PST) Date: Wed, 10 Feb 2016 12:19:58 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Rob To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=001a1144516a6ee574052b7028b7 Archived-At: Subject: [OPSAWG] draft-dahm-opsawg-tacacs-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:20:03 -0000 --001a1144516a6ee574052b7028b7 Content-Type: text/plain; charset=UTF-8 We at TACACS.net have reviewed the draft for TACACS+ improvements with TLS and we support the initiative. We look forward to this being accepted and implemented as a standard. --- Rob Lemaster, CISSP Sr.Product Manager TACACS.net --001a1144516a6ee574052b7028b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We at TACACS.net have rev= iewed the draft for TACACS+ improvements with TLS and we support the initia= tive.=C2=A0
We look forward= to this being accepted and implemented as a standard.=C2=A0

<= span style=3D"font-size:12.8px">---
Rob Lemaster, CISSP
Sr.Product Manager
= TACACS.net
--001a1144516a6ee574052b7028b7-- From nobody Wed Feb 10 12:31:55 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21AC1B2F85 for ; Wed, 10 Feb 2016 12:31:52 -0800 (PST) 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] autolearn=ham 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 eJS3U58MzYXg for ; Wed, 10 Feb 2016 12:31:50 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id B26861B2F84 for ; Wed, 10 Feb 2016 12:31:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 71562D0F; Wed, 10 Feb 2016 20:31:49 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwiRFphg2k8v; Wed, 10 Feb 2016 20:31:49 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id A316DB63; Wed, 10 Feb 2016 20:31:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Wed, 10 Feb 2016 15:31:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ New Version with AI extensions for playing Go. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:31:52 -0000 On Feb 9, 2016, at 4:01 PM, Warren Kumari wrote: > As would the chairs... and I'm assuming any security conscious network = engineer. > Please review and provide feedback... I have a number of comments. The main question is how, exactly this = document became adopted as a WG document. I've gone through my inbox = and the web archive, and I don't see any call for WG adoption. Just a = notice that the document was accepted as a WG document. I have *major* problems with the document as an IETF standard. We = already have two AAA IETF protocols. Standardizing a third one is, in = my opinion, entirely outside of the purview of OPSAWG. There are a host of procedural problems with how the document was = adopted. I suggest that the document be withdrawn, and re-submitted as = an individual draft. Alan DeKok. From nobody Wed Feb 10 12:40:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543CA1B2FA5 for ; Wed, 10 Feb 2016 12:40:20 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 aFxO0M8StjKE for ; Wed, 10 Feb 2016 12:40:18 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 722DE1B2F9F for ; Wed, 10 Feb 2016 12:40:18 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1AKdp28023597; Wed, 10 Feb 2016 15:39:51 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Alan DeKok , Warren Kumari Thread-Topic: [OPSAWG] TACACS+ New Version with AI extensions for playing Go. Thread-Index: AQHRYfEeqb8PHlengEOjh7oVXWZ0U58kifwAgAGKE4D//65/AA== Date: Wed, 10 Feb 2016 20:40:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3537963604_37432949" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-10_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602100380 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ New Version with AI extensions for playing Go. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:40:20 -0000 --B_3537963604_37432949 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 2/10/16, 15:31 , "OPSAWG on behalf of Alan DeKok" wrote: >On Feb 9, 2016, at 4:01 PM, Warren Kumari wrote: >> As would the chairs... and I'm assuming any security conscious network >>engineer. >> Please review and provide feedback... > >... > I have *major* problems with the document as an IETF standard. We >already have two AAA IETF protocols. Standardizing a third one is, in my >opinion, entirely outside of the purview of OPSAWG. You have a point - but TACACS is a reality that isn=E2=80=99t going away. Thus specifying how to use it/interoperate with it seems useful. >I suggest that the document be withdrawn, and re-submitted as an >individual draft. No strong opinion here, but I=E2=80=99m not quite convinced by your reasoning. --B_3537963604_37432949 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQwhYDU0h3pqv8n6n6CcuGxqqnF8WbdCb6vJweSUxM3UVYqrmnJfSfb4EO+ZkPlOfduMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDIxMDIwNDAwNFow DQYJKoZIhvcNAQEBBQAEggEAkF7Ru6EXzwFENnNA1hb7bx7jzdHe7mObKHKhDKIs6Z7xVfTc 4itRv5uKnQ7Y/LfK9v0LWQ98sSW17nwJCy5HmwdmkcbWKbPgntCcmJKCkkPxG8gIM0xzW/FC kfFi3sS5zquWuFr2cFREWSPHhgEm9DuTq104HBpU4JI8UsKRQYSEiBCV+uj7rifqwrQBZBI/ f7PNga1082J/ceJ33aijuBM8nFYZDFNbycBwaJVu2AcTZDZD07p5JgFJm4ltS8AdCvEylb2X 4G7rvFoOpLzjsgx012rNcU8KKAS7hJxhHepyw7V3DLhOb9znNnCmqlOhBfCJEgNfNkaQsYNK GaHKSA== --B_3537963604_37432949-- From nobody Wed Feb 10 12:51:17 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A2F1AD079 for ; Wed, 10 Feb 2016 12:51:16 -0800 (PST) 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] autolearn=ham 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 rd_RJVhWndec for ; Wed, 10 Feb 2016 12:51:13 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 820181AD09A for ; Wed, 10 Feb 2016 12:51:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D79E5D9A; Wed, 10 Feb 2016 20:51:12 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_qWKvrQEV7l; Wed, 10 Feb 2016 20:51:12 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 04104B63; Wed, 10 Feb 2016 20:51:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Wed, 10 Feb 2016 15:51:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1B6433C3-8F88-4832-B007-0A544DD5A315@deployingradius.com> References: To: "Blumenthal, Uri - 0553 - MITLL" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Douglas Gash \(dcmgash\)" , Andrej Ota , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ New Version with AI extensions for playing Go. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:51:16 -0000 On Feb 10, 2016, at 3:40 PM, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > You have a point - but TACACS is a reality that isn=E2=80=99t going = away. Thus > specifying how to use it/interoperate with it seems useful. Then it should be published as an individual submission, as an = informational document. I submit that we should be parsimonious with the IETF "stamp of = approval". Publishing a proprietary vendor protocol as an *IETF = standard protocol* is a huge problem. Cisco had 18 years to submit the document for consideration by the = IETF. They decided not to. That's fine, it's their decision. This isn't publishing extensions to existing documents, where the WG = has been disbanded. This isn't publishing documents which are relevant = to multiple working groups, but don't really belong in any particular = one. This is creating an entirely new standard protocol, which is in direct = competition to existing, and active, working groups. Worse, it's a = protocol which the vendor refused to document for 18 years. Now that they're getting bit by interoperability issues, they're = seeking the IETF stamp of approval. It's a complete end-run around the = entire IETF process. Alan DeKok. From nobody Wed Feb 10 12:51:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799601AD09A for ; Wed, 10 Feb 2016 12:51:45 -0800 (PST) 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] autolearn=ham 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 ypeqX2fhcOPC for ; Wed, 10 Feb 2016 12:51:44 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 011581AD084 for ; Wed, 10 Feb 2016 12:51:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 5D756D0F; Wed, 10 Feb 2016 20:51:43 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCD3WjwxxB-W; Wed, 10 Feb 2016 20:51:43 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 5EBD6B63; Wed, 10 Feb 2016 20:51:42 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=us-ascii From: Alan DeKok In-Reply-To: Date: Wed, 10 Feb 2016 15:51:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:51:45 -0000 On Feb 10, 2016, at 3:31 PM, Alan DeKok = wrote: > There are a host of procedural problems with how the document was = adopted. I suggest that the document be withdrawn, and re-submitted as = an individual draft. To be clear: 1. the document never had a WG call for adoption as required in Section = 4.2.1 of RFC 6174 2. the charter has not been updated to reflect this work. 3. the charter says: "All new work items and rechartering proposals will be brought for = approval with the IESG." 4. I can find no record of this approval taking place. If it had taken = place, the charter would have been updated. 5. I had objected to this in person at the OPSAWG meeting in IETF 94. = However, the web site shows no minutes from that meeting: https://tools.ietf.org/wg/opsawg/minutes 6. I believe that this document is an incorrect technical choice as per = section 6.5.1 of RFC 2016. As such, I ask the chairs to withdraw the document as a WG document = until such time as the procedural issues above have been addressed. Alan DeKok. From nobody Wed Feb 10 12:57:51 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83701B2FCF for ; Wed, 10 Feb 2016 12:57:50 -0800 (PST) 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] autolearn=ham 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 CYPFk8BLEqkD for ; Wed, 10 Feb 2016 12:57:48 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id D676F1AD0A0 for ; Wed, 10 Feb 2016 12:57:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 3D054D0F; Wed, 10 Feb 2016 20:57:47 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrAvjJVLfDwy; Wed, 10 Feb 2016 20:57:47 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 3830ACAE; Wed, 10 Feb 2016 20:57:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Wed, 10 Feb 2016 15:57:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> References: To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:57:50 -0000 And some more notes 7. The charter says: "The Operations and Management Area receives occasional proposals for=20 the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. " 8. This document is competes directly with two existing working groups, = RADEXT and DIME, to create a third AAA protocol. 9. As such, this document should be explicitly outside of the scope of = the OPSAWG. > On Feb 10, 2016, at 3:51 PM, Alan DeKok = wrote: >=20 > On Feb 10, 2016, at 3:31 PM, Alan DeKok = wrote: >> There are a host of procedural problems with how the document was = adopted. I suggest that the document be withdrawn, and re-submitted as = an individual draft. >=20 > To be clear: >=20 > 1. the document never had a WG call for adoption as required in = Section 4.2.1 of RFC 6174 >=20 > 2. the charter has not been updated to reflect this work. >=20 > 3. the charter says: >=20 > "All new work items and rechartering proposals will be brought for = approval with the IESG." >=20 > 4. I can find no record of this approval taking place. If it had = taken place, the charter would have been updated. >=20 > 5. I had objected to this in person at the OPSAWG meeting in IETF 94. = However, the web site shows no minutes from that meeting: >=20 > https://tools.ietf.org/wg/opsawg/minutes >=20 > 6. I believe that this document is an incorrect technical choice as = per section 6.5.1 of RFC 2016. >=20 > As such, I ask the chairs to withdraw the document as a WG document = until such time as the procedural issues above have been addressed. >=20 > Alan DeKok. >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Feb 10 14:09:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760541B3095 for ; Wed, 10 Feb 2016 14:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 vBNgrxRMK6El for ; Wed, 10 Feb 2016 14:09:45 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901191B308D for ; Wed, 10 Feb 2016 14:09:45 -0800 (PST) Received: from dhcp-220-120.meetings.nanog.org (dhcp-220-120.meetings.nanog.org [199.187.220.120]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1AM9a8G092905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2016 22:09:37 GMT (envelope-from joelja@bogus.com) To: Alan DeKok , Warren Kumari References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56BBB51F.4080303@bogus.com> Date: Wed, 10 Feb 2016 14:09:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vP3jjRC7NU112WncsvJ3HmXUVSv0W29FJ" Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 22:09:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vP3jjRC7NU112WncsvJ3HmXUVSv0W29FJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/10/16 12:57 PM, Alan DeKok wrote: > And some more notes >=20 > 7. The charter says: >=20 > "The Operations and Management Area receives occasional proposals for=20 > the development and publication of RFCs dealing with operational and > management topics that are not in scope of an existing working group > and do not justify the formation of a new working group. " >=20 > 8. This document is competes directly with two existing working groups,= RADEXT and DIME, to create a third AAA protocol. it's pretty hard to argue that we've created something that's been around since 1993 I;m sure we had this dicussion before circa 1996, I don't remember it thankfully. I dare say it is inappropriate for dime or radext to undertake work on tacacs+ under their current charters. it is entirely unclear how this would interfere with the activities of either... > 9. As such, this document should be explicitly outside of the scope of= the OPSAWG. >=20 >> On Feb 10, 2016, at 3:51 PM, Alan DeKok wr= ote: >> >> On Feb 10, 2016, at 3:31 PM, Alan DeKok wr= ote: >>> There are a host of procedural problems with how the document was ado= pted. I suggest that the document be withdrawn, and re-submitted as an i= ndividual draft. >> >> To be clear: >> >> 1. the document never had a WG call for adoption as required in Sectio= n 4.2.1 of RFC 6174 >> >> 2. the charter has not been updated to reflect this work. >> >> 3. the charter says: >> >> "All new work items and rechartering proposals will be brought for a= pproval with the IESG." >> >> 4. I can find no record of this approval taking place. If it had take= n place, the charter would have been updated. >> >> 5. I had objected to this in person at the OPSAWG meeting in IETF 94. = However, the web site shows no minutes from that meeting: >> >> https://tools.ietf.org/wg/opsawg/minutes >> >> 6. I believe that this document is an incorrect technical choice as pe= r section 6.5.1 of RFC 2016. >> >> As such, I ask the chairs to withdraw the document as a WG document u= ntil such time as the procedural issues above have been addressed. >> >> Alan DeKok. >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 >=20 --vP3jjRC7NU112WncsvJ3HmXUVSv0W29FJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAla7tR8ACgkQ8AA1q7Z/VrLYXQCfRXwvCqOiqRZsbjm08u5JPfJp QpoAnif1ZlVqrETkWYspk+WimlkhdEfl =dU32 -----END PGP SIGNATURE----- --vP3jjRC7NU112WncsvJ3HmXUVSv0W29FJ-- From nobody Wed Feb 10 14:17:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE721B30AF for ; Wed, 10 Feb 2016 14:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Mt71RsjCgKgg for ; Wed, 10 Feb 2016 14:17:18 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590861B30B1 for ; Wed, 10 Feb 2016 14:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3404; q=dns/txt; s=iport; t=1455142638; x=1456352238; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vMCVirdkkg6/xOgq4/9no1oMEy7I+9y34RhEVR6iOl0=; b=cnni3sASNwNFRoKrebqMqx9crXU7j+/zd1ipXGb5/qL1H8bSWvwaxnUQ Dh8T/0ueEY3Xc38fZ1S+0vqA8ItwUAX8p5+jJC/MWcKRVE9gLRDpnJM2m I1GN5i78VUOURpsj0M1qee6tDnFqcJnPivEm8OO4GKOxDJ/uY304G5b30 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQD3tbtW/5NdJa1egzpSbQaIVrEjA?= =?us-ascii?q?Q2BZhcKhSJKAoE5OBQBAQEBAQEBgQqEQgEBAwEBAQEaSAkLBQsCAQhGJwslAgQ?= =?us-ascii?q?BDQWIEwgOwEoBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIpJiGwFjV+FD4QKAYVLi?= =?us-ascii?q?AWOdI4+AR4BAUKDZGqHV3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,427,1449532800"; d="scan'208";a="237267931" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2016 22:17:17 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u1AMHHpd032181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2016 22:17:17 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 10 Feb 2016 16:17:16 -0600 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.1104.009; Wed, 10 Feb 2016 16:17:16 -0600 From: "Douglas Gash (dcmgash)" To: Alan DeKok , Warren Kumari Thread-Topic: [OPSAWG] Procedural issues with the TACACS+ document Thread-Index: AQHRZETbgK9sXm7A1E6w0iosJTGYMp8mJ2sAgAAWNAA= Date: Wed, 10 Feb 2016 22:17:16 +0000 Message-ID: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> In-Reply-To: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.7] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2A4BFDC23A2E864B8E96581431D41E6D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 22:17:20 -0000 Hi Alan, TACACS+ cannot compete with RADIUS in the area RADIUS is strong: for Network access. The authors have no interest in trying to do so. TACACS+ in 2016 has quite a different use case: for device administration, where it is widely deployed by multiple vendors. Its application for device administration is why the authors approached opsawg. The authors believe that it has a place for device administration in the datacenter and would seek to get the TACACS+ protocol definition documented and straightened out for this purpose, and registered with IETF. I understand that you hold different view in this matter. I=B9m sure that the IETF checks and balances will resolve the conflict for the best interests of the whole, and I=B9ll happily follow their decision. I don=B9t think there was any conspiracy by Cisco not to pursue the publication before. Cisco initiated the process to get the protocol approved by IETF in 1996/1997 (https://tools.ietf.org/html/draft-grant-tacacs-02), but the original authors pursued other endeavours, and no one followed up until now, with a process that actually started up outside Cisco. Regarding procedural matters, if we have missed any steps, that is my bad and I will consult with those more versed in procedure to rectify that. Best Regards, Doug. On 10/02/2016 20:57, "Alan DeKok" wrote: > And some more notes > >7. The charter says: > >"The Operations and Management Area receives occasional proposals for >the development and publication of RFCs dealing with operational and >management topics that are not in scope of an existing working group >and do not justify the formation of a new working group. " > >8. This document is competes directly with two existing working groups, >RADEXT and DIME, to create a third AAA protocol. > >9. As such, this document should be explicitly outside of the scope of >the OPSAWG. > >> On Feb 10, 2016, at 3:51 PM, Alan DeKok >>wrote: >>=20 >> On Feb 10, 2016, at 3:31 PM, Alan DeKok >>wrote: >>> There are a host of procedural problems with how the document was >>>adopted. I suggest that the document be withdrawn, and re-submitted as >>>an individual draft. >>=20 >> To be clear: >>=20 >> 1. the document never had a WG call for adoption as required in Section >>4.2.1 of RFC 6174 >>=20 >> 2. the charter has not been updated to reflect this work. >>=20 >> 3. the charter says: >>=20 >> "All new work items and rechartering proposals will be brought for >>approval with the IESG." >>=20 >> 4. I can find no record of this approval taking place. If it had taken >>place, the charter would have been updated. >>=20 >> 5. I had objected to this in person at the OPSAWG meeting in IETF 94. >>However, the web site shows no minutes from that meeting: >>=20 >> https://tools.ietf.org/wg/opsawg/minutes >>=20 >> 6. I believe that this document is an incorrect technical choice as per >>section 6.5.1 of RFC 2016. >>=20 >> As such, I ask the chairs to withdraw the document as a WG document >>until such time as the procedural issues above have been addressed. >>=20 >> Alan DeKok. >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > From nobody Wed Feb 10 14:32:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0271D1B30CB for ; Wed, 10 Feb 2016 14:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 SQcl3JmmSxuX for ; Wed, 10 Feb 2016 14:32:42 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076831B30BA for ; Wed, 10 Feb 2016 14:32:41 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 9so37315362iom.1 for ; Wed, 10 Feb 2016 14:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=toPFej00A6F0MJjKFa+qSHc3aXLmdoTs/4c82WHIXEc=; b=OrI2qpJnXptPd+NDYzJDmEkXANSA1qj9vxWn+HZQwiTXBq2MqkfZ/ZKbB3hNoTPyv7 8a7cCwFSPt/ZJaqmZMbqScaKw4ebH18+CokLdLs26UVedLmZLuP34jnmUBY1c3nOd5NS P1xo0VUJZVJA+GUywb/E5u++5oGFOlD4OAwL1EduyV0Pcp4bvN7hfpFtPgVSoAm75hDv 6mS7S6/zJ6gbRn2YKmsLZMY0BYxWqGADhVJhWHuRFZboEqwYeqxpcuTe0CB3+6KrQW2Q AEComEsDTi3enF3DGbUm1tN6qsqqprf424i8v1gV1iPCj6g+pkwIqZ1W/SEu0jLiSyP7 sOyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=toPFej00A6F0MJjKFa+qSHc3aXLmdoTs/4c82WHIXEc=; b=WyTvUXZEf+trNOplAj21WbAdhb0QMgc0+LyK7p9/2ovxXBgK7rkvEYceVj/Qo5Tz80 AVkshzMe9RIqODmMiPAVfHpFwPMneaFDaRawab7DjuzVNsBBRj/sOq4fZOyBmVdMO8yi rIcRokqzsJZH1u+Nfhtml9EZeBRqSPCtjDiZ/P1QAQL6f0uj/EHHKuDQdz3fjCt+tOYF JfXbZsQoaJmB2mB3+4UXvJS+SMb4WfxgdvlLGTLd2umli+x+ENNoQUjcqJEQAFT2PWu9 T0jeSNjE8cOaS9Oq8QqDKKDjZkcbrT5690RnUBWlTjAb95fxCDRCF1uKPrRhLdqrNSOM s9qQ== X-Gm-Message-State: AG10YOS3chSn85vkMCgctC6OsipHo9XTOs9gllNQF8uh3hgZ982DFIaK25GWgA5NFbk4dfESEzG/7cnPbrkf3OBP MIME-Version: 1.0 X-Received: by 10.107.153.11 with SMTP id b11mr8842560ioe.113.1455143561042; Wed, 10 Feb 2016 14:32:41 -0800 (PST) Received: by 10.64.1.112 with HTTP; Wed, 10 Feb 2016 14:32:40 -0800 (PST) In-Reply-To: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> Date: Wed, 10 Feb 2016 22:32:40 +0000 Message-ID: From: Andrej Ota To: Alan DeKok Content-Type: multipart/alternative; boundary=001a1140faa20dfd63052b720358 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 22:32:46 -0000 --001a1140faa20dfd63052b720358 Content-Type: text/plain; charset=UTF-8 I cannot comment on procedural items. However, on the topic of actual draft content, item no. 8 contains an error. Please see the in-line comments. On Wed, Feb 10, 2016 at 8:57 PM, Alan DeKok wrote: > And some more notes > > 7. The charter says: > > "The Operations and Management Area receives occasional proposals for > the development and publication of RFCs dealing with operational and > management topics that are not in scope of an existing working group > and do not justify the formation of a new working group. " > > 8. This document is competes directly with two existing working groups, > RADEXT and DIME, to create a third AAA protocol. > On the topic of "a third AAA protocol": Current TACACS+ draft work is continuation of original work which stalled in 1997. This predates first DIAMETER draft and was created around the same time as the first RADIUS RFC. TACACS+, as specified in the expired draft[1], also has a wide deployment base, is actively used, new vendors and new devices are appearing on the market implementing what is called "TACACS+" with implementations that conform to the original and expired TACACS+ draft. Stating this is "a third AAA protocol" is a false statement and one I find to be intellectually dishonest. At worst one could call it the 2nd AAA protocol. On the topic of "competes directly with ...": The goals and aims are completely different. This is not a new protocol, it's almost 20 years old (00 draft was published in October 1996). It's not a new development trying to compete with anything or anyone. Draft is attempting to standardise the current ground truth while providing a single relevant addition to the original draft, which the use of TLS "tunnel". > 9. As such, this document should be explicitly outside of the scope of > the OPSAWG. > In connection with the quote from charter under item no. 7, I claim the following statements to be true: - Ground truth is that TACACS+ is widely deployed protocol for device management AAA. - Ground truth is that new device vendors and new devices are entering market which are implementing TACACS+. The protocol is not dying out. - Ground truth is that DIAMETER has no penetration in the area of network device management AAA. - Ground truth is that TACACS+ implementations are based on an IETF draft which expired in 1997. Combination of these statements, which I claim to be all true, is causing current and relevant operational issues for network operators. As such I think this draft is well within the scope of the OPSAWG. I believe the community at large will benefit if it will be maintain it's current strict and narrow focus and ultimately get approved as an RFC. If it turns out that the protocol which already has a widespread adoption and had it for more than a decade, can actually be beaten by other alternatives, may it happen on the basis of actual operational merit and not based on attempt to disqualify TACACS+ as an "entry too late" item in WG queue. It is not too late, it is an active protocol, it is not standardised, lack of a standard is causing issues by itself. This last item I believe can and should be addressed. [1] https://tools.ietf.org/html/draft-grant-tacacs-02 > > > On Feb 10, 2016, at 3:51 PM, Alan DeKok > wrote: > > > > On Feb 10, 2016, at 3:31 PM, Alan DeKok > wrote: > >> There are a host of procedural problems with how the document was > adopted. I suggest that the document be withdrawn, and re-submitted as an > individual draft. > > > > To be clear: > > > > 1. the document never had a WG call for adoption as required in Section > 4.2.1 of RFC 6174 > > > > 2. the charter has not been updated to reflect this work. > > > > 3. the charter says: > > > > "All new work items and rechartering proposals will be brought for > approval with the IESG." > > > > 4. I can find no record of this approval taking place. If it had taken > place, the charter would have been updated. > > > > 5. I had objected to this in person at the OPSAWG meeting in IETF 94. > However, the web site shows no minutes from that meeting: > > > > https://tools.ietf.org/wg/opsawg/minutes > > > > 6. I believe that this document is an incorrect technical choice as per > section 6.5.1 of RFC 2016. > > > > As such, I ask the chairs to withdraw the document as a WG document > until such time as the procedural issues above have been addressed. > > > > Alan DeKok. > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > -- -- Andrej Ota Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland Registered in Dublin, Ireland - Registration # 368047 --001a1140faa20dfd63052b720358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I cannot comment on procedural items. However, on the topi= c of actual draft content, item no. 8 contains an error. Please see the in-= line comments.


On Wed, Feb 10, 2016 at 8:57 PM, Alan DeKok <aland@deploying= radius.com> wrote:
=C2=A0 And some more n= otes

7. The charter says:

"The Operations and Management Area receives occasional proposals for<= br> the development and publication of RFCs dealing with operational and
management topics that are not in scope of an existing working group
and do not justify the formation of a new working group. "

8. This document is competes directly with two existing working groups, RAD= EXT and DIME, to create a third AAA protocol.

On the topic of "a third AAA protocol":
Current = TACACS+ draft work is continuation of original work which stalled in 1997. = This predates first DIAMETER draft and was created around the same time as = the first RADIUS RFC. TACACS+, as specified in the expired draft[1], also h= as a wide deployment base, is actively used, new vendors and new devices ar= e appearing on the market implementing what is called "TACACS+" w= ith implementations that conform to the original and expired TACACS+ draft.= =C2=A0

Stating this is "a third AAA protocol&= quot; is a false statement and one I find to be intellectually dishonest. A= t worst one could call it the 2nd AAA protocol.

On= the topic of "competes directly with ...":
The goals a= nd aims are completely different. This is not a new protocol, it's almo= st 20 years old (00 draft was published in October 1996). It's not a ne= w development trying to compete with anything or anyone. Draft is attemptin= g to standardise the current ground truth while providing a single relevant= addition to the original draft, which the use of TLS "tunnel".

=C2=A0
9.=C2=A0 As such, = this document should be explicitly outside of the scope of the OPSAWG.
<= /blockquote>

In connection with the quote from char= ter under item no. 7, I claim the following statements to be true:
=C2=A0- Ground truth is that TACACS+ is widely deployed protocol for devi= ce management AAA.
=C2=A0- Ground truth is that new device = vendors and new devices are entering market which are implementing TACACS+.= The protocol is not dying out.
=C2=A0- Ground truth is that DIAM= ETER has no penetration in the area of network device management AAA.
=
=C2=A0- Ground truth is that TACACS+ implementations are based on an I= ETF draft which expired in 1997.

Combination of th= ese statements, which I claim to be all true, is causing current and releva= nt operational issues for network operators.

As su= ch I think this draft is well within the scope of the OPSAWG. I believe the= community at large will benefit if it will be maintain it's current st= rict and narrow focus and ultimately get approved as an RFC. If it turns ou= t that the protocol which already has a widespread adoption and had it for = more than a decade, can actually be beaten by other alternatives, may it ha= ppen on the basis of actual operational merit and not based on attempt to d= isqualify TACACS+ as an "entry too late" item in WG queue. It is = not too late, it is an active protocol, it is not standardised, lack of a s= tandard is causing issues by itself. This last item I believe can and shoul= d be addressed.

=C2=A0

> On Feb 10, 2016, at 3:51 PM, Alan DeKok <aland@deployingradius.com> wrote:
>
> On Feb 10, 2016, at 3:31 PM, Alan DeKok <aland@deployingradius.com> wrote:
>> There are a host of procedural problems with how the document was = adopted.=C2=A0 I suggest that the document be withdrawn, and re-submitted a= s an individual draft.
>
>=C2=A0 To be clear:
>
> 1. the document never had a WG call for adoption as required in Sectio= n 4.2.1 of RFC 6174
>
> 2. the charter has not been updated to reflect this work.
>
> 3. the charter says:
>
>=C2=A0 "All new work items and rechartering proposals=C2=A0 will b= e brought for approval with the IESG."
>
> 4. I can find no record of this approval taking place.=C2=A0 If it had= taken place, the charter would have been updated.
>
> 5. I had objected to this in person at the OPSAWG meeting in IETF 94.= =C2=A0 However, the web site shows no minutes from that meeting:
>
> https://tools.ietf.org/wg/opsawg/minutes
>
> 6. I believe that this document is an incorrect technical choice as pe= r section 6.5.1 of RFC 2016.
>
>=C2=A0 As such, I ask the chairs to withdraw the document as a WG docum= ent until such time as the procedural issues above have been addressed.
>
>=C2=A0 Alan DeKok.
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg



--
--
Andrej Ota

Google Ireland Ltd., Google Do= cks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland - =C2= =A0Registration # 368047
--001a1140faa20dfd63052b720358-- From nobody Wed Feb 10 14:35:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958541B30B6 for ; Wed, 10 Feb 2016 14:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 m5rrIIeY7WJy for ; Wed, 10 Feb 2016 14:35:14 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D24A1B30DD for ; Wed, 10 Feb 2016 14:35:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aTdLp-00045E-9b; Wed, 10 Feb 2016 22:35:09 +0000 Date: Wed, 10 Feb 2016 14:35:08 -0800 Message-ID: From: Randy Bush To: Alan DeKok In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "Douglas Gash \(dcmgash\)" , Andrej Ota , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ New Version with AI extensions for playing Go. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 22:35:19 -0000 > I have *major* problems with the document as an IETF standard. We > already have two AAA IETF protocols. Standardizing a third one is, in > my opinion, entirely outside of the purview of OPSAWG. after all, it's the one we actually use. so it has to be killed asap. randy From nobody Wed Feb 10 15:35:09 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA4B1A6FC2 for ; Wed, 10 Feb 2016 15:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7YuTMe_j9oq2 for ; Wed, 10 Feb 2016 15:35:04 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4B51A6FBF for ; Wed, 10 Feb 2016 15:35:04 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id l127so38501592iof.3 for ; Wed, 10 Feb 2016 15:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=83KhP/HSYh1EXZBs77g/VqFt4C0KK9v2D8hOqMxWamI=; b=KEXRlJgwq7vvNuFbHtmweZPfG+z6c1Rqqd+aivb3Dx1fETu3gVrID9+GK8oF/B0ZbK m0qA60y/Mb6QUpVNFqkSEMzsCUarQ/V4uw1w4YZc+WB4o/jojTPT6XjAtN33qbEjrHE2 vUuJ+tX4v4mBjlB3ARnEXCqUM6ftQHWVvRPcXd9l/xaJ6cS2B76H2lMbJvWqUNnYglC1 oyyXgu0DJiL1Lt/sXLfSbLYtAa1KBT3Wdguj1+tf1K77JYMZOEVvLH5JFI/FPD9UU+ad 733VD45bTwVozW1jd3k8RpXc0qDwsXGKQZnTDYURLAy6krZH00KuauQcy5+t3YIqpYon OFTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=83KhP/HSYh1EXZBs77g/VqFt4C0KK9v2D8hOqMxWamI=; b=eBVubqVxpiOnIwb64cZ9GWDaf7eKjDWNSSrmI/L0XDwzeTz5RG7OU8nnxdSY5w6JEF ZdwA2oQvygYu3FFWQVFFiJ/K5gDfP8oL7iy6hhZ9txSDmtvYMForSLZMnLWN4sw0QRGL lDyHuhOrbNu6pIeyt1wb8R/eRhmDnCYXBrTZoX7RoLJRbPNHymUZzqpHDVbKokrLR1Ph fWCF2qFKiw6goWbsppUnZ4D8A2VF4NO/qKFlH1pjYE9nmKLgHpULxffpSjax4pflrFV7 YbVy9PePWwga2jvEBFgmOHnGM2KeaX5UGrZJoXJo4/5QqSIuU4d6lqGVPdTljCyfE0Tu MsXA== X-Gm-Message-State: AG10YOTLnBg/oDBYoMTQO/lvSemjIz4+sWb3/IGLpCUXRI8BJLIl0mxsVFVeA6RJrxtr5A== X-Received: by 10.107.16.153 with SMTP id 25mr42578630ioq.100.1455147303611; Wed, 10 Feb 2016 15:35:03 -0800 (PST) Received: from [199.187.220.202] (dhcp-220-202.meetings.nanog.org. [199.187.220.202]) by smtp.gmail.com with ESMTPSA id h83sm1682671iod.4.2016.02.10.15.34.58 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 10 Feb 2016 15:35:02 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Wed, 10 Feb 2016 15:34:48 -0800 From: Edwin Mallette To: Alan DeKok , Warren Kumari Message-ID: Thread-Topic: [OPSAWG] Procedural issues with the TACACS+ document References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> In-Reply-To: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 23:35:06 -0000 Just a couple comments=8A 1) As one operator (of many, I am certain) that utilizes TACACS+ for AAA on every network device, I would certainly hate to see some procedural minutiae bog this effort down. 2) This draft is well written and adds a few welcome additional features. 3) Please don=B9t let any procedural issues (real or imagined) inhibit the completion of this good and much needed effort. Cheers! Ed On 2/10/16, 12:57 PM, "OPSAWG on behalf of Alan DeKok" wrote: > And some more notes > >7. The charter says: > >"The Operations and Management Area receives occasional proposals for >the development and publication of RFCs dealing with operational and >management topics that are not in scope of an existing working group >and do not justify the formation of a new working group. " > >8. This document is competes directly with two existing working groups, >RADEXT and DIME, to create a third AAA protocol. > >9. As such, this document should be explicitly outside of the scope of >the OPSAWG. > >> On Feb 10, 2016, at 3:51 PM, Alan DeKok >>wrote: >>=20 >> On Feb 10, 2016, at 3:31 PM, Alan DeKok >>wrote: >>> There are a host of procedural problems with how the document was >>>adopted. I suggest that the document be withdrawn, and re-submitted as >>>an individual draft. >>=20 >> To be clear: >>=20 >> 1. the document never had a WG call for adoption as required in Section >>4.2.1 of RFC 6174 >>=20 >> 2. the charter has not been updated to reflect this work. >>=20 >> 3. the charter says: >>=20 >> "All new work items and rechartering proposals will be brought for >>approval with the IESG." >>=20 >> 4. I can find no record of this approval taking place. If it had taken >>place, the charter would have been updated. >>=20 >> 5. I had objected to this in person at the OPSAWG meeting in IETF 94. >>However, the web site shows no minutes from that meeting: >>=20 >> https://tools.ietf.org/wg/opsawg/minutes >>=20 >> 6. I believe that this document is an incorrect technical choice as per >>section 6.5.1 of RFC 2016. >>=20 >> As such, I ask the chairs to withdraw the document as a WG document >>until such time as the procedural issues above have been addressed. >>=20 >> Alan DeKok. >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Feb 10 15:40:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F181A6FDA for ; Wed, 10 Feb 2016 15:40:46 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 WclfyroY7mOq for ; Wed, 10 Feb 2016 15:40:44 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5329C1A6FD7 for ; Wed, 10 Feb 2016 15:40:42 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1ANeHeJ038374; Wed, 10 Feb 2016 18:40:17 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Edwin Mallette , Alan DeKok , Warren Kumari Thread-Topic: [OPSAWG] Procedural issues with the TACACS+ document Thread-Index: AdFkXHFSg5ZIjXEBjUKCej1QAX7CTw== Date: Wed, 10 Feb 2016 23:40:37 +0000 Message-ID: <20160210234046.18296914.47293.50727@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0196979531==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-11_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602100433 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 23:40:46 -0000 --===============0196979531== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable +1 Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Edwin Mallette Sent: Wednesday, February 10, 2016 18:36 To: Alan DeKok; Warren Kumari Cc: Douglas Gash (dcmgash); opsawg@ietf.org; Andrej Ota; Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document Just a couple comments=C5=A0 1) As one operator (of many, I am certain) that utilizes TACACS+ for AAA on every network device, I would certainly hate to see some procedural minutiae bog this effort down. 2) This draft is well written and adds a few welcome additional features. 3) Please don=C2=B9t let any procedural issues (real or imagined) inhibit t= he completion of this good and much needed effort. Cheers! Ed On 2/10/16, 12:57 PM, "OPSAWG on behalf of Alan DeKok" wrote: > And some more notes > >7. The charter says: > >"The Operations and Management Area receives occasional proposals for >the development and publication of RFCs dealing with operational and >management topics that are not in scope of an existing working group >and do not justify the formation of a new working group. " > >8. This document is competes directly with two existing working groups, >RADEXT and DIME, to create a third AAA protocol. > >9. As such, this document should be explicitly outside of the scope of >the OPSAWG. > >> On Feb 10, 2016, at 3:51 PM, Alan DeKok >>wrote: >>=20 >> On Feb 10, 2016, at 3:31 PM, Alan DeKok >>wrote: >>> There are a host of procedural problems with how the document was >>>adopted. I suggest that the document be withdrawn, and re-submitted as >>>an individual draft. >>=20 >> To be clear: >>=20 >> 1. the document never had a WG call for adoption as required in Section >>4.2.1 of RFC 6174 >>=20 >> 2. the charter has not been updated to reflect this work. >>=20 >> 3. the charter says: >>=20 >> "All new work items and rechartering proposals will be brought for >>approval with the IESG." >>=20 >> 4. I can find no record of this approval taking place. If it had taken >>place, the charter would have been updated. >>=20 >> 5. I had objected to this in person at the OPSAWG meeting in IETF 94. >>However, the web site shows no minutes from that meeting: >>=20 >> https://tools.ietf.org/wg/opsawg/minutes >>=20 >> 6. I believe that this document is an incorrect technical choice as per >>section 6.5.1 of RFC 2016. >>=20 >> As such, I ask the chairs to withdraw the document as a WG document >>until such time as the procedural issues above have been addressed. >>=20 >> Alan DeKok. >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============0196979531== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDIxMDIzNDA0NFowLwYJKoZIhvcNAQkEMSIEIGwkn3IcO8xI Tk7Xg7oaHCHXoZdoQVCUTiN2sV2iSEroMAsGCSqGSIb3DQEBCwSCAQBK4AYQ1+rpLubM+rktgpH2 7WiFirW64oiVgDXsa0UiMo1LOjR79v9ct6nLf5vX6DrKXaTXZChIg6CrkIOYZSdvIOQHQD3O/oCC k32uwnBQu3d73L2ltFneDbMEcUnUt0woesX5nmOh21nZMB0d4+H22dhTCKyHxdT92qQ1+v0oHIuZ IJHz5k8HWQD8OMe/UUd7pccDi1YeM+V/NtObgzOosfADTdtrVnn9S4LbHUfMLiaDuWJy4U3UoSnZ pqbiA2k2oTaryNqmzcqI6E+4oJx+9xtxFlYDorkfzEaHDLPe9H6IMJ5dsTustrT96ZCGinr9VIgt 9rk0dyPSb3nCpjsHAAAAAAAA --===============0196979531==-- From nobody Wed Feb 10 16:12:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5CD1A854D for ; Wed, 10 Feb 2016 16:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 HjA3kT18TqWh for ; Wed, 10 Feb 2016 16:12:42 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672DC1A86E8 for ; Wed, 10 Feb 2016 16:12:42 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id c10so20388419pfc.2 for ; Wed, 10 Feb 2016 16:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=V6Mi6BoEG2/WQ8mK1iTg1FOOfQOPtqr5JF1fg3ACRV8=; b=TilhBwLfBxKgbU3b2YC1EfoNEOoo9rcyfJ1XzPJMFnZg6rRbptvPh3pI8kpLR1YYR8 +km1+oBiuLyWxYWihzV4Yn5qAnr1q9lz8uCkV2Z/4vwxCneAhjIGugUGfNn3HFN8nLpI XI7r2fh2rNOHYQNgdvxkfzDs4yM8aZiX2W25NhKHJBk4EmNhFM3spKXjV2LXf9KqeucA o3GGcY07oW0FjtABi1uaSkJqrN6s3LCjq7n8tJfZjO9unv0+O4ckKb5e99uT5RY0HhMU lwdw4KOkw9C9kPxbpZ+OCAqXLqvvGy/1k7CCtDXMXLNI1nc81WdqbuHpPIZZgYwxdpFV CeQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=V6Mi6BoEG2/WQ8mK1iTg1FOOfQOPtqr5JF1fg3ACRV8=; b=hKFVGKlkUJODVZjZ8X+C3f6fAX4Mjnz2NgNnjvGVGQ9gQBX1EKIoyo4navEIUOIP9k VZBhTjwQE3Uru11su8B/2CNUa3KKS6NAwf0qqA7ZMysPLVS22weeaVeHUPZkWIEL3Hs0 spTInJ/wdlnLCVLwu/vAUuaSdWNPowOGDT00SS7T4GVcQSCrKiRy99+PcbfBAdHsf9OP 73TarwivzvHpsnV+BkD6RRH6pTQ5Y1Qcw6WXYVZ0jRf+hc76dTIu2Ar33S4DkFos2n0G iT6UQkVrtHhxuYU1nHL4RsDTzwLlioXxESKmryhzmt1JrC3V14krNqNKJQ0PnXds8LFk rfiQ== X-Gm-Message-State: AG10YOQA6Uae5+R43tCUXlaF+CtlQfbPDJWAuowqfa6mAxEFrLCEJDCJ8IzAsJ/D+c+LJQ== X-Received: by 10.98.89.139 with SMTP id k11mr62492787pfj.56.1455149562047; Wed, 10 Feb 2016 16:12:42 -0800 (PST) Received: from ?IPv6:2406:e007:60f8:1:28cc:dc4c:9703:6781? ([2406:e007:60f8:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id dg12sm7659185pac.47.2016.02.10.16.12.39 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 16:12:40 -0800 (PST) To: opsawg@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56BBD1FE.3050206@gmail.com> Date: Thu, 11 Feb 2016 13:12:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 00:12:47 -0000 On 11/02/2016 09:51, Alan DeKok wrote: > On Feb 10, 2016, at 3:31 PM, Alan DeKok wrote: >> There are a host of procedural problems with how the document was adopted. I suggest that the document be withdrawn, and re-submitted as an individual draft. > > To be clear: > > 1. the document never had a WG call for adoption as required in Section 4.2.1 of RFC 6174 That's an Informational RFC that can't require anything of anybody. The same is true of RFC 7221, which is very clear that the process is optional: http://tools.ietf.org/html/rfc7221#section-2.1 No smoking gun there, not even any smoke. That said, I looked back at the WG mailing list for last November and there was explicit discussion of adoption in the thread "New Version Notification for draft-dahm-opsawg-tacacs-01.txt". A WG Last Call is of course required in due course. > > 2. the charter has not been updated to reflect this work. I agree that the WG chairs and AD should be beaten with wet noodles for failing to update the milestones since 2013. > 3. the charter says: > > "All new work items and rechartering proposals will be brought for approval with the IESG." I've always read that to mean new work items that fall outside the existing charter, which covers "development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group". TACACS+ clearly lies within that chartered scope. However, it might be wise to delete that sentence from the charter. It's unnecessary to say that rechartering requires approval, because that is a basic IETF procedure. Brian From nobody Wed Feb 10 19:30:35 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BB91A8A0D for ; Wed, 10 Feb 2016 19:30:34 -0800 (PST) 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] autolearn=ham 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 gLEXPzxMEz2W for ; Wed, 10 Feb 2016 19:30:32 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7341A00E2 for ; Wed, 10 Feb 2016 19:30:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id A8A7FD14; Thu, 11 Feb 2016 03:30:31 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWVahjiDpN-a; Thu, 11 Feb 2016 03:30:31 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id E29638E5; Thu, 11 Feb 2016 03:30:29 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BBB51F.4080303@bogus.com> Date: Wed, 10 Feb 2016 22:30:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Douglas Gash \(dcmgash\)" , Andrej Ota , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 03:30:34 -0000 On Feb 10, 2016, at 5:09 PM, joel jaeggli wrote: >=20 > it's pretty hard to argue that we've created something that's been > around since 1993 I;m sure we had this dicussion before circa 1996, I > don't remember it thankfully. I dare say it is inappropriate for dime = or > radext to undertake work on tacacs+ under their current charters. That's not my point. My point is that TACACS+ has a 100% overlap in functionality with the = RADIUS protocol. It is a vendor-specific protocol, which the vendor refused to = standardize. My opinion is that it's because the vendor saw it as = advantageous to have a proprietary protocol. Both for customer lock-in, = and for complete control. =20 Now that the other people have implemented the protocol, they see it = as being beneficial to standardize it. That is a *complete* end-run = around the IETF process. Publishing it as an informational draft is a good idea. Publishing it = as an IETF standard means that we reject the work done in RADEXT and = DIME to standardize AAA protocols. That we should ignore the last 20 = years of history of people working on those protocols, in good faith = that they would be IETF standards. That we should just publish any = document which has sufficient implementations, no matter that there's an = existing WG which is doing 100% similar work. > it is entirely unclear how this would interfere with the activities of > either... Standardizing IPX would not interfere with IPv4 standardization. But = it would send entirely the wrong message, that a vendor-specific = protocol has the IETFs blessing. What we're saying by standardizing TACACS+ is that the IETF process is = irrelevant. The RADEXT WG is irrelevant. All vendors need to do is to = push proprietary protocols behind the scenes, and then present them to = the IETF as a fait accompli. It's really a slap in the face for everyone who followed the IETF = process for the last 20 years, and did work in RADIUS, AAA, DIME, and = RADEXT. Alan DeKok. From nobody Wed Feb 10 19:37:18 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D601A8A16 for ; Wed, 10 Feb 2016 19:37:17 -0800 (PST) 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] autolearn=ham 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 hL7lYsKfygN3 for ; Wed, 10 Feb 2016 19:37:16 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 805601A8A13 for ; Wed, 10 Feb 2016 19:37:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E247DD14; Thu, 11 Feb 2016 03:37:15 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYdAFRRnU6Fd; Thu, 11 Feb 2016 03:37:15 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 7081BD0F; Thu, 11 Feb 2016 03:37:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BBD1FE.3050206@gmail.com> Date: Wed, 10 Feb 2016 22:37:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7EE28A5A-0C73-4F9D-B52E-0BFB1E985B52@deployingradius.com> References: <56BBD1FE.3050206@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 03:37:17 -0000 On Feb 10, 2016, at 7:12 PM, Brian E Carpenter = wrote:ny smoke. >=20 >=20 > That said, I looked back at the WG mailing list for last November and = there was > explicit discussion of adoption in the thread "New Version = Notification for draft-dahm-opsawg-tacacs-01.txt". I've seen many WGs where lots of people were in favour of a draft. = That doesn't mean the draft is automatically accepted as a WG document. > I agree that the WG chairs and AD should be beaten with wet noodles = for > failing to update the milestones since 2013. I've seen documents refused as WG items, even with unanimity that the = documents were appropriate... because they were not part of the charter = work items. If the process matters, I would suggest that it should apply equally = to everyone.=20 > I've always read that to mean new work items that fall outside the = existing charter, > which covers "development and publication of RFCs dealing with = operational and > management topics that are not in scope of an existing working group". = TACACS+ > clearly lies within that chartered scope. TACACS+ has 100% functionality overlap with RADIUS. Sure, it's not extending RADIUS, and doesn't technically fall within = the purview of RADEXT. But I find it rather surprising that OPSAWG is = standardizing a protocol which competes directly with an existing, = active WG. Is this really what we want to do here? If we standardize TACACS+, we = might as well disband RADEXT and DIME, because there's no point in = following a standards process when people can do an end-run around it. Alan DeKok. From nobody Wed Feb 10 20:08:59 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD6C1A8A86 for ; Wed, 10 Feb 2016 20:08:57 -0800 (PST) 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] autolearn=ham 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 HJ7bFDTwwlsB for ; Wed, 10 Feb 2016 20:08:56 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DD6D81A8A85 for ; Wed, 10 Feb 2016 20:08:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 2086412B5; Thu, 11 Feb 2016 04:08:55 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj1BL0ixkToF; Thu, 11 Feb 2016 04:08:55 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 04867D0F; Thu, 11 Feb 2016 04:08:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Wed, 10 Feb 2016 23:08:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> To: Andrej Ota X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 04:08:57 -0000 On Feb 10, 2016, at 5:32 PM, Andrej Ota wrote: > Current TACACS+ draft work is continuation of original work which = stalled in 1997. "Stalled"? I don't think that's an accurate description. More accurately, the IETF consensus for the past 20 years was that the = official IETF AAA protocol was RADIUS. Wide-spread adoption of a vendor protocol is insufficient reason to = make it an IETF standard. There is no *technical* reason to make the document an IETF standard. = The goal of documenting TACACS+ could be done by publishing it as an = informational RFC. So I have to ask, why is it being proposed (much less accepted) as an = IETF standard document? The only conclusion is that it's to get the "stamp of approval" from = the IETF, as an official IETF AAA protocol. I suggest that the IETF should be *very* parsimonious with such = approvals. We already have two AAA protocols, and TACACS+ adds *no = technical benefits* over either RADIUS or Diameter. As such, it is entirely inappropriate for the IETF to approve this = document as a standards track document. > Stating this is "a third AAA protocol" is a false statement and one I = find to be intellectually dishonest. At worst one could call it the 2nd = AAA protocol. Please keep the ad hominems out of this discussion. We already have two IETF AAA protocols. There is no good reason to = add a third one. The fact that TACACS+ was originally proposed 20 years = ago is irrelevant. The IETF is already doing work in the space. > On the topic of "competes directly with ...": > The goals and aims are completely different. So it's not a AAA protocol? Your argument is logically inconsistent. Either it is a AAA protocol, = and competes directly with RADIUS and Diameter, or it isn't a AAA = protocol, and your accusation that I was being "intellectually = dishonest" is itself dishonest. > This is not a new protocol, it's almost 20 years old (00 draft was = published in October 1996). It's not a new development trying to compete = with anything or anyone. You're saying that an AAA protocol with 100% overlap with RADIUS isn't = competing with RADIUS. Um... no. It's pretty obviously competing with RADIUS. The only = reason TACACS+ is alive today is because of major vendors pushing it = *against* RADIUS. > Draft is attempting to standardise the current ground truth while = providing a single relevant addition to the original draft, which the = use of TLS "tunnel". Note "standardise", not "document". So the goal is an IETF standard = stamp on the document, not a document describing the protocol. > In connection with the quote from charter under item no. 7, I claim = the following statements to be true: > - Ground truth is that TACACS+ is widely deployed protocol for device = management AAA. > - Ground truth is that new device vendors and new devices are = entering market which are implementing TACACS+. The protocol is not = dying out. > - Ground truth is that DIAMETER has no penetration in the area of = network device management AAA. The truth is that there is 100% overlap in functionality between = TACACS+ and RADIUS.=20 > - Ground truth is that TACACS+ implementations are based on an IETF = draft which expired in 1997. No. It was an *individual* draft. I could write a draft claiming I'm = a genius, and it would mean nothing. Similarly, some random person = publishing a draft in 1997 doesn't mean it's an "IETF" draft. It's just = another person with an idea that was *rejected by the IETF*. > Combination of these statements, which I claim to be all true, is = causing current and relevant operational issues for network operators. None of that is relevant to the IETF process. > As such I think this draft is well within the scope of the OPSAWG. I = believe the community at large will benefit if it will be maintain it's = current strict and narrow focus and ultimately get approved as an RFC. = If it turns out that the protocol which already has a widespread = adoption and had it for more than a decade, can actually be beaten by = other alternatives, may it happen on the basis of actual operational = merit and not based on attempt to disqualify TACACS+ as an "entry too = late" item in WG queue. It is not too late, it is an active protocol, it = is not standardised, lack of a standard is causing issues by itself. = This last item I believe can and should be addressed. That is entirely mischaracterizing my position. The IETF consensus for the last 20 years has been that RADIUS was = chosen over TACACS+. There is no *technical* reason to re-visit that = decision. Alan DeKok. From nobody Wed Feb 10 20:20:30 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5021A8A96 for ; Wed, 10 Feb 2016 20:20:29 -0800 (PST) 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] autolearn=ham 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 MLRgEeaHE981 for ; Wed, 10 Feb 2016 20:20:28 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CAA351A8A85 for ; Wed, 10 Feb 2016 20:20:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 14B6E12FE; Thu, 11 Feb 2016 04:20:27 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l_09QWHLuip; Thu, 11 Feb 2016 04:20:26 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id C89D6556; Thu, 11 Feb 2016 04:20:25 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Wed, 10 Feb 2016 23:20:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4CCD0944-E137-4836-B2E6-347737CE7C5F@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Andrej Ota , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 04:20:29 -0000 On Feb 10, 2016, at 5:17 PM, Douglas Gash (dcmgash) = wrote: > TACACS+ cannot compete with RADIUS in the area RADIUS is strong: for > Network access. The authors have no interest in trying to do so. Realistically TACACS+ is an AAA protocol with full AAA functionality. = As such, it is competing 100% with RADIUS. > TACACS+ in 2016 has quite a different use case: for device = administration, > where it is widely deployed by multiple vendors. The solution to a common device administration problem would be to = either create an IETF protocol, or to leverage an existing one. Please suggest how: 1) publishing TACACS+ as an *IETF standard* is required to document it 2) any functionality in TACACS+ cannot be implemented in RADIUS > Its application for > device administration is why the authors approached opsawg. The = authors > believe that it has a place for device administration in the = datacenter > and would seek to get the TACACS+ protocol definition documented and > straightened out for this purpose, and registered with IETF. There are many device administration protocols in the IETF. SNMP for = one. So this response is a bit too vague to be explanatory. Call me dumb, = but I would like to have a clear statement as to what TACACS+ does that = RADIUS doesn't. > I don=B9t think there was any conspiracy by Cisco not to pursue the > publication before. Cisco initiated the process to get the protocol > approved by IETF in 1996/1997 > (https://tools.ietf.org/html/draft-grant-tacacs-02), but the original > authors pursued other endeavours, and no one followed up until now, = with a > process that actually started up outside Cisco. The IETF consensus for the last 20 years is that RADIUS, and then = Diameter, are the IETF AAA protocols. I see no technical reason to re-visit that decision now. > Regarding procedural matters, if we have missed any steps, that is my = bad > and I will consult with those more versed in procedure to rectify = that. The chairs and ADs are responsible for process administration, not the = document authors. Alan DeKok. From nobody Wed Feb 10 21:00:20 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10061A8BB1 for ; Wed, 10 Feb 2016 21:00:19 -0800 (PST) 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] autolearn=ham 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 3U2Ku2dcdreO for ; Wed, 10 Feb 2016 21:00:17 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 329D61A8ADC for ; Wed, 10 Feb 2016 21:00:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 42633D14; Thu, 11 Feb 2016 05:00:14 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhmvOolNjyju; Thu, 11 Feb 2016 05:00:14 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id C355C556; Thu, 11 Feb 2016 05:00:10 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2016 00:00:09 -0500 To: opsawg@ietf.org, joel jaeggli Message-Id: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 05:00:19 -0000 I think most people aren't aware of the history of AAA protocols in = the iETF. This message summarizes relevant documents in the area, and = makes an appeal to the WG to remove the document as a WG document. RADIUS was standardized in 2000 in RFC 2058, after years of WG = discussion. The original protocol goes back to 1993, unlike the TACACS+ = draft, which was submitted in 1997. Diameter was standardized in 2003 in RFC 3588, again after years of WG = discussion. TACACS+ was never considered by the IETF as an AAA = protocol. The IETF created a process to specify requirements for AAA protocols. = This process is documented in RFC 2989 [1] (2000), which had about 20 = authors from all major networking companies at the time. It solicited = submissions, and established a panel to evaluate the submissions. The = results are documented inRFC 3127 [2] (2003). TACACS+ was not even = considered, as it did not meet the requirements set out in RFC 2989. What is happening here is that a single WG is re-visiting a multi-year = process which involved dozens of experts in the area. A process which = established IETF consensus. A process which was started almost two = decades ago, and finished 13 years ago. While RFC 2989 and RFC 3127 are "informational", they are only = informational because they do not document a protocol design. They do, = however, document IETF consensus. Standardizing a new AAA protocol without IETF-wide discussion means = we're ignoring the requirements of RFC 2989, and discarding the results = shown in RFC 3127. Standardizing TACACS+ is like a single WG standardizing IPv8 on it's = own, after decades of work on IPv6, without achieving wider IETF = consensus, or even updating the WG charter. It's one WG doing a = complete end-run around IETF consensus. The document draft-ietf-opsawg-tacacs-00.txt *explicitly* describes = itself as an AAA protocol in it's abstract. Despite the authors stating = it is for "device administration", that phrase *does not appear in the = document*. Despite claims that it is not an AAA protocol, the document = itself claims TACACS+ is an AAA protocol. The document discusses user = authentication, authorization, and accounting, in a manner which = overlaps 100% with RADIUS. In fact, RADIUS has more capability than TACACS+. RADIUS is = standardized to transport many more attributes which describe hundreds = of possible pieces of information. The TACACS+ document documents = little more than the base protocol, and a less than 30 kinds of = information it can transport. The TACACS+ functionality therefore *explicitly* overlaps 100% with = RADIUS. It is explicitly *not* "device authorization". It is uniformly = inferior to RADIUS in functionality and capability. It meets none of = the requirements set out in RFC 2989, and wasn't even considered in RFC = 3127. The only *technical* capability that TACACS+ has which RADIUS doesn't = is "device administration". Perhaps what is meant here is "command = authorization", in which individual administrator commands are = authorized via the AAA protocol. However, this capability is *not* = documented in the draft, which means that any "device administration" = remains a proprietary vendor extension, and entirely outside of the = control of the IETF. The document overturns nearly two decades of IETF consensus. It = competes directly with an established IETF protocol. It's functionality = is explicitly inferior to RADIUS. It's suggested use-case is entirely = undocumented in the draft. Therefore, I ask the WG, chairs, and AD, to withdraw this document as = a WG item. It is entirely inappropriate for a standards track document. [1] https://tools.ietf.org/html/rfc2989 [2] https://tools.ietf.org/html/rfc3127 From nobody Wed Feb 10 21:08:20 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730891A8F36 for ; Wed, 10 Feb 2016 21:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 x9lLuLlAOITZ for ; Wed, 10 Feb 2016 21:08:18 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505891A8F33 for ; Wed, 10 Feb 2016 21:05:25 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id dk10so1260026pac.1 for ; Wed, 10 Feb 2016 21:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=1Xbg11tNWQ3m/dBiYRTa/vgwqvF+e7qwpGHN/G4OELs=; b=lI95UmO6Kg3ZBCYdtjUsXWlYHPOTtsttAOTLSt91w1ArvpSsXI6PTc7AknNV3Pu7uK /XV/u1AIVbeIi2wzDANYmvikIg2N8WkbdwowYwtqww4ybIXZYXWemM0G8fYLzP1e3a+H 7q7QN0s5ANegX5Nydm1dFyY1GtVk3uQHztHS7PdhShCUYIkY9HipaUl2U5XMIuzfIP3+ Qd6ZNTovxv5sUUlAo3Ys+ZiyKeX1Ri0pyp93LevvYQQnxvgsbyi7uEoJgkU7GmiAdXPc B87kZICNmd5t8xLOreCGNNrFSL2ntsKRayoOPyLhaHGIlE4ePdgxeWV9lWt1jU1mgzww 5nEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=1Xbg11tNWQ3m/dBiYRTa/vgwqvF+e7qwpGHN/G4OELs=; b=XeigBlJy3jjfSECwAeCCBxmWx5qyDJWtutQ2c+tO/rje/LoM53rooTkOpGqOEayygF xe0W0bIb6DWQm+1v6Xin7Gx151gSmaDved5h2Z+dpMEjSCIlMz4wXnZuguWwQoPSPGsq JxsxM2XsReUb73LBd3mI0CP/Cek/RqE3XosnpXT2pm1AUIlFjoAm7PTz0Aybb59TYUzA WAZLLgLUlwTp5sbqaBqmxr3LrAB++R50y5tzHpvBvf5zlWya3a+KuN6eU28aWCjMV5Zf uMSz8i21ogLQm5rycRPYtzx0p3AXZ/8V9riN4w8Na5tpx7IJLxVP1NdIcRjWpvq9dOTi IjKA== X-Gm-Message-State: AG10YOTbta1EDDx60eVwd6wn5hfiBV9ed3xNRwlk5vdshnukqyvs5KMLJHoAz0aWoFGtsQ== X-Received: by 10.66.142.168 with SMTP id rx8mr63358989pab.16.1455167125028; Wed, 10 Feb 2016 21:05:25 -0800 (PST) Received: from Melindas-MacBook-Pro.local (63-140-105-96-radius.dynamic.acsalaska.net. [63.140.105.96]) by smtp.googlemail.com with ESMTPSA id k65sm8736245pfb.30.2016.02.10.21.05.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 21:05:24 -0800 (PST) To: Alan DeKok , "Douglas Gash (dcmgash)" References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <4CCD0944-E137-4836-B2E6-347737CE7C5F@deployingradius.com> From: Melinda Shore Message-ID: <56BC1606.7000304@gmail.com> Date: Wed, 10 Feb 2016 20:03:02 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <4CCD0944-E137-4836-B2E6-347737CE7C5F@deployingradius.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 05:08:19 -0000 On 2/10/16 7:20 PM, Alan DeKok wrote: > Realistically TACACS+ is an AAA protocol with full AAA functionality. > As such, it is competing 100% with RADIUS. That could well be, but traditionally the IETF does sometimes standardize protocols that do basically the same things and might be seen as competing. Our job is to specify useful things (interoperable useful things), and I don't think the IETF has ever made it our job to choose a winner - we let the market choose. That said, I think the process here has been very very badly botched. Very. Melinda From nobody Wed Feb 10 21:58:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81F41A9051 for ; Wed, 10 Feb 2016 21:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 h9yUTdIPaJKa for ; Wed, 10 Feb 2016 21:58:30 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15A01A8902 for ; Wed, 10 Feb 2016 21:58:29 -0800 (PST) Received: from mb-2.local (h7.180.128.40.static.ip.windstream.net [40.128.180.7]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1B5wMZV095862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Feb 2016 05:58:23 GMT (envelope-from joelja@bogus.com) To: Alan DeKok , opsawg@ietf.org References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56BC22FD.5050702@bogus.com> Date: Wed, 10 Feb 2016 21:58:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RSBw1udsafBMfEVGVhgwvgV5fGgcfttdh" Archived-At: Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 05:58:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RSBw1udsafBMfEVGVhgwvgV5fGgcfttdh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/10/16 9:00 PM, Alan DeKok wrote: > I think most people aren't aware of the history of AAA protocols in > the iETF. This message summarizes relevant documents in the area, > and makes an appeal to the WG to remove the document as a WG > document. >=20 > RADIUS was standardized in 2000 in RFC 2058, after years of WG > discussion. The original protocol goes back to 1993, unlike the > TACACS+ draft, which was submitted in 1997. >=20 > Diameter was standardized in 2003 in RFC 3588, again after years of > WG discussion. TACACS+ was never considered by the IETF as an AAA > protocol. >=20 > The IETF created a process to specify requirements for AAA protocols. > This process is documented in RFC 2989 [1] (2000), which had about 20 > authors from all major networking companies at the time. It > solicited submissions, and established a panel to evaluate the > submissions. The results are documented inRFC 3127 [2] (2003). > TACACS+ was not even considered, as it did not meet the requirements > set out in RFC 2989. >=20 > What is happening here is that a single WG is re-visiting a > multi-year process which involved dozens of experts in the area. A > process which established IETF consensus. A process which was > started almost two decades ago, and finished 13 years ago. >=20 > While RFC 2989 and RFC 3127 are "informational", they are only > informational because they do not document a protocol design. They > do, however, document IETF consensus. >=20 > Standardizing a new AAA protocol without IETF-wide discussion means > we're ignoring the requirements of RFC 2989, and discarding the > results shown in RFC 3127. >=20 > Standardizing TACACS+ is like a single WG standardizing IPv8 on it's > own, after decades of work on IPv6, without achieving wider IETF > consensus, or even updating the WG charter. It's one WG doing a > complete end-run around IETF consensus. >=20 > The document draft-ietf-opsawg-tacacs-00.txt *explicitly* describes > itself as an AAA protocol in it's abstract. Despite the authors > stating it is for "device administration", that phrase *does not > appear in the document*. Despite claims that it is not an AAA > protocol, the document itself claims TACACS+ is an AAA protocol. The > document discusses user authentication, authorization, and > accounting, in a manner which overlaps 100% with RADIUS. >=20 > In fact, RADIUS has more capability than TACACS+. RADIUS is > standardized to transport many more attributes which describe > hundreds of possible pieces of information. The TACACS+ document > documents little more than the base protocol, and a less than 30 > kinds of information it can transport. >=20 > The TACACS+ functionality therefore *explicitly* overlaps 100% with > RADIUS. It is explicitly *not* "device authorization". It is > uniformly inferior to RADIUS in functionality and capability. It > meets none of the requirements set out in RFC 2989, and wasn't even > considered in RFC 3127. >=20 > The only *technical* capability that TACACS+ has which RADIUS doesn't > is "device administration". Perhaps what is meant here is "command > authorization", in which individual administrator commands are > authorized via the AAA protocol. However, this capability is *not* > documented in the draft, which means that any "device administration" > remains a proprietary vendor extension, and entirely outside of the > control of the IETF. >=20 >=20 > The document overturns nearly two decades of IETF consensus. It > competes directly with an established IETF protocol. It's > functionality is explicitly inferior to RADIUS. It's suggested > use-case is entirely undocumented in the draft. >=20 > Therefore, I ask the WG, chairs, and AD, to withdraw this document as > a WG item. It is entirely inappropriate for a standards track > document. Ok, we operate under the order of precidence in 2026: https://tools.ietf.org/html/rfc2026#section-6.5 I expect that prior to intercession on my part that an appeal will commence with the chairs considering the appeal. thanks joel >=20 >=20 > [1] https://tools.ietf.org/html/rfc2989 >=20 > [2] https://tools.ietf.org/html/rfc3127 >=20 >=20 --RSBw1udsafBMfEVGVhgwvgV5fGgcfttdh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAla8Iv0ACgkQ8AA1q7Z/VrKo8ACfYfqu5gZMCiYoahD/bd2cQlQp bpcAnRXw4MspA2KSKy1+BIOGp/Ir3R++ =wqlF -----END PGP SIGNATURE----- --RSBw1udsafBMfEVGVhgwvgV5fGgcfttdh-- From nobody Wed Feb 10 22:14:45 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D6E1A9095 for ; Wed, 10 Feb 2016 22:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 Tt1qYUpoRmdX for ; Wed, 10 Feb 2016 22:14:41 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFE91A9093 for ; Wed, 10 Feb 2016 22:14:41 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CDF4BA2; Thu, 11 Feb 2016 07:14:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1455171278; bh=07TynRpM2oVZ7dvtwQweK8TVOAkW1a4MSRE89i3RTZs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=RT+GjN5HG/IPMSo5+/HaPdxD5oM3giy9N1/4YIP6t2pQkz9KoW0VZ+WnOOZZ4yrP6 XUII2lpoVhsPwhUCCnlHo63pNutxDGiOy8dI7YIRfoDb5wauOXiW1ZRJGgNX9kr0Mo LJztntnZiKZancy3cLVNrLTgNEn/tjyRw7aX04lE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CAF19A1; Thu, 11 Feb 2016 07:14:38 +0100 (CET) Date: Thu, 11 Feb 2016 07:14:38 +0100 (CET) From: Mikael Abrahamsson To: Alan DeKok In-Reply-To: <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> Message-ID: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 06:14:43 -0000 On Wed, 10 Feb 2016, Alan DeKok wrote: > My point is that TACACS+ has a 100% overlap in functionality with the > RADIUS protocol. As an operator that has been running TACACS for 15+ years, my answer to that is: "I don't care". I want the IETF to publish an RFC documenting TACACS as it's in use currently. It's in wide use, and I don't see a reason not to let a document through that documents what's already in use and potentially adds a few more features. If someone came and asked for a new WG for TACACS, that would be a different matter. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Feb 11 01:16:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784811ACD9A for ; Thu, 11 Feb 2016 01:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 4igjnpj8qBOc for ; Thu, 11 Feb 2016 01:16:10 -0800 (PST) Received: from zm-out-02.forthnet.gr (zm-out-02.forthnet.gr [194.219.0.14]) by ietfa.amsl.com (Postfix) with ESMTP id C96E71ACD8C for ; Thu, 11 Feb 2016 01:16:09 -0800 (PST) Received: from zm-in-02.cloud.forthnet.prv (zm-in-02.cloud.forthnet.prv [10.24.31.16]) by zm-out-02.forthnet.gr (Postfix) with ESMTP id C6C9612229A for ; Thu, 11 Feb 2016 11:16:07 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTP id AD3491211AB; Thu, 11 Feb 2016 11:16:07 +0200 (EET) X-DSPAM-Result: Spam Authentication-Results: zm-in-02.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-02.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-02.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id ACWGjjOuhtEu; Thu, 11 Feb 2016 11:16:05 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTP id A1C41120DAE; Thu, 11 Feb 2016 11:16:05 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-02.cloud.forthnet.prv A1C41120DAE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1455182165; bh=q4v12mXIxxLnobu/QNwytxKCDxCr4XD0Q5wwIO82H6w=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=DCY1c/Icp+tK5OJq920oGPbHFZsLfDemcTLxK498bHSO1/ffGGp2MrH78rej9PLhj EE85RWj3mRjGq+SjVPgyNjnDgddVBv2Mhj2pKp51coD1ZOYBMWsSdF36cOb0q2G6My TafCzoc2VQjhtONy9WvrZ20oeI2WxoQJ5qKI5Z4A= X-Virus-Scanned: amavisd-new at zm-in-02.cloud.forthnet.prv Received: from zm-in-02.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-02.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id rw_QImZwcUy6; Thu, 11 Feb 2016 11:16:05 +0200 (EET) Received: from [IPv6:2a02:2148:82:6000:40ad:28dc:9aca:dc84] (ip-2a02-2148-0082-6000-40ad-28dc-9aca-dc84.ip6.forthnet.gr [IPv6:2a02:2148:82:6000:40ad:28dc:9aca:dc84]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTPA id 3A3E8120A28; Thu, 11 Feb 2016 11:16:05 +0200 (EET) References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> To: "opsawg@ietf.org" From: Tassos Chatzithomaoglou X-Enigmail-Draft-Status: N1110 Organization: Forthnet Message-ID: <56BC5157.7060801@forthnet.gr> Date: Thu, 11 Feb 2016 11:16:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 09:16:13 -0000 +1 As an operator using tacacs+ for the role/level-based administration of many thousands devices, i would like to see a standard RFC for tacacs+. If that must be paired with a clear reference to device administration, that's also fine by me. -- Tassos Edwin Mallette wrote on 11/2/2016 1:34 =CF=80=CE=BC: > Just a couple comments=C5=A0 > > 1) As one operator (of many, I am certain) that utilizes TACACS+ for AA= A > on every network device, I would certainly hate to see some procedural > minutiae bog this effort down. > 2) This draft is well written and adds a few welcome additional feature= s. > 3) Please don=C2=B9t let any procedural issues (real or imagined) inhib= it the > completion of this good and much needed effort. > > Cheers! > > Ed > > On 2/10/16, 12:57 PM, "OPSAWG on behalf of Alan DeKok" > wrote: > >> And some more notes >> >> 7. The charter says: >> >> "The Operations and Management Area receives occasional proposals for >> the development and publication of RFCs dealing with operational and >> management topics that are not in scope of an existing working group >> and do not justify the formation of a new working group. " >> >> 8. This document is competes directly with two existing working groups= , >> RADEXT and DIME, to create a third AAA protocol. >> >> 9. As such, this document should be explicitly outside of the scope o= f >> the OPSAWG. >> >>> On Feb 10, 2016, at 3:51 PM, Alan DeKok >>> wrote: >>> >>> On Feb 10, 2016, at 3:31 PM, Alan DeKok >>> wrote: >>>> There are a host of procedural problems with how the document was >>>> adopted. I suggest that the document be withdrawn, and re-submitted= as >>>> an individual draft. >>> To be clear: >>> >>> 1. the document never had a WG call for adoption as required in Secti= on >>> 4.2.1 of RFC 6174 >>> >>> 2. the charter has not been updated to reflect this work. >>> >>> 3. the charter says: >>> >>> "All new work items and rechartering proposals will be brought for >>> approval with the IESG." >>> >>> 4. I can find no record of this approval taking place. If it had tak= en >>> place, the charter would have been updated. >>> >>> 5. I had objected to this in person at the OPSAWG meeting in IETF 94. >>> However, the web site shows no minutes from that meeting: >>> >>> https://tools.ietf.org/wg/opsawg/minutes >>> >>> 6. I believe that this document is an incorrect technical choice as p= er >>> section 6.5.1 of RFC 2016. >>> >>> As such, I ask the chairs to withdraw the document as a WG document >>> until such time as the procedural issues above have been addressed. >>> >>> Alan DeKok. >>> >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Thu Feb 11 02:18:07 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4A21ACE7F for ; Thu, 11 Feb 2016 02:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 x9Kl5h3Qxka4 for ; Thu, 11 Feb 2016 02:18:03 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0114.outbound.protection.outlook.com [104.47.2.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EBB1ACE78 for ; Thu, 11 Feb 2016 02:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uRLOOZU02Xvr1fi9Uhxcm209dQcGB4620zUU0Xrx9Hs=; b=jU8oT7dw/6x86ivhYDGE+cQW3BJ/MQMw7pHjGGXzCoGMsVwol4eJDy9jWFblEzLQ9HNwf8sNfTeFSAuggfoY5AYljNn+xPXsdOaa9Vg3QvHdhrseOX5tI8SqNrTbFVa9I6LTvDGtrq4jFii8WHIY0UI+Vnbw/shToY6aQQAHQUs= Authentication-Results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.390.13; Thu, 11 Feb 2016 10:17:57 +0000 Message-ID: <018201d164b5$04877760$4001a8c0@gateway.2wire.net> From: t.petch To: Alan DeKok , Warren Kumari References: Date: Thu, 11 Feb 2016 10:14:25 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB5PR08CA0016.eurprd08.prod.outlook.com (25.163.102.154) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB060; 2:hxskLAxDOZr3I6o/2O79XyOwOEIMtoWF6/+HDnlEZ9wRJf2wRVhdBpA3UJ4bp/WyqeDvU1tl2ro80EGPhuzzf+yx2dsP49HfqUtYre0PMySmamHo9Ey8hBRDAzb8bMJ79ZxQzLey/4XwH5y3KbQzgw==; 3:w7sTowa//AVOUASi4Bm8J8kp/F03fKLFBhmkuO/rtQvBZ5Ye8LFfy0JodpSVtiYft7waOby9YwDIqBAtFpPYAeqeuf1BzjmO8YfOb/x06nIYOqBcfglb8WYRBHtuUqLh; 25:laMrEOrDenMOzk3raMX5sQaPB0YJBr4qEYimPNG9Y0Iyi3aibxdR68jk+I1wORbNrRluhmtAxHbEa/gh/T38U9Bnmu3pXccZ8X4z2o/u+iNzRLDXiCHUEnzAjqUHjP+e5JG6z2GeWMoZ+K3ejFdOSDmBBD85o9vUdYbquaxfrt+vYATy5I4yXaMqhhXilvNySneuLz5QdueAI3aDFszfJAQvJuBd4iNCRxKpcHsm6jnLsKtoQDadCuERRwYBeNjFO1X7FfQw9lPuh02rfoDPgiN5bIoHg1alP4Wd8quhyowGXtXD/Y51HDwnLusY3Y6l X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-MS-Office365-Filtering-Correlation-Id: 575cb89f-c2cd-4d25-5a31-08d332cc9ccb X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB060; 4:LQ4XbqYahwY0TRZfXRb4PU2/wCKJJTjHtutdGOk+6pkAs77bmSCeofxKEcveQ3DtEWfpbwQwAgAvNun9E+dlvYoiirWsNFXog9Y1UI2DjqLFSLM66Xe0xA4tm6X/Wu0ZP0VZOUG8XrcY1xLTo+I7DLsOi5l6W4KZm1E3EK2NgsnnwXCx7ObO1SrGKQeu8C9P/nXOg+DZiabaoBKt67xiSNbAHOvCOhMiDJ//DlGQR8mYZEDzNW/xPdl23jbHERVjFI5C7AVkXF068tTxbVqJarAiW88tjARPhqAAVNlaD1Bc7Z/hvkYboCeTnN9czLq34p7bOdArEy6oRbqeF4N4oiZZIQOnLPFeQck6zEc0jAv/A/Tjmw3CvGK9UaavbWFW X-Forefront-PRVS: 08497C3D99 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(42186005)(23756003)(44736004)(40100003)(116806002)(189998001)(93886004)(76176999)(50986999)(50466002)(122386002)(92566002)(61296003)(81816999)(86362001)(47776003)(84392002)(81686999)(50226001)(66066001)(1556002)(33646002)(2906002)(44716002)(586003)(3846002)(5004730100002)(106356001)(19580405001)(87976001)(5001770100001)(14496001)(6116002)(5001960100002)(5008740100001)(19580395003)(4326007)(15975445007)(1096002)(62236002)(230700001)(1456003)(77096005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB3PR07MB060; 23:wTQXV/z3att05E6Y1PXGL7WoNfyAf3+MDQwLuSyM?= =?iso-8859-1?Q?LOv8ez5T64U4OBiDUdX394E2XJD5xJgyk+qBi4J4VFBabt4z45mZ5QpBF+?= =?iso-8859-1?Q?DLLuoo3nGKoO5UTdJ/fNd+dVHbTE5/CSuaJmLOF+/iEW4mwfUKQ+JQeoSb?= =?iso-8859-1?Q?8Vt8Ym1+dzi7slQBeFUgqiz/h6RlzEENjNjpJ3pCkx0jLanKBatTMFCREZ?= =?iso-8859-1?Q?PMdgM6t8n+2V6gV61qIHV33+Em1JueZdADBDeu/O4gGLQuUowOmXmNqegl?= =?iso-8859-1?Q?lzlNL5ftj861OyCdAMg3+gr9tax+S+krKPXeYgBsHJrgpQw8H0uztusChP?= =?iso-8859-1?Q?vxDs5eBAn6DqRxIsbMYBgqWxaJlvITt7PLO/xkZgcew3retFYDSN4Sb2Xr?= =?iso-8859-1?Q?OuvlvAfLdiEcmyGxyKDjaJHH1lecqoKYNL0+sUV/ZVDOOZm7GtFow05Poq?= =?iso-8859-1?Q?CSQA2cy9n8ByF0x88kDrm3T0LQZzaOV3cbqp9/3rylbtaEvXazNyRkEzek?= =?iso-8859-1?Q?5wxSKZWRtg5dax+qV7jsMPNbozvjzKXDuEnHAvTtObg5nMgZZGP2Zrx/GB?= =?iso-8859-1?Q?/7bGuNkcLqN3rMO3w7UWZyk5nU1zXDaIDalaDdC/PJp0efeJJcTdJbwxrB?= =?iso-8859-1?Q?NreeFQHxQyn+FKMXSrcIaWQOeRZIH5saLsGeE4WZ1O/c2CFE0+eMdyxFFc?= =?iso-8859-1?Q?SZ89Zo0mxzzI+QAYAN69FlhW+6dvVzRgjv2/n+tAwPi4L9ktId9awRnQeA?= =?iso-8859-1?Q?/oGtt8QJV7VxmWL+JfrTYNQmYiqVOni/8iWc2pt3lF3KROENthKOPdVWK9?= =?iso-8859-1?Q?2Yfy7YGAaKKBBc/9gATMrdSDepCa7OHVqAXTMbpONq9Pffc9uRbcKLAPcS?= =?iso-8859-1?Q?W0i4X8U6HtfUIWzSP7XizEIFKzVlZ6587cfIZrZF7ZKkViBy8M4WFb1YsD?= =?iso-8859-1?Q?ms4FOKJHrhBcAtolZvPJlEp+e/FA1JQpl/xyq+J7NTYaTHOjnXZ3/VdOb8?= =?iso-8859-1?Q?2PTQWDzjmsSxMYYo4id/MMjz9zDzJanc1fns4UurnjtbranJe1x4Al8ak8?= =?iso-8859-1?Q?qNQClCndPRFJUUytUORQwGssgADwrkUhPqwYtXEHrZvPgkrwIsd+6Ixc4y?= =?iso-8859-1?Q?/vLpKh/rnUBb2rtEizxG8Y2E4TW5e9zywqgOmbXAsyQK/Et5y074QBBNJJ?= =?iso-8859-1?Q?vszW2V/MTdRH/3Hw2WJg23KMMzuiS2PgUmLqdeLDsrUtvVwajDCoWqLv+9?= =?iso-8859-1?Q?KFl0VKrKe4a8Ycw2wJaJ1ghn7UTq4iFN6NlzKmjqcKimBOFOtLE0rUaeMO?= =?iso-8859-1?Q?o=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB060; 5:78YFY/+gywRDAjoaJ0UbmmkiqDOm48lcLJJ8ToAV5SJIn7WFdlrceIdHzG5fwGAU4zAxQvCxZRF4iqCm+t3uiv7Z0pNWj2bnRzu2HfK6OIISsg4/EfNM5ipf5EjEg7TnqO8Yn7B5uQen5pJEwC8Drw==; 24:TzXQpUVYVSpQjTPxx9JWNSDwVWFdm0M06sjL++g24V2oBfhOP2JMoa2Qc2Tz5byvC8G1+9BWFOPwqvMONodR2KyzktgoNv4ogaaSJ1QLYZs= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2016 10:17:57.1541 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , opsawg@ietf.org, Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 10:18:06 -0000 ---- Original Message ----- From: "Alan DeKok" To: "Warren Kumari" Sent: Wednesday, February 10, 2016 8:51 PM > On Feb 10, 2016, at 3:31 PM, Alan DeKok wrote: > > There are a host of procedural problems with how the document was adopted. I suggest that the document be withdrawn, and re-submitted as an individual draft. And at some stage in the process, there would be a check on any applicable IPR, which may colour the thinking as to whether or not this is suitable for an IETF Standard. I have yet to see any such claim or declaration yet, given the genesis of this protocol, would be surprised if there were not one. Tom Petch > To be clear: > > 1. the document never had a WG call for adoption as required in Section 4.2.1 of RFC 6174 > > 2. the charter has not been updated to reflect this work. > > 3. the charter says: > > "All new work items and rechartering proposals will be brought for approval with the IESG." > > 4. I can find no record of this approval taking place. If it had taken place, the charter would have been updated. > > 5. I had objected to this in person at the OPSAWG meeting in IETF 94. However, the web site shows no minutes from that meeting: > > https://tools.ietf.org/wg/opsawg/minutes > > 6. I believe that this document is an incorrect technical choice as per section 6.5.1 of RFC 2016. > > As such, I ask the chairs to withdraw the document as a WG document until such time as the procedural issues above have been addressed. > > Alan DeKok. From nobody Thu Feb 11 04:29:29 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5C1B2A2D for ; Thu, 11 Feb 2016 04:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 Xkou0JI-PapX for ; Thu, 11 Feb 2016 04:29:25 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE471B2A30 for ; Thu, 11 Feb 2016 04:29:24 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id 9so52706408iom.1 for ; Thu, 11 Feb 2016 04:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T0DpO0htimUHSalRGI6POMXJKrh6vRzOyHS0TafyfXY=; b=j1C+ZhbRVJEmPHQOeWVZ6FaBBbl9c/yqV/COeJgWNQei16wetJNxP1UpjRoXCcu34d TdydZvyyRXZBdl7rimm5wZkRMZo8wnH+PNF7lWfv7wOF5zlPD6bd3NDiZjxQqOF+BDGY tHgd3k7HY3e+qVrTbqIAfur9tR8EkUnPbn9hqcgJeSMiUNDfajvlhvQ5Ok0AatFrt375 HfYXikRz3ZfgmzGT2lCP+W0+8M5HIZDYOf++xN4UIwkNo0xwMMU5WUok/SdXf4joF+rN UF/4Vyhc0Jg/CU12NHgLefFzwQM9doAmtUeBR+t9GnJveI6vRFqQrrtTKrPB71EPXf5J 9eZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T0DpO0htimUHSalRGI6POMXJKrh6vRzOyHS0TafyfXY=; b=GfCQ+84/Z4TwU/2VZPSRnkXxy1LmQbknB0NKSb+7gob7XcLWvq12X6EdM/1gtzoJsD GlnSLi1Xeg2CchtLnhtIPQBBXhoU5mSulAHGIgmyDVf6Co0ZarexxqKMtVpQTvjSULDB QS382nRXz8xsQNEt0vAbHVKJuuqYnscD9PUN7YnWv9wAqWPIg58OqbCF2meH1MRT2cJo CuvhCjhJ97sUjGdn2NAlZ0jDPPMNyI7gOwYgvSFKUxz5JTGeuLw5m+iRhlmF6/3tkLA1 f70Wbcoa0I+vooPZWkDCE1iuyJ2NqcQ+huSoo98pXstnhSBUhoMSx0OfBZaCjClf2HWQ gzsg== X-Gm-Message-State: AG10YORgziX8tOALJM51N987cH6gQoubqafA5SDZuGhb+G8hKxrS7En/GL1F6pvrSIt1XQYDGfs12DNVNSAD+2Ta MIME-Version: 1.0 X-Received: by 10.107.129.89 with SMTP id c86mr46297928iod.102.1455193763939; Thu, 11 Feb 2016 04:29:23 -0800 (PST) Received: by 10.64.1.112 with HTTP; Thu, 11 Feb 2016 04:29:23 -0800 (PST) In-Reply-To: <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> Date: Thu, 11 Feb 2016 12:29:23 +0000 Message-ID: From: Andrej Ota To: Alan DeKok Content-Type: multipart/alternative; boundary=001a113f943c615377052b7db301 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 12:29:28 -0000 --001a113f943c615377052b7db301 Content-Type: text/plain; charset=UTF-8 I'll try to answer multiple points from multiple e-mails to try to avoid fragmented discussion. I do not dispute errors or omissions I made and which were pointed out. On he topic of 1st, 2nd, ... AAA protocol: My intention was not an ad hominem attack, but I did want to convey my strong aversion to statement implying TACACS+ is a late arrival when it is in fact a protocol we have been living with for almost 20 years without it ever being standardised or agreed upon. A feat I do not wish to be discounted or ignored, regardless of its origin. Ignoring it serves no useful purpose and I don't see it as benefiting anyone who wishes to discuss protocols and standardisation on the merit of usefulness to the network operator and vendor communities. On the topic of relation to other AAA protocols: TACACS+ definitely is AAA protocol and as such can be seen and used as a competitor to RADIUS. At the same time I do not see it as a direct replacement (to consider it a viable competitor) as it caters to a very specific niche related to a very specific work. Track record from last 20 years demonstrates the difference in scopes. Is it competing with RADIUS? I would rather say that RADIUS is competing with TACACS+ at this niche for last 20 years and still not doing a stellar job at it. Is there a meaningful way to address this difference in scopes? Would it help if we make it explicitly about network element AAA for management purposes and avoid chatting about NAS? I don't even know what to say about alleged push of vendors *against* RADIUS. I have to deal with few of vendors that only implement RADIUS and not TACACS+ while I have yet to bump into a vendor which does the opposite. On the topic of informational vs. standards track: Authors are aiming for standards track due to two reasons: 1) In the face of differing implementations, we cannot provide a simple recap of what works but we feel we have to make a statement on how it should work in the first place (e.g. removing ambiguities) without introducing major incompatibilities. 2) Device management AAA as used in the field today carries security risks. To address some of them, authors decided to slap some lipstick on a pig in the form of TLS tunnel. Having done this, we cannot honestly call this an informational RFC in the sense of how RFC 3164 was informational. On the topic of vendor-specific and the message that IETF sends: I'm sure I'm missing something here, but from what I understand, the main objection is procedural as in the draft wasn't properly adopted by workgroup to work on it. As long as that is addressed in accordance with the procedure, the draft could become IETF draft which WG would discuss and modify as it sees fit and one which could ultimately be considered for standards track RFC. I though we were in that process, but if it was botched, we certainly want to have that addressed. I understand and appreciate the sensitivity of IETF even appearing to give "a seal of approval" to some random vendor stuff. I certainly know how this work could be misinterpreted if not handled in a very transparent manner. But instead of a flat out refusal to deal with this protocol as it stands today, I would like to appeal for suggestions on how to address this in order to bring value to the community and industry. It's clear that this was originally a proprietary protocol. I also think it became more than that over two decades of use in a very specific niche area where AAA is used in network operations. With multi-vendor adoption and willingness of original authors to release it to current IETF process (copyrights, IPR and all included) I think we can accept both negative legacy and its practically demonstrated usability and viability while not encroaching on the territories which are undisputedly RADIUS and Diameter dominated. On the topic of slapping anyone in the face: Continued long-term existence of non-IETF and non-RFC AAA protocol, its widespread adoption in a single niche area and impact it has on the day to day network operations cannot be ignored or discounted. As much as RADIUS can be used in the same niche (as any other AAA protocol and other stuff like LDAP can be used for the same purpose), it did not supplant the non-standard solution for the last 20 years. I do not see how TACACS+ RFC (if it ever comes to it) would change this. While IETF is and should be forward-looking in defining how things could and should be done better, this doesn't mean that it should avoid dealing with sometimes ugly issues at hand as long as the work helps the community of users and vendors to do their work more efficiently. On the topic of technical benefits: There must be something that TACACS+ is doing at least good enough while RADIUS isn't doing it so much better to replace it. My personal opinion is that TACACS+ is simple and dumb enough protocol to be cheap to implement and still fit for the purpose. This two properties combined make it an attractive choice for both users and vendors. My personal experience is that TACACS+ appears to work more consistently over a range of different vendors than I can say for devices which provide RADIUS exclusively. I also find it easier to diagnose and debug as it uses reliable transport. RFC6613 was supposed to change the latter, but after 3+ years I still don't see it adopted for the purpose of network management AAA. On the topic of proprietary and vendor lock-in: I don't see any evidence of vendor lock-in after 20 years of use, but I do see a risk because there is no authoritative and standard definition of what is TACACS+. The IETF process is aimed to address this and I don't think calling out current proprietary status is an argument against considering the proposal, but rather an argument to work on a proposal. The IETF process should ensure that proprietary monicker is removed after all conditions are met. Proprietary protocol probably isn't evil by itself, but is made evil by the fact that even the original author cannot be held accountable if it changes it or ignores it. This effort aims to address that as well and is an argument to work on the proposal, not throwing it out. Current state of IPR for any TACACS+ implementor is unknown. The IETF process must and will ensure that all IPR will be ultimately disclosed which will take away a lot of stress an unknowns from both vendors and users. How can this ever be a wrong thing to do and how could it be bad if IETF is the one forcing the issue? I again see this as an argument to work on this within IETF and not reject all work on it. -- -- Andrej Ota Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland Registered in Dublin, Ireland - Registration # 368047 --001a113f943c615377052b7db301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll try to answer multiple= points from multiple e-mails to try to avoid fragmented discussion. I do n= ot dispute errors or omissions I made and which were pointed out.

On he topic of = 1st, 2nd, ... AAA protocol:
My intention wa= s not an ad hominem attack, but I did want to convey my strong aversion to = statement implying TACACS+ is a late arrival when it is in fact a protocol = we have been living with for almost 20 years without it ever being standard= ised or agreed upon. A feat I do not wish to be discounted or ignored, rega= rdless of its origin. Ignoring it serves no useful purpose and I don't = see it as benefiting anyone who wishes to discuss protocols and standardisa= tion on the merit of usefulness to the network operator and vendor communit= ies.

<= br>
On the topic of relation to other AAA p= rotocols:
TACACS+ definitely is AAA protoco= l and as such can be seen and used as a competitor to RADIUS. At the same t= ime I do not see it as a direct replacement (to consider it a viable compet= itor) as it caters to a very specific niche related to a very specific work= . Track record from last 20 years demonstrates the difference in scopes. Is= it competing with RADIUS? I would rather say that RADIUS is competing with= TACACS+ at this niche for last 20 years and still not doing a stellar job = at it.

Is there a meaningful way to address this difference in scopes? Would it h= elp if we make it explicitly about network element AAA for management purpo= ses and avoid chatting about NAS?

I don't even know what to say about alleged= push of vendors *against* RADIUS. I have to deal with few of vendors that = only implement RADIUS and not TACACS+ while I have yet to bump into a vendo= r which does the opposite.


On the topic of i= nformational vs. standards track:
Authors a= re aiming for standards track due to two reasons:
=C2=A01) In the face of differing implementations, we cannot provide= a simple recap of what works but we feel we have to make a statement on ho= w it should work in the first place (e.g. removing ambiguities) without int= roducing major incompatibilities.
=C2=A02) = Device management AAA as used in the field today carries security risks. To= address some of them, authors decided to slap some lipstick on a pig in th= e form of TLS tunnel.

Having done this, we cannot honestly call this an informat= ional RFC in the sense of how RFC 3164 was informational.


On the topic of vendor-specific and the message that IETF = sends:
I'm sure I'm missing somethi= ng here, but from what I understand, the main objection is procedural as in= the draft wasn't properly adopted by workgroup to work on it. As long = as that is addressed in accordance with the procedure, the draft could beco= me IETF draft which WG would discuss and modify as it sees fit and one whic= h could ultimately be considered for standards track RFC. I though we were = in that process, but if it was botched, we certainly want to have that addr= essed.

I understand and appreciate the sensitivity of IETF even appearing to give= "a seal of approval" to some random vendor stuff. I certainly kn= ow how this work could be misinterpreted if not handled in a very transpare= nt manner. But instead of a flat out refusal to deal with this protocol as = it stands today, I would like to appeal for suggestions on how to address t= his in order to bring value to the community and industry. It's clear t= hat this was originally a proprietary protocol. I also think it became more= than that over two decades of use in a very specific niche area where AAA = is used in network operations. With multi-vendor adoption and willingness o= f original authors to release it to current IETF process (copyrights, IPR a= nd all included) I think we can accept both negative legacy and its practic= ally demonstrated usability and viability while not encroaching on the terr= itories which are undisputedly RADIUS and Diameter dominated.


On the topic of slapping anyone in the face:
Continued long-term existence of non-IETF and non-RFC A= AA protocol, its widespread adoption in a single niche area and impact it h= as on the day to day network operations cannot be ignored or discounted. As= much as RADIUS can be used in the same niche (as any other AAA protocol an= d other stuff like LDAP can be used for the same purpose), it did not suppl= ant the non-standard solution for the last 20 years. I do not see how TACAC= S+ RFC (if it ever comes to it) would change this.

Whi= le IETF is and should be forward-looking in defining how things could and s= hould be done better, this doesn't mean that it should avoid dealing wi= th sometimes ugly issues at hand as long as the work helps the community of= users and vendors to do their work more efficiently.


On= the topic of technical benefits:
There mus= t be something that TACACS+ is doing at least good enough while RADIUS isn&= #39;t doing it so much better to replace it.

My personal opinion is that TACACS+ = is simple and dumb enough protocol to be cheap to implement and still fit f= or the purpose. This two properties combined make it an attractive choice f= or both users and vendors.

My personal experience is that TACACS+ appears to work= more consistently over a range of different vendors than I can say for dev= ices which provide RADIUS exclusively. I also find it easier to diagnose an= d debug as it uses reliable transport. RFC6613 was supposed to change the l= atter, but after 3+ years I still don't see it adopted for the purpose = of network management AAA.


On the topic of p= roprietary and vendor lock-in:
I don't = see any evidence of vendor lock-in after 20 years of use, but I do see a ri= sk because there is no authoritative and standard definition of what is TAC= ACS+. The IETF process is aimed to address this and I don't think calli= ng out current proprietary status is an argument against considering the pr= oposal, but rather an argument to work on a proposal.

The IETF process should ens= ure that proprietary monicker is removed after all conditions are met. Prop= rietary protocol probably isn't evil by itself, but is made evil by the= fact that even the original author cannot be held accountable if it change= s it or ignores it. This effort aims to address that as well and is an argu= ment to work on the proposal, not throwing it out.

Current state of IPR for any T= ACACS+ implementor is unknown. The IETF process must and will ensure that a= ll IPR will be ultimately disclosed which will take away a lot of stress an= unknowns from both vendors and users. How can this ever be a wrong thing t= o do and how could it be bad if IETF is the one forcing the issue? I again = see this as an argument to work on this within IETF and not reject all work= on it.


--
--
Andrej Ota

Google Ireland Ltd= ., Google Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ire= land - =C2=A0Registration # 368047
--001a113f943c615377052b7db301-- From nobody Thu Feb 11 06:06:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373411B320C for ; Thu, 11 Feb 2016 06:06:42 -0800 (PST) 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] autolearn=ham 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 tKwCnw8fXYCf for ; Thu, 11 Feb 2016 06:06:39 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AA98F1B31FC for ; Thu, 11 Feb 2016 06:06:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D7BBE12B9; Thu, 11 Feb 2016 14:06:38 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr2q_dAxB2Mh; Thu, 11 Feb 2016 14:06:38 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id A4111556; Thu, 11 Feb 2016 14:06:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 11 Feb 2016 09:06:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> To: Andrej Ota X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 14:06:42 -0000 I'll reply mostly in summary. TACACS+ is a late arrival to the IETF. It was never considered as an = AAA protocol by the IETF. 20 years of IETF consensus is that TACACS+ is = not an IETF protocol. It is not appropriate for a WG to re-consider = that decision without a larger involvement from the IETF. The fact that = a proprietary version of TACACS+ is also 20 years old is irrelevant to = the IETF process. If we ignore the IETF process here, we might as well = shut down the IETF as irrelevant. One WG should not be able to over-rule the rest of the IETF. TACACS+ catering to a "nice" related to specific work is command = authorization, or device administration. This use case is so niche that = it isn't even mentioned in the draft. This use-case *remains* a = vendor-specific proprietary protocol. It's successfully competed with = RADIUS in this space because the vendor refused to standardize command = authorization in RADIUS. Most likely because they saw it as a = competitive advantage. So... TACACS+ competed with RADIUS by forcing customers to use a = proprietary protocol, to the detriment of the standards. And the reward = for 20 years of this anticompetitive behaviour, is that we reward the = vendor with the label "IETF approved - standards track protocol". Again, there is *zero* technical reason to make TACACS+ a standards = track document. There are many procedural reasons to avoid making = TACACS+ a standards track document. i.e. 20 years of IETF consensus. Those are my objections. Please explain how the document is = *massively different* for implementors with two words changed: = "Informational" versus "Standards Tack". Please explain why we should = ignore 20 years of IETF consensus. > Is there a meaningful way to address this difference in scopes? Would = it help if we make it explicitly about network element AAA for = management purposes and avoid chatting about NAS? I have no objection to standardization of the functionality which is = now proprietary in TACACS+. I think it's a good idea. But = rubber-stamping TACACS+ without even *mentioning* device management in = the draft is bizarre at best. > On the topic of informational vs. standards track: > Authors are aiming for standards track due to two reasons: > 1) In the face of differing implementations, we cannot provide a = simple recap of what works but we feel we have to make a statement on = how it should work in the first place (e.g. removing ambiguities) = without introducing major incompatibilities. > 2) Device management AAA as used in the field today carries security = risks. To address some of them, authors decided to slap some lipstick on = a pig in the form of TLS tunnel. Neither of those reasons requires a standards track document. > On the topic of vendor-specific and the message that IETF sends: > I'm sure I'm missing something here, but from what I understand, the = main objection is procedural as in the draft wasn't properly adopted by = workgroup to work on it. As long as that is addressed in accordance with = the procedure, the draft could become IETF draft which WG would discuss = and modify as it sees fit and one which could ultimately be considered = for standards track RFC. I though we were in that process, but if it was = botched, we certainly want to have that addressed. No. The main objection (which would be seen in the IETF 94 minutes, = but they're missing) is the label "standards track". The fact that the procedure used to make it standards track was = "flexible" raises alarm bells. > I understand and appreciate the sensitivity of IETF even appearing to = give "a seal of approval" to some random vendor stuff. I certainly know = how this work could be misinterpreted if not handled in a very = transparent manner. But instead of a flat out refusal to deal with this = protocol as it stands today, I would like to appeal for suggestions on = how to address this in order to bring value to the community and = industry. Make the document informational. The rest of the content doesn't need to change. > On the topic of technical benefits: > There must be something that TACACS+ is doing at least good enough = while RADIUS isn't doing it so much better to replace it. Command authorization, because the vendor refuses to standardize it in = RADIUS. Which they could have done any time in the last 20 years. They = refused. Well... they refused. I fail to see how refusing to follow the = standards process means the we should reward them with an official = standards track RFC. Alan DeKok. From nobody Thu Feb 11 06:10:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6DC1B31F7 for ; Thu, 11 Feb 2016 06:10:40 -0800 (PST) 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] autolearn=ham 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 nDmgLxYTHJOB for ; Thu, 11 Feb 2016 06:10:34 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id ED4F51B31F5 for ; Thu, 11 Feb 2016 06:10:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 26A7912B9; Thu, 11 Feb 2016 14:10:33 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2SpTZ0VlB4A; Thu, 11 Feb 2016 14:10:33 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id B2C2BB63; Thu, 11 Feb 2016 14:10:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 11 Feb 2016 09:10:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 14:10:40 -0000 On Feb 11, 2016, at 1:14 AM, Mikael Abrahamsson = wrote: >=20 > On Wed, 10 Feb 2016, Alan DeKok wrote: >=20 >> My point is that TACACS+ has a 100% overlap in functionality with the = RADIUS protocol. >=20 > As an operator that has been running TACACS for 15+ years, my answer = to that is: >=20 > "I don't care". >=20 > I want the IETF to publish an RFC documenting TACACS as it's in use = currently. It's in wide use, and I don't see a reason not to let a = document through that documents what's already in use and potentially = adds a few more features. Please explain why the draft should be a standards track document, = instead of informational. And the document does not describe TACACS+ as it is currently in use. = As such, it does not meet your criteria. > If someone came and asked for a new WG for TACACS, that would be a = different matter. But that's what's being done here. The OPSAWG is the WG which is = working on TACACS+.=20 Alan DeKok. From nobody Thu Feb 11 06:58:10 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529141B32E4 for ; Thu, 11 Feb 2016 06:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 QeJltMFPqhj0 for ; Thu, 11 Feb 2016 06:58:07 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53AD1B32E5 for ; Thu, 11 Feb 2016 06:58:06 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D0124A2; Thu, 11 Feb 2016 15:58:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1455202682; bh=VbscDhO8PqqsBxfwWrCQ3W6pQ7yq4qNVIOXeDUd9lE0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ma/09+cgB5yfISv0YnbMFWfCtUA3s+bZaOHEFKICo2QD/v7acSa10aJU/rUhwHc+t ea5iNyWfCpjJO0gL/Ngx2+2xlSD2D516bdGqsi/sv6onSU8kp2RSUo+0/ojik19JZX JP6eLt4BzS+vuSWO9DFieHfP7nCG40WpfeSKqPXk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CA0E0A1; Thu, 11 Feb 2016 15:58:02 +0100 (CET) Date: Thu, 11 Feb 2016 15:58:02 +0100 (CET) From: Mikael Abrahamsson To: Alan DeKok In-Reply-To: <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> Message-ID: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 14:58:09 -0000 On Thu, 11 Feb 2016, Alan DeKok wrote: >> If someone came and asked for a new WG for TACACS, that would be a different matter. > > But that's what's being done here. The OPSAWG is the WG which is working on TACACS+. Clarification, nobody has asked to form a TACACS WG. Also, just for clarification, your objection is that the proposed document is standards-track, and you want it to be informational? When reading your email it seems sometimes that you don't want this to be a OPSAWG document at all, sometimes that you don't want TACACS documented as an RFC at all, sometimes that your main objection is that there has been a procedural error. I want TACACS to become documented as an RFC, preferably all functionality currently in wide spread use. In your view, how do we get that done? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Feb 11 07:25:40 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDA81B3364 for ; Thu, 11 Feb 2016 07:25:38 -0800 (PST) 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] autolearn=ham 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 RhLSrPDotCCZ for ; Thu, 11 Feb 2016 07:25:36 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 24A271B3365 for ; Thu, 11 Feb 2016 07:25:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 7EE56D14; Thu, 11 Feb 2016 15:25:35 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngkJy1I0vA36; Thu, 11 Feb 2016 15:25:35 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id ECF09556; Thu, 11 Feb 2016 15:25:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 11 Feb 2016 10:25:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 15:25:38 -0000 On Feb 11, 2016, at 9:58 AM, Mikael Abrahamsson = wrote: > Also, just for clarification, your objection is that the proposed = document is standards-track, and you want it to be informational? When = reading your email it seems sometimes that you don't want this to be a = OPSAWG document at all, sometimes that you don't want TACACS documented = as an RFC at all, sometimes that your main objection is that there has = been a procedural error. My objection is all of that. When people say "We want the draft to be = standardized for reason X", I have objections to X. For many versions = of X. - there are procedural issues with WG adoption of the document - even if there were no procedural issues, the document violates IETF = consensus as described in RFC 3127 - even if there were no procedural issues or violation of IETF = consensus, the document does not describe the stated use-case for why = it's being adopted - even if none of the above happened, the functionality in the document = overlaps 100% with RADIUS, and is therefore technically unnecessary - even if none of the above happened, the protocol could be sufficiently = documented via publication as an information document, instead of a = standards track document For each reason individually, and for all of those reasons together, = this document should not be a standards track document. > I want TACACS to become documented as an RFC, preferably all = functionality currently in wide spread use. In your view, how do we get = that done? Publish it was an informational document, via an individual submission = and AD sponsorship. Alan DeKok. From nobody Thu Feb 11 08:31:11 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6561B3438 for ; Thu, 11 Feb 2016 08:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 5asryr_Rt_l9 for ; Thu, 11 Feb 2016 08:31:08 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8661A1B343B for ; Thu, 11 Feb 2016 08:31:07 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id tk3so18434466lbb.3 for ; Thu, 11 Feb 2016 08:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SrmqUczSWInGVD2aFe2dZ15i///vPPCWu0fUvsgVbAw=; b=yCROCEZBO3TiIayXS6jeCSYZBSDpqdyValzJ+sTP5OnOa1SNaCnqCS447LH0C2d7fh ipFXGDZ7CVk87BtO+x76U8n1XXGM1JS9db7j4TiMWUY9Csftl+fvrupsHHWm/xsHFkhD Xm3aiVl2B73BcbCiT7/OouDQba8mzQH+UHd2QtApEGG6tvwveM9UQl/G9Z50De+myIU7 8g/M6+Wd5BLprOAqrHYV50XU4MVL6GcbSlyQy5AEliZzGRuAoKs/i7sDjGeAfhStAbAQ H2txBK11bjXxVrZCUz2KSymK0gWavzvmTQXf7oWWFcAhlRk/QXBW5/tLgVHC9oL3jlyj YYxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SrmqUczSWInGVD2aFe2dZ15i///vPPCWu0fUvsgVbAw=; b=FOJYEgLfhBgl7qeG6KqodIPAc8DSbszWCBBNkC69CH7QOKVOWM9N77dIj1WgBuCAdi QEq77hDqEg/9ejSG2P2bXP5ze7Hn3ocjoiD2ExJN5DcNxq3zSMXQQ8RNFNhaQ7u7MYaT QHKcUt3NXFmzj/5aOSeflC8ks68yjzcwfgRa8gUJ/hYUNGbGDMnUHn5TAzzwk6yN77QB gScPW+8II1no9CGefaU7QkYiNkgRI3LOkm8FDA4EEMYvib3gKIAuhCok7j90mXhkgx3P 95HfAdZ86RCgWMSSVN+IHL/3sQOrUhqEtcJPEimKp/NHOhT+nvR8i/RRP6AU6z+qDG60 YXBA== X-Gm-Message-State: AG10YORf8qTZ4zDU0B5YwUBKaAOYY2mOPafrHndXlTT+TUnE2b0zNQbGcMfiENvqMZaRz1HMB3s0xee3cYeFgA== MIME-Version: 1.0 X-Received: by 10.112.164.97 with SMTP id yp1mr18707974lbb.30.1455208265778; Thu, 11 Feb 2016 08:31:05 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 11 Feb 2016 08:31:05 -0800 (PST) In-Reply-To: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> Date: Thu, 11 Feb 2016 08:31:05 -0800 Message-ID: From: Andy Bierman To: Alan DeKok Content-Type: multipart/alternative; boundary=001a11c33c98c1a141052b8113ac Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 16:31:10 -0000 --001a11c33c98c1a141052b8113ac Content-Type: text/plain; charset=UTF-8 On Thu, Feb 11, 2016 at 7:25 AM, Alan DeKok wrote: > On Feb 11, 2016, at 9:58 AM, Mikael Abrahamsson wrote: > > Also, just for clarification, your objection is that the proposed > document is standards-track, and you want it to be informational? When > reading your email it seems sometimes that you don't want this to be a > OPSAWG document at all, sometimes that you don't want TACACS documented as > an RFC at all, sometimes that your main objection is that there has been a > procedural error. > > My objection is all of that. When people say "We want the draft to be > standardized for reason X", I have objections to X. For many versions of X. > > - there are procedural issues with WG adoption of the document > > - even if there were no procedural issues, the document violates IETF > consensus as described in RFC 3127 > > - even if there were no procedural issues or violation of IETF consensus, > the document does not describe the stated use-case for why it's being > adopted > > - even if none of the above happened, the functionality in the document > overlaps 100% with RADIUS, and is therefore technically unnecessary > > - even if none of the above happened, the protocol could be sufficiently > documented via publication as an information document, instead of a > standards track document > > > For each reason individually, and for all of those reasons together, > this document should not be a standards track document. > > > I want TACACS to become documented as an RFC, preferably all > functionality currently in wide spread use. In your view, how do we get > that done? > > Publish it was an informational document, via an individual submission > and AD sponsorship. > I do not have a dog in this hunt, but I agree with Alan that the "WG standardization process" should not be used to rubber-stamp or simply document a vendor protocol. It should be used where multiple competing documents are evaluated as a starting point for the WG. An AD-sponsored Informational RFC is the correct process if you want to rubber-stamp a document without a consensus-based process. > Alan DeKok. > > Andy > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a11c33c98c1a141052b8113ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 11, 2016 at 7:25 AM, Alan DeKok <aland@deployingra= dius.com> wrote:
On Feb 1= 1, 2016, at 9:58 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> Also, just for clarification, your objection is that the proposed docu= ment is standards-track, and you want it to be informational? When reading = your email it seems sometimes that you don't want this to be a OPSAWG d= ocument at all, sometimes that you don't want TACACS documented as an R= FC at all, sometimes that your main objection is that there has been a proc= edural error.

=C2=A0 My objection is all of that.=C2=A0 When people say "We want the= draft to be standardized for reason X", I have objections to X.=C2=A0= For many versions of X.

- there are procedural issues with WG adoption of the document

- even if there were no procedural issues, the document violates IETF conse= nsus as described in RFC 3127

- even if there were no procedural issues or violation of IETF consensus, t= he document does not describe the stated use-case for why it's being ad= opted

- even if none of the above happened, the functionality in the document ove= rlaps 100% with RADIUS, and is therefore technically unnecessary

- even if none of the above happened, the protocol could be sufficiently do= cumented via publication as an information document, instead of a standards= track document


=C2=A0 For each reason individually, and for all of those reasons together,= this document should not be a standards track document.

> I want TACACS to become documented as an RFC, preferably all functiona= lity currently in wide spread use. In your view, how do we get that done?
=C2=A0 Publish it was an informational document, via an individual submissi= on and AD sponsorship.


I= do not have a dog in this hunt, but I agree with Alan that the "WG st= andardization process"
should not be used to rubber-stamp or= simply document a vendor protocol. It should be
used where multi= ple competing documents are evaluated as a starting point for the WG.
=

An AD-sponsored Informational RFC is the correct proces= s if you want to rubber-stamp
a document without a consensus-base= d process.


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--001a11c33c98c1a141052b8113ac-- From nobody Thu Feb 11 09:14:29 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75A1B3669 for ; Thu, 11 Feb 2016 09:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 JeOjGCVamBCq for ; Thu, 11 Feb 2016 09:14:21 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EEF1B3662 for ; Thu, 11 Feb 2016 09:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h5SYtSJ//Km3B6gUDlqA7rVsplg4N0dYOQt/ngKIyFY=; b=Oxuud5zfQzDUhlnfblagHUub3lPffuE9eJz/XogU3UqJflb8OVbfnO3w/mDBiR/dfTuoHL7mkDbdLe7SWhiooaiCnWuPo/9v2ZLDk0FYmNuf8uUB+ukBWAq3F/L5a0gddIeMEWdo1liyVd53Mx/OWKcrGfZcFNCKkL+fhG5+81Y= Authentication-Results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.409.10; Thu, 11 Feb 2016 17:13:59 +0000 Message-ID: <007901d164ef$228a37e0$4001a8c0@gateway.2wire.net> From: t.petch To: Andrej Ota , Alan DeKok References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> Date: Thu, 11 Feb 2016 17:09:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: AM3PR02CA0017.eurprd02.prod.outlook.com (10.242.240.17) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB055; 2:JYaPznlBseiO/sA0eYxUEVLCcp0v2CHPyjHDv/WLY7m4h/0bt4Zl6RU6olcMH8P4H9bg3wyV39AqnThdhPnGHeNkK/4pfBar29SABas3CqN+J5wIWsQP8iVUjOz2uzbIWCbPUWLN/DVnjwTc3APtUw==; 3:7MwTG1jdumNNwnHMIamQVb1qNyOCM84ywiaAaxyIMR2/acLH6ZbCvwqyBy7rHgHFOPk7rQfnzuUUqPXts/SgVgV7ldZti1uB+2ZW6c1wNCxex6HizGvHZS/qwB0cU+SH; 25:dh0zg0F7DcRrYyBOouDLD6UYoeqUXYqVeJUQefIaR2pF2Kjsk5YsOC2aYnHV6lgF1Sy9ucb/mOheg/IpmrTH/cCSz64II3CLyWxhIeXp8FyfU8+m1hQWff9dw+LbNOx9MmE9LUQr/2yWKGoZZTOtwbxhvbB0eCueJ5hdP6nWoPcik6EqdMjWPPh6geb4Pp8v/MP4UJ8sYvkW7fjxl2n2Ym3VDbCkzbRPmAHOG/ttybELJieiUrABY+zXmJC4caXfaQZ/C8v/5K5fzsispRY6usVomuooer880Oilv1euTeD3h91SuIK16laH9Mw26wql X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-MS-Office365-Filtering-Correlation-Id: a48f6090-4042-4fc9-e486-08d33306bb36 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMXPR07MB055; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB055; X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB055; 4:EBIS/+MpAEgfxctpanuD0+hSGCs/7qvZBh+zk4YcP/fvEg/tBoreqrqyICERTtqzFfkGaXwecD/nV2L5X4yTs4IyoeMDOvd4slLPOfDq6E9HV7UcgcPDiEswmGlJJFuyh1Jz0oU3bEp2wTAJc9zY/2aylmvwkyOkl3i/taPGe3crzidgZaHmD2BXZUhHPbibHg1lUBr+xe5ds+XeMPm7V7AhsWOxZ1s6XIWLh0vdWdeEoM7j2yTkqPgz6fLcyI0gV2muEW75o5Mtlqz/rbaXiRTwcwJeoKpgo9jVS/TUac7ilL07fcB7p7duQqJiKxMQEm//LwpzHdngCUppdCF4dBviJP+SJdFw0jqlcKluJqtrACBAyXjjQ9hLOIXWURd3 X-Forefront-PRVS: 08497C3D99 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(1096002)(116806002)(230700001)(87976001)(5004730100002)(15975445007)(77096005)(44736004)(586003)(3846002)(14496001)(189998001)(23676002)(6116002)(122386002)(92566002)(50226001)(561944003)(5001770100001)(86362001)(76176999)(66066001)(5001960100002)(81816999)(50466002)(62236002)(93886004)(42186005)(81686999)(4326007)(44716002)(33646002)(61296003)(2906002)(50986999)(5008740100001)(19580405001)(19580395003)(40100003)(47776003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVhQUjA3TUIwNTU7MjM6VkUrWjV6aElZOWJYbm1hY0NLQ2xWL2Fla1ll?= =?utf-8?B?NDl6ODczb0FxTjRITCtIOS9HZTlQNXpzWnd0NWE5cXRaQ1lNU284WW5kcmU2?= =?utf-8?B?Y2pKY3pDSmUxRGpIQjFubzRDeHc4b3Y4ejZQY1NMTXVlME0wZ3FvVS96Q3FR?= =?utf-8?B?VlVscmMwc016RmR3b1VVZi96OGRwclZGV0hMbThZdnRsbTRqdEdCUkdORnlD?= =?utf-8?B?OUhpN3BiQWpzSzJTaVN6VEFoV0pTVTJtMVdNT0dSNW9EbWs5VllLWHEvUHlS?= =?utf-8?B?cTdBaEMxY0FTYWhoeHB4Z3JmMUZpV1pxaHNBSjF1dHVMRTNtSldkZ2Q4Z1NO?= =?utf-8?B?UjMvOEdQeVc5ODNESjVoVFYyY1ptTjhseU9rT2NtNVlvbTZEM0tLSmJJd0x0?= =?utf-8?B?dDhsT0IyNkJDM3BZdFdQQU1XVkE1cXNGTTR5WG1TaE1nZEhqejBsaVh0d3I4?= =?utf-8?B?SXVvZHlhMU9iY2JDczM5ZnRHdHlDTHRWcHRTejA2dGZ5TUlFeGlkMVRQcjZ6?= =?utf-8?B?RHFHYVlJY2kxQnVBSy9LRlpaMW9UTmlIR28rdmhrV2xnZjJHREhmM0p5bkp4?= =?utf-8?B?b001SkZ5VmZ1TUVoMlIyZ0RabDJJeGlPbDRZZGI3SFF6ZENKeVRzWTYwZ1Fr?= =?utf-8?B?QVhKcnZDUG4xck1oYTFrNkFteVhDdEdPMXpsSDdSUjlmbXNzSHN1TkZnUmR2?= =?utf-8?B?MzJORW1qUFZ0SlpzbjJlQUdIM2M1dVRlbklRR1NYU21JNWZ6L0UvNTY5OG9F?= =?utf-8?B?cjdHQ3JhbXlkNHVVVkpkQjVYNVJ5ZXBVNDQ0RHFpdVUrZTljaU4vemMyUC9u?= =?utf-8?B?VjU5cVhGTXRQRHR6TGNFRHJKekMvaEZieEJRMFNUd0VlU0RZNmI1S3l6MEFB?= =?utf-8?B?VDlDcG1XS2sxVC9OYnc1ZWx1OXNFMHpkRis2SlNrN2ZEMStSVkFDUEtUWjd1?= =?utf-8?B?WFpxbWNkVUpwM05TbERVbVFvd05Qd3UxdDZ3bGNXL1FvbGhhTWlsTGJvczNK?= =?utf-8?B?dnhXMk9ubSttdGF4dCtPK3RERXFKeU1CWnBiaEFtNHNsaDJtRFlkNUl1OXBn?= =?utf-8?B?eGI1VmhwQ0Z3WlNyZmdYL3VJUmdjcDlqckF2RXczelZrUzN2akxZQTAvWGk3?= =?utf-8?B?enBxeURMemswYWY2VG9qMWExNlpzMnlWajdPR3ZhM1RKTi9FaFI1ZU5xRWtq?= =?utf-8?B?TnI1MVpqc0xIYUFvSXR0QnBMN1VienRUenZzOXU3Zmt6QjM2cm1RUHZlRE5J?= =?utf-8?B?Z1YxT0pWT2lsZzNxTU1KQmdNNjBMUFE5N0t0b2dSaU5pUDdNdlN5SlFOalJn?= =?utf-8?B?RStiMC9obytVNm9LVjVNbG1Wa29uZ1hYMUYwSFJ5QzVpSlVwRDhVQU5jUTNY?= =?utf-8?B?dHE3U1R5Qm1Lc1lVanhHOSs2cnVYYUhQRjlLY1Y5NW14Tk5uSUhFWllVSVpQ?= =?utf-8?B?WGxsdVJMaUFCOXIyU0RKMzJCT3V3enZGM3JsVzF4d1RFL3lodnVnckhVVFlm?= =?utf-8?B?Y2Irb1RiWGNBNXNEVVdObFdIRCtKMENjZk1BdEh1R2FGNTR2ZE1EUWxjQUVv?= =?utf-8?Q?PIt/ny8duYpRaATgOEslglsH5YQyPzB2sPpkN3lklbQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB055; 5:TwzDbtTgG9x0A7RKacYUrLm95yzLRTtdPStWP/AMxEvAlsrVABUOyJOYbNln6wFncvnSkDdfxQ/FvRoNinzalzXkylT8zmgusQkvqw7GcGScjlidWvIy/6UGkmBKQoD5NnrcRXAKpbUK8ryPqVBxyw==; 24:tDhmS1Kg6NPPkHZhaWy/EmxqlSPVfG+k9+cMM3J7YvOJur8zCiO/GELyMM9YrRRc2lswTVDXc/Ga0mYdVX3eIf/AxwiKn5YAUARlM/Zwy8Y= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2016 17:13:59.0009 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , opsawg@ietf.org, Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 17:14:28 -0000 Tom Petch ----- Original Message ----- From: "Andrej Ota" Sent: Thursday, February 11, 2016 12:29 PM > I'll try to answer multiple points from multiple e-mails to try to avoid > fragmented discussion. I do not dispute errors or omissions I made and > which were pointed out. > > On he topic of 1st, 2nd, ... AAA protocol: > My intention was not an ad hominem attack, but I did want to convey my > strong aversion to statement implying TACACS+ is a late arrival when it is > in fact a protocol we have been living with for almost 20 years without it > ever being standardised or agreed upon. A feat I do not wish to be > discounted or ignored, regardless of its origin. Ignoring it serves no > useful purpose and I don't see it as benefiting anyone who wishes to > discuss protocols and standardisation on the merit of usefulness to the > network operator and vendor communities. > > > On the topic of relation to other AAA protocols: > TACACS+ definitely is AAA protocol and as such can be seen and used as a > competitor to RADIUS. At the same time I do not see it as a direct > replacement (to consider it a viable competitor) as it caters to a very > specific niche related to a very specific work. Track record from last 20 > years demonstrates the difference in scopes. Is it competing with RADIUS? I > would rather say that RADIUS is competing with TACACS+ at this niche for > last 20 years and still not doing a stellar job at it. > > Is there a meaningful way to address this difference in scopes? Would it > help if we make it explicitly about network element AAA for management > purposes and avoid chatting about NAS? > > I don't even know what to say about alleged push of vendors *against* > RADIUS. I have to deal with few of vendors that only implement RADIUS and > not TACACS+ while I have yet to bump into a vendor which does the opposite. > > > On the topic of informational vs. standards track: > Authors are aiming for standards track due to two reasons: > 1) In the face of differing implementations, we cannot provide a simple > recap of what works but we feel we have to make a statement on how it > should work in the first place (e.g. removing ambiguities) without > introducing major incompatibilities. > 2) Device management AAA as used in the field today carries security > risks. To address some of them, authors decided to slap some lipstick on a > pig in the form of TLS tunnel. > > Having done this, we cannot honestly call this an informational RFC in the > sense of how RFC 3164 was informational. > > > On the topic of vendor-specific and the message that IETF sends: > I'm sure I'm missing something here, but from what I understand, the main > objection is procedural as in the draft wasn't properly adopted by > workgroup to work on it. As long as that is addressed in accordance with > the procedure, the draft could become IETF draft which WG would discuss and > modify as it sees fit and one which could ultimately be considered for > standards track RFC. I though we were in that process, but if it was > botched, we certainly want to have that addressed. > > I understand and appreciate the sensitivity of IETF even appearing to give > "a seal of approval" to some random vendor stuff. I certainly know how this > work could be misinterpreted if not handled in a very transparent manner. > But instead of a flat out refusal to deal with this protocol as it stands > today, I would like to appeal for suggestions on how to address this in > order to bring value to the community and industry. It's clear that this > was originally a proprietary protocol. I also think it became more than > that over two decades of use in a very specific niche area where AAA is > used in network operations. With multi-vendor adoption and willingness of > original authors to release it to current IETF process (copyrights, IPR and > all included) I think we can accept both negative legacy and its > practically demonstrated usability and viability while not encroaching on > the territories which are undisputedly RADIUS and Diameter dominated. > > > On the topic of slapping anyone in the face: > Continued long-term existence of non-IETF and non-RFC AAA protocol, its > widespread adoption in a single niche area and impact it has on the day to > day network operations cannot be ignored or discounted. As much as RADIUS > can be used in the same niche (as any other AAA protocol and other stuff > like LDAP can be used for the same purpose), it did not supplant the > non-standard solution for the last 20 years. I do not see how TACACS+ RFC > (if it ever comes to it) would change this. > > While IETF is and should be forward-looking in defining how things could > and should be done better, this doesn't mean that it should avoid dealing > with sometimes ugly issues at hand as long as the work helps the community > of users and vendors to do their work more efficiently. > > > On the topic of technical benefits: > There must be something that TACACS+ is doing at least good enough while > RADIUS isn't doing it so much better to replace it. > > My personal opinion is that TACACS+ is simple and dumb enough protocol to > be cheap to implement and still fit for the purpose. This two properties > combined make it an attractive choice for both users and vendors. > > My personal experience is that TACACS+ appears to work more consistently > over a range of different vendors than I can say for devices which provide > RADIUS exclusively. I also find it easier to diagnose and debug as it uses > reliable transport. RFC6613 was supposed to change the latter, but after 3+ > years I still don't see it adopted for the purpose of network management > AAA. > > > On the topic of proprietary and vendor lock-in: > I don't see any evidence of vendor lock-in after 20 years of use, but I do > see a risk because there is no authoritative and standard definition of > what is TACACS+. The IETF process is aimed to address this and I don't > think calling out current proprietary status is an argument against > considering the proposal, but rather an argument to work on a proposal. > > The IETF process should ensure that proprietary monicker is removed after > all conditions are met. Proprietary protocol probably isn't evil by itself, > but is made evil by the fact that even the original author cannot be held > accountable if it changes it or ignores it. This effort aims to address > that as well and is an argument to work on the proposal, not throwing it > out. > > Current state of IPR for any TACACS+ implementor is unknown. The IETF > process must and will ensure that all IPR will be ultimately disclosed > which will take away a lot of stress an unknowns from both vendors and > users. How can this ever be a wrong thing to do and how could it be bad if > IETF is the one forcing the issue? I again see this as an argument to work > on this within IETF and not reject all work on it. The IETF process is that each contributor must disclose any known IPR - "all those contributing to the working group's discussions must disclose the existence of any IPR the Contributor or other IETF participant believes Covers or may ultimately Cover the technology under discussion." [BCP0079] except that I know that US legal liability makes companies there keep their staff in ignorance of such IPR so what I expect, and do not yet see, is a disclosure from the company in question. That can and does make a difference to the decisions of the IETF. Tom Petch > > -- > -- > Andrej Ota > > Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland > Registered in Dublin, Ireland - Registration # 368047 > ------------------------------------------------------------------------ -------- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Thu Feb 11 09:19:40 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF21B3685 for ; Thu, 11 Feb 2016 09:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 EoMOzkG359Ob for ; Thu, 11 Feb 2016 09:19:38 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59DF1B367D for ; Thu, 11 Feb 2016 09:19:37 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id g127so44381174ywf.2 for ; Thu, 11 Feb 2016 09:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PBlMHTaXZoCIpQvFVlsEwBKJL90/IiUh69LiBGSRm7I=; b=ZG2qpaeNe0kAAQexcs60HUESA03lkGihvF4fBaGyIsHmVen6AYQutS2JYRKYpn5lON snqurch/AhFbCGvBnlAXzRHqbTKiAMxD3Uu0WUoZzJEzAsMtht60YEi+pLUZ1i8v63X1 ptc9S5EZEjZk7Jcxghq3wuQkQgliE1LiyEvAkx1FEvsPTf1GEVZCaxaqzqULv58RdZ+h 5oBxm70GNGOsZGeKL1AgM13wMhX+WsYrkIX97V8pKR2qAU0ew8NIktvVAe+Jqmijd0Rg 8wOqCwvT5761ISjJoS5MLqx0xWygQotebJDiJ7E3uVngJu/y6B5KKJzYDylA0rsKo5UJ NzXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PBlMHTaXZoCIpQvFVlsEwBKJL90/IiUh69LiBGSRm7I=; b=J5PK5p+lEB323ZzVcqJ6yWmqhUZLmj/gztkPTOIE6OpJ29G9Lzm9tDeZQE80OEQo5G 5UHymPv7RqnH1s3H2+BTy8DMyyVH1BDkRLToeHxxgQMNf07Qr+XrzSiF8B1193xkn3kG gESHwG3z20b11YuHZs+28Wz/jggSNkw1W1zRCM76OmgLvQkgWsdWOOMbSO8hf4VViaVt DxnJnsa5kzI90qDwQ6Kv/UrGJhurz8Wz18kIsPZQ1iQi0croMWschWh7NrCSUbi44ze3 llErq9CFERTPG38oqkpbMYD9SSglyfIA3sHJXuJtVdMeIZoJopxnjpU16gPaJT+9OfYx gs5Q== X-Gm-Message-State: AG10YORuLldOzdWSGfNZzIXmhpBAMW7aG5ka15ca0ttwFzpMMNxAkHUmGEDJM436rmsWDO2KoYB6mBjJKKEjWw== MIME-Version: 1.0 X-Received: by 10.129.76.145 with SMTP id z139mr12242980ywa.56.1455211177167; Thu, 11 Feb 2016 09:19:37 -0800 (PST) Received: by 10.13.209.198 with HTTP; Thu, 11 Feb 2016 09:19:37 -0800 (PST) In-Reply-To: <1B6433C3-8F88-4832-B007-0A544DD5A315@deployingradius.com> References: <1B6433C3-8F88-4832-B007-0A544DD5A315@deployingradius.com> Date: Thu, 11 Feb 2016 12:19:37 -0500 Message-ID: From: Christopher Morrow To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ New Version with AI extensions for playing Go. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 17:19:39 -0000 On Wed, Feb 10, 2016 at 3:51 PM, Alan DeKok wro= te: > On Feb 10, 2016, at 3:40 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> >> You have a point - but TACACS is a reality that isn=E2=80=99t going away= . Thus >> specifying how to use it/interoperate with it seems useful. > > Then it should be published as an individual submission, as an informat= ional document. > > I submit that we should be parsimonious with the IETF "stamp of approva= l". Publishing a proprietary vendor protocol as an *IETF standard protocol= * is a huge problem. there's no 'stamp of approval' yet, wg adoption is really just "this is something that the wg is interested in working on" It may flounder and die, or it may blossom into a useful standards document. > > Cisco had 18 years to submit the document for consideration by the IETF= . They decided not to. That's fine, it's their decision. > as a reminder it's not 'cisco' but the authors as individuals... who may ha= ve: A) been pulled away from the work for other reasons B) not wanted to get abused by ietf folk for something that is working and has adoption across a wide swath of the industry C) other - it's not super important I suppose really WHY they didn't pursue this work in 1996... Almost all vendors today implement tacacs+ (mostly tac+) for AAA services on their devices after all. > This isn't publishing extensions to existing documents, where the WG ha= s been disbanded. This isn't publishing documents which are relevant to mu= ltiple working groups, but don't really belong in any particular one. > oddly there's not a 'networking working group' anymore, since the work fits well with 'ops' area work this doesn't seem like a bad place for it to happen. > This is creating an entirely new standard protocol, which is in direct = competition to existing, and active, working groups. Worse, it's a protoco= l which the vendor refused to document for 18 years. > it's not 'entirely new', it's actually 20 yrs old, needs improvements for security AND operations/management reasons and is used across almost all network equipment in large networks (private networks, public networks, enterprise networks, etc). > Now that they're getting bit by interoperability issues, they're seekin= g the IETF stamp of approval. It's a complete end-run around the entire IE= TF process. > I don't think the complaint is 'interoperability issues' as much as: "Gosh, this should be standardized so we have a platform to make improvements to the security problems we see in the active protocol today." -chris > Alan DeKok. > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Feb 11 09:21:10 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA78E1B367E for ; Thu, 11 Feb 2016 09:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 c99zjwHNa-Sc for ; Thu, 11 Feb 2016 09:21:06 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2D31B367D for ; Thu, 11 Feb 2016 09:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8506; q=dns/txt; s=iport; t=1455211266; x=1456420866; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yRL2mZzQtTEwfrgdEu3o5Ogbe/61l0D3p6GIqBCGeRE=; b=iMX06UvD59HeCVJQWXO8hZjb4iyYEj83YWhzySJ7O1LgbWau6lHYieeX daiHETVPTkv4AblZolBbg8OEGKbWisbStuH30xn3A8f7rAaYA6te2PwDt 2g8TvKMjcSF+mj2I0+2iIyOn24F/2vixME2salgPeOdxUuU3ibvzkteNH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATBQDgwbxW/4YNJK1egzpSbQaIVbMXF?= =?us-ascii?q?wqFIkoCgTU8EAEBAQEBAQGBCoRBAQEBBAEBATctBwQHDAQCAQgVASAQJwslAgQ?= =?us-ascii?q?BDQUUB4d/DsFKAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKSIhsBYdTjyQBiDmFG?= =?us-ascii?q?Y51jj0BNyuCAhmBSmqHV3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,431,1449532800"; d="scan'208";a="72425634" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 17:21:05 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u1BHL4LX012255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 17:21:04 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 11:21:04 -0600 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.1104.009; Thu, 11 Feb 2016 11:21:04 -0600 From: "Douglas Gash (dcmgash)" To: "t.petch" , Andrej Ota , Alan DeKok Thread-Topic: [OPSAWG] Procedural issues with the TACACS+ document Thread-Index: AQHRZETbgK9sXm7A1E6w0iosJTGYMp8mJ2sAgAAUE4CAAFmoAIAAlpKA///q91CAAGaCgA== Date: Thu, 11 Feb 2016 17:21:03 +0000 Message-ID: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <007901d164ef$228a37e0$4001a8c0@gateway.2wire.net> In-Reply-To: <007901d164ef$228a37e0$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <11CCC301AB0E7249BDB68BA7FAB46C54@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 17:21:09 -0000 Let me follow up on that, to make sure there are no obstacles form that perspective. On 11/02/2016 17:09, "t.petch" wrote: > > >Tom Petch > >----- Original Message ----- >From: "Andrej Ota" >Sent: Thursday, February 11, 2016 12:29 PM > > >> I'll try to answer multiple points from multiple e-mails to try to >avoid >> fragmented discussion. I do not dispute errors or omissions I made and >> which were pointed out. >> >> On he topic of 1st, 2nd, ... AAA protocol: >> My intention was not an ad hominem attack, but I did want to convey my >> strong aversion to statement implying TACACS+ is a late arrival when >it is >> in fact a protocol we have been living with for almost 20 years >without it >> ever being standardised or agreed upon. A feat I do not wish to be >> discounted or ignored, regardless of its origin. Ignoring it serves no >> useful purpose and I don't see it as benefiting anyone who wishes to >> discuss protocols and standardisation on the merit of usefulness to >the >> network operator and vendor communities. >> >> >> On the topic of relation to other AAA protocols: >> TACACS+ definitely is AAA protocol and as such can be seen and used as >a >> competitor to RADIUS. At the same time I do not see it as a direct >> replacement (to consider it a viable competitor) as it caters to a >very >> specific niche related to a very specific work. Track record from last >20 >> years demonstrates the difference in scopes. Is it competing with >RADIUS? I >> would rather say that RADIUS is competing with TACACS+ at this niche >for >> last 20 years and still not doing a stellar job at it. >> >> Is there a meaningful way to address this difference in scopes? Would >it >> help if we make it explicitly about network element AAA for management >> purposes and avoid chatting about NAS? >> >> I don't even know what to say about alleged push of vendors *against* >> RADIUS. I have to deal with few of vendors that only implement RADIUS >and >> not TACACS+ while I have yet to bump into a vendor which does the >opposite. >> >> >> On the topic of informational vs. standards track: >> Authors are aiming for standards track due to two reasons: >> 1) In the face of differing implementations, we cannot provide a >simple >> recap of what works but we feel we have to make a statement on how it >> should work in the first place (e.g. removing ambiguities) without >> introducing major incompatibilities. >> 2) Device management AAA as used in the field today carries security >> risks. To address some of them, authors decided to slap some lipstick >on a >> pig in the form of TLS tunnel. >> >> Having done this, we cannot honestly call this an informational RFC in >the >> sense of how RFC 3164 was informational. >> >> >> On the topic of vendor-specific and the message that IETF sends: >> I'm sure I'm missing something here, but from what I understand, the >main >> objection is procedural as in the draft wasn't properly adopted by >> workgroup to work on it. As long as that is addressed in accordance >with >> the procedure, the draft could become IETF draft which WG would >discuss and >> modify as it sees fit and one which could ultimately be considered for >> standards track RFC. I though we were in that process, but if it was >> botched, we certainly want to have that addressed. >> >> I understand and appreciate the sensitivity of IETF even appearing to >give >> "a seal of approval" to some random vendor stuff. I certainly know how >this >> work could be misinterpreted if not handled in a very transparent >manner. >> But instead of a flat out refusal to deal with this protocol as it >stands >> today, I would like to appeal for suggestions on how to address this >in >> order to bring value to the community and industry. It's clear that >this >> was originally a proprietary protocol. I also think it became more >than >> that over two decades of use in a very specific niche area where AAA >is >> used in network operations. With multi-vendor adoption and willingness >of >> original authors to release it to current IETF process (copyrights, >IPR and >> all included) I think we can accept both negative legacy and its >> practically demonstrated usability and viability while not encroaching >on >> the territories which are undisputedly RADIUS and Diameter dominated. >> >> >> On the topic of slapping anyone in the face: >> Continued long-term existence of non-IETF and non-RFC AAA protocol, >its >> widespread adoption in a single niche area and impact it has on the >day to >> day network operations cannot be ignored or discounted. As much as >RADIUS >> can be used in the same niche (as any other AAA protocol and other >stuff >> like LDAP can be used for the same purpose), it did not supplant the >> non-standard solution for the last 20 years. I do not see how TACACS+ >RFC >> (if it ever comes to it) would change this. >> >> While IETF is and should be forward-looking in defining how things >could >> and should be done better, this doesn't mean that it should avoid >dealing >> with sometimes ugly issues at hand as long as the work helps the >community >> of users and vendors to do their work more efficiently. >> >> >> On the topic of technical benefits: >> There must be something that TACACS+ is doing at least good enough >while >> RADIUS isn't doing it so much better to replace it. >> >> My personal opinion is that TACACS+ is simple and dumb enough protocol >to >> be cheap to implement and still fit for the purpose. This two >properties >> combined make it an attractive choice for both users and vendors. >> >> My personal experience is that TACACS+ appears to work more >consistently >> over a range of different vendors than I can say for devices which >provide >> RADIUS exclusively. I also find it easier to diagnose and debug as it >uses >> reliable transport. RFC6613 was supposed to change the latter, but >after 3+ >> years I still don't see it adopted for the purpose of network >management >> AAA. >> >> >> On the topic of proprietary and vendor lock-in: >> I don't see any evidence of vendor lock-in after 20 years of use, but >I do >> see a risk because there is no authoritative and standard definition >of >> what is TACACS+. The IETF process is aimed to address this and I don't >> think calling out current proprietary status is an argument against >> considering the proposal, but rather an argument to work on a >proposal. >> >> The IETF process should ensure that proprietary monicker is removed >after >> all conditions are met. Proprietary protocol probably isn't evil by >itself, >> but is made evil by the fact that even the original author cannot be >held >> accountable if it changes it or ignores it. This effort aims to >address >> that as well and is an argument to work on the proposal, not throwing >it >> out. >> >> Current state of IPR for any TACACS+ implementor is unknown. The IETF >> process must and will ensure that all IPR will be ultimately disclosed >> which will take away a lot of stress an unknowns from both vendors and >> users. How can this ever be a wrong thing to do and how could it be >bad if >> IETF is the one forcing the issue? I again see this as an argument to >work >> on this within IETF and not reject all work on it. > >The IETF process is that each contributor must disclose any known IPR - >"all those contributing to the working group's discussions must disclose >the existence of any IPR the Contributor or other IETF participant >believes Covers or may ultimately Cover the technology under >discussion." [BCP0079] >except that I know that US legal liability makes companies there keep >their staff in ignorance of such IPR so what I expect, and do not yet >see, is a disclosure from the company in question. That can and does >make a difference to the decisions of the IETF. > >Tom Petch > > >> >> -- >> -- >> Andrej Ota >> >> Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland >> Registered in Dublin, Ireland - Registration # 368047 >> > > >------------------------------------------------------------------------ >-------- > > >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > From nobody Thu Feb 11 09:46:57 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116E01B3825 for ; Thu, 11 Feb 2016 09:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 s9CXkIwtEhHl for ; Thu, 11 Feb 2016 09:46:54 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFC81B2CE7 for ; Thu, 11 Feb 2016 09:46:54 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id z7so23902450yka.3 for ; Thu, 11 Feb 2016 09:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o4lKzzavtLYKFnNQR0PDhIK8GYFEkcfzNo0Fm1p73pM=; b=IzcVFuareVY3v05SFUCrVVYKA8qm2lcraCVzpsMO2xjD+oV/QU31fSyPOZhj/g6Mxa V5nZ+i4kf6edMPlECcDs+3FcSU4nvYi6k03ebYwkvodpQKTU4MDEhr+i8SLmUxoPMxy1 KpKJGIYALMb3rSHCkcltYSvAaBZTgPGFct2i4ZS2j+ScwctLJ/CKZ3TzF4eW0iKdOEbL ojXCm+gz/riVuOikPQ1tBthdE5JMZLbyblvvh3OaomWT1zX9ZLTwBWhqGHZEn365UQzO 7mrttfYGEL6QREbOR9yzgYW6CTc1cXUvJM0zkIFhwIBo0OnN6h0SoYd/KENAifuK8Gzk dPfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=o4lKzzavtLYKFnNQR0PDhIK8GYFEkcfzNo0Fm1p73pM=; b=g3d8iwj1YDLcsPSbyEVp1zaTfz3arhBg/fEOAbHa8VvNfMOtcO7EcOW9fWEuyf98TV l+xST+rdddB+xHippr6FYZsoRNkFgk4vbHpPhejQNB4NjersK9UsQNrr3vSHRvs0JJYd Z/CrMXLxJ5dUEyy7TEA0eLPPGyB2bwlMzphsHtP939VaCn87aPFfI08I7BvAL+p77WqR uMZ2MQSFMEYIwIDRwSH3YmLmaCQN48fpdb4TDnAxcmJTUPQvMR8JSgGb/7LT6do6vp8E uDz4bz6QsEC8/sOSmSLZWeIRBJHxPje+CoKWTk61McsF/td+xWb2BtEPt45lx7Pp1o8f 83Kw== X-Gm-Message-State: AG10YOTyZRLp8AnM8xbQOmV+gWxIypc309r/hf3FJrcMNhQ4S0sm7S1+cYaLIRNwvvLbEIqb4A80f/HuRH1gqg== MIME-Version: 1.0 X-Received: by 10.37.230.210 with SMTP id d201mr15269204ybh.134.1455212813399; Thu, 11 Feb 2016 09:46:53 -0800 (PST) Received: by 10.13.209.198 with HTTP; Thu, 11 Feb 2016 09:46:53 -0800 (PST) In-Reply-To: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> Date: Thu, 11 Feb 2016 12:46:53 -0500 Message-ID: From: Christopher Morrow To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 17:46:56 -0000 On Thu, Feb 11, 2016 at 12:00 AM, Alan DeKok wr= ote: > The IETF created a process to specify requirements for AAA protocols. = This process is documented in RFC 2989 [1] (2000), which had about 20 autho= rs from all major networking companies at the time. It solicited submissio= ns, and established a panel to evaluate the submissions. The results are d= ocumented inRFC 3127 [2] (2003). TACACS+ was not even considered, as it di= d not meet the requirements set out in RFC 2989. > 2989 is titled: "Criteria for Evaluating AAA Protocols for Network Access" 2989 is explicitly not about 'device management' or 'device administration' access management (AAA). tacacs+ is explicitly about 'device management' or 'device administration' access management (AAA). I don't think 2989 applies at all to this discussion. 3127 says: "This memo represents the process and findings of the Authentica= tion, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements," again, not applicable to 'device management' / 'device administration' ... so not applicable to this discussion, at all. > Standardizing a new AAA protocol without IETF-wide discussion means we'= re ignoring the requirements of RFC 2989, and discarding the results shown = in RFC 3127. > it doesn't seem like 'IETF-wide discussion' is being missed at all, actuall= y. > The document draft-ietf-opsawg-tacacs-00.txt *explicitly* describes its= elf as an AAA protocol in it's abstract. Despite the authors stating it is= for "device administration", that phrase *does not appear in the document*= . Despite claims that it is not an AAA protocol, the document itself claim= s TACACS+ is an AAA protocol. The document discusses user authentication, = authorization, and accounting, in a manner which overlaps 100% with RADIUS. > perhaps, but you seem to have content questions, did you make these comments to the authors? > In fact, RADIUS has more capability than TACACS+. RADIUS is standardiz= ed to transport many more attributes which describe hundreds of possible pi= eces of information. The TACACS+ document documents little more than the b= ase protocol, and a less than 30 kinds of information it can transport. > I'm not sure that the three points here are relevant to the discussion, we don't always want more things in the knife drawer, we want the right knife for the job. > The TACACS+ functionality therefore *explicitly* overlaps 100% with RAD= IUS. It is explicitly *not* "device authorization". It is uniformly infer= ior to RADIUS in functionality and capability. It meets none of the requir= ements set out in RFC 2989, and wasn't even considered in RFC 3127. > because 2989 and 3127 are not about the problem tac+ solves. For network operations the meaning of AAA is different than that used for 'dialup users' (or equivalent as the technology advances). o Authorizing users of your network access to the network is different than authorizing administration/management of the devices which make the network. o Accounting for the device administration activities is not the same acocunting for bits/time spent on a customer o Authenticating a device administrator is likely very different from authenticating a user of the network > The only *technical* capability that TACACS+ has which RADIUS doesn't i= s "device administration". Perhaps what is meant here is "command authoriz= ation", in which individual administrator commands are authorized via the A= AA protocol. However, this capability is *not* documented in the draft, wh= ich means that any "device administration" remains a proprietary vendor ext= ension, and entirely outside of the control of the IETF. > I think you mean to rephrase and aim this comment to the editors... so they can add a note about it in the draft. I do see discussion of authorization and why it's important/used in the original grant-tacacs-02 draft, and in the draft-dahm version 02 there's this: https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01#section-5 this seems to have some level of detail and useful information about the authorization process/work/packets. > > The document overturns nearly two decades of IETF consensus. It compet= es directly with an established IETF protocol. It's functionality is expli= citly inferior to RADIUS. It's suggested use-case is entirely undocumented= in the draft. > i don't know that 'two decades' is particularly important, much has changed over the last 20 yrs in the IETF and the Internet and in stuff provided by vendors/etc. Making device administration better and more secure over time is a win for operations, networks and users. -chris From nobody Thu Feb 11 09:50:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124B71B3842 for ; Thu, 11 Feb 2016 09:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 6rovSBM7kxBa for ; Thu, 11 Feb 2016 09:50:12 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BCE1B3840 for ; Thu, 11 Feb 2016 09:50:11 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id h129so45284880ywb.1 for ; Thu, 11 Feb 2016 09:50:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QAjTHXfaXtsMcxrfsnG/qxSzXBsD2kdF/KngrnoZ1zU=; b=m4R/lW5ycFKTLfgYaYjW3VDrt15f4vGW8jlZ5Kvod9sB8EC0d0qo42WsV5+Hqr7ah7 dfvy85IrHvndHLtRurdxlLUOXJMBmxecSonI/ukfd8XbKE9Dv7eaAMElbPVU1NHZK5WI NjHqauxqYADpduJGiSNN2t2p4LL3uU/NCQdRXQo56VEbjzmlt+AFUXNpMKNNxHfp+2pP DYntVQfc8L6b5Ou7R8rHOfkQTMlmtyxkTcNydElBlP9FiSgo24FBf4RA1Yza+UsZkerx tOC0QLhTv1pUsKtizMwpAb43BHKlcUZZIdfPznIHi8ZVa3nt4VopBGSb8fbhaBYAVVX+ oK5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QAjTHXfaXtsMcxrfsnG/qxSzXBsD2kdF/KngrnoZ1zU=; b=mth6hS2Hwk5plEqTpzTdE59kdyUcMk1P7PYFPw+NV+D/wK96VFrU0TuzJRw0WsgOdo 94TI/JCBwvuIoyClYEcio19//FfJEgNvXc8g9IFwVKbSiG/J/mbFpYuXZv56qeGyEov+ XSxnOwzbqPDL2uF8cTkbH1AC/XKuomXupksojc7umXQZ/J8lgnOjwScAXHZABmAv95Tj EaX1q6uRfkyfJ+LkAIun6sfyTo72IzbHm8A1wqcL1zfDUbrvBzTu0WTXvRhIO+WGTma6 YVhqfGwUpdKkCcaQLS5be11LlLTyD/tXSFnbL+rG6mWIlR/kAhOsswb/7J904/FCjpb+ wxfg== X-Gm-Message-State: AG10YOTiExDn56RxRWisg+zhd/87QjEIZDemFgws2UgUb8dTqzf+W/78CYB5I+1rRxh46yJ5yQ3WxJliRmkCgA== MIME-Version: 1.0 X-Received: by 10.13.200.65 with SMTP id k62mr24068576ywd.145.1455213011328; Thu, 11 Feb 2016 09:50:11 -0800 (PST) Received: by 10.13.209.198 with HTTP; Thu, 11 Feb 2016 09:50:11 -0800 (PST) In-Reply-To: References: Date: Thu, 11 Feb 2016 12:50:11 -0500 Message-ID: From: Christopher Morrow To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , Andrej Ota , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 17:50:14 -0000 On Wed, Feb 10, 2016 at 3:51 PM, Alan DeKok wrote: > 6174 is about what teh datatracker implements, not about the actual process... I think maybe you mean: 7221 "Handling of Internet-Drafts by IETF Working Groups" particularly you might be interested in: https://tools.ietf.org/html/rfc7221#section-2 note that this is 'common steps' though, there's not a hard requirement for an adoption call, if the chairs feel the work applies it can be adopted without this step. From nobody Thu Feb 11 09:51:09 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DAD1B384E for ; Thu, 11 Feb 2016 09:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7ZdPLhgusEqP for ; Thu, 11 Feb 2016 09:51:07 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BBF1B384C for ; Thu, 11 Feb 2016 09:51:07 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id z7so23955560yka.3 for ; Thu, 11 Feb 2016 09:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qJHVp9FDe4XxKxce0PBTAsMK0DrgpGksr03KycJ95yM=; b=zIxUGKsYAUJDCjpvHUIdNGDcO+pN/nzX4CbfOVUudJ3pdAR/z53EgYnGccl2ez5gto C5rSEHOqrZ2VoPIj1FOPoLqs31TCZkmzEeTuCxVTUJOg2ZNLiWJBO3T+BVWEv4k27nGy XWNU2EERXZBfz0jv3NhS16Qr/H7WpBO3rzg67qH0gW0iMq2IMxBZjkm4/4KhnyuKctz4 wg5W2leEe+I/0H2ANxfYRR6tZIbDW48ONbh7H4PUL7RUGgNLTRUU6sFDS+9+vBLuDbul MI9hd46nmSIz53kjTXDLmXuV78aat4M7VN4jjjAwMwfyoYbZfuthOjreU2IseFDs2dwb z+yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qJHVp9FDe4XxKxce0PBTAsMK0DrgpGksr03KycJ95yM=; b=UcRPuMd+NeIniSmQCLtk9PQ+7PGB2gJHhWpbUi7mHH/S5mLYr5Zz6jmy3ebYvYYe6w F3YZOfY02otdLgnY0Kqm5ivk9jHFmPmlrFWpVgQ87n3tM9/kCM4oAqEz/2nRxkK1o4mg U39JQio3GXGmeqh9F7tK1s0hmFyeQnasUDLIXXpySu4wzCr8AoPh8GBaYNqTm+qq63rB cCQs8zBu9DgQp2Is+6Q82ivdykf++0f72HD22OKpJMUyBnbWg/z9W7kFSC9WTXGLU4XU 69n8dTXge6/vA2ini04KcAoBRKB2M7nHBedN2ubo5mGVOQS8ghvCUEflkjCNmAagJybc g4iQ== X-Gm-Message-State: AG10YOQi/F9I4DI5TTl5YDxb/ZuBpOjtcuO1fYlegpwOyIg4RG7n+GJVRh/5HkLi3FUsyKVX9lRtEtenGcrS4Q== MIME-Version: 1.0 X-Received: by 10.37.20.195 with SMTP id 186mr26177240ybu.60.1455213066988; Thu, 11 Feb 2016 09:51:06 -0800 (PST) Received: by 10.13.209.198 with HTTP; Thu, 11 Feb 2016 09:51:06 -0800 (PST) In-Reply-To: References: Date: Thu, 11 Feb 2016 12:51:06 -0500 Message-ID: From: Christopher Morrow To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , Andrej Ota , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 17:51:08 -0000 On Wed, Feb 10, 2016 at 3:51 PM, Alan DeKok wrote: > RFC 2016 this also doesn't seem to apply to the discussion at hand... "Uniform Resource Agents (URAs)" From nobody Thu Feb 11 09:54:39 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D3E1B3868 for ; Thu, 11 Feb 2016 09:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 85Su7UU9bWua for ; Thu, 11 Feb 2016 09:54:37 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C8B1B3869 for ; Thu, 11 Feb 2016 09:54:35 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u200so45365142ywf.0 for ; Thu, 11 Feb 2016 09:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mrIWRw2gGtk7yOsm/HghGS9opfu+CaJ95N1CvRIV47Y=; b=MAwXdXlgojS2v3SWcM6vvKYbblcTL4iaOxbwgAZ/B1heAP38te9DWt2dwToI3RqyRw 1P5NYqnq+VsCvPHc10gcFtf4pdesVR+zS1DQMyR/UjlVE2fZdL95vRuMjv5xw8bxg4s9 o0jYjHPQDs3e/ZyepIHz4dpZBNcowv0bOZaK7VHJj9KTQ/G4XSMIkW+2CMboepJqVngi OLpo3JILLUbfjm+1i+xH9WEptLFHoKmc3aLMJ2PkZx9DfVfvOzaH0mh3FxeLSx9lpJVj hV0PgVXtNO3zy146Yj10dpvMPCpoiiDaKJsCJwmHHhkUeyUB24acIb65WiczurtgVZe/ XAsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mrIWRw2gGtk7yOsm/HghGS9opfu+CaJ95N1CvRIV47Y=; b=WrWAKdPLU7sIkFVH/GASSIc20QvsubB4+Ndnszvkysx/sckFTencIzTVISuhoM9bxj qppxIbD3p0LZ7YRhTDs9JT1Og67OwiRbDAjbDgtVF43nsysitYAyc0OurEcUMLmUkg5F Q+LQ56zObW6389Rdl6xVH45XdwDCXYxq+g5P+k34DqTTqJhpjCX/XEWJGwixVke1lH6F rMxsn4gkOV9Q7H4aHsf0KyM8RPCOttGqfo2rWPXgfcQL+HOZp2M1o+hLywuXca83Cpgo VN9xUZxLQ503dQ2dP6lxtn4RrhmQJ30penR6u8ScIUiS2mhJYVQJcX4ROEY6Lco62B7j ZrKw== X-Gm-Message-State: AG10YOR4mS0XqQl1Rgig9f8Tfme5DFHBO5xvKlAKoEYCPXeuw4ttcY3k4g3WfvqGOZp493FdWBkQxnolNZZR8w== MIME-Version: 1.0 X-Received: by 10.129.76.145 with SMTP id z139mr12354994ywa.56.1455213275060; Thu, 11 Feb 2016 09:54:35 -0800 (PST) Received: by 10.13.209.198 with HTTP; Thu, 11 Feb 2016 09:54:34 -0800 (PST) In-Reply-To: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> Date: Thu, 11 Feb 2016 12:54:34 -0500 Message-ID: From: Christopher Morrow To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , Andrej Ota , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 17:54:38 -0000 On Wed, Feb 10, 2016 at 3:57 PM, Alan DeKok wrote: > 8. This document is competes directly with two existing working groups, RADEXT and DIME, to create a third AAA protocol. DIME charter text: "The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access," RadExt Charter text is less clear except that their milestones are explicit and focused on the 'network access' problem, not the 'network managment' or 'network operations' or 'network adminsitration' problem(s). So, I think calling out to these is also out of scope. From nobody Thu Feb 11 10:00:14 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6396C1B3873 for ; Thu, 11 Feb 2016 10:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 hidnPSxBPABy for ; Thu, 11 Feb 2016 10:00:12 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DC91B3864 for ; Thu, 11 Feb 2016 10:00:11 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id h129so45512614ywb.1 for ; Thu, 11 Feb 2016 10:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bw/bzBYfmENBZxgXCpA33XMal3NRJfGhpBgstGNkOnE=; b=YxssJvGu02mH592f8PzCYyxfbcnG98HaNkXKgLLACVbv5XhjzQi9gUemunGkWMufcn TOGWV2waLHclWHWHk2F/9y2fYJZDXSSYGc3gjVH9ymXhaFmxHCyQ1AlkZk63NJcgwjwZ C15+hDw8c5wgx1NBHt+kA8g9LTm4vIUV2tPpsAOFmkEs4zFHY+GCTMssjDGjUxU89GdP DJPGXmsvdgPjf18nCPEfQlhrEledsHAS3s+4Dfs5mr2byoIFiJt6Kq0PDEeXiXYHvddi zTesS4ikSCeQzCfRi0hUY6B/ymaqIuYzn16tTGJ0UmCHSkxKQgkFbp31PscAuX9Mr3aI FLuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bw/bzBYfmENBZxgXCpA33XMal3NRJfGhpBgstGNkOnE=; b=HLCD09Fx1xGS1cWUOsEONesCnHGnzbBlrGiO2Q1skjda0HDp4bCRtxXg4Qoc1AZKCv wlitNynU/wXAa67xb/9sRws0t/LS2B2vT4HGPqrzEYnB1rifFRf7Bcp9V89VvwcYgTuR CIHtF5lkoUovJZmfc4qZQBbqIv62R0Cc/88RlfUyURz2wDvr9CcxJRV3AcdCU9ulw8sJ 6ynIRAKXTVfDafr0nTzzANT/50/QMhObDAEQPpF7/rKxCFK5g2mmy7Z2lFwDM6JAC/Ji mqGKTYsxxp+tI98sKfQizIfLDlXMwqO4qyd+OPm6EDX+WmB7kofzOLfuQLtIXToHlNwO cLjg== X-Gm-Message-State: AG10YOT7EuQ3/zbx9pIgOIkntBBnabOdbI6BNF2MoI7z3bZL99kr4hhMAdEuJeHw8XsAus3NPnG63D2jX0DDGw== MIME-Version: 1.0 X-Received: by 10.129.76.145 with SMTP id z139mr12372887ywa.56.1455213611320; Thu, 11 Feb 2016 10:00:11 -0800 (PST) Received: by 10.13.209.198 with HTTP; Thu, 11 Feb 2016 10:00:11 -0800 (PST) In-Reply-To: <7EE28A5A-0C73-4F9D-B52E-0BFB1E985B52@deployingradius.com> References: <56BBD1FE.3050206@gmail.com> <7EE28A5A-0C73-4F9D-B52E-0BFB1E985B52@deployingradius.com> Date: Thu, 11 Feb 2016 13:00:11 -0500 Message-ID: From: Christopher Morrow To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 18:00:13 -0000 On Wed, Feb 10, 2016 at 10:37 PM, Alan DeKok wrote: > TACACS+ has 100% functionality overlap with RADIUS. you keep saying this, but I can't get a radius server to authorize my command on a network device in my network... you seem absolutely sure, but I'm absolutely sure (because I've driven down this road a few times with 4 different vendors if IP gear and 3 different optical vendors) you are incorrect. I think you are very much in the rough, and I'm not clear on why you are as vigorous about this. There are network operators on this list and in the rest of the world that have said: "tac+ is how I AAA my network gear, I need it to be improved/worked-on/etc, please do that for me" also: "I support this draft, and want to see it complete the IETF process... so I can then start having better security of the management of my global network elements." -chris From nobody Thu Feb 11 10:01:58 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754C01B3864 for ; Thu, 11 Feb 2016 10:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 hlGj7F9_wjB3 for ; Thu, 11 Feb 2016 10:01:56 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8291B3874 for ; Thu, 11 Feb 2016 10:01:56 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id r207so24205302ykd.2 for ; Thu, 11 Feb 2016 10:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nwI2eHX0bGebhom+ZhTd5OGFp9F6IuLdxJUPnwTez/U=; b=vfkRtwTZOgJtJECmb4vTSMAEmzsSGGKUDYAoIddri9jnjtKTjT9xuVrVSupbs6LPuJ YLZScrC1Ysyki9Ad6gYHeCPce1Ifi6pnCF9mLuXv+KS4WvosHnDRAfDp78fqMsfaH8Ut /JzKR9gTuyQp8D5tx9+E8bTxrDiL4kq9ZTMB080vNYc0kNT5m/X56JIAY7x3ladMZVku y3bnfCiSaONO2aQy1WlLoFLXSROXRBeKw8bZpbhnS2rVEy74JUP1dyv+0b84pF5L4a+5 y6q/6D9uZtHWeOp7W+SAgTyO/TsBzzN55MoZrGgug0wy7h76VgnIXeoFF6aG1binoKBy vptA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nwI2eHX0bGebhom+ZhTd5OGFp9F6IuLdxJUPnwTez/U=; b=ImM+qt/cTPcEF3FQn7P+1AOkwok5EP7FRBbE5yeaVfauPZMhvMHD6dWTCnYlyCRQNh 72n+MOWpR9co/CyoRZJIfH5SATm7geTsxRgwL7BfvcMhjrIYFcrmxqKVoKUUP5U64wZM 6jLiVKoS4QvER13KOlGDvtTeEvOY2gfipPtW7CA6hYoEHpsKgM+tKGcIb1EqDk2tDuka Fsa42sIOcKOfq9vcRMaAAWW1u5xoy2zWVCEPF6EtL69LV3fnBlUoyXA0HfV8u7mo/ujV 6w9g4Njg8QR7wfCi0DboGf+OQmaY21ZVVNTNlnXtAezV7/HnFSkECQUrSss8WVg/O1Wt FJTQ== X-Gm-Message-State: AG10YOQnSstnvMBGdkFJVKFHLJMFPvOR3uxgpqlIiGcOKC2+jcOzeFvmsGE0Me3YfYt2PObAOirzJtml/a8zHg== MIME-Version: 1.0 X-Received: by 10.37.230.210 with SMTP id d201mr15315743ybh.134.1455213715733; Thu, 11 Feb 2016 10:01:55 -0800 (PST) Received: by 10.13.209.198 with HTTP; Thu, 11 Feb 2016 10:01:55 -0800 (PST) In-Reply-To: <56BC1606.7000304@gmail.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <4CCD0944-E137-4836-B2E6-347737CE7C5F@deployingradius.com> <56BC1606.7000304@gmail.com> Date: Thu, 11 Feb 2016 13:01:55 -0500 Message-ID: From: Christopher Morrow To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Thorsten Dahm , Andrej Ota Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 18:01:57 -0000 On Thu, Feb 11, 2016 at 12:03 AM, Melinda Shore wrote: > That said, I think the process here has been very very > badly botched. Very. 1) cite your sources 2) show your work 3) it doesn't really seem like that's the case, at all. (see previous cites by mr carpenter) From nobody Thu Feb 11 11:31:53 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052AE1B3988 for ; Thu, 11 Feb 2016 11:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 YLCq1GUlDTAb for ; Thu, 11 Feb 2016 11:31:50 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EAC1B2EAF for ; Thu, 11 Feb 2016 11:31:50 -0800 (PST) Received: by mail-pa0-x22e.google.com with SMTP id p5so3190160paw.1 for ; Thu, 11 Feb 2016 11:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=AC8Td6V7dKvatpvfsbVuyOS2/OvQzFSbo690HFI11Dg=; b=e9LuwWYkiz3eym/GNeccjK06ZPh3m1676181/DOWjubYmnYda3mYg/G/AaCwVBGd/u i34DhEZYQMqIb86thZXGulDWnh2RH9h6zQil6ICeA0+AF5f5AeBHhIDEqsCcO+XSXVXJ +VR9JIR9Fefs0Z5PJSWIYXMgoEFAyLZqsbwTnDZEoFi4n8MTCgkPRMSLS5FCy9cwg4wc zRM7MovCPKuE+NhD47l49L6lp9Wwd1eEC5bS6R+hh3eNAMOT6s+YyP6j2o9XrIOCKWtj 3zFfLMQ1sjZ3hQiSTkOGLxCXlY9CC8ubH5XB7tF7fxiFqckcHx47a+ePc+FbbrlYy0DH sQCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=AC8Td6V7dKvatpvfsbVuyOS2/OvQzFSbo690HFI11Dg=; b=FCVSeQEWq7o98S1i3kgdhNNHDXxF5NR6eMFfnkRDir5+UXNnVA/rAvYmKrPmUVej0e aNRRLGaloTmDH4SVkqxGwiJTFNvD/m3x60VoMQz3qrwoHUffYFCi1w/dlWT3sv/LGZGz zbG7EwY2EpdlEQg668KiOY6C5OcPT5cc/7vSEvMs/AU4ZuFnvA3/sNBZsiNgjX1mKxAb TnK//0UAPFBoTREMeqP6KIJHwYL1+IdZ018+3ygQ/KsXaRyCNDESdWgZkzxXFURIMkNp SjXHsQJUc2OO1Mwz/OlNilY2+iPnGCEzx2xDEEkta1UkHaZ27zrxgZl0+eRXI7ee4x/w T5jg== X-Gm-Message-State: AG10YOT6e48bZWswJ78iIXY9L1zK9gnAL4emsAZ6BFv003vmvxv/X9eDr5P4TYrINk42JA== X-Received: by 10.66.255.39 with SMTP id an7mr69061966pad.101.1455219105124; Thu, 11 Feb 2016 11:31:45 -0800 (PST) Received: from ?IPv6:2406:e007:5496:1:28cc:dc4c:9703:6781? ([2406:e007:5496:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 16sm14090068pfk.28.2016.02.11.11.31.42 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 11:31:43 -0800 (PST) To: opsawg@ietf.org References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56BCE1A7.6050807@gmail.com> Date: Fri, 12 Feb 2016 08:31:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:31:52 -0000 As far as I can tell the only point at issue here is two words in the third header line of the draft: "Intended status: Standards Track" There doesn't seem to be any dispute that TACACS+ is a widely deployed protocol and that this is a competent description of it, and as already observed the WG chairs didn't exceed their authority in the adoption process. Since the WG hasn't yet even been asked (by WGLC) whether the document should be approved, I can't see what appealable decision has been taken, since basically no decision has been taken. Could we perhaps have a rational debate about whether the draft should be on the standards track or not? It's a perfectly valid question to ask. Standardising multiple solutions to similar problems is not unknown in the IETF; in fact it's rather common in both the Routing Area and the Ops and Management Area. But otoh, RFC 1958 (another Informational document) does say: 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Regards Brian From nobody Thu Feb 11 11:36:16 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825DC1B398D for ; Thu, 11 Feb 2016 11:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 eyb5P03Zxt15 for ; Thu, 11 Feb 2016 11:36:12 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C5C1B3988 for ; Thu, 11 Feb 2016 11:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6609; q=dns/txt; s=iport; t=1455219370; x=1456428970; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=WXd782r/EKlD4W7EK/BQHK9yHpXCXHVnsh9GD66Ps0o=; b=cCOV6slOTXErIa/SqK3qEcKEJFa9I+AciT4W4ij0pnmzrbvPkPnrhlpW M0Gvb9c9NzmHEXjj76aLa2GqeV9KuyOWyF4ABhCVtWiAYMa2E5tTD1w3j /DoPWGb4jLtvEIqhHBs+wJpjXqaMCynK5vzzNI2md1OmP/fJE/uMFmZK/ Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBADp4bxW/xbLJq1ejVSvF4QIhg0Cg?= =?us-ascii?q?gABAQEBAQGBC4RCAQEEI1UBEA8UCRYLAgIJAwIBAgFFBgEMCAEBEIgGsjSPBgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQ0IkXqBOgWWd4EUgWyBZINWhRmJI4VSjj5ig?= =?us-ascii?q?2Y7iQEBAQE?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="asc'?scan'208,217";a="630581644" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 19:36:07 +0000 Received: from [10.61.231.36] ([10.61.231.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1BJa13m022328; Thu, 11 Feb 2016 19:36:01 GMT To: Alan DeKok , Mikael Abrahamsson References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <56BCE2A0.3000909@cisco.com> Date: Thu, 11 Feb 2016 20:36:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cAxaMpio5qF67O76brF88Ta2l2AsMcPtq" Archived-At: Cc: "opsawg@ietf.org" Subject: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:36:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cAxaMpio5qF67O76brF88Ta2l2AsMcPtq Content-Type: multipart/alternative; boundary="------------060109070406070308030609" This is a multi-part message in MIME format. --------------060109070406070308030609 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alan, I'm not unsympathetic to the idea that we should focus efforts where possible, and I'm also not interested in piling on. But I think a comment is in order regarding RFC 3127 and then I have a proposal for a way forward. On 2/11/16 4:25 PM, Alan DeKok wrote: > > - even if there were no procedural issues, the document violates IETF c= onsensus as described in RFC 3127 One has to put into perspective what was going on back then. Many different approaches were proposed to cover not only AAA but policy in general, and the market was at risk of fragmentation. There was a pretty visible and dare I say heated process at the IETF that turned into an attempt to align those who wanted to pursue policy with COPS and COPS-PR and those who wanted to do something with RADIUS/Diameter. =20 RFC 3127 and its predecessor RFC 2989 represented hard work in the context of the efforts going on at the IETF at the time. It was a tool upon which the ADs relied to organize the work of O&M *at the time*. However, in the 15 interceding years, what's become clear is that RADIUS has broad applicability for a great many AAA uses; and for some cases TACACS+ is appropriate. For these purposes, such as command authorization, TACACS+ is a defacto standard, no matter what the IETF process says. The nascence of this space is long past. RFC 3127 was never intended to be a constraint so far into the future but rather a guide to ADs at the time as to how to proceed. The choice here, it seems to me, is really one of change control. I agree with you, Tom, and others who write that the IETF doesn't just rubber stamp protocols. On the other hand, changes should be made with due care toward what is deployed. I personally have faith that our processes and good community involvement would provide for a good path forward on this. In summary, if people want a standard, I propose the following way forwar= d: 1. An applicability statement for TACACS+ that describes when TACACS+ is appropriate for use; 2. The proper following of working group process; 3. Appropriate and timely IPR declarations; and 4. It should be clear that the IETF has the necessary rights to effect changes. Thoughts/Comments? Eliot --------------060109070406070308030609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alan,

I'm not unsympathetic to the idea that we should focus efforts where possible, and I'm also not interested in piling on.=C2=A0 But I think= a comment is in order regarding RFC 3127 and then I have a proposal for a way forward.

On 2/11/16 4:25 PM, Alan DeKok wrote:<= br> 

- even if there were no procedural issues, the document violates IETF con=
sensus as described in RFC 3127

One has to put into perspective what was going on back then.=C2=A0 Ma= ny different approaches were proposed to cover not only AAA but policy in general, and the market was at risk of fragmentation.=C2=A0 There = was a pretty visible and dare I say heated process at the IETF that turned into an attempt to align those who wanted to pursue policy with COPS and COPS-PR and those who wanted to do something with RADIUS/Diameter.=C2=A0=C2=A0=C2=A0 RFC 3127 and its predecessor RFC 2= 989 represented hard work in the context of the efforts going on at the IETF at the time.=C2=A0 It was a tool upon which the ADs relied to organize the work of O&M at the time.

However, in the 15 interceding years, what's become clear is that RADIUS has broad applicability for a great many AAA uses; and for some cases TACACS+ is appropriate.=C2=A0 For these purposes, such as command authorization, TACACS+ is a defacto standard, no matter what the IETF process says.=C2=A0 The nascence of this space is long past.= =C2=A0 RFC 3127 was never intended to be a constraint so far into the future but rather a guide to ADs at the time as to how to proceed.
The choice here, it seems to me, is really one of change control.=C2=A0= I agree with you, Tom, and others who write that the IETF doesn't just rubber stamp protocols.=C2=A0 On the other hand, changes should be ma= de with due care toward what is deployed.=C2=A0 I personally have faith = that our processes and good community involvement would provide for a good path forward on this.

In summary, if people want a standard, I propose the following way forward:

1.=C2=A0 An applicability statement for TACACS+ that describes when TACACS+ is appropriate for use;
2.=C2=A0 The proper following of working group process;
3.=C2=A0 Appropriate and timely IPR declarations; and
4.=C2=A0 It should be clear that the IETF has the necessary rights to= effect changes.

Thoughts/Comments?

Eliot
--------------060109070406070308030609-- --cAxaMpio5qF67O76brF88Ta2l2AsMcPtq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWvOKhAAoJEIe2a0bZ0noz+TwIAIe8nVH7si/Ae1OU0hkMCnip R/A+wzCmuvf4ozjnwqjPltda3zaKO8WSThSKFmVrhpRjpmY+sL14tl0EIHIw0R8s fUV4KkYlGgjS/AqomjWX7wjJoonIWq8Cw8vm0of2kFyfUyXrt0JOeHskC1pU/r2X OBSORSpyzFD5KMiMbypz4LlAtWCJG02xgqrRUxzydW+5qt0GMTeygDm4fGw6GVxe 5kM1aNKm1ti2Aqut7TEbj+rPxRyZWup+YqvwpFBksHGtEaOqw5h0eGDWmrWHZVZJ ylWAMeT5yRfNVrTq0iKlfYYlPrLbyeuJ0uI/P6U2PVk+dX77LyeIBmZGw8qhKes= =8bxO -----END PGP SIGNATURE----- --cAxaMpio5qF67O76brF88Ta2l2AsMcPtq-- From nobody Thu Feb 11 11:46:59 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836841B399D for ; Thu, 11 Feb 2016 11:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 3b5nFu782CyC for ; Thu, 11 Feb 2016 11:46:41 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0688.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:688]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FDE1B399B for ; Thu, 11 Feb 2016 11:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=direcpathcorp.onmicrosoft.com; s=selector1-direcpath-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZU0t37CgQTPmF9y6cucIPgRYMHy/3zL5X8JQYu/w0Xc=; b=BZatojAk0q57UJf+uyWEzcmlGRJky9tKrP0Sf0RXE1V6bb8lshyRNYQjP77NFpj03JmnXQD9TX51Xmrb6EqYO0c+pTcMA5h7G47MPZzdywrPSMvPTuobYXh+Bt2mZQZRryunUnkZWlihW8Syzk9f1QOQR9cTBLWD8cdSSjh9BT8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=direcpath.com; Received: from [10.6.2.149] (24.98.60.52) by CY1PR01MB1724.prod.exchangelabs.com (10.162.160.146) with Microsoft SMTP Server (TLS) id 15.1.409.10; Thu, 11 Feb 2016 19:46:18 +0000 To: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> From: Robert Drake Message-ID: <56BCE503.7000107@direcpath.com> Date: Thu, 11 Feb 2016 14:46:11 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [24.98.60.52] X-ClientProxiedBy: CY1PR20CA0041.namprd20.prod.outlook.com (25.161.165.179) To CY1PR01MB1724.prod.exchangelabs.com (25.162.160.146) X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB1724; 2:Knlp9sh5Kfx/8xZpEsElAOGprXKQjmBVxPnv7ZURULUAtO4dZlx/757LgGgSOFprhRyZEps47SJXfsVqJ0fFwugwGB9ccuUtINSIRg+kxZEqzCm/H+v+2uOyG3X+ZFRRdLwl6HxGCl4cnI9U/M6Jrw==; 3:w0eSpQtuAX1fWjZ6EiPpADmWpVfGJh3pghbO4/PZijYowKiMGthzTJGHL52srOefE8qk1FIXjRwz0+PL17PI1wUmESETV0OWnTkpSnzgmUPZkIrxEvaE5gQbZJxGOin2; 25:IYMMewiXz5/lSu65vred6A5a6m1WvcE4ydvYrLGN8qq/5Kjw3ednC6OnYe+CtrEtZ+R1+0OLn4d3YoRn403p+pXOSR4tqa4lm4zdvCuc2B2NIRsgWU8PwUUoeqzV4DwPkfcmWpcAITQkAZqBrJLpw7IgOLD6k9fbs7tpuKqSbjE/kBxEw+cYDaYz+YjrDDOQ4PqvNmeUPlyHx5cIm3HEQZwqScPEB/1UE4jNporWiKzj8b/W8ZaJ6mCehA3VzjOnyrI5irFUzjk7VJWNTV/2HAbIKaxV3nk7rwS5cfKgD+MI00DaIFdbxC6M1YP2LZ8O; 4:1buBXweXx2AaZkI0uuiRxKG72bV+3wnHZ8eiOrhVGEz3Aq8ICv4lmcxd7PMaUFefkqVaCVf/cYTn5AwDVYCOodzWiwFJBD0pBoUqXDi48r4ZItoVwBKUGy5DVcS1hsB8MBGBtlK/nYq25zDLUvXyxF06jsRUD69pMv6f6r3OBBBYI0xjjN4nYQcab2IhzSSBzuXNw88xiCbudfKmQhumjdqbQuc4osRAZQk+gSFCgmJQRDXc8kSSOPgXmBnI5mAwa4oyIPDqGl4fJ+oDH1Wb/4QoUdLkcQanUrDpGlChdsfix3RTRRnyyKZn7HJdKY4/XhHNAUiDEXvKyBiiq4YAQnH6qLwfVuc0WErkpYYfEUQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR01MB1724; X-MS-Office365-Filtering-Correlation-Id: 0907a387-d378-471e-e191-08d3331c02b0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR01MB1724; BCL:0; PCL:0; RULEID:; SRVR:CY1PR01MB1724; X-Forefront-PRVS: 08497C3D99 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(479174004)(24454002)(377454003)(5004730100002)(122386002)(33656002)(83506001)(77096005)(2950100001)(2351001)(93886004)(47776003)(42186005)(65956001)(5008740100001)(40100003)(450100001)(64126003)(76176999)(59896002)(54356999)(50986999)(87976001)(65816999)(87266999)(65806001)(66066001)(107886002)(36756003)(4001350100001)(586003)(92566002)(23746002)(110136002)(189998001)(50466002)(5001960100002)(3846002)(6116002)(86362001)(230700001)(2906002)(1096002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR01MB1724; H:[10.6.2.149]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR01MB1724; 23:3lGy2kAjq44bBiDP4HUFbY76QB4uaHkWUYfZB?= =?Windows-1252?Q?RXxcmBA3a46ZPXOqCdj0lh/SMyK4lNctzK3dBsg+P+F/Q2JXSt5c/68f?= =?Windows-1252?Q?jBUYqE2z4QdZ/2j12W4BmIiREmKEuDagG/uSc2NsSHaBkcSm5uZ0rPiJ?= =?Windows-1252?Q?YheAL6OkkFVmUlHf4DqIQmi0cLNatl/2zQBsMqeTkYEkfLyuCNai7zRP?= =?Windows-1252?Q?cC5d8PAJhiDStUq5jflksYelEIYh0Q4kpVTRQLhqfcnSxdYy+V18u9gb?= =?Windows-1252?Q?dRf3bcjp6UqIHfcYWTQqsoYJiK+FLGZvLRpELdqSabNcrt4ly7+rHYJF?= =?Windows-1252?Q?0xwA+g3N25B34nZy884Y/yd0OC2zdYCbJz/0WNaTe790TGOtGic+PaEY?= =?Windows-1252?Q?146TJTKsHa3RybxxbCeIIO7xDIsd5HpYk/9Aqm8XWtfTPqWGLdGIrsyn?= =?Windows-1252?Q?BuYLE9mvXoivOCnz3vBDtiq4myM+zw6/2o969PO7LECutZs351MiE1aC?= =?Windows-1252?Q?fk7sQVf4YGF0CAkAPcxJk2ekphvuq3Qd2COs9IxlXmbFy731ToqxxyBw?= =?Windows-1252?Q?Ge7HfJ1NnDvdyo4nUdl7Ll7KgpgaDrH4EBivwGSOn61ncs909/T4W4nn?= =?Windows-1252?Q?Uy4Fsvqr5qW7FUAmtfNsunxpTpFdsuWBmeCAv/dCUsZEhUuMRzy83LJm?= =?Windows-1252?Q?KB5l9kpKJ22zr9J6ma4L1wxj4JpO2WmjQpS03uJrazwmuHcGHZZ4QsgS?= =?Windows-1252?Q?xJPvZ3dEgRtiWkfq8AN7lIqlASPUESks1SqgFsbzR605Xwteuw6FlLkV?= =?Windows-1252?Q?PJ0zm2LJ4taB36o20a3bimil8PK3oSvQTaSXaqOTx2k5YZRlM1bWSSY6?= =?Windows-1252?Q?YZBRqDDBneJwlcbVMFMvMaUKEQ/sdWzEH/Iynhr0oS2A1hlsndCy9JyX?= =?Windows-1252?Q?KLztfbB8UE1GW9qZkhW0GzWHHqLxSvAPu0wphjl5H8u5cP0Yuk7NaL1D?= =?Windows-1252?Q?RoZFiNRQUohpdxOV3IbIkLtFsSr+RLGgPvdYVZ9hjv+TKuzyiZZZGmEB?= =?Windows-1252?Q?z+BwHYba6co556t9vi8XnRUzODXKuDwLCGlNmO0IQW0mIWLKaymCKGOg?= =?Windows-1252?Q?/L9xKJAcwARCNt/zFBNju5xlhaNlBYiFTp2syKpMcTHx/vyA/+QMs0yN?= =?Windows-1252?Q?Ti/E9TWnlyo5iDObPz9IiU6W0dTkV/frw0fUNTSZqKMZHGwzvcgL29D7?= =?Windows-1252?Q?ZXz6kPvaz5FMxq4Kg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB1724; 5:3C9uIRbAxK3+6W76OWmbHjMnwji0GDvBvE8lzUKrOiJTMkDnyggeYruEMYLkp8nJLzyIkmxmHn6uETErWnfnuz57ZetG9pAnQFzqarn8DZZQbubOWuj3O5HpLHucGgLy918l30ID2SSe4P8bbTsPmg==; 24:wIpqh5fFlCHDViR2NEYRMXy+aSVAU0CGcEzmmdCL4K8fZH4ArtATr3FfbYLshACfBKG/eoxJnqJ6uGS5J5091ijt7HKTIPx5LNjorLr5gcY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: direcpath.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2016 19:46:18.4900 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR01MB1724 Archived-At: Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:46:51 -0000 On 2/11/2016 9:06 AM, Alan DeKok wrote: > I'll reply mostly in summary. > > TACACS+ is a late arrival to the IETF. It was never considered as an AAA protocol by the IETF. 20 years of IETF consensus is that TACACS+ is not an IETF protocol. It is not appropriate for a WG to re-consider that decision without a larger involvement from the IETF. The fact that a proprietary version of TACACS+ is also 20 years old is irrelevant to the IETF process. If we ignore the IETF process here, we might as well shut down the IETF as irrelevant. > > One WG should not be able to over-rule the rest of the IETF. Does another WG want to take up the reins of fixing TACACS+? > > TACACS+ catering to a "nice" related to specific work is command authorization, or device administration. This use case is so niche that it isn't even mentioned in the draft. This use-case *remains* a vendor-specific proprietary protocol. It's successfully competed with RADIUS in this space because the vendor refused to standardize command authorization in RADIUS. Most likely because they saw it as a competitive advantage. > > So... TACACS+ competed with RADIUS by forcing customers to use a proprietary protocol, to the detriment of the standards. And the reward for 20 years of this anticompetitive behaviour, is that we reward the vendor with the label "IETF approved - standards track protocol". > > Again, there is *zero* technical reason to make TACACS+ a standards track document. There are many procedural reasons to avoid making TACACS+ a standards track document. i.e. 20 years of IETF consensus. > > Those are my objections. Please explain how the document is *massively different* for implementors with two words changed: "Informational" versus "Standards Tack". Please explain why we should ignore 20 years of IETF consensus. Does anyone want to take up the reins of fixing the procedural errors of the TACACS+ draft so it meets the requirements for standards track? > >> Is there a meaningful way to address this difference in scopes? Would it help if we make it explicitly about network element AAA for management purposes and avoid chatting about NAS? > I have no objection to standardization of the functionality which is now proprietary in TACACS+. I think it's a good idea. But rubber-stamping TACACS+ without even *mentioning* device management in the draft is bizarre at best. I would say it's an oversight and not malicious. Perhaps writing the authors and asking them to add something about this would be good, or if you like you might contribute a paragraph or two. It looks like the original draft does mention device management in the Abstract, as well as giving documentation on how to do authorization and accounting for commands (as part of the REQUEST packet body). I haven't looked again at the new draft to see if it retains that information, but if not it probably needs to be put back in. >> On the topic of informational vs. standards track: >> Authors are aiming for standards track due to two reasons: >> 1) In the face of differing implementations, we cannot provide a simple recap of what works but we feel we have to make a statement on how it should work in the first place (e.g. removing ambiguities) without introducing major incompatibilities. >> 2) Device management AAA as used in the field today carries security risks. To address some of them, authors decided to slap some lipstick on a pig in the form of TLS tunnel. > Neither of those reasons requires a standards track document. I would argue #1 does require standards track, unless the difference between "standards track" and "informational" is largely academic. We need to be able to push vendors on compatibility. I don't know enough about the IETF processes to know if this is really true, but I don't think there would be 50 emails about this if it was okay with everyone to change to informational. > >> On the topic of technical benefits: >> There must be something that TACACS+ is doing at least good enough while RADIUS isn't doing it so much better to replace it. > Command authorization, because the vendor refuses to standardize it in RADIUS. Which they could have done any time in the last 20 years. They refused. > > Well... they refused. I fail to see how refusing to follow the standards process means the we should reward them with an official standards track RFC. Is the RADIUS WG going to add support for command authorization? It seems like if RADIUS wanted this then one vendor refusing to submit a standard wouldn't be a barrier. Surely anyone could write a standard and propose it as a draft? > > Alan DeKok. Robert From nobody Thu Feb 11 11:58:01 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A307A1B39C0 for ; Thu, 11 Feb 2016 11:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6MRlokuzm79a for ; Thu, 11 Feb 2016 11:57:53 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5971B3961 for ; Thu, 11 Feb 2016 11:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6721; q=dns/txt; s=iport; t=1455220673; x=1456430273; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rQhcjfLXglC6cO2goROVp1mhCYgFdtR0ITz2wr6bsQ8=; b=lkVlzfMKLqt/HJFhygJtaacAI3Es9p/FjKylMnsKHONKcay8qZdQo9G6 +s26rhz2vt91YWJPBvzAet3EqihgzhEb7NUIKLVdqmccj7VkAMVzk9UGy P4DOJocd4wrP8DTd0iIfKeWns4U5x+lZBby4e0X5qiY9pxXrHfLBa/YdG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAo57xW/4oNJK1egzpSbQaIVbEqA?= =?us-ascii?q?Q2BZxcKhSJKAoE0OBQBAQEBAQEBfwuEQQEBAQQBAQE3FBkHGwIBCBEDAQIBDBI?= =?us-ascii?q?QJwoBHQgCBBMdBId5DsEsAQEBAQEBAQEBAQEBAQEBAQEBARMEiU17hAIRAYRYB?= =?us-ascii?q?YdTjyQBjVKBXYRDiFWOPQEeAQFCg2VqhyM0fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208";a="236670372" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 19:57:52 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1BJvq2r018659 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Feb 2016 19:57:52 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 13:57:51 -0600 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.1104.009; Thu, 11 Feb 2016 13:57:51 -0600 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: OPSAWG Digest, Vol 105, Issue 61 Thread-Index: AQHRZQUFR25ws+U0m0qCeowPheJvrZ8np4EA Date: Thu, 11 Feb 2016 19:57:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.108.248] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A8D2BBC66A46F4EBD95F29157C62AFE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 61 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:57:58 -0000 Certainly we will add more detail to the specification to ensure that there is no ambiguity that: 1) The focus of the specification is to support the device administration use case, and to describe what this means. 2) That there is no intent to compete with other protocols (such as RADIUS/DIAMETER) for the network access use case. On 11/02/2016 19:46, "OPSAWG on behalf of opsawg-request@ietf.org" wrote: >Send OPSAWG mailing list submissions to > opsawg@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsawg >or, via email, send a message with subject or body 'help' to > opsawg-request@ietf.org > >You can reach the person managing the list at > opsawg-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OPSAWG digest..." > > >Today's Topics: > > 1. Re: Procedural issues with the TACACS+ document (Robert Drake) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 11 Feb 2016 14:46:11 -0500 >From: Robert Drake >To: >Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document >Message-ID: <56BCE503.7000107@direcpath.com> >Content-Type: text/plain; charset=3D"windows-1252"; format=3Dflowed > > > >On 2/11/2016 9:06 AM, Alan DeKok wrote: >> I'll reply mostly in summary. >> >> TACACS+ is a late arrival to the IETF. It was never considered as >>an AAA protocol by the IETF. 20 years of IETF consensus is that TACACS+ >>is not an IETF protocol. It is not appropriate for a WG to re-consider >>that decision without a larger involvement from the IETF. The fact that >>a proprietary version of TACACS+ is also 20 years old is irrelevant to >>the IETF process. If we ignore the IETF process here, we might as well >>shut down the IETF as irrelevant. >> >> One WG should not be able to over-rule the rest of the IETF. > >Does another WG want to take up the reins of fixing TACACS+? > >> >> TACACS+ catering to a "nice" related to specific work is command >>authorization, or device administration. This use case is so niche that >>it isn't even mentioned in the draft. This use-case *remains* a >>vendor-specific proprietary protocol. It's successfully competed with >>RADIUS in this space because the vendor refused to standardize command >>authorization in RADIUS. Most likely because they saw it as a >>competitive advantage. >> >> So... TACACS+ competed with RADIUS by forcing customers to use a >>proprietary protocol, to the detriment of the standards. And the reward >>for 20 years of this anticompetitive behaviour, is that we reward the >>vendor with the label "IETF approved - standards track protocol". >> >> Again, there is *zero* technical reason to make TACACS+ a standards >>track document. There are many procedural reasons to avoid making >>TACACS+ a standards track document. i.e. 20 years of IETF consensus. >> >> Those are my objections. Please explain how the document is >>*massively different* for implementors with two words changed: >>"Informational" versus "Standards Tack". Please explain why we should >>ignore 20 years of IETF consensus. > >Does anyone want to take up the reins of fixing the procedural errors of >the TACACS+ draft so it meets the requirements for standards track? > >> >>> Is there a meaningful way to address this difference in scopes? Would >>>it help if we make it explicitly about network element AAA for >>>management purposes and avoid chatting about NAS? >> I have no objection to standardization of the functionality which is >>now proprietary in TACACS+. I think it's a good idea. But >>rubber-stamping TACACS+ without even *mentioning* device management in >>the draft is bizarre at best. >I would say it's an oversight and not malicious. Perhaps writing the >authors and asking them to add something about this would be good, or if >you like you might contribute a paragraph or two. It looks like the >original draft does mention device management in the Abstract, as well >as giving documentation on how to do authorization and accounting for >commands (as part of the REQUEST packet body). > >I haven't looked again at the new draft to see if it retains that >information, but if not it probably needs to be put back in. > > >>> On the topic of informational vs. standards track: >>> Authors are aiming for standards track due to two reasons: >>> 1) In the face of differing implementations, we cannot provide a >>>simple recap of what works but we feel we have to make a statement on >>>how it should work in the first place (e.g. removing ambiguities) >>>without introducing major incompatibilities. >>> 2) Device management AAA as used in the field today carries security >>>risks. To address some of them, authors decided to slap some lipstick >>>on a pig in the form of TLS tunnel. >> Neither of those reasons requires a standards track document. >I would argue #1 does require standards track, unless the difference >between "standards track" and "informational" is largely academic. We >need to be able to push vendors on compatibility. I don't know enough >about the IETF processes to know if this is really true, but I don't >think there would be 50 emails about this if it was okay with everyone >to change to informational. > > >> >>> On the topic of technical benefits: >>> There must be something that TACACS+ is doing at least good enough >>>while RADIUS isn't doing it so much better to replace it. >> Command authorization, because the vendor refuses to standardize it >>in RADIUS. Which they could have done any time in the last 20 years. >>They refused. >> >> Well... they refused. I fail to see how refusing to follow the >>standards process means the we should reward them with an official >>standards track RFC. >Is the RADIUS WG going to add support for command authorization? It >seems like if RADIUS wanted this then one vendor refusing to submit a >standard wouldn't be a barrier. Surely anyone could write a standard >and propose it as a draft? > > >> >> Alan DeKok. >Robert > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 105, Issue 61 >*************************************** From nobody Thu Feb 11 12:01:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1C31B39BE for ; Thu, 11 Feb 2016 12:01:33 -0800 (PST) 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] autolearn=ham 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 WHM-W9t8HOM3 for ; Thu, 11 Feb 2016 12:01:28 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id D10EA1B39CD for ; Thu, 11 Feb 2016 12:01:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 171B1D14; Thu, 11 Feb 2016 20:01:01 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiM7z0sdu6Tj; Thu, 11 Feb 2016 20:01:01 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 895758E5; Thu, 11 Feb 2016 20:01:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 11 Feb 2016 15:00:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1E95FB31-2386-4407-B36E-C8BDDCFB31E9@deployingradius.com> References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> To: Christopher Morrow X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:01:33 -0000 On Feb 11, 2016, at 12:46 PM, Christopher Morrow = wrote: > 2989 is titled: "Criteria for Evaluating AAA Protocols for Network = Access" >=20 > 2989 is explicitly not about 'device management' or 'device > administration' access management (AAA). > tacacs+ is explicitly about 'device management' or 'device > administration' access management (AAA). The TACACS draft is silent on device management. The only discussion = in the draft of functionality is AAA. For you, the AAA RFCs I mentioned don't apply to a self-described AAA = document. Because the document really (wink wink) applies to device = management. Which it doesn't talk about. i.e. A isn't the same as B because A is really the same as C, even = though A claims to be the same as B. This is logic so twisted as to become farcical.=20 > again, not applicable to 'device management' / 'device administration' > ... so not applicable to this discussion, at all. Then you should be in favour of not standardizing the TACACS+ = document, because it doesn't talk about device management either. >> Standardizing a new AAA protocol without IETF-wide discussion means = we're ignoring the requirements of RFC 2989, and discarding the results = shown in RFC 3127. >>=20 >=20 > it doesn't seem like 'IETF-wide discussion' is being missed at all, = actually. Forgive me if I'm missing a wider CC list. Are the people who wrote = RFC 2989 and RFC 3127 involved in this discussion? No? Then a wider = IETF discussion is being missed. > perhaps, but you seem to have content questions, did you make these > comments to the authors? I think dealing with larger issues is a higher priority than editorial = comments. >> The TACACS+ functionality therefore *explicitly* overlaps 100% with = RADIUS. It is explicitly *not* "device authorization". It is uniformly = inferior to RADIUS in functionality and capability. It meets none of = the requirements set out in RFC 2989, and wasn't even considered in RFC = 3127 >=20 > because 2989 and 3127 are not about the problem tac+ solves. And neither is the TACACS+ document. > For network operations the meaning of AAA is different than that used > for 'dialup users' (or equivalent as the technology advances). >=20 > o Authorizing users of your network access to the network is different > than authorizing administration/management of the devices which make > the network. >=20 > o Accounting for the device administration activities is not the same > acocunting for bits/time spent on a customer >=20 > o Authenticating a device administrator is likely very different from > authenticating a user of the network Remind me again where the TACACS+ document discusses that? > I think you mean to rephrase and aim this comment to the editors... so > they can add a note about it in the draft. I do see discussion of > authorization and why it's important/used in the original > grant-tacacs-02 draft, and in the draft-dahm version 02 there's this: >=20 > https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01#section-5 >=20 > this seems to have some level of detail and useful information about > the authorization process/work/packets. Which is a vague discussion of "authorization". It misses "device = management" entirely. > i don't know that 'two decades' is particularly important, much has > changed over the last 20 yrs in the IETF and the Internet and in stuff > provided by vendors/etc. Making device administration better and more > secure over time is a win for operations, networks and users. While I agree with that, there were many opportunities over the last = 20 years to standardize device management in the IETF. The vendors = refused. Because (as I've said repeatedly), they saw benefits in = avoiding the standards process. Now that they're getting bitten by inter-operability problems, *oops*, = it's time get a rubber stamp on the protocol. I welcome publishing the document as an information draft. I see no = reason why it should be an IETF standard. And so far, I haven't seen a = convincing argument from anyone else. The arguments in favour amount = to: - just 'cause - it's widely used - it's not an AAA protocol, even though it's explicitly an AAA protocol Alan DeKok. From nobody Thu Feb 11 12:14:26 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F4F1B39D8 for ; Thu, 11 Feb 2016 12:14:24 -0800 (PST) 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] autolearn=ham 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 16fY3k_8Bt7L for ; Thu, 11 Feb 2016 12:14:14 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id B30F71B2F15 for ; Thu, 11 Feb 2016 12:14:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id C3A97CEE; Thu, 11 Feb 2016 20:14:13 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6XNus5O3SxH; Thu, 11 Feb 2016 20:14:13 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 1FDF88E5; Thu, 11 Feb 2016 20:14:12 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=us-ascii From: Alan DeKok In-Reply-To: <56BCE1A7.6050807@gmail.com> Date: Thu, 11 Feb 2016 15:14:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9B53AFCE-8792-4CB4-AC47-A2F0D986D759@deployingradius.com> References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> <56BCE1A7.6050807@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:14:24 -0000 On Feb 11, 2016, at 2:31 PM, Brian E Carpenter = wrote: >=20 > As far as I can tell the only point at issue here is two words in the > third header line of the draft: >=20 > "Intended status: Standards Track" For me, that's just the tip of the iceberg. There isn't much point in = talking about more minor issues when there are major issues still = unresolved. > There doesn't seem to be any dispute that TACACS+ is a widely deployed > protocol I agree. > and that this is a competent description of it, Sort of. It's a description of the TACACS+ base protocol as a generic = AAA protocol. Which *on it's face* has 100% overlap with RADIUS. The defence of TACACS+ is entirely related to use-cases which aren't in = the document. Even if we publish this document as a standards track document, the = contents of the device management queries and responses can *only* be = vendor specific. Each vendor has their own command-line syntax which, = while similar, have proprietary differences. So the *use-case* of the = protocol remains entirely vendor-specific. So the base protocol would be documented, but the practical = application thereof would be 100% vendor proprietary. That's an unusual = use-case for an IETF standard protocol. > and as already > observed the WG chairs didn't exceed their authority in the adoption > process. Since the WG hasn't yet even been asked (by WGLC) whether the > document should be approved, I can't see what appealable decision has > been taken, since basically no decision has been taken. Does this mean that WG adoption is a meaningless step? That charter = updates are meaningless steps? I'm a little surprised to see a public decision by a WG chair be = described as "no decision". That's... legalese I didn't expect in the = IETF. > Could we perhaps have a rational debate about whether the draft should = be > on the standards track or not? It's a perfectly valid question to ask. I've been asking for reasons why it should be adopted. The answers are = largely "it's widely used". Well, so is IPX. IPX has multiple implementations by multiple = vendors, and is running in probably 1000 times as many systems as = TACACS+. It's even older than TACACS+. It's still in use. Sure, IPX overlaps with IPv4, but heck... it's widely used, so let's = make it an IETF standard protocol. If you find those reasons unconvincing, you should find the reasons = for TACACS+ adoption unconvincing, too. Alan deKok. From nobody Thu Feb 11 12:21:25 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC38B1B39F6 for ; Thu, 11 Feb 2016 12:21:20 -0800 (PST) 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] autolearn=ham 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 MAU5fJtpT9l6 for ; Thu, 11 Feb 2016 12:21:11 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DC6E71B39D8 for ; Thu, 11 Feb 2016 12:21:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 42BEED14; Thu, 11 Feb 2016 20:21:05 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-1-gr5bsvIq; Thu, 11 Feb 2016 20:21:05 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id A151A8E5; Thu, 11 Feb 2016 20:21:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BCE2A0.3000909@cisco.com> Date: Thu, 11 Feb 2016 15:21:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:21:21 -0000 On Feb 11, 2016, at 2:36 PM, Eliot Lear wrote: > One has to put into perspective what was going on back then. Many = different approaches were proposed to cover not only AAA but policy in = general, and the market was at risk of fragmentation. There was a = pretty visible and dare I say heated process at the IETF that turned = into an attempt to align those who wanted to pursue policy with COPS and = COPS-PR and those who wanted to do something with RADIUS/Diameter. = RFC 3127 and its predecessor RFC 2989 represented hard work in the = context of the efforts going on at the IETF at the time. It was a tool = upon which the ADs relied to organize the work of O&M at the time. I understand. I was involved in those discussions at the time. As a = less public figure than I am now, but I was still a participant. > However, in the 15 interceding years, what's become clear is that = RADIUS has broad applicability for a great many AAA uses; and for some = cases TACACS+ is appropriate. For these purposes, such as command = authorization, TACACS+ is a defacto standard, no matter what the IETF = process says. The nascence of this space is long past. RFC 3127 was = never intended to be a constraint so far into the future but rather a = guide to ADs at the time as to how to proceed. I welcome new protocols (even old ones) to solve problems that = existing protocols don't solve. > The choice here, it seems to me, is really one of change control. I = agree with you, Tom, and others who write that the IETF doesn't just = rubber stamp protocols. On the other hand, changes should be made with = due care toward what is deployed. I personally have faith that our = processes and good community involvement would provide for a good path = forward on this. >=20 > In summary, if people want a standard, I propose the following way = forward: >=20 > 1. An applicability statement for TACACS+ that describes when TACACS+ = is appropriate for use; > 2. The proper following of working group process; > 3. Appropriate and timely IPR declarations; and > 4. It should be clear that the IETF has the necessary rights to = effect changes. Those are all good steps.=20 I'd still like to know why it's necessary to have the cachet of an = IETF standard for a protocol which is vendor-specific. And for which = the *functional* change control will still reside with the vendors. And = for which the vendors *could* have standardized it via an IETF protocol = at any time in the past 20 years, and refused, because they saw benefits = in bypassing the standardization process. i.e. the contents of any device management authorization exchange are = entirely vendor specific, and due to the way TACACS+ is being used, = *must* remain vendor-specific. Alan DeKok. From nobody Thu Feb 11 12:30:24 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FE51B3A0F for ; Thu, 11 Feb 2016 12:30:21 -0800 (PST) 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] autolearn=ham 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 0JGjSCE3Nl91 for ; Thu, 11 Feb 2016 12:30:19 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7B21B3A0D for ; Thu, 11 Feb 2016 12:30:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 62CAA11C9; Thu, 11 Feb 2016 20:30:18 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyvr7-GOArkl; Thu, 11 Feb 2016 20:30:18 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id EB3078E5; Thu, 11 Feb 2016 20:30:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BCE503.7000107@direcpath.com> Date: Thu, 11 Feb 2016 15:30:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <484DE7E8-363F-45EE-B521-78E53E0582C1@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> <56BCE503.7000107@direcpath.com> To: Robert Drake X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:30:21 -0000 On Feb 11, 2016, at 2:46 PM, Robert Drake wrote: >> One WG should not be able to over-rule the rest of the IETF. >=20 > Does another WG want to take up the reins of fixing TACACS+? That's not my point. My point is that we have IETF consensus on = topics. A WG shouldn't be able to over-ride IETF consensus without = having a larger discussion. i.e. Involving the people who established = IETF consensus, and explaining why the WG needs to go against it. With reasons. Not "It's popular". > I would argue #1 does require standards track, unless the difference = between "standards track" and "informational" is largely academic. We = need to be able to push vendors on compatibility. I don't know enough = about the IETF processes to know if this is really true, but I don't = think there would be 50 emails about this if it was okay with everyone = to change to informational. I think the discussions are because most people don't see much of a = difference between standards track and informational. I do. > Is the RADIUS WG going to add support for command authorization? It = seems like if RADIUS wanted this then one vendor refusing to submit a = standard wouldn't be a barrier. Surely anyone could write a standard = and propose it as a draft? It would be well within the scope of RADEXT. The RADEXT WG would (I'm = guessing) be OK with standardizing it. But while anyone can write a standard, any standard is pointless = unless it's implemented. And the vendors have refused to standardize = command authorization in RADIUS. Because they saw it as a competitive advantage to bypass the IETF. = Now that they have problems with inter-operability, they're looking for = IETF approval. Again, why is there a need to have the document as standards track? = RADIUS accounting (RFC 2866) is Informational, for crying out loud. Are = we really saying that RADIUS / RADEXT WG with an active history going = back to 1996 is *not* going to have a standards track protocol, but = TACACS+ gets one, because "it's popular"? That's an amazing interpretation of the IETF consensus, and IETF = process. Maybe I'm naive, but it looks a while lot to me like one WG = has to follow the rules to get a protocol standardized, and another WG = doesn't. Alan DeKok. From nobody Thu Feb 11 12:34:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495D41B2F37 for ; Thu, 11 Feb 2016 12:34:16 -0800 (PST) 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] autolearn=ham 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 f0TkIXmqP2mE for ; Thu, 11 Feb 2016 12:34:06 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5401B39DD for ; Thu, 11 Feb 2016 12:34:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 4E69612C6; Thu, 11 Feb 2016 20:34:01 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYGfv0QRFguu; Thu, 11 Feb 2016 20:34:01 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 7DF128E5; Thu, 11 Feb 2016 20:34:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 11 Feb 2016 15:33:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6F7DA1C6-DB03-49F7-8A34-D53290939FC5@deployingradius.com> References: <56BBD1FE.3050206@gmail.com> <7EE28A5A-0C73-4F9D-B52E-0BFB1E985B52@deployingradius.com> To: Christopher Morrow X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:34:16 -0000 On Feb 11, 2016, at 1:00 PM, Christopher Morrow = wrote: >=20 > On Wed, Feb 10, 2016 at 10:37 PM, Alan DeKok = wrote: >> TACACS+ has 100% functionality overlap with RADIUS. >=20 > you keep saying this, but I can't get a radius server to authorize my > command on a network device in my network... Because the vendors refused to standardize it, and refused to cede = change control to the IETF. > I think you are very much in the rough, and I'm not clear on why you > are as vigorous about this. I've been explaining. In detail. I have this odd idea that processes and consensus matter. If they = don't, then I'm going to declare myself the dictator of RADEXT, and = demand publication of any crazy idea I come up with. Because processes = don't matter. > There are network operators on this list > and in the rest of the world that have said: "tac+ is how I AAA my > network gear, I need it to be improved/worked-on/etc, please do that > for me" Will those vendors cede change control to the IETF for the contents of = TACACS+? i.e. the commands being authorized? No? Then... TACACS+ won't be an IETF protocol, will it? > also: "I support this draft, and want to see it complete the IETF > process... so I can then start having better security of the > management of my global network elements." Vendors do all kinds of inventive things. Things which are perceived = as useful, and which are widely deployed. Not all of them are made IETF standards. I have this strange idea = that there is "process" and "consensus" required for IETF = standardization. Not just "it's popular, so *boom*, it's a standard!". Alan DeKok. From nobody Thu Feb 11 12:35:34 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E3A1B3A1A for ; Thu, 11 Feb 2016 12:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 8GaALgnEgjHb for ; Thu, 11 Feb 2016 12:35:24 -0800 (PST) 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 D6C511B3A17 for ; Thu, 11 Feb 2016 12:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5019; q=dns/txt; s=iport; t=1455222922; x=1456432522; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sIZYIBJUnAQTPxlnyo497R4hsNA4GzZ4j84hQGEiGUY=; b=R80k7/ZE8yk8Cxr9BF6b9LBmRdejsUOWkiGShWzU3wdnv13q17nY5Mu7 RNneXp0jdShw1chK4h1ac7DozGRr5PgmJ2fkRGwBKHuGKpiGR7dL8l32m aQ2wMmaxDt721n8dvpDc5aJ904t4J9jEgVvi1Ahuo53JYAz0BJWVKTqBe U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUBQDT77xW/4wNJK1egzpSbQaIVbMgF?= =?us-ascii?q?wqFIkoCgTU8EAEBAQEBAQF/C4RBAQEBBAEBAUsgGwIBCBEDAQIBDCInCgEdCAI?= =?us-ascii?q?EExQJBId5DsE4AQEBAQEBAQEBAQEBAQEBAQEBARMEikiEAhEBJIQ0BYdThVQ4i?= =?us-ascii?q?RgBjVKBXYRDiFWOPQE3K4NlaocjNHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208";a="70525363" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 20:35:18 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1BKZINu024795 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Feb 2016 20:35:18 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 14:35:17 -0600 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.1104.009; Thu, 11 Feb 2016 14:35:17 -0600 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: OPSAWG Digest, Vol 105, Issue 65 Thread-Index: AQHRZQnLDEBtzL9uN02QX4V6qHgx158nsemA Date: Thu, 11 Feb 2016 20:35:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.108.248] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 65 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:35:31 -0000 I believe the content isn=B9t entirely vendor specific. For example, for command authorisation, the standard authorisation packet from the document is: service=3Dshell cmd=3D cmd-arg=3D cmd-arg=3D ... This level of content is specified in the document, but if the comment is that it is insufficiently clear then I would accept that and we can raise its visibility. If, on the other hand you mean that the and are vendor specific, then clearly, this is the case, but that is a feature of a higher level in the stack than this document could specify. On 11/02/2016 20:21, "OPSAWG on behalf of opsawg-request@ietf.org" wrote: >Send OPSAWG mailing list submissions to > opsawg@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsawg >or, via email, send a message with subject or body 'help' to > opsawg-request@ietf.org > >You can reach the person managing the list at > opsawg-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OPSAWG digest..." > > >Today's Topics: > > 1. Re: Way forward? Re: Procedural issues with the TACACS+ > document (Alan DeKok) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 11 Feb 2016 15:21:03 -0500 >From: Alan DeKok >To: Eliot Lear >Cc: "opsawg@ietf.org" >Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the > TACACS+ document >Message-ID: >Content-Type: text/plain; charset=3Dus-ascii > >On Feb 11, 2016, at 2:36 PM, Eliot Lear wrote: >> One has to put into perspective what was going on back then. Many >>different approaches were proposed to cover not only AAA but policy in >>general, and the market was at risk of fragmentation. There was a >>pretty visible and dare I say heated process at the IETF that turned >>into an attempt to align those who wanted to pursue policy with COPS and >>COPS-PR and those who wanted to do something with RADIUS/Diameter. >>RFC 3127 and its predecessor RFC 2989 represented hard work in the >>context of the efforts going on at the IETF at the time. It was a tool >>upon which the ADs relied to organize the work of O&M at the time. > > I understand. I was involved in those discussions at the time. As a >less public figure than I am now, but I was still a participant. > >> However, in the 15 interceding years, what's become clear is that >>RADIUS has broad applicability for a great many AAA uses; and for some >>cases TACACS+ is appropriate. For these purposes, such as command >>authorization, TACACS+ is a defacto standard, no matter what the IETF >>process says. The nascence of this space is long past. RFC 3127 was >>never intended to be a constraint so far into the future but rather a >>guide to ADs at the time as to how to proceed. > > I welcome new protocols (even old ones) to solve problems that existing >protocols don't solve. > >> The choice here, it seems to me, is really one of change control. I >>agree with you, Tom, and others who write that the IETF doesn't just >>rubber stamp protocols. On the other hand, changes should be made with >>due care toward what is deployed. I personally have faith that our >>processes and good community involvement would provide for a good path >>forward on this. >>=20 >> In summary, if people want a standard, I propose the following way >>forward: >>=20 >> 1. An applicability statement for TACACS+ that describes when TACACS+ >>is appropriate for use; >> 2. The proper following of working group process; >> 3. Appropriate and timely IPR declarations; and >> 4. It should be clear that the IETF has the necessary rights to effect >>changes. > > Those are all good steps. > > I'd still like to know why it's necessary to have the cachet of an IETF >standard for a protocol which is vendor-specific. And for which the >*functional* change control will still reside with the vendors. And for >which the vendors *could* have standardized it via an IETF protocol at >any time in the past 20 years, and refused, because they saw benefits in >bypassing the standardization process. > > i.e. the contents of any device management authorization exchange are >entirely vendor specific, and due to the way TACACS+ is being used, >*must* remain vendor-specific. > > Alan DeKok. > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 105, Issue 65 >*************************************** From nobody Thu Feb 11 13:14:18 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B688E1B3A8F for ; Thu, 11 Feb 2016 13:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 FaJPm9aq90xW for ; Thu, 11 Feb 2016 13:14:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF52B1B3A4F for ; Thu, 11 Feb 2016 13:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5844; q=dns/txt; s=iport; t=1455225250; x=1456434850; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yhxrnHJhmcX7ONEEkpjJ0E2IsQz8sQnx18go1A3ZixA=; b=mcLq0JPurs6oRWXk5c7EMX5sk42RO0xHKsX5KkRHqkxrixaacKLyYnWy eeWWdoM/8xDSOGQ/HKzuGdtc7PqCdwHsliQ3K779d0p+Oey6V8xo1+RiW krBuXxjFVFAHfqH6QyrmIGOtknfQHI88uAgDcG4O9EKy3yn5x4UYQV9TF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBQAy+bxW/4MNJK1egzpSbQaIVbMgF?= =?us-ascii?q?wqFIkoCgTU7EQEBAQEBAQGBCoRBAQEBAwEBAQE3FBkHEAsCAQgRAwECAQwSECc?= =?us-ascii?q?KAR0IAgQBEhQJBIdxCA7BNwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEikiEAhEBJ?= =?us-ascii?q?IQ0BYdTixuECQGNUoFdhEOIVY49ATYsg2VqhyM0fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208";a="76138318" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 21:14:09 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1BLE9MW017686 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 21:14:09 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 15:14:09 -0600 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.1104.009; Thu, 11 Feb 2016 15:14:09 -0600 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" , "aland@deployingradius.com" Thread-Topic: OPSAWG Digest, Vol 105, Issue 65 Thread-Index: AQHRZQnLDEBtzL9uN02QX4V6qHgx158nvMiA Date: Thu, 11 Feb 2016 21:14:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.108.248] Content-Type: text/plain; charset="us-ascii" Content-ID: <17B2A0C9EA77D649B0D26A3D4E4148FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 65 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 21:14:15 -0000 On 11/02/2016 20:21, "OPSAWG on behalf of opsawg-request@ietf.org" wrote: >Send OPSAWG mailing list submissions to > opsawg@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsawg >or, via email, send a message with subject or body 'help' to > opsawg-request@ietf.org > >You can reach the person managing the list at > opsawg-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OPSAWG digest..." > > >Today's Topics: > > 1. Re: Way forward? Re: Procedural issues with the TACACS+ > document (Alan DeKok) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 11 Feb 2016 15:21:03 -0500 >From: Alan DeKok >To: Eliot Lear >Cc: "opsawg@ietf.org" >Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the > TACACS+ document >Message-ID: >Content-Type: text/plain; charset=3Dus-ascii > >On Feb 11, 2016, at 2:36 PM, Eliot Lear wrote: >> One has to put into perspective what was going on back then. Many >>different approaches were proposed to cover not only AAA but policy in >>general, and the market was at risk of fragmentation. There was a >>pretty visible and dare I say heated process at the IETF that turned >>into an attempt to align those who wanted to pursue policy with COPS and >>COPS-PR and those who wanted to do something with RADIUS/Diameter. >>RFC 3127 and its predecessor RFC 2989 represented hard work in the >>context of the efforts going on at the IETF at the time. It was a tool >>upon which the ADs relied to organize the work of O&M at the time. > > I understand. I was involved in those discussions at the time. As a >less public figure than I am now, but I was still a participant. > >> However, in the 15 interceding years, what's become clear is that >>RADIUS has broad applicability for a great many AAA uses; and for some >>cases TACACS+ is appropriate. For these purposes, such as command >>authorization, TACACS+ is a defacto standard, no matter what the IETF >>process says. The nascence of this space is long past. RFC 3127 was >>never intended to be a constraint so far into the future but rather a >>guide to ADs at the time as to how to proceed. > > I welcome new protocols (even old ones) to solve problems that existing >protocols don't solve. > >> The choice here, it seems to me, is really one of change control. I >>agree with you, Tom, and others who write that the IETF doesn't just >>rubber stamp protocols. On the other hand, changes should be made with >>due care toward what is deployed. I personally have faith that our >>processes and good community involvement would provide for a good path >>forward on this. >>=20 >> In summary, if people want a standard, I propose the following way >>forward: >>=20 >> 1. An applicability statement for TACACS+ that describes when TACACS+ >>is appropriate for use; >> 2. The proper following of working group process; >> 3. Appropriate and timely IPR declarations; and >> 4. It should be clear that the IETF has the necessary rights to effect >>changes. > > Those are all good steps. > > I'd still like to know why it's necessary to have the cachet of an IETF >standard for a protocol which is vendor-specific. So the protocol itself is not intended to be vendor specific, and if you spot any vendor specific elements, please shout them out so that we can discard them. > And for which the *functional* change control will still reside with >the vendors. In terms of the data on top of the protocol, such as specific commands and arguments, then I think this is a higher level on the stack. I would suggest that this would generally be regarded as application layer configuration in the TACACS+ servers. > And for which the vendors *could* have standardized it via an IETF >protocol at any time in the past 20 years, and refused, because they saw >benefits in bypassing the standardization process. I am not aware of any refusal to standardise the TACACS+ protocol. In fact it was only a couple of years ago that I realised that TACACS+ had never been approved as a standard by IETF, it is so pervasive that I assumed it had been. I had it on my todo list to try to rectify that situation, and so when some engineers from outside Cisco, who were users of the protocol suggested moving forward with standardisation I was very happy to contribute, and generally the response has been favourable. > > i.e. the contents of any device management authorization exchange are >entirely vendor specific, and due to the way TACACS+ is being used, >*must* remain vendor-specific. Certainly, the content that the protocol carries must be flexible enough to support the needs of whatever applications vendors and users need, as requirements evolve. But we can standardise the way the commands are encoded, and that is the purpose of the document. Is this level of standardisation, I.e. How device application level commands are encoded, acceptable to you, rathe than requiring we standardise the application level commands themselves? Thanks, Regards, Doug. > > Alan DeKok. > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 105, Issue 65 >*************************************** From nobody Thu Feb 11 14:54:11 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5151F1B2A56 for ; Thu, 11 Feb 2016 14:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Csrz-P1jqX0L for ; Thu, 11 Feb 2016 14:54:05 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9E91B3B1B for ; Thu, 11 Feb 2016 14:54:05 -0800 (PST) Received: by mail-pa0-x22a.google.com with SMTP id p5so5617461paw.1 for ; Thu, 11 Feb 2016 14:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=LVVPW3YXoAQkk13o17Oq5JvsS9eb9N0oL8fsyYtZSMI=; b=w+q0QkwV0Z5pDEdAR6fz52h8+bcbXM3xDrKxzvRLjvYUN1NZuyUBDXvXzVLJHWmsX4 Ee/uKSCFv2c/oiA4FIpVXbo7HxaSJV0P15csj71h7ciAZIhwcSUIYp5oZKqu9pj9Ld+N 8RBWS+gLptpA4WrckIVN083PioCdYvuaAjsVEDQON5zYVw1qC37MxaglPkjVYbT/Ve5J AvFBUnCG17bA1blqfZJluyJquvSufDh/CXp4w+SRqoWP0FwqWD81P3qgbQ+WCTYr9yDI 5ix8AQzRdnzJY/Aa1vzL8NkUCC7Q7X1riAyVN0da4iL4/bBwK/jwt3dyQlvn7di+yV7S DOQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=LVVPW3YXoAQkk13o17Oq5JvsS9eb9N0oL8fsyYtZSMI=; b=C8SKfD5iTaPxdHwk34Nx8IP6leSMI3J5YFEBTmiJUJRcreOjDKlrtrqCNQW9t1/Gui uRV504/hGuiRf/clFvkFMMsJMsvNnlIlLw8EkQFPY3s0Q/30tZGvcDvUe3gkmN8qAw9n fFK6tIBGUEfhlrn1h3L3N80ZUCfIW7ibU5ZGJDgdOBtykb9dfTDxjukyxCvoItUeX6QM rG9qjOOJbYnZ9qhNgInGOa799wMd14uD8pXtWSR0Iu7/+3lxuegEH4aU3GXf2Qr+VXaG d82Wn0L+IIYsoa9p7GFmccoNdwG9E7UgFDe7UonsG1Tvr+HsEhwdIxO1/C4AymK6L7Xt jJIQ== X-Gm-Message-State: AG10YOQS8jFjsvox/g63CzWTYjEjz2ezJkkbcNQ7ROs++uGMJ5pUmyJSCS5HYuM+0Dog5g== X-Received: by 10.66.55.106 with SMTP id r10mr55918197pap.133.1455231244858; Thu, 11 Feb 2016 14:54:04 -0800 (PST) Received: from ?IPv6:2406:e007:5496:1:28cc:dc4c:9703:6781? ([2406:e007:5496:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c24sm14603987pfj.41.2016.02.11.14.54.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 14:54:03 -0800 (PST) To: Alan DeKok References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> <56BCE1A7.6050807@gmail.com> <9B53AFCE-8792-4CB4-AC47-A2F0D986D759@deployingradius.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56BD1113.2010106@gmail.com> Date: Fri, 12 Feb 2016 11:54:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <9B53AFCE-8792-4CB4-AC47-A2F0D986D759@deployingradius.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:54:10 -0000 On 12/02/2016 09:14, Alan DeKok wrote: > On Feb 11, 2016, at 2:31 PM, Brian E Carpenter wrote: >> >> As far as I can tell the only point at issue here is two words in the >> third header line of the draft: >> >> "Intended status: Standards Track" > > For me, that's just the tip of the iceberg. There isn't much point in talking about more minor issues when there are major issues still unresolved. > >> There doesn't seem to be any dispute that TACACS+ is a widely deployed >> protocol > > I agree. > >> and that this is a competent description of it, > > Sort of. It's a description of the TACACS+ base protocol as a generic AAA protocol. Which *on it's face* has 100% overlap with RADIUS. > > The defence of TACACS+ is entirely related to use-cases which aren't in the document. > > Even if we publish this document as a standards track document, the contents of the device management queries and responses can *only* be vendor specific. Each vendor has their own command-line syntax which, while similar, have proprietary differences. So the *use-case* of the protocol remains entirely vendor-specific. > > So the base protocol would be documented, but the practical application thereof would be 100% vendor proprietary. That's an unusual use-case for an IETF standard protocol. > >> and as already >> observed the WG chairs didn't exceed their authority in the adoption >> process. Since the WG hasn't yet even been asked (by WGLC) whether the >> document should be approved, I can't see what appealable decision has >> been taken, since basically no decision has been taken. > > Does this mean that WG adoption is a meaningless step? Yes, in terms of the IETF process rules for approving a document are concerned. The notion of formal WG adoption is useful innovation, but it isn't actually required by the rules. > That charter updates are meaningless steps? Charter updates are formal step, but the OPSAWG charter is already written to encompass work of this kind. As I hinted before, it's unfortunate that the WG milestones haven't been updated recently, but that's true of many WGs. We are collectively sloppy on that. > I'm a little surprised to see a public decision by a WG chair be described as "no decision". That's... legalese I didn't expect in the IETF. It's no decision on the disposition of the document. Until the end of a WG last call, the document is completely open for discussion and change by the WG. >> Could we perhaps have a rational debate about whether the draft should be >> on the standards track or not? It's a perfectly valid question to ask. > > I've been asking for reasons why it should be adopted. The answers are largely "it's widely used". Actually I think you've been asking for reasons why it should standardised, and there are only two words in the draft header that affect that question. I don't really have an opinion on that. > Well, so is IPX. IPX has multiple implementations by multiple vendors, and is running in probably 1000 times as many systems as TACACS+. It's even older than TACACS+. It's still in use. > > Sure, IPX overlaps with IPv4, but heck... it's widely used, so let's make it an IETF standard protocol. > > If you find those reasons unconvincing, you should find the reasons for TACACS+ adoption unconvincing, too. TACACS+ is used by IP operators, so it seems relevant in a way that IPX isn't. But if you want to propose an IPX BOF in the Internet Area, or request a slot in a future INTAREA WG meeting for IPX, you're obviously free to do so. Rgds Brian From nobody Thu Feb 11 14:59:58 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97161B3B1B for ; Thu, 11 Feb 2016 14:59:46 -0800 (PST) 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] autolearn=ham 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 b_6f4l3gFeHV for ; Thu, 11 Feb 2016 14:59:41 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC881B3BCF for ; Thu, 11 Feb 2016 14:59:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 4F1D5D98; Thu, 11 Feb 2016 22:59:40 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l14VswGuo2hL; Thu, 11 Feb 2016 22:59:40 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id C2B97B63; Thu, 11 Feb 2016 22:59:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 11 Feb 2016 17:59:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4C569A3E-7A96-48B4-BEEF-0A73FEA9B218@deployingradius.com> References: To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 65 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:59:47 -0000 On Feb 11, 2016, at 4:14 PM, Douglas Gash (dcmgash) = wrote: > In terms of the data on top of the protocol, such as specific commands = and > arguments, then I think this is a higher level on the stack. I would > suggest that this would generally be regarded as application layer > configuration in the TACACS+ servers. That is a good argument... but it means that the purpose of the = protocol is little more than transporting vendor-specific data. Which = makes the protocol less relevant for standardization. > Is this level of standardisation, I.e. How device application level > commands are encoded, acceptable to you, rathe than requiring we > standardise the application level commands themselves? It's a step. But my concerns still remain. My concerns would be best addressed by pretty much re-writing the = document, and changing it's focus. Remove all of the discussion of = TACACS+ as a AAA protocol. Remove the definitions of Authentication, = Authorization, and Accounting, they are well known and defined in many = other places. Make it clear that the focus of the protocol is command = authorization, and nothing else. That other functionality is = deprecated, and SHOULD NOT be used. If that mirrors the current use-case for the protocol, these changes = should be acceptable. if the changes are not acceptable, then it's = clear that the protocol is intended to compete directly with RADIUS. In = which case I wold object strenuously to the document as a standards = track protocol. The security considerations section of the document needs to be more = than a paragraph. The non-TLS version of the TLS protocol should be = deprecated. For" 3.6.1. Legacy Body Encryption", the text should be changed to = use the term "obfuscation". The method described is not what would be = described in the crypto community as "encryption". IMHO, the packet = encryption method should be removed entirely, and TLS transport = mandated. Alan DeKok. From nobody Thu Feb 11 15:48:31 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E258F1B3CA5 for ; Thu, 11 Feb 2016 15:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 JbKgXLCfF2EO for ; Thu, 11 Feb 2016 15:48:16 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC181B3CA2 for ; Thu, 11 Feb 2016 15:48:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2867; q=dns/txt; s=iport; t=1455234493; x=1456444093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BeU3wXIQp4a2rlvN8ssjSzz/hUbog/Qq9S4zi5PtF8Y=; b=B9u8Dkk6EFlYfGUQc8/32OEEtUckYvXiD8yyqpmCR5rad9rcEEQDFA/i BCTuvQ6/ca4mvt0/Dg5zwK/gNZGTCssFWc372jvs+5nOPhasTeXsCKR6Y EzhpqjvQsprIUjZ9r4iFE2QbA4QEcLTV+2j89V3x43l81lmhcS2iHou9p 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALBQAGHb1W/4UNJK1egzqBPwaIVa8bg?= =?us-ascii?q?iGBZ4YNAoE2OhIBAQEBAQEBgQqEQgEBBHkQAgEIRjIlAgQOBRSIBsFFAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBGIlNe4hsBY1fhQ+ECQGNUo51jj0BJwE6g2Vqh1d8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="237549056" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 23:48:13 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u1BNmD11011258 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 23:48:13 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 17:48:12 -0600 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.1104.009; Thu, 11 Feb 2016 17:48:12 -0600 From: "Douglas Gash (dcmgash)" To: Alan DeKok Thread-Topic: OPSAWG Digest, Vol 105, Issue 65 Thread-Index: AQHRZQnLDEBtzL9uN02QX4V6qHgx158nvMiAgAAdfQCAAA2NAA== Date: Thu, 11 Feb 2016 23:48:12 +0000 Message-ID: References: <4C569A3E-7A96-48B4-BEEF-0A73FEA9B218@deployingradius.com> In-Reply-To: <4C569A3E-7A96-48B4-BEEF-0A73FEA9B218@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.108.248] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 65 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 23:48:25 -0000 I think that your suggestions about refocussing the document to clarify that the use case of TACACS+ is for Device Administration makes good sense. I agree it will likely entail a significant re-work, but I don=B9t think that the author collective will shy from that. Further, I think this input will ultimately make it a better and more appropriate document, and hopefully, even a standard. I also agree with change of terminology of the legacy encryption to obfuscation. Outright removal might be tricky, but instead casting it strongly as a deprecated may help bridge the gap. We may need a little time, but I think we can use this to get a good outcome, thanks for your patient input! Thanks, Regards, Doug. On 11/02/2016 22:59, "Alan DeKok" wrote: >On Feb 11, 2016, at 4:14 PM, Douglas Gash (dcmgash) >wrote: >> In terms of the data on top of the protocol, such as specific commands >>and >> arguments, then I think this is a higher level on the stack. I would >> suggest that this would generally be regarded as application layer >> configuration in the TACACS+ servers. > > That is a good argument... but it means that the purpose of the >protocol is little more than transporting vendor-specific data. Which >makes the protocol less relevant for standardization. > >> Is this level of standardisation, I.e. How device application level >> commands are encoded, acceptable to you, rathe than requiring we >> standardise the application level commands themselves? > > It's a step. But my concerns still remain. > > My concerns would be best addressed by pretty much re-writing the >document, and changing it's focus. Remove all of the discussion of >TACACS+ as a AAA protocol. Remove the definitions of Authentication, >Authorization, and Accounting, they are well known and defined in many >other places. Make it clear that the focus of the protocol is command >authorization, and nothing else. That other functionality is deprecated, >and SHOULD NOT be used. > > If that mirrors the current use-case for the protocol, these changes >should be acceptable. if the changes are not acceptable, then it's clear >that the protocol is intended to compete directly with RADIUS. In which >case I wold object strenuously to the document as a standards track >protocol. > > The security considerations section of the document needs to be more >than a paragraph. The non-TLS version of the TLS protocol should be >deprecated. > > For" 3.6.1. Legacy Body Encryption", the text should be changed to use >the term "obfuscation". The method described is not what would be >described in the crypto community as "encryption". IMHO, the packet >encryption method should be removed entirely, and TLS transport mandated. > > Alan DeKok. > From nobody Thu Feb 11 22:01:46 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653631B4001 for ; Thu, 11 Feb 2016 22:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 F-e4zM5mSy34 for ; Thu, 11 Feb 2016 22:01:42 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513AA1B4000 for ; Thu, 11 Feb 2016 22:01:42 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0ED0DA2; Fri, 12 Feb 2016 07:01:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1455256900; bh=mMCWLzUpmcSRrIyyIr+G0dyaocrfCGmPgS5cNoC1MpE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=VFdyUq5LOGenRD215u+as36QZnb1lBSRk5xV3OWKzjerlD4jDKA/UoDQy3OZKbUqW TykLWJohwPY898zKHjwPTFkUNjioQnzOjia6mWAyrTrN4/Xy5ScoUNarG9DoVWdpxy 3tpsqvcsVwWsA3yO/FqHf1tBm/06LXKXDDNYZDt4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0705FA1; Fri, 12 Feb 2016 07:01:40 +0100 (CET) Date: Fri, 12 Feb 2016 07:01:39 +0100 (CET) From: Mikael Abrahamsson To: Alan DeKok In-Reply-To: Message-ID: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 06:01:44 -0000 On Thu, 11 Feb 2016, Alan DeKok wrote: > I'd still like to know why it's necessary to have the cachet of an IETF > standard for a protocol which is vendor-specific. It is not vendor specific. In the past 15 years I have used TAC+ on Cisco, Juniper, Huawei and others. That's what we used, and if you wanted to provide IP core equipment, that's what you had to support. Basically, if you're sending packets through an IP core network today, those devices are likely to do AAA using TAC+. Apart from that, these IP core routers use mechanisms that are "all" documented in an IETF RFC. I just don't understand your objection to also documenting the AAA protocol that is in super widespread use in the industry. To me, it's like you would be saying that IS-IS shouldn't be in the IETF because it was originally an ISO protocol. It's equally absurd. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 12 01:44:53 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C171B4278 for ; Fri, 12 Feb 2016 01:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 90xkryA0G_G5 for ; Fri, 12 Feb 2016 01:44:41 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0105.outbound.protection.outlook.com [104.47.0.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02971B427A for ; Fri, 12 Feb 2016 01:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fx+YO0jPs/v1F4rHp/u03NWqlZWcJjPegL1GWvN/c38=; b=IX3XSN6wGrayHhiPuJQNnE3NTmXDlEuUjfLZdj4UhT07hmdm2lH0JAXmuoN476jldmfsYQzoOtIE4MIYumuPsBZGpmncFUHEOpKTKVVVc50nlBx67bk56VG4E+jbVqn/z5swDB6GkgHQSRgm5IKA22/0n1ZhRiI14HlidnkXjqw= Authentication-Results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 12 Feb 2016 09:44:37 +0000 Message-ID: <00cc01d16579$85bc1880$4001a8c0@gateway.2wire.net> From: t.petch To: Alan DeKok , Mikael Abrahamsson , Eliot Lear References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> Date: Fri, 12 Feb 2016 09:41:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB3PR08CA0026.eurprd08.prod.outlook.com (25.161.51.164) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 2:4HaATDk03MSqO/kOgGzJ4tAyRBhAYw9Ki4e+h9NZQuaRTC8uN6Rj+XhWpTJd1ImRvwv3NL9jO5yLnms507YkjqyBK4KZRO6QgMQ31FJXOgehiKWDY/Vf6XSgMSgWq92wCCbuHLB3yLoJh7pohnJCaA==; 3:0Ibrxp64rZ7QWg3GahilErAUhnge8KMqX2h/fzidSMqKWB+HOWjUEGmgKErMh2FXfNZ1cmPQZFYdEfT7XLkPWB7gtZ52iNe0IfX3VEHKHnCp/yi85G4U8gRGZ6kaNAVn; 25:bWxp3oqbAcCbePAJn0VCLY8ldOAMd6XKYQKKF3qhMSwKhnHhnDFtqsZZT/gcsVLHMALQtQkykEySAIMzeIm4GXsiPNA+30L3j2P6eYlMqBGPmnApnD8NLHLwwWdJFCLX5DKVVIYvmerzEMxcUt/d8fHiblmbyb9SU6lmjekXxkakOu4hzAEhTLgu/f1jdIfQJUsvMtCTh1NqPI8fV9UvC8TnFLBMYj38ZJ5Nwq+LHtPy1udSWnfSOZtnmKBDMd94C0X40iATcwdGXy+ErIUgqKyqa5Qik96pQ9k1B0UxcZONH27DvrEhpvvxQaHVeaa8 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-MS-Office365-Filtering-Correlation-Id: fb77ef5c-6195-4d2a-04af-08d333911f27 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB051; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB051; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 4:0jmdCVpV5TfHpHQ+cEtmd3/qN4DDmJ06gRQWPeohdMRrV3A6d5TMhL5F2wmhrqh3EgFY2gDXtfgf0o8+KnUlqFBSsra7Fmq6BBJG7mRdxvktRmIBKhJ8/trEZ+dbDpNLS2hr7gt0EIu1o05UvXMbjuZh/fvlvcNW1iiMzw0sWn18lZYJCUFAU9cpL5TMM2QsPL5Wq0l9YNhVG2A647kDURe+H0n0M46F2yHbr1r/0h/2v7mY6xyBlo57q565g0FYZ5X2s2iyDW+KpVYXML/755y4TuIHqCBCzsaA8HaJh9b5ulwxRg9wDXMgCIvO4nCJlN28U4AiNxVkLQVkPTrRNEBL9qYipXrSPErWcQKf4isAHq8JGOzCuBhJR544RT22qh4CEmWOsF4EhkY2iMGidFLa6mUwkJp5y1n1HRql00M= X-Forefront-PRVS: 0850800A29 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(479174004)(19580405001)(50466002)(47776003)(87976001)(93886004)(66066001)(189998001)(44716002)(5001770100001)(44736004)(2906002)(19580395003)(5008740100001)(561944003)(86362001)(61296003)(1096002)(14496001)(116806002)(4326007)(122386002)(81686999)(50986999)(76176999)(230700001)(5001960100002)(81816999)(62236002)(33646002)(77096005)(5820100001)(586003)(50226001)(84392002)(42186005)(5004730100002)(92566002)(40100003)(3846002)(6116002)(23676002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVNQUjA3TUIwNTE7MjM6TUYzVGpmQitXZEVhYS8yVWZKaGQxOE9ycFM0?= =?utf-8?B?aW5laXYrUW5CcEo0VWxuM05NZDV3bUY2YlZsdHdsM04rWitrdDFxVWNOUmJ3?= =?utf-8?B?MlIvODkrOUNNa0o5dVF6elk4TUJoVVFScCtLZXMzMlpaMjg4L3JKaFppMEYw?= =?utf-8?B?OG9sdEVQSDBzdHdkRXNhZEpzVFhveENHNE1NZGhkVUJvc05XQXpqamZVQWhY?= =?utf-8?B?eFlER1g4cCtIb3VUUzF5Y0RnbGVxZFlPT2ZYaXl6NFNQRjBQaFV4VDBXbWNH?= =?utf-8?B?a0FzcXAwSklOTjhqc3hnQXF5V3hla1U2cDlRMFUvTkUyTmFIMjMyTDIyNTV3?= =?utf-8?B?MGxseDlYamVCOEcranBySTI1b21OMm0rOENPS3lsUHRpQXUzUGpWNU1YaDhs?= =?utf-8?B?NGN3MDcxcmkwTUgralJVSjFqd2k4dEFYN3F5aTFHQytqVjNoem1qV3dVME1i?= =?utf-8?B?SlMxdzBjZlllYlY1cktNTmJ2Nmk0d2FocWxJbGYrWGZweS9BT0NSaHEwVGlV?= =?utf-8?B?bWZnMjltMFlVaU1qcVBteGJLanBtRHg5SU1rKzRISUJUd2pPYlBvUFBOZ2th?= =?utf-8?B?UGJ4ZzY4L3BnS3hmemgzQUJOVFBRNEZpU21XSFBrYjNVRHVVbzFDYXIxK3Ft?= =?utf-8?B?Z05WUGFCZkZQZGp2QTFTaGROYlgvb3RCQ2JJRE5LK2NUWE51Z0VseWJyWHlX?= =?utf-8?B?MUswcFlScW1VWERYNExqMmlKWjl3Y1dsZDV2a1BSb3NQK1JXR2I4NnRwZGh1?= =?utf-8?B?M0dYKzUrd0FxZlNIdUt5dTlJeVp1aDBiZlF6R1psbTlhaEVJWWUwWGxqU2Y2?= =?utf-8?B?VUQwdGZOTXZiQ3E1RjliT1FaZ1ptUDMrSi9Ub3VYYzZqSGVpMHhGQnBiRDRJ?= =?utf-8?B?UnFRVmtSQzhkOHBKWGtVUFNkcVZ4T3FGelZLZGd0SkdLRlVtL2c3K20xQS9U?= =?utf-8?B?bmo5eUtYSjl2eDF6TXdxZmFzVXIyNG13OTRIbUZCa2JOaUxIUFNjMzE5VzVY?= =?utf-8?B?djRFbWJiSVFWQ3FnVlcvN3B6ZmxQaHpBSEU5bW5aaWRpTmhENVE2aE1lb3lI?= =?utf-8?B?UFNVc0Q1RFdVUEtlU0JJNUlYN1RxRmVVZ2REL0JWTzRFTEFIS2NLQUJsK1Rm?= =?utf-8?B?c1lSL0VvakdiVktGdmc5cjZtbHo0Q01UdnBERVhDc3g1Rm42WjgrYUZhbzZ2?= =?utf-8?B?VWxQQStRRXVxcm1YWXJDT1ZoRWU4emZHUmY1QW1ndnNqbUw1LzkyZ2NBbXVZ?= =?utf-8?B?YUlyYUxtRkx3NElmQmx6b1pNSWRwYjF5MzhpVURIZFpidnBQdFc1TDh3WGVz?= =?utf-8?B?UFZHTVdkdXdYRUZ5NllKRmw5Uysxd1lvMEJWUUo5WU5sU0xJazVud2VjZitJ?= =?utf-8?B?VTRwNWVIcGtRakdUNmgzcEgvMTZraW1CdkxOM2I5RUdTVWhlKytVbHl6aW9z?= =?utf-8?B?OE5PNUM3dVV6RGFrSUJ3bDRoTjl6U2pLSUd4aC9TUFY4MkhlVy9rZndDMUZx?= =?utf-8?B?cjJkSUZlTHRDQ28rUHFaSTVETnBpVDRvSS9jK2tmT0FNdDUycjV0VVVhcVAv?= =?utf-8?B?K0NMbkdsZFh3QS9TTGJmRkFuejBQbjNBT2gvZjB0L3Y2NCtiR2JYV3Jselh6?= =?utf-8?Q?RQRYbT8W5xtZBwFIZOl?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 5:lwtRu5zwlxhUfxpx78NEjH2pgW3gm5jTk5t1J8Kfy7uqs4OUeXVU8xlCSzpcWX7WWurLfZTyAHKhXiEcxbneajHmO1WMc9Cs1l8xdRFh+ov7c7v9Lpgo+4j7HFMpfbmFCDGF8QwDYhzqVm0yFnm8vw==; 24:ayS9EZP6kbvITXqCknbnpY9JGITCH8nWRkAWfXP2UC56lzwtNIXXlzVtB0gvC/OZwl2KXjWbTqg1GosOKTxnN/q9i7BAGCfJxcNx85UEgcI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2016 09:44:37.1553 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 09:44:49 -0000 ----- Original Message ----- From: "Eliot Lear" Sent: Thursday, February 11, 2016 7:36 PM Hi Alan, I'm not unsympathetic to the idea that we should focus efforts where possible, and I'm also not interested in piling on. But I think a comment is in order regarding RFC 3127 and then I have a proposal for a way forward. On 2/11/16 4:25 PM, Alan DeKok wrote: > > - even if there were no procedural issues, the document violates IETF consensus as described in RFC 3127 One has to put into perspective what was going on back then. Many different approaches were proposed to cover not only AAA but policy in general, and the market was at risk of fragmentation. There was a pretty visible and dare I say heated process at the IETF that turned into an attempt to align those who wanted to pursue policy with COPS and COPS-PR and those who wanted to do something with RADIUS/Diameter. RFC 3127 and its predecessor RFC 2989 represented hard work in the context of the efforts going on at the IETF at the time. It was a tool upon which the ADs relied to organize the work of O&M *at the time*. However, in the 15 interceding years, what's become clear is that RADIUS has broad applicability for a great many AAA uses; and for some cases TACACS+ is appropriate. For these purposes, such as command authorization, TACACS+ is a defacto standard, no matter what the IETF process says. The nascence of this space is long past. RFC 3127 was never intended to be a constraint so far into the future but rather a guide to ADs at the time as to how to proceed. The choice here, it seems to me, is really one of change control. I agree with you, Tom, and others who write that the IETF doesn't just rubber stamp protocols. On the other hand, changes should be made with due care toward what is deployed. I personally have faith that our processes and good community involvement would provide for a good path forward on this. In summary, if people want a standard, I propose the following way forward: 1. An applicability statement for TACACS+ that describes when TACACS+ is appropriate for use; 2. The proper following of working group process; 3. Appropriate and timely IPR declarations; and 4. It should be clear that the IETF has the necessary rights to effect changes. Thoughts/Comments? Eliot Looking at the Informational RFC in the RFC-index, I see Cisco Architecture for Lawful Intercept in IP Networks Cisco Systems NetFlow Services Export Version 9 Cisco's Mobile IPv4 Host Configuration Extensions Cisco Systems UniDirectional Link Detection (UDLD) Protocol Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material [mmm RADIUS!] etc etc so the question in my mind, is why not do the same now (especially as I understand that the work was started along these lines in 1997)? Mikael says "and if you wanted to provide IP core equipment, that's what you had to support" suggesting that a de facto standard exists and provides interoperability without any involvement of the IETF so again, an Informational RFC from a vendor would seem more than adequate. Why does anyone want Standards Track? I am suspicious until I have a plausible answer to that (IPR being only one area of suspicion and even a plausible answer may not allay my suspicions). Tom Petch Eliot ------------------------------------------------------------------------ -------- From nobody Fri Feb 12 02:19:16 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9A81B42DA for ; Fri, 12 Feb 2016 02:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 HJO0-S8ioUfm for ; Fri, 12 Feb 2016 02:19:14 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FE81B42D8 for ; Fri, 12 Feb 2016 02:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2623; q=dns/txt; s=iport; t=1455272354; x=1456481954; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=q1+cce95nBpshWUzip+qW6Q4jDrHMLKHBawJj7vdndc=; b=adw0A2Rr3VYhKdR53KTfcdtLS8POswyYo3uvVrEROROLrM//6qyqF+1h KMwQqKz9o/a8krIVHyJcJvlMxDwUmJGqZhkvKrz0Ms8w1GKFOBDWz8/kT 505YiD8slQ5tZGSEflck7UfdeqMWlJwy7HCSByn1P5jPqAlr3UH5cMLML o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgC0sL1W/xbLJq1djVSvH4ITDoFnh?= =?us-ascii?q?g0CgXAUAQEBAQEBAYEKhEIBAQQjVhALEgYJIQICDwI4DgYBDAgBAReHf7IRjxU?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDwiKR4cygToFlneDAoFkiG+JJIVSjj4eAUOCA?= =?us-ascii?q?hmBSjuITQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,435,1449532800"; d="asc'?scan'208";a="649265780" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 10:19:10 +0000 Received: from [10.61.94.97] (ams3-vpn-dhcp7778.cisco.com [10.61.94.97]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1CAJA3T030414; Fri, 12 Feb 2016 10:19:10 GMT To: "t.petch" , Alan DeKok , Mikael Abrahamsson References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <00cc01d16579$85bc1880$4001a8c0@gateway.2wire.net> From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <56BDB19D.807@cisco.com> Date: Fri, 12 Feb 2016 11:19:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <00cc01d16579$85bc1880$4001a8c0@gateway.2wire.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SEGCRI08vSRonEnL9JMekfeQuqalNnk6i" Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 10:19:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SEGCRI08vSRonEnL9JMekfeQuqalNnk6i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tom, On 2/12/16 10:41 AM, t.petch wrote: > Looking at the Informational RFC in the RFC-index, I see > > Cisco Architecture for Lawful Intercept in IP Networks > Cisco Systems NetFlow Services Export Version 9 > Cisco's Mobile IPv4 Host Configuration Extensions > Cisco Systems UniDirectional Link Detection (UDLD) Protocol > Cisco Systems' Private VLANs: Scalable Security in a Multi-Client > Environment > Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs > Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying > Material > [mmm RADIUS!] > etc etc > > so the question in my mind, is why not do the same now (especially as I= > understand that the work was started along these lines in 1997)? Actually the work started long before THAT, even. I think it dates to 1993 if memory serves. Again, in my mind this is a matter of whether or not the IETF wants change control, and I suspect that matters more to the operators than to anyone at Cisco. I am given to understand that occasionally some operators get touchy about something not being a standa= rd. But speaking plainly, this isn't a science experiment. It isn't something anyone is floating as a suggestion. It's what's being done in the network today, and it is supported across multiple implementations.=20 It is a defacto standard. Unless there's very good reason not to do so[*], let's just call it what it is. And again, I would reiterate: let's also make clear what it's not. A good applicability statement should help with that. Eliot [*] A very good reason would be if it doesn't meet the requirements for specifications that the IETF generally laid out. --SEGCRI08vSRonEnL9JMekfeQuqalNnk6i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWvbGeAAoJEIe2a0bZ0nozaMsIAMOHn1GIaQXuaBwathhCLYLF 0c4HGl+k818narDhd53SfNliVVkMvhu1O5o0KheN5dKJJBTNZJDojG97lx4tjIG6 RPBcHwh7F62kkn4Q+O+C1KgrsVj6xopybOsjDfXMORQMwhKyqOzccCYUfjJee5IC 7qSKgIUslrR3zrVrVm9IFhCCbWDNADsz/Vm3NuXML3exIrRRQMubM9xPEv9DVSE+ SjPNMiUrTcNqnnkA9UJkf7kK0xA3gUaUQsCf4Rfuj+rn9arsZj87BO6FLq//A1/y FxO+ptGJgp2mpsrWapn1mUNYdYuxzO+Sri7MOPghEID1E5TzUONw30bxehIWgkY= =4OGK -----END PGP SIGNATURE----- --SEGCRI08vSRonEnL9JMekfeQuqalNnk6i-- From nobody Fri Feb 12 03:29:50 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0DD1B43C8; Fri, 12 Feb 2016 03:29:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160212112946.17985.5377.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 03:29:46 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 11:29:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group of the IETF. Title : HMAC-SHA-2 Authentication Protocols in USM for SNMPv3 Authors : Johannes Merkle Manfred Lochter Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04.txt Pages : 13 Date : 2016-02-12 Abstract: This document specifies several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp-new/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 12 04:23:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A023A1B4497 for ; Fri, 12 Feb 2016 04:23:46 -0800 (PST) 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] autolearn=ham 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 ztIyQ4SAJCjT for ; Fri, 12 Feb 2016 04:23:44 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6504E1B4493 for ; Fri, 12 Feb 2016 04:23:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id BFB0FCAC; Fri, 12 Feb 2016 12:23:43 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG0US6ei7O2p; Fri, 12 Feb 2016 12:23:43 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 07D5C439; Fri, 12 Feb 2016 12:23:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BDB19D.807@cisco.com> Date: Fri, 12 Feb 2016 07:23:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <00cc01d16579$85bc1880$4001a8c0@gateway.2wire.net> <56BDB19D.807@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 12:23:46 -0000 On Feb 12, 2016, at 5:19 AM, Eliot Lear wrote: > Actually the work started long before THAT, even. I think it dates to > 1993 if memory serves.=20 Pretty much. RFC 2989 and RFC 3127 are the outcomes (~y2000), not the = start of the process. > But speaking plainly, this isn't a science experiment. It isn't > something anyone is floating as a suggestion. It's what's being done = in > the network today, and it is supported across multiple = implementations.=20 > It is a defacto standard. Like IPX, or any number of other non-IETF protocols. That doesn't mean they deserve RFC status, much less a standards track = document. > Unless there's very good reason not to do > so[*], let's just call it what it is. And again, I would reiterate: > let's also make clear what it's not. A good applicability statement > should help with that. >=20 > Eliot > [*] A very good reason would be if it doesn't meet the requirements = for > specifications that the IETF generally laid out. The discussion here has been that TACACS+ is a AAA protocol. If I = believe that, I also have to believe that it's such a terrible AAA = protocol, that it wasn't even considered in the discussion in RFC 3127. i.e. at the time the original draft was published, the major = networking companies (including Cisco via their employees) and the ITEF = consensus was that TACACS+ was not suitable for consideration as an AAA = protocol. We're welcome to re-visit that decision. Priorities change, and we = learn new things. But the cognitive dissonance here is mind-boggling. People say that = TACACS+ is a AAA protocol, but the requirements on AAA protocols don't = apply, because it's not a AAA protocol. It's a device management = protocol. Even though the document doesn't describe device management, = or even contain the terms "device management" or "device = administration". By that logic, war is peace, freedom is slavery, ignorance is = strength. I've asked repeatedly why the document should be granted standards = track status. The argument is largely "it's widely used". Well, so = what? Many other protocols are *more* widely used, and aren't standards = track. Again, while there are many widely used protools as information, or = not even RFCs, while there are inconsistent arguments in favour of the = protocol, while a self-described AAA protocol goes against IETF = consensus, while a self-described AAA protocol is so inadequate that it = wasn't even considered in RFC 3127, while there were procedural issues = making it a WG document... Why, exactly, are is the WG full-steam ahead in making it a standards = track document? It looks like the IETF ideal of "individuals" is failing here. There = are large forces behind the scenes pushing for standardization, and that = is winning over petty things like individuals without deep pockets, and = IETF process. Alan DeKok. From nobody Fri Feb 12 04:29:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B305C1B44B3 for ; Fri, 12 Feb 2016 04:29:13 -0800 (PST) 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] autolearn=ham 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 f0v_757po_QF for ; Fri, 12 Feb 2016 04:29:12 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 16F0F1B44B6 for ; Fri, 12 Feb 2016 04:29:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 5F3C1CD2; Fri, 12 Feb 2016 12:29:11 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UEVyMMPZz20; Fri, 12 Feb 2016 12:29:11 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id DA4958E5; Fri, 12 Feb 2016 12:29:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Fri, 12 Feb 2016 07:29:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 12:29:13 -0000 On Feb 12, 2016, at 1:01 AM, Mikael Abrahamsson = wrote: >=20 > It is not vendor specific. In the past 15 years I have used TAC+ on = Cisco, Juniper, Huawei and others. That's what we used, and if you = wanted to provide IP core equipment, that's what you had to support. I understand. But let's be realistic here. TACACS+ started out as a = vendor-specific protocol. Undocumented. Proprietary. Everyone else = implemented it in order to be compatible with the major vendor at the = time. Like IPX. Like any number of Microsoft proprietary protocols, for = example. And for those protocols, everyone agrees they're really = vendor-specific, even though we have multiple implementations. Why do you have a different standard for TACACS+? > Basically, if you're sending packets through an IP core network today, = those devices are likely to do AAA using TAC+. Apart from that, these IP = core routers use mechanisms that are "all" documented in an IETF RFC. So it *is* a AAA protocol? Good. The requirements of RFC 2989 should apply. And the conclusions = of RFC 3127 should apply. TACACS+ was such a poor AAA protocol that it = wasn't even considered in RFC 3127. Since the protocol hasn't changed = since then, there are no *technical* reasons why we should re-visit the = consensus shown in RFC 3127. > I just don't understand your objection to also documenting the AAA = protocol that is in super widespread use in the industry. I've been explaining in detail. > To me, it's like you would be saying that IS-IS shouldn't be in the = IETF because it was originally an ISO protocol. It's equally absurd. To me, it's like you're not even reading my counter-arguments. It's easy to dismiss someone's views when you don't pay attention to = them. Alan DeKok. From nobody Fri Feb 12 05:26:08 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5666B1A00A8 for ; Fri, 12 Feb 2016 05:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 hF8xxAd-PH4q for ; Fri, 12 Feb 2016 05:26:04 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1D91A00AC for ; Fri, 12 Feb 2016 05:26:04 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D3C5943AF3; Fri, 12 Feb 2016 14:26:02 +0100 (CET) To: Alan DeKok , Robert Drake References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> <56BCE503.7000107@direcpath.com> <484DE7E8-363F-45EE-B521-78E53E0582C1@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N0111 Message-ID: <56BDDD6A.8040902@restena.lu> Date: Fri, 12 Feb 2016 14:26:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <484DE7E8-363F-45EE-B521-78E53E0582C1@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UEkILTWFAs53DdRpK0S4048b4BmWaq28C" Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 13:26:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UEkILTWFAs53DdRpK0S4048b4BmWaq28C Content-Type: multipart/mixed; boundary="------------010208070009020903000302" This is a multi-part message in MIME format. --------------010208070009020903000302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, >> Is the RADIUS WG going to add support for command authorization? It s= eems like if RADIUS wanted this then one vendor refusing to submit a stan= dard wouldn't be a barrier. Surely anyone could write a standard and pro= pose it as a draft? >=20 > It would be well within the scope of RADEXT. The RADEXT WG would (I'= m guessing) be OK with standardizing it. chair-hat on: RADEXT's charter states "The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol pending approval of the new work from the Area Director" So feature additions are indeed well inside the current charter scope. > But while anyone can write a standard, any standard is pointless unle= ss it's implemented. And the vendors have refused to standardize command= authorization in RADIUS. >=20 > Because they saw it as a competitive advantage to bypass the IETF. chair-hat off for the rest of this mail: That's true. Cisco even has devised a mapping between RADIUS attributes and authorization commands usually transported over TACACS+. The RADIUS VSA "cisco-av-pair" basically takes TACACS+ syntax inside. As a random example, quickly googled: http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_serv= er_for_windows/4.0/user/guide/ad.html Quoting the section "About the cisco-av-pair RADIUS attribute": "[...]cisco-av-pair, supports the inclusion of many AV pairs by using the following format: attribute sep value where attribute and value are an AV pair supported by the releases of IOS implemented on your AAA clients, and sep is =3D for mandatory attributes and asterisk (*) for optional attributes. You can then use the full set of Terminal Access Controller Access Control System (TACACS+) authorization features for RADIUS." Many of the commands that TACACS+ can understand in Cisco devices have direct RADIUS VSA counterpart. The syntax also /allows/ for per-command authorization in that same VSA. That last sentence in the doc above even wants to imply that per-command authorization is possible. The catch is that one can even send the converted per-command-authz syntax inside the VSA, and a Cisco device nicely ignores it. It process other attributes from the same group in the same way (I tried that, admittedly nearly a decade ago meanwhile), so this is quite clearly visible *bad will* and not a technology gap. For some reason, some people see this and conclude "TACACS+ is better, because I can send per-command-authorization". While a much more natural conclusion would be to complain about the obvious bug or bad-will limitation in the product. Consequently, I can even halfways understand that the same people want TACACS+ standardised; while others who are not in that IMHO flawed line of thinking want it to go away and never come back. I myself need to have one stepchild instance of TACACS+ server running in our network because we need to have per-command authorisation at a few places. The product that runs TACACS+ is called "Radiator", which is actually a RADIUS server that runs TACACS+ in a niche of its memory because it can; while doing so much more with RADIUS. That is quite telling IMHO. This story goes to show that those who have to deal with TACACS+ or the lack of per-command-authorization in RADIUS in their real deployment life have a story to tell, and feel strongly about the issue, and maybe even loathe TACACS+ for its anti-competitiveness in that respect; while others love it for allowing them to do something they otherwise can't. This would explain the heatedness of the debate. > Now that they have problems with inter-operability, they're looking fo= r IETF approval. >=20 > Again, why is there a need to have the document as standards track? = RADIUS accounting (RFC 2866) is Informational, for crying out loud. Are = we really saying that RADIUS / RADEXT WG with an active history going bac= k to 1996 is *not* going to have a standards track protocol, but TACACS+ = gets one, because "it's popular"? >=20 > That's an amazing interpretation of the IETF consensus, and IETF proc= ess. Maybe I'm naive, but it looks a while lot to me like one WG has to = follow the rules to get a protocol standardized, and another WG doesn't. My personal opinion is that documenting the protocol is probably good because it is so widespread (-> Informational). But it's also so low priority that I wouldn't care much if it weren't documented at all (->/dev/null). Rather than seeing a standards-track document I'd rather see Cisco living up to their promise of "the full set of Terminal Access Controller Access Control System (TACACS+) authorization features for RADIUS" in actual deployed code; it would immediately make the necessity for TACACS+ go away; at which point nobody would care about documenting this then-obsolete piece of network technology any more. About process, at least in RADEXT we always ask for document adoption, and we have a good debating culture at this early stage; so passing the WG adoption threshold means something. I'm a bit shocked to learn that this is apparently different in osawg. Greetings, Stefan Winter >=20 > Alan DeKok. >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------010208070009020903000302 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------010208070009020903000302-- --UEkILTWFAs53DdRpK0S4048b4BmWaq28C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWvd1qAAoJEMDeajWKOdxmvFMQAKMlAHdemUD8cj8JyxHZQrjH PyJJ+Jafgi+cldMzHSnNE1qdn7DIIWlmKdta7pY/fven/QoAsZS66uZvoduy64b+ JQIhuv2FMBmMOX2vGALsnRvth1esUQe9p4BRD9K6GDw1dgjDmba3fBKZvIB72b2I 4HYmVmVMz+JkOyDGjvBGWbh6yJekL5SDwJzqBqNBNnSRm3ZqVZv9C2Hy/N8eZ55R 3FHo4Pux4MmEtuVcnlwJ9u770I1rI/nuPLQ6kO4+Zv2wc4f1AtNzDVYurqXVzFHE bskBwP8GdQiVbzYDhg9M+D/Ig4gb9cKvnMCOuif3N19kpo718fgBCnOXXSAt4tmR ivJL03c/l/JCQY6k4EFEyvlwSvczJ2sw0lQ6mCHIsgVPzFoAJSdmVu3AnIqH6a8M kbuQGy6MN5QpKrcV2ieaKRsnUY+GL1CybTam2UR8DePhwjHWXgVMLfZ7mZcyymJ/ LR8ed0OCFQ6EuFs7xHz0dUKb0Kzeimfhd4uPx4GlC2YkXaf23Hd2Wd+uz2B5PO5E XF6BLdlSpkV9QQMALz1BKLRy5RhObtud8BwlB46AAEj0s5EKq850hjoBH3JY6Rqs u/vlRX9YXYO6LEsD86aaedG+XBgONkxy5bvec12JSJsP7ceVBzVZcvpg8TXyFHJW VFmkC4MCbGXy1x8unPZ/ =qCjg -----END PGP SIGNATURE----- --UEkILTWFAs53DdRpK0S4048b4BmWaq28C-- From nobody Fri Feb 12 05:32:55 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1A1A00B1 for ; Fri, 12 Feb 2016 05:32:53 -0800 (PST) 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] autolearn=ham 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 ugSrLU__p8Tk for ; Fri, 12 Feb 2016 05:32:51 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id B2E201A00C6 for ; Fri, 12 Feb 2016 05:32:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 03790D98; Fri, 12 Feb 2016 13:32:51 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE_RYk4lJ9jt; Fri, 12 Feb 2016 13:32:50 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 81826488; Fri, 12 Feb 2016 13:32:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BD1113.2010106@gmail.com> Date: Fri, 12 Feb 2016 08:32:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> <56BCE1A7.6050807@gmail.com> <9B53AFCE-8792-4CB4-AC47-A2F0D986D759@deployingradius.com> <56BD1113.2010106@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 13:32:53 -0000 On Feb 11, 2016, at 5:54 PM, Brian E Carpenter = wrote: > Charter updates are formal step, but the OPSAWG charter is already = written > to encompass work of this kind. Except that the charter says new work will require IESG approval. > As I hinted before, it's unfortunate that > the WG milestones haven't been updated recently, but that's true of = many WGs. That's a non sequitur. I never discussed milestones. > We are collectively sloppy on that. Speaking for myself, I don't work for a large company. I don't have a = CEO who can apply "behind the scenes" pressure to get things pushed = ahead. My main involvement is in a small WG that most people don't care = about. As such, my main protection and guidance is the documented IETF = process. If we ignore that process, then we're letting large companies = do what they want, simply because they're large companies. > TACACS+ is used by IP operators, so it seems relevant in a way that = IPX isn't. > But if you want to propose an IPX BOF in the Internet Area, or request = a slot > in a future INTAREA WG meeting for IPX, you're obviously free to do = so. Which pretty much misses the point of my argument. There are many protocols used on the wider internet which have many = more deployments across more vendors than TACACS+. Those protocols are = not documented in RFCs. So... why this one? The only answer so far is that "it's supported by large companies". Alan DeKok. From nobody Fri Feb 12 05:51:58 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8410C1A00F5 for ; Fri, 12 Feb 2016 05:51:57 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 93VfcWwO-K10 for ; Fri, 12 Feb 2016 05:51:56 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7481A010C for ; Fri, 12 Feb 2016 05:51:55 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id E5BCE43AEC; Fri, 12 Feb 2016 14:51:53 +0100 (CET) To: Christopher Morrow , Alan DeKok References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <56BDE379.9020407@restena.lu> Date: Fri, 12 Feb 2016 14:51:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L0Os1jWF6cWjgXtHUdX13GsgDN7aGLu8c" Archived-At: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 13:51:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L0Os1jWF6cWjgXtHUdX13GsgDN7aGLu8c Content-Type: multipart/mixed; boundary="------------020001060103070302010300" This is a multi-part message in MIME format. --------------020001060103070302010300 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > RadExt Charter text is less clear except that their milestones are > explicit and focused on the 'network access' problem, not the 'network > managment' or 'network operations' or 'network adminsitration' > problem(s). The sentence "The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol pending approval of the new work from the Area Director" is quite clear, IMHO: new features so long as the AD allows us to. We can work on standardisation of the previous "cisco-av-pair" when there are volunteers to do it, and if our (OPS area) ADs allow us to do i= t. There is not even a charter update needed. > So, I think calling out to these is also out of scope. It's not. Greetings, --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------020001060103070302010300 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020001060103070302010300-- --L0Os1jWF6cWjgXtHUdX13GsgDN7aGLu8c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWveN5AAoJEMDeajWKOdxmwiUQAM4dhsaCzDE2lyG7kSPXxJJo 5i9kBAHu3CpCN+BcbFHQGSiAk70lIPuGVyCiAlTL9/7KWsx1IR+tY60P7N7GLpiU D6BQv7tyae56HPrqB+QD5Ld+41SoUPd8ruSdUYqJFl5jgEOB7rLDPijgGq2UrmgC IU4PVaYMlSJ0my1dzy4fWjuJC5KP6cEQGQkJ8cqL73o/FS8L+VD7zgFPi1HjkD9a 3SbDsrSyzgoh4ohFw+SbnsFmx1KyerwZm7SEpxi+XbSwGThApzPZxRD0KF78nzrm 0vSIQWcySjEW3kDPlDQh1aJEc3MtA3YPgPxJ8IcnH/csesAd0V9VaLZE/bVpM11W A1NSu8A7gnYYYY7tkcJTm7drqR4MLxvyP/o/D8UM0h98pls9YEdYyR+gwM9nES6p vrjDAZqBJQ8HoJKvSS6sFzDVyD0FpR3IvDvOMkb8xuXEiKHLGSDYSKOHEsYSo99S qKb7BAJ4YAU56+8q0epxR3y1pKcJa9CTaFMD5vVS646VsMZ2vmm2ZUFCeznzWTrO RPY6+eqUL0T0QsIf2vy+G85050JO/BZs8amcFnUu2fE9HquPUJpl69kAGIEatOXu hmiHqF0mv7GTC4SG0aeSep0Tkb+98NJHeRxP8KdolwLgRqhh8kNdZJHOfe+fTaLY SQxestOaAy2JaRXRhFhc =6eH1 -----END PGP SIGNATURE----- --L0Os1jWF6cWjgXtHUdX13GsgDN7aGLu8c-- From nobody Fri Feb 12 05:58:46 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767661A014F for ; Fri, 12 Feb 2016 05:58:44 -0800 (PST) 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] autolearn=ham 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 DZ4nkZlGbIqJ for ; Fri, 12 Feb 2016 05:58:42 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4B61A0143 for ; Fri, 12 Feb 2016 05:58:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E5882D98; Fri, 12 Feb 2016 13:58:41 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHtnOXHEUC4g; Fri, 12 Feb 2016 13:58:41 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id E7B668E5; Fri, 12 Feb 2016 13:58:40 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BDE379.9020407@restena.lu> Date: Fri, 12 Feb 2016 08:58:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BDE379.9020407@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Douglas Gash \(dcmgash\)" , Andrej Ota , "opsawg@ietf.org" , Thorsten Dahm Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 13:58:44 -0000 On Feb 12, 2016, at 8:51 AM, Stefan Winter = wrote: >=20 >> RadExt Charter text is less clear except that their milestones are >> explicit and focused on the 'network access' problem, not the = 'network >> managment' or 'network operations' or 'network adminsitration' >> problem(s). >=20 > The sentence "The RADIUS Extensions Working Group will focus on > extensions to the RADIUS protocol pending approval of the new work = from > the Area Director" >=20 > is quite clear, IMHO: new features so long as the AD allows us to. In addition, RADIUS has been used for network administration since = it's origins. RFC 2058 makes it clear that it is *explicitly* intended = to authenticate, authorize, and do accounting for administrators logging = into network equipment: https://tools.ietf.org/html/rfc2058#section-5.6 =20 Has Service-Type of: Administrative The user should be granted access to the administrative interface to the NAS = from which privileged commands can be executed. Any counter-argument that RADIUS isn't intended for "network = operations" or "network administration" is false, and has been = documented publicly as being false for two decades. The "command authorization" is *explicitly* in scope for RADIUS, and = has *always* been in scope for RADIUS. As Stefan says, it's only due to = one vendors anti-competitive behaviour that we're even having this = discussion. Alan DeKok. From nobody Fri Feb 12 06:08:00 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE951A0178 for ; Fri, 12 Feb 2016 06:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 9viTJF4ptPly for ; Fri, 12 Feb 2016 06:07:58 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178571A0137 for ; Fri, 12 Feb 2016 06:07:58 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 693DBA2; Fri, 12 Feb 2016 15:07:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1455286075; bh=5H5NtZmxtXWNJE/yyqzOB8/Dds7wjUYK/EY0Xz2T4zI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=4vh5iK2fS0Cn25LsNZ4JtXDeTEC/Hijvj/jwYh876RQhHnF5PJ5GHTQ2GNk8Tf0Mt k9HMBbvpnx9pET/KlzZRxaQct98ByEtcpp6eEKg24AjT89JQKQHOXQa8eH0PE8fs// r7Mn59h0XuiknwQ5RdW4XWWFgdLhSi886odwarLw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5E495A1; Fri, 12 Feb 2016 15:07:55 +0100 (CET) Date: Fri, 12 Feb 2016 15:07:55 +0100 (CET) From: Mikael Abrahamsson To: Alan DeKok In-Reply-To: <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> Message-ID: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:07:59 -0000 On Fri, 12 Feb 2016, Alan DeKok wrote: > So it *is* a AAA protocol? I actually do not know what criteria you put in the AAA term. It might be different from what I use it for. For me TACACS does the following things: It checks username/password when I login, and the TAC+ server says if I can login or not with those credentials. It sends CLI commands I run on the router to the TAC+ server, and the TAC+ server grants or doesn't grant me to run those individual commands, on a per-command basis. It also records what commands I ran. That's what I thought the "Authentication, Authorization, Accounting" meant. As far as I have understood, Radius/Diameter doesn't do the last function(s) I described. Why is that? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 12 06:12:21 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503FF1A0180 for ; Fri, 12 Feb 2016 06:12:19 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 yUZvI-BzDHEO for ; Fri, 12 Feb 2016 06:12:17 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBAB1A017A for ; Fri, 12 Feb 2016 06:12:17 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2CCF343AF3 for ; Fri, 12 Feb 2016 15:12:16 +0100 (CET) To: opsawg@ietf.org From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <56BDE83F.1030102@restena.lu> Date: Fri, 12 Feb 2016 15:12:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ctdo2iHn9WVC3cTWLEBX7bXM56UF4qIKX" Archived-At: Subject: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:12:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ctdo2iHn9WVC3cTWLEBX7bXM56UF4qIKX Content-Type: multipart/mixed; boundary="------------020103090302030400030907" This is a multi-part message in MIME format. --------------020103090302030400030907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, this debate has been going on for quite a while. It's multi-faceted, which doesn't help coming to conclusions. Maybe we can un-entangle one point: there are suggestions to either make this Standards Track or Informational; and one wheteher the protocol should be documented vs. improved. Maybe there should be two (or more) drafts instead: 1) The TACACS+ Protocol as Deployed in 2016 (Informational, *no changes*) 2-n) The New Feature X for TACACS+ (possibly Standards Track, one document per bolt-on feature) (one of the Xes being TLS encryption, but I'm sure there are more) Those voices on the list who demanded documentation can then happily accept Informational; the documentation is done either way. Those who opposed Standards Track for the durrent draft because it's about a protocol coming in from outside IETF can now go silent, because Informational addresses their concern. Those who demand new features can then put all their energy into a proper, per-feature argument with all those arguments collated in a per-topic document. Those who opposed the current draft for Standards Track can continue to oppose those new documents; this time in a focused discussion with less broadsides fired. If you can follow my line of thinking to this point, let's take it even one step further: we are now discussing a larger effort, involving multiple RFCs, taking an existing technology to a level it wasn't before. This is usually much rather a job for a working group in its own right, with a charter detailing which work happens when; not a job for a one-shot effort in the opsawg. So my ultimate suggestion would be: have a BoF at IETF95, try to form a working group, work on all issues that were brought up individually. (FWIW, this is exactly how RADIUS came to be... from an undocumented proprietary protcol to a successful IETF one. And guess what, even we had lengthy discussions about TLS encryption; debating is simply part of the culture) Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------020103090302030400030907 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020103090302030400030907-- --ctdo2iHn9WVC3cTWLEBX7bXM56UF4qIKX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWvehAAAoJEMDeajWKOdxmeCUP/RiX5mn+WD/pllfRhbMr1fw5 usy1YB3EkFvOSiz7iWok4H5HqRIqUxViHMqUakrmdpw08PEO36lPfXxchhrRYdJC crMaO5B77xZYifTDK7EwAzsHNGfxurQIBWZvA3JtLYe3yEwTSJbOJoMnJsvbgqA8 v7+60Wv3IG4NpRN5/18lAZyWeT7eJY+JVl7p6F5Gkzh6WxLg5ImHOlB3J98MTU7Y PnZAffpJ6K99suTWPpiaq+HIgVS67WWZp6Xz1wFI2SvVFjMmcOYBP78A94OgQYo7 p9J+0KrXqwtUu6iN+Lv7z2e5ax1/XJJYHwOO6ZCEhhT4whmGGRGwyp5cQUHZBiSo a6yec3K2OEvDrYoLZY7hRVWee8f1njMkrCKEvwyOaKTEbaGZoMynzzKsQNwHJNTS MXcv/xU4NYpMPha6mjcareyMvWUHZaOt5EGw7jxCgxdu3KVsj0+/7wbs6gzy6Div CHkqGo9g7S6KE0T6HfMdrYejJOd5lml/raLNiRa+7NG1l8ZmmOuNmh2LSD0Yt0d+ pyrhoSN6qUiqiICDE4eaJ+8oQ2/GrwVpoNEojEF/1I1Sskvs4fEAuyymJzoYpsi7 vMcGVISmF3fiGgtGPgYX0+7Pu56hv97jAWn4iL+Ng+4LxoqBD4cqNax667fDJ90B /ITy7VFctRs5DwZdaVpG =5Ttz -----END PGP SIGNATURE----- --ctdo2iHn9WVC3cTWLEBX7bXM56UF4qIKX-- From nobody Fri Feb 12 06:22:10 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D5E1A01D8 for ; Fri, 12 Feb 2016 06:22:08 -0800 (PST) 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] autolearn=ham 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 LvFUzjS-iFQV for ; Fri, 12 Feb 2016 06:22:07 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2101A01D7 for ; Fri, 12 Feb 2016 06:22:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id C9B5FD98; Fri, 12 Feb 2016 14:22:06 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPlI95b8CDeF; Fri, 12 Feb 2016 14:22:06 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 545DB488; Fri, 12 Feb 2016 14:22:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Fri, 12 Feb 2016 09:22:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:22:09 -0000 On Feb 12, 2016, at 9:07 AM, Mikael Abrahamsson = wrote: >=20 > On Fri, 12 Feb 2016, Alan DeKok wrote: >=20 >> So it *is* a AAA protocol? >=20 > I actually do not know what criteria you put in the AAA term. It might = be different from what I use it for. This is getting silly. The document describes itself as an AAA = protocol. I'm willing to accept that. But most times I mention it's an AAA protocol, the response is "NO! = the rules for AAA protocols don't apply! It's a device management = protocol!" I find such circular arguments unconvincing, and downright = anti-social. > For me TACACS does the following things: >=20 > It checks username/password when I login, and the TAC+ server says if = I can login or not with those credentials. > It sends CLI commands I run on the router to the TAC+ server, and the = TAC+ server grants or doesn't grant me to run those individual commands, = on a per-command basis. It also records what commands I ran. >=20 > That's what I thought the "Authentication, Authorization, Accounting" = meant. By that standard, SQL and LDAP are AAA protocols. They authenticate = administrators, authorize them to do some tasks and not others, and = perform accounting / logging on the commands run by those = administrator.s > As far as I have understood, Radius/Diameter doesn't do the last = function(s) I described. Why is that? Because your understanding is wrong? RADIUS does that. Not for every vendor, but it's explicitly designed = to do that. The *common* use-case for network management is that command = authorization is done via TACACS+. And why is that? Because of a anti-competitive behaviour by a major networking vendor. = Who saw it being as beneficial to *not* standardize command = authorization. Despite (was Stefan pointed out) their own documentation = which says it works in RADIUS, but which the switches completely ignore! Now that they're getting bitten by interoperability issues, they want = a rubber-stamp on the protocol as standards track. I've explained this repeatedly. I suggest reading my messages to see = what my argument is. That would help you to avoid asking questions = which have already been answered repeatedly. Speaking of repeated questions... I've asked this question repeatedly: Why is it necessary to have a standards track document? What's wrong = with informational? I've respected you by answering your questions and explaining my = position. Please consider doing the same for me. Alan DeKok. From nobody Fri Feb 12 06:31:03 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305B81A0266 for ; Fri, 12 Feb 2016 06:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HA0-P0fK1is3 for ; Fri, 12 Feb 2016 06:31:00 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2166D1A0264 for ; Fri, 12 Feb 2016 06:31:00 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 55D68A2; Fri, 12 Feb 2016 15:30:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1455287458; bh=64K2P2WTtKeR8cVmod1Q6s5qR3gJzj/wqF0icW2QenM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=M4MGWvyH3z/EdW4g3LoMWo7vVAX4Lpv5HKPiqFS+BbwTomel/iOzQ6XbpEurjE2aJ 0B/19IztHS/bsmCc+q/T4ibXYEqxXRUgSxYqLb7MmKgJSOCddETLtrxnE8+Ato19Wy HJM1Yq4SWnfyY6/8OjrndyRjIEFi0oaM1GCWTA78= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 518EFA1; Fri, 12 Feb 2016 15:30:58 +0100 (CET) Date: Fri, 12 Feb 2016 15:30:58 +0100 (CET) From: Mikael Abrahamsson To: Alan DeKok In-Reply-To: Message-ID: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:31:01 -0000 On Fri, 12 Feb 2016, Alan DeKok wrote: > Why is it necessary to have a standards track document? What's wrong with informational? > > I've respected you by answering your questions and explaining my position. Please consider doing the same for me. As far as I know, I have never insisted it needs to be a standards track document. I just re-read all my email I have sent on this issue, and I have consistently used the term "documented in an RFC". ... so you blame me for not reading your email, but it seems you're not reading mine, or putting words in my mouth I never uttered and asking me to argue for a position I have never taken. I don't care if the document is Informational or Standards track, but I still want the document. You have opposed the document to be created at all, and that's what I have been arguing against. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 12 06:40:36 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690EB1A038A for ; Fri, 12 Feb 2016 06:40:33 -0800 (PST) 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] autolearn=ham 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 qgta1gVotqxD for ; Fri, 12 Feb 2016 06:40:31 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 872811A0378 for ; Fri, 12 Feb 2016 06:40:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E90C0CF6; Fri, 12 Feb 2016 14:40:30 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RppZkw8sCbnW; Fri, 12 Feb 2016 14:40:30 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 7C915488; Fri, 12 Feb 2016 14:40:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Fri, 12 Feb 2016 09:40:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <020D24B6-7A14-48EE-BBA6-829276274A4E@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:40:33 -0000 On Feb 12, 2016, at 9:30 AM, Mikael Abrahamsson = wrote: > As far as I know, I have never insisted it needs to be a standards = track document. I just re-read all my email I have sent on this issue, = and I have consistently used the term "documented in an RFC". Forgive me, but you were opposing my position. > ... so you blame me for not reading your email, but it seems you're = not reading mine, or putting words in my mouth I never uttered and = asking me to argue for a position I have never taken. No. I never said you refused to answer the question. I had never = asked you the question directly before. > I don't care if the document is Informational or Standards track, but = I still want the document. You have opposed the document to be created = at all, and that's what I have been arguing against. And again, please read my messages. Including the one you just = replied to. I have *repeatedly* said that I'm OK with it being an informational = RFC. This whole conversation began with me requesting that the document = be an informational RFC. Just.. enough, already. Please. Alan DeKok. From nobody Fri Feb 12 07:01:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CA71A1A1C for ; Fri, 12 Feb 2016 07:01:02 -0800 (PST) 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] autolearn=ham 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 PwLA1rnn3oRo for ; Fri, 12 Feb 2016 07:01:01 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DDAC81A1A14 for ; Fri, 12 Feb 2016 07:01:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 4B628D9A; Fri, 12 Feb 2016 15:01:00 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCYm9JUn2Ult; Fri, 12 Feb 2016 15:01:00 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id D02AF488; Fri, 12 Feb 2016 15:00:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BDE83F.1030102@restena.lu> Date: Fri, 12 Feb 2016 10:00:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56BDE83F.1030102@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 15:01:02 -0000 On Feb 12, 2016, at 9:12 AM, Stefan Winter = wrote: > Maybe there should be two (or more) drafts instead: I support that. > If you can follow my line of thinking to this point, let's take it = even > one step further: we are now discussing a larger effort, involving > multiple RFCs, taking an existing technology to a level it wasn't > before. This is usually much rather a job for a working group in its = own > right, with a charter detailing which work happens when; not a job for = a > one-shot effort in the opsawg. I believe that a new WG would be required here. =46rom the OPSAWG charter:=20 https://datatracker.ietf.org/wg/opsawg/charter/ " It is not within the scope of the OPSAWG to pick up failed WG work = ..." =46rom the AAA WG milestones https://datatracker.ietf.org/wg/aaa/charter/ Done Submission of evaluation document as an Informational RFC. Done Submission of requirements document as an Informational RFC. i.e. RFC 2989 and RFC 3127. I would argue that TACACS+ (the AAA protocol) is a failed WG item. It = was deemed insufficient by the AAA WG in 2001. If the argument is that TACACS+ is *not* an AAA protocol, and is = instead a management protocol, then the document (#2 in Stefan's = suggestion) should be updated to state that. Further, development of = new IETF standard protocols would also seem to be outside of the charter = of the OPSAWG: The focus of the work will be on topics that govern the behavior or = WGs in the O&M area (e.g., manageability requirements) and on small,=20 highly focused projects that don't merit a WG of their own or belong=20= to WGs that have already concluded (e.g. advancement of documents on=20= the standards track, application statements, extensions of MIB=20 modules). TACACS+ *may* be considered a "small, highly focussed project", but it = definitely doesn't meet any of the other criteria. And I would argue that documenting a network administration protocol = (new to the IETF) is not a "small, highly focussed project". It's a = serious effort which requires more than a review by OPSAWG, which has = many other priorities. Alan DeKok. From nobody Fri Feb 12 07:46:21 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288D71A1BBD for ; Fri, 12 Feb 2016 07:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 njLTgEBIhoi0 for ; Fri, 12 Feb 2016 07:46:19 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9406F1A1BC3 for ; Fri, 12 Feb 2016 07:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7506; q=dns/txt; s=iport; t=1455291978; x=1456501578; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=mvb44cCCYQZUXz7S+jorf9OPVqEYztICYmiK2Wc8rd0=; b=Ooj+S01LHSVDM6xg/sDxu/5GG1r9Rc2plwRa6Yt4AJZstQOb2ktQ4Rq1 2JLuwADcO17YZHMl4inI42pmqmjKjQY+BZ5vFloON2xICwl626BuKY2CU A+9UZQq+AIuZ5UqFcUmRDFD49J9m/PgBnsiZnuydWk0xKW8fFYzeuavOc o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBABF/b1W/xbLJq1ehAxtiFuzJxcBC?= =?us-ascii?q?YUiSgKCAwEBAQEBAYELhEIBAQQBAQEgSwoRCxgJFgsCAgkDAgECARUwBgEMBgI?= =?us-ascii?q?BARGIBQ6yYI8OAQEBAQEBAQEBAQEBAQEBAQEBAQ8EBIpHhzKBOgWWd4MCgWSDV?= =?us-ascii?q?oUZiSSFUo4+YoNlOy6IKgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,436,1449532800"; d="asc'?scan'208,217";a="625410668" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 15:46:15 +0000 Received: from [10.61.241.182] ([10.61.241.182]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1CFkE6H031137; Fri, 12 Feb 2016 15:46:15 GMT To: Stefan Winter , opsawg@ietf.org References: <56BDE83F.1030102@restena.lu> From: Eliot Lear Message-ID: <56BDFE46.9000802@cisco.com> Date: Fri, 12 Feb 2016 16:46:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BDE83F.1030102@restena.lu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oi1nUduTo8XE0fDLtjmE5LplEregK4c4f" Archived-At: Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 15:46:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oi1nUduTo8XE0fDLtjmE5LplEregK4c4f Content-Type: multipart/alternative; boundary="------------080209070704060201060107" This is a multi-part message in MIME format. --------------080209070704060201060107 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stefan, Unless it is absolutely determined that the current work can't doesn't meet criteria for an IETF standard, I would be opposed to such an exercise. For one thing, we all have other things to do. For another, and as or more important, we would be denying the reality of the situation. I would rather understand now what sort of changes are being proposed in order for the current work to come up to snuff. Eliot On 2/12/16 3:12 PM, Stefan Winter wrote: > Hello, > > this debate has been going on for quite a while. It's multi-faceted, > which doesn't help coming to conclusions. > > Maybe we can un-entangle one point: there are suggestions to either mak= e > this Standards Track or Informational; and one wheteher the protocol > should be documented vs. improved. > > Maybe there should be two (or more) drafts instead: > > 1) The TACACS+ Protocol as Deployed in 2016 > (Informational, *no changes*) > > 2-n) The New Feature X for TACACS+ > (possibly Standards Track, one document per bolt-on feature) > > (one of the Xes being TLS encryption, but I'm sure there are more) > > Those voices on the list who demanded documentation can then happily > accept Informational; the documentation is done either way. Those who > opposed Standards Track for the durrent draft because it's about a > protocol coming in from outside IETF can now go silent, because > Informational addresses their concern. > > Those who demand new features can then put all their energy into a > proper, per-feature argument with all those arguments collated in a > per-topic document. Those who opposed the current draft for Standards > Track can continue to oppose those new documents; this time in a focuse= d > discussion with less broadsides fired. > > If you can follow my line of thinking to this point, let's take it even= > one step further: we are now discussing a larger effort, involving > multiple RFCs, taking an existing technology to a level it wasn't > before. This is usually much rather a job for a working group in its ow= n > right, with a charter detailing which work happens when; not a job for = a > one-shot effort in the opsawg. > > So my ultimate suggestion would be: have a BoF at IETF95, try to form a= > working group, work on all issues that were brought up individually. > > (FWIW, this is exactly how RADIUS came to be... from an undocumented > proprietary protcol to a successful IETF one. And guess what, even we > had lengthy discussions about TLS encryption; debating is simply part o= f > the culture) > > Greetings, > > Stefan Winter > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------080209070704060201060107 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stefan,

Unless it is absolutely determined that the current work can't doesn't meet criteria for an IETF standard, I would be opposed to such an exercise.=C2=A0 For one thing, we all have other things to do= =2E=C2=A0 For another, and as or more important, we would be denying the reality of the situation.=C2=A0 I would rather understand now what so= rt of changes are being proposed in order for the current work to come up to snuff.

Eliot



On 2/12/16 3:12 PM, Stefan Winter wrote:
Hello,

this debate has been going on for quite a while. It's multi-faceted,
which doesn't help coming to conclusions.

Maybe we can un-entangle one point: there are suggestions to either make
this Standards Track or Informational; and one wheteher the protocol
should be documented vs. improved.

Maybe there should be two (or more) drafts instead:

1) The TACACS+ Protocol as Deployed in 2016
   (Informational, *no changes*)

2-n) The New Feature X for TACACS+
   (possibly Standards Track, one document per bolt-on feature)

(one of the Xes being TLS encryption, but I'm sure there are more)

Those voices on the list who demanded documentation can then happily
accept Informational; the documentation is done either way. Those who
opposed Standards Track for the durrent draft because it's about a
protocol coming in from outside IETF can now go silent, because
Informational addresses their concern.

Those who demand new features can then put all their energy into a
proper, per-feature argument with all those arguments collated in a
per-topic document. Those who opposed the current draft for Standards
Track can continue to oppose those new documents; this time in a focused
discussion with less broadsides fired.

If you can follow my line of thinking to this point, let's take it even
one step further: we are now discussing a larger effort, involving
multiple RFCs, taking an existing technology to a level it wasn't
before. This is usually much rather a job for a working group in its own
right, with a charter detailing which work happens when; not a job for a
one-shot effort in the opsawg.

So my ultimate suggestion would be: have a BoF at IETF95, try to form a
working group, work on all issues that were brought up individually.

(FWIW, this is exactly how RADIUS came to be... from an undocumented
proprietary protcol to a successful IETF one. And guess what, even we
had lengthy discussions about TLS encryption; debating is simply part of
the culture)

Greetings,

Stefan Winter




_______________________________________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------080209070704060201060107-- --oi1nUduTo8XE0fDLtjmE5LplEregK4c4f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWvf5GAAoJEIe2a0bZ0nozCp4IALOXzgFCl3TsJ3Bo23GUE/E5 dvh1fPKNtFzvbqmvsSbmMgkVZ4CCu9x4xB0z8ey5jDlMNnYmG/aJ1eOAZm8HVe7a lumy+WZNPZxQPQ7BMuSHW0jeQRJ/EEMZzaqOz/dv5NyirJJnFhob1WI6W7+MsMH0 y6u9fYwlbkCLV6oWtRn8ND7bjZpvvbCafHV22+D1F22erX+bmcSFt/aSRaBj9+H1 Kx+mumFt+qIqvH4OTG5bf2ypaJ2j0Rl1tejkuztEnvyKbPQq0NGPTQ3Oxy8m2ewY G/Pb1KSua+4YmFVhf5kENmZ7RI5ZyhBJhAbm/rXND8K+K1P12HMfUkjLjqsP9rg= =AFzO -----END PGP SIGNATURE----- --oi1nUduTo8XE0fDLtjmE5LplEregK4c4f-- From nobody Fri Feb 12 08:22:52 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1328D1A6EFC for ; Fri, 12 Feb 2016 08:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 MEVotguFEwRH for ; Fri, 12 Feb 2016 08:22:48 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0757.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::757]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDD21A6EE8 for ; Fri, 12 Feb 2016 08:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=peJV3W6phmkK6Y1Q9Sk4AGpcjaJ6fwxPkiGeVzbNm3g=; b=CK/YIUiwLiyqyMk+Zg1w5fHz09N50QoWVNcaIKJBHiEztT2QJDe6/qhQ1Tl1iQYuiw+L5xH7zxDwtngTObEtOsJWM4vgiP3EmJAKekt5KJ0AO3HEli6opCZ4vjDFZIEBQZsi7iLd+W5x6bFUY8vUmR/5g4hLHv+dQtH+IkHckJo= Authentication-Results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.409.10; Fri, 12 Feb 2016 16:22:27 +0000 Message-ID: <017301d165b1$197882c0$4001a8c0@gateway.2wire.net> From: t.petch To: Alan DeKok , Eliot Lear References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <00cc01d16579$85bc1880$4001a8c0@gateway.2wire.net> <56BDB19D.807@cisco.com> Date: Fri, 12 Feb 2016 16:18:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: AM3PR04CA0122.eurprd04.prod.outlook.com (25.163.180.176) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 2:TQ+k8/o8QlR02GB1arl9etUtUK5Mm3jIO6O7Ubq5NGdFIJ5Y8x4bg7ode9YjI7DgSoM6zkd4NaAOXIB5QpvwcuH23sejuXG3p/NftW32ycLEkGO3nL1tH7+0Hae5trW/Y9jdmMg2h874g6G8MtZnvA==; 3:p6SlwMwJ4CrgEgobk5aMfHl+Q2H81aedLB/9EpE5EVKa9fRuh0x9zU4PNW5z6kYvdLDZP6ZYI93++5/NW/rOzRaoRchaxV+sxGdJCJOPt2ay1ppVa/NYF+dZEM8lEI5+; 25:o3dcg0LzVvwKfT/gR25HI9vEJIaSeo5hqSsIM1qBQ7T7wQgYX7IJuP4+fmOT0Qrew7F3toyIUFb5XB7XWneABBddbzvHSlvuLhB3FKVrI19sCPFrcOVZZJsjBGTYQ/2K5GXybZxAMvqMqhu3wU2gxkKMyzZZVgfHDaYQMBrEW01q4/ajBIHSkN/llmLlXMAuTwoEZaE1EFPuLxA3+Vx3G/wDXGU0LIn3EPMIEbHJjVp/gUtnazry2ONU5cyiRNsKElBb9KHYHJK5ws1Oee7AEOyeGWKBSTYIRGJG7eSLau0mLMulNeC9B73qBaQ4WGi8 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-MS-Office365-Filtering-Correlation-Id: 18f44e70-bb79-4470-c10d-08d333c8b2cd X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DBXPR07MB062; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB062; X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 4:JqxAEKrHVpJiRpKiGuVUOr8wLb4q25CcDS8Tua32dXSEXS6Zjx9WhS65IrXMZLe2+ynes/MLD3jt4jFJQuvZyuwyvYjHBFB/CuLh6totwfVPud3QfYjsX/IFsZa9IstRRi7G3hsQcTm/z67Gg8cQiSzkjvSAocbfUkPciKDK2LxnqK+QnIlAZLS8gJ4wAF63LQoIIDDhmIl+26DtuXMxVdMsBXMmq9HmzA+dASI3S5ASVmmH4QyOqaamkIkTA8ubYxbeFD6xVZ8gnB7xZuB7eTjeSc4pN1vdUVxVTvDTIXb6LYy+Xxi/hgnz3z/clGcjsi+JX6EE8mJzQDs2Tu+wnQPPXhXQaVAys/UjtE4hYiCS9awjJJl6t2UZsvcT82IO2Iq6wK/MTmb8QRxUe4vu/+soTrJmgwivsLMjFKuAXvk= X-Forefront-PRVS: 0850800A29 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(54014002)(44736004)(81816999)(76176999)(19580395003)(81686999)(50986999)(61296003)(19580405001)(77096005)(92566002)(87976001)(5004730100002)(23756003)(42186005)(1096002)(44716002)(6116002)(62236002)(122386002)(3846002)(33646002)(40100003)(586003)(50466002)(47776003)(5008740100001)(66066001)(50226001)(14496001)(5001770100001)(116806002)(189998001)(5001960100002)(230700001)(2906002)(84392002)(4326007)(86362001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DBXPR07MB062; 23:4q0bagZvjXNHV9aezKN9bXMlcL9YUafwoLG5sKNo?= =?iso-8859-1?Q?PNQNUX4I4C6eDho3bJIqafvB5rQWZUur8Vmt0Gy7ifTf2uvTnwYFKbaaCl?= =?iso-8859-1?Q?oXRp+mx1YFvw9RIJmt4a7XmzBod60JrdQcAiItr0bpcqyMxZ22hbyNtY8V?= =?iso-8859-1?Q?UKO7CyBdbCJR9GAFB+f3vTw4PYqP7y+K07lh4oJHBt08QmQGSau0tE/Xw7?= =?iso-8859-1?Q?CR4JljpWaLCtjYPFeUiZ5cs9BjZesqvByHEFHvk0TBL1RnMVehVLwLg3ES?= =?iso-8859-1?Q?wRaEU5zdnZ26i1Ce5+P55UXPeNMHZdyI3AQYhxJIu1abD4Pd736BKU93yU?= =?iso-8859-1?Q?PTPcRLHwMCSREzSWMJyqmOCkR59nR/mPtCDvScRF0OOhmpJI4VnDQFHLlF?= =?iso-8859-1?Q?6bM7zHKFouQO6bknb4z97jmiCRrAKs2ShJs3+mYGlOdC0TXf1dM8oRccw0?= =?iso-8859-1?Q?xiaGqA4m9oshyqnSpJmMZqtanqIn5HHTDRHDj99s3sCjj6AKvIIXRjJY4D?= =?iso-8859-1?Q?5rvvwkxy4+r9E6zbwx5+8DS0apDFRlDx+APU1tQIy12bDlgEGOPHtrsh0/?= =?iso-8859-1?Q?/U9d8+HHSElSLWBeq4REtPNQMM4NkUBXBpCxaBszcS5g4cgTgAVO8+4rgr?= =?iso-8859-1?Q?6HG1pylaWnnJtIZG4a21NGtqe1kf2AYRAm9o0rLelfus/TyxIsBEyCnUL6?= =?iso-8859-1?Q?0WpYFeaYMg0eG8BckTNriTuMmHWp4NEDKjCxjL6VxfQ1q3gKUKjS8XO4RK?= =?iso-8859-1?Q?zSGH8IISitWRmk265IfYHXNDIYjLaabsPn6hikPUlWyoDuNlLZcb1CWVkV?= =?iso-8859-1?Q?F0EHgegz7ihSsEdiFOgBCsLMw/drPcspPrku3FXOlAVW19jTGU4fEIJddi?= =?iso-8859-1?Q?msY2XSfzHuaoy9ZMfNg+VQ+q6ZPdftOsYFFDIjN7JcuN8/kfeYlZza7Y58?= =?iso-8859-1?Q?cR9JDn7QXRRyVFknvti/AJ3BkT2H1ragbHOPyaGGTcVwVyn8PspA5zxPFm?= =?iso-8859-1?Q?uIu/XBupZLhHFxyoaShwciicH8eaARIWngp4i8dEC4/zL81POUXB+KTSmU?= =?iso-8859-1?Q?bUVf/Epy4yldFCGIeHxi2NWEbQtR2cbwksq3w+Mavl/AGYkIbH3e83XVW2?= =?iso-8859-1?Q?6I4vn7oztk7Ix6GfmW7SDelj7J4VWHSDO8wD4oy6bc8krclj6W4r/s+JrP?= =?iso-8859-1?Q?mzNHRsdY1z?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 5:aJ4sFWDGQo1LePEfNIeyHVSKGe3FWGt+idXRZND6mb96l3xp7TQ4pkH5AgeNfoMEJrginU505DzWXevsoRFyftbNI6xujE2L/RDyMxjzWhCG96sgpbNVpEzXnArKxkKFc0eAFr9eqp1M94KI+42CuQ==; 24:oT6FRMo2dOHF5uUfY+oSozMJcTWac7qfYNPiXAQsid4wK4JhV6R6qKFsOsfPACM09XK7CStOzyw0rZ1TjPnc4zAp7lHpDs7RhRmqPYAbM18= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2016 16:22:27.2244 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:22:51 -0000 ----- Original Message ----- From: "Alan DeKok" To: "Eliot Lear" Sent: Friday, February 12, 2016 12:23 PM On Feb 12, 2016, at 5:19 AM, Eliot Lear wrote: > Actually the work started long before THAT, even. I think it dates to > 1993 if memory serves. RFC1492 is dated July 1993 but what I find more interesting than the timeline is the content of that RFC " The original TACACS protocol specification does exist. However, due to copyright issues, I was not able to obtain a copy of this document and this lack of access is the main reason for the writing of this document. This version of the specification was developed with the assistance of Cisco Systems, who has an implementation of the TACACS protocol that is believed to be compatible with the original specification. To be precise, the Cisco Systems implementation supports both the simple (non-extended) and extended versions. It is the simple version that would be compatible with the original. Please keep in mind that this is an informational RFC and does not specify a standard, and that more information may be uncovered in the future (i.e., the original specification may become available) that could cause parts of this document to be known to be incorrect." which I find delightful. How you build an Internet Standard with that as a starting point I am unsure but an ISE submission from an involved manufacturer (which, in the end, the IESG has to say does or does not conflict with the work of the IETF) would seem more appropriate. Tom Petch Pretty much. RFC 2989 and RFC 3127 are the outcomes (~y2000), not the start of the process. > But speaking plainly, this isn't a science experiment. It isn't > something anyone is floating as a suggestion. It's what's being done in > the network today, and it is supported across multiple implementations. > It is a defacto standard. Like IPX, or any number of other non-IETF protocols. That doesn't mean they deserve RFC status, much less a standards track document. > Unless there's very good reason not to do > so[*], let's just call it what it is. And again, I would reiterate: > let's also make clear what it's not. A good applicability statement > should help with that. > > Eliot > [*] A very good reason would be if it doesn't meet the requirements for > specifications that the IETF generally laid out. The discussion here has been that TACACS+ is a AAA protocol. If I believe that, I also have to believe that it's such a terrible AAA protocol, that it wasn't even considered in the discussion in RFC 3127. i.e. at the time the original draft was published, the major networking companies (including Cisco via their employees) and the ITEF consensus was that TACACS+ was not suitable for consideration as an AAA protocol. We're welcome to re-visit that decision. Priorities change, and we learn new things. But the cognitive dissonance here is mind-boggling. People say that TACACS+ is a AAA protocol, but the requirements on AAA protocols don't apply, because it's not a AAA protocol. It's a device management protocol. Even though the document doesn't describe device management, or even contain the terms "device management" or "device administration". By that logic, war is peace, freedom is slavery, ignorance is strength. I've asked repeatedly why the document should be granted standards track status. The argument is largely "it's widely used". Well, so what? Many other protocols are *more* widely used, and aren't standards track. Again, while there are many widely used protools as information, or not even RFCs, while there are inconsistent arguments in favour of the protocol, while a self-described AAA protocol goes against IETF consensus, while a self-described AAA protocol is so inadequate that it wasn't even considered in RFC 3127, while there were procedural issues making it a WG document... Why, exactly, are is the WG full-steam ahead in making it a standards track document? It looks like the IETF ideal of "individuals" is failing here. There are large forces behind the scenes pushing for standardization, and that is winning over petty things like individuals without deep pockets, and IETF process. Alan DeKok. From nobody Fri Feb 12 08:34:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA52B1A6F86 for ; Fri, 12 Feb 2016 08:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] autolearn=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 lB6xsa4HFQkn for ; Fri, 12 Feb 2016 08:34:43 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B2A1A6F82 for ; Fri, 12 Feb 2016 08:34:39 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id u200so68708728ywf.0 for ; Fri, 12 Feb 2016 08:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=yuFY4FEYm/qw07m4ZDcmyHc43PFCdSQMp8MfKqQiihY=; b=JdueLyPsC1UNxa6WBz6eGRbKzogWk2huI6Li7v7yFjo6JNhmrAcwVBvetVUO7VRv19 vsppymwlPGbGdul5ypjBliwrmFF96gLzOP2Bxs+Kz4hC68YbZjRLD7MuVQlg361p6C4i FAUQ/5UWrlelYja3v8FdCYZ208unS1hhGGVKxl0GRKTkNE1d0BhDjGE12MpbDTLm8ihf /y6Rvwnx5VsRKk3qNUQ5hpMvpK7hlynAniKdmPhICoEkorZJGtEhGgdqz/fHDeE4AlDb GFjGaA/qWwE5cCes7w5TEep2eMW0ygcawv+DKNjcIXrON0Xl1L2DSS4EUjg3+eXYsjCQ oHSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=yuFY4FEYm/qw07m4ZDcmyHc43PFCdSQMp8MfKqQiihY=; b=PqtE793ICrZj5wn6y29N12Al2obZ+6BirLPhTLnEcjHseT9p6Z4URmunX3ZLH9Uwkr +pMZYlms4Swkz9YbTjDf/zotGfbZOK1M7/AAmUkovY5jEcW9sjGb3orQugBZzqaKeJHt GBn29bPCHuCLwuMJR7BNNAODajpfMHk6poVidi95FlWuXjmdYyGggUeJwbC+QnXCUx1Q Wx2RJuFqXaeo6o/jWQmgHJUmJ5aMpKuzW/llKCp9wjqwJ8a8xeBZSxu/AJRzQbuI0qb7 MH+mZbx1gc2t7FV6CQfFqWHF92oyrHJW+edmRDB41jkRGmqwCbTpvDEPGqW+w/Wx6/7W THNA== X-Gm-Message-State: AG10YOTisMcfQCrUkYqucA4Bz+Mc9/TJO3ulXpXbtUf+8MfNuvO/2w+e0DaLRcuYigop95I2cUvKvzUBUj8jSrVy X-Received: by 10.129.119.10 with SMTP id s10mr1596940ywc.127.1455294879078; Fri, 12 Feb 2016 08:34:39 -0800 (PST) MIME-Version: 1.0 References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> <56BCE503.7000107@direcpath.com> <484DE7E8-363F-45EE-B521-78E53E0582C1@deployingradius.com> <56BDDD6A.8040902@restena.lu> In-Reply-To: <56BDDD6A.8040902@restena.lu> From: Warren Kumari Date: Fri, 12 Feb 2016 16:34:29 +0000 Message-ID: To: Stefan Winter , Alan DeKok , Robert Drake Content-Type: multipart/alternative; boundary=001a1141c8364fd14e052b953e7e Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:34:45 -0000 --001a1141c8364fd14e052b953e7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 12, 2016 at 8:26 AM Stefan Winter wrote: > Hello, > > >> Is the RADIUS WG going to add support for command authorization? It > seems like if RADIUS wanted this then one vendor refusing to submit a > standard wouldn't be a barrier. Surely anyone could write a standard and > propose it as a draft? > > > > It would be well within the scope of RADEXT. The RADEXT WG would (I'= m > guessing) be OK with standardizing it. > > chair-hat on: > > RADEXT's charter states > > "The RADIUS Extensions Working Group will focus on extensions to the > RADIUS protocol pending approval of the new work from the Area Director" > > So feature additions are indeed well inside the current charter scope. > > > But while anyone can write a standard, any standard is pointless > unless it's implemented. And the vendors have refused to standardize > command authorization in RADIUS. > > > > Because they saw it as a competitive advantage to bypass the IETF. > > chair-hat off for the rest of this mail: > > That's true. Cisco even has devised a mapping between RADIUS attributes > and authorization commands usually transported over TACACS+. The RADIUS > VSA "cisco-av-pair" basically takes TACACS+ syntax inside. > > As a random example, quickly googled: > > > http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_serv= er_for_windows/4.0/user/guide/ad.html > > Quoting the section "About the cisco-av-pair RADIUS attribute": > > "[...]cisco-av-pair, supports the inclusion of many AV pairs by using > the following format: > > attribute sep value > > where attribute and value are an AV pair supported by the releases of > IOS implemented on your AAA clients, and sep is =3D for mandatory > attributes and asterisk (*) for optional attributes. You can then use > the full set of Terminal Access Controller Access Control System > (TACACS+) authorization features for RADIUS." > > Many of the commands that TACACS+ can understand in Cisco devices have > direct RADIUS VSA counterpart. The syntax also /allows/ for per-command > authorization in that same VSA. > > That last sentence in the doc above even wants to imply that per-command > authorization is possible. > > The catch is that one can even send the converted per-command-authz > syntax inside the VSA, and a Cisco device nicely ignores it. It process > other attributes from the same group in the same way (I tried that, > admittedly nearly a decade ago meanwhile), so this is quite clearly > visible *bad will* and not a technology gap. > > For some reason, some people see this and conclude "TACACS+ is better, > because I can send per-command-authorization". While a much more natural > conclusion would be to complain about the obvious bug or bad-will > limitation in the product. > > Consequently, I can even halfways understand that the same people want > TACACS+ standardised; while others who are not in that IMHO flawed line > of thinking want it to go away and never come back. > > I myself need to have one stepchild instance of TACACS+ server running > in our network because we need to have per-command authorisation at a > few places. The product that runs TACACS+ is called "Radiator", which is > actually a RADIUS server that runs TACACS+ in a niche of its memory > because it can; while doing so much more with RADIUS. That is quite > telling IMHO. > > This story goes to show that those who have to deal with TACACS+ or the > lack of per-command-authorization in RADIUS in their real deployment > life have a story to tell, and feel strongly about the issue, and maybe > even loathe TACACS+ for its anti-competitiveness in that respect; while > others love it for allowing them to do something they otherwise can't. > > This would explain the heatedness of the debate. > > > Now that they have problems with inter-operability, they're looking fo= r > IETF approval. > > > > Again, why is there a need to have the document as standards track? > RADIUS accounting (RFC 2866) is Informational, for crying out loud. Are = we > really saying that RADIUS / RADEXT WG with an active history going back t= o > 1996 is *not* going to have a standards track protocol, but TACACS+ gets > one, because "it's popular"? > > > > That's an amazing interpretation of the IETF consensus, and IETF > process. Maybe I'm naive, but it looks a while lot to me like one WG has > to follow the rules to get a protocol standardized, and another WG doesn'= t. > > My personal opinion is that documenting the protocol is probably good > because it is so widespread (-> Informational). But it's also so low > priority that I wouldn't care much if it weren't documented at all > (->/dev/null). > Rather than seeing a standards-track document I'd rather see Cisco > living up to their promise of "the full set of Terminal Access > Controller Access Control System (TACACS+) authorization features for > RADIUS" in actual deployed code; it would immediately make the necessity > for TACACS+ go away; at which point nobody would care about documenting > this then-obsolete piece of network technology any more. > That is working on the assumption that the reason that operators are using TACACS+ instead of RADIUS is /only/ because of this feature. In many cases it is also because operators already have TACACS servers installed and / or find TACACS+ *much* simpler to deploy and manage. RADIUS is a grand protocol - it has many bells and whistles and extra functionality, but e.g: shrubbery's tac_plus is free, comes with many distributions, and is dead simply to install and configure. > > About process, at least in RADEXT we always ask for document adoption, > and we have a good debating culture at this early stage; so passing the > WG adoption threshold means something. I'm a bit shocked to learn that > this is apparently different in osawg. > > Greetings, > > Stefan Winter > > > > > Alan DeKok. > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et > de la Recherche > 2, avenue de l'Universit=C3=A9 > L-4365 Esch-sur-Alzette > > Tel: +352 424409 1 > Fax: +352 422473 > > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me > > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a1141c8364fd14e052b953e7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri= , Feb 12, 2016 at 8:26 AM Stefan Winter <stefan.winter@restena.lu> wrote:
Hello,

>> Is the RADIUS WG going to add support for command authorization?= =C2=A0 It seems like if RADIUS wanted this then one vendor refusing to subm= it a standard wouldn't be a barrier.=C2=A0 Surely anyone could write a = standard and propose it as a draft?
>
>=C2=A0 =C2=A0It would be well within the scope of RADEXT.=C2=A0 The RAD= EXT WG would (I'm guessing) be OK with standardizing it.

chair-hat on:

RADEXT's charter states

"The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol pending approval of the new work from the Area Director&quo= t;

So feature additions are indeed well inside the current charter scope.

>=C2=A0 =C2=A0But while anyone can write a standard, any standard is poi= ntless unless it's implemented.=C2=A0 And the vendors have refused to s= tandardize command authorization in RADIUS.
>
>=C2=A0 =C2=A0Because they saw it as a competitive advantage to bypass t= he IETF.

chair-hat off for the rest of this mail:

That's true. Cisco even has devised a mapping between RADIUS attributes=
and authorization commands usually transported over TACACS+. The RADIUS
VSA "cisco-av-pair" basically takes TACACS+ syntax inside.

As a random example, quickly googled:

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_co= ntrol_server_for_windows/4.0/user/guide/ad.html

Quoting the section "About the cisco-av-pair RADIUS attribute":
"[...]cisco-av-pair, supports the inclusion of many AV pairs by using<= br> the following format:

attribute sep value

where attribute and value are an AV pair supported by the releases of
IOS implemented on your AAA clients, and sep is =3D for mandatory
attributes and asterisk (*) for optional attributes. You can then use
the full set of Terminal Access Controller Access Control System
(TACACS+) authorization features for RADIUS."

Many of the commands that TACACS+ can understand in Cisco devices have
direct RADIUS VSA counterpart. The syntax also /allows/ for per-command
authorization in that same VSA.

That last sentence in the doc above even wants to imply that per-command authorization is possible.

The catch is that one can even send the converted per-command-authz
syntax inside the VSA, and a Cisco device nicely ignores it. It process
other attributes from the same group in the same way (I tried that,
admittedly nearly a decade ago meanwhile), so this is quite clearly
visible *bad will* and not a technology gap.

For some reason, some people see this and conclude "TACACS+ is better,=
because I can send per-command-authorization". While a much more natur= al
conclusion would be to complain about the obvious bug or bad-will
limitation in the product.

Consequently, I can even halfways understand that the same people want
TACACS+ standardised; while others who are not in that IMHO flawed line
of thinking want it to go away and never come back.

I myself need to have one stepchild instance of TACACS+ server running
in our network because we need to have per-command authorisation at a
few places. The product that runs TACACS+ is called "Radiator", w= hich is
actually a RADIUS server that runs TACACS+ in a niche of its memory
because it can; while doing so much more with RADIUS. That is quite
telling IMHO.

This story goes to show that those who have to deal with TACACS+ or the
lack of per-command-authorization in RADIUS in their real deployment
life have a story to tell, and feel strongly about the issue, and maybe
even loathe TACACS+ for its anti-competitiveness in that respect; while
others love it for allowing them to do something they otherwise can't.<= br>
This would explain the heatedness of the debate.

>=C2=A0 Now that they have problems with inter-operability, they're = looking for IETF approval.
>
>=C2=A0 =C2=A0Again, why is there a need to have the document as standar= ds track?=C2=A0 RADIUS accounting (RFC 2866) is Informational, for crying o= ut loud.=C2=A0 Are we really saying that RADIUS / RADEXT WG with an active = history going back to 1996 is *not* going to have a standards track protoco= l, but TACACS+ gets one, because "it's popular"?
>
>=C2=A0 =C2=A0That's an amazing interpretation of the IETF consensus= , and IETF process.=C2=A0 Maybe I'm naive, but it looks a while lot to = me like one WG has to follow the rules to get a protocol standardized, and = another WG doesn't.

My personal opinion is that documenting the protocol is probably good
because it is so widespread (-> Informational). But it's also so low=
priority that I wouldn't care much if it weren't documented at all<= br> (->/dev/null).
Rather than seeing a standards-track document I'd rather see Cisco
living up to their promise of "the full set of Terminal Access
Controller Access Control System (TACACS+) authorization features for
RADIUS" in actual deployed code; it would immediately make the necessi= ty
for TACACS+ go away; at which point nobody would care about documenting
this then-obsolete piece of network technology any more.

<no hats at all>
That is working on the a= ssumption that the reason that operators are using TACACS+ instead of RADIU= S is /only/ because of this feature. In many cases it is also because opera= tors already have TACACS servers installed and / or find TACACS+ *much* sim= pler to deploy and manage. RADIUS is a grand protocol - it has many bells a= nd whistles and extra functionality, but e.g: shrubbery's tac_plus is f= ree, comes with many distributions, and is dead simply to install and confi= gure.
</no hats>

=C2=A0

About process, at least in RADEXT we always ask for document adoption,
and we have a good debating culture at this early stage; so passing the
WG adoption threshold means something. I'm a bit shocked to learn that<= br> this is apparently different in osawg.

Greetings,

Stefan Winter

>
>=C2=A0 =C2=A0Alan DeKok.
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg >


--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Educati= on Nationale et
de la Recherche
2, avenue de l'Universit=C3=A9
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371= /pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
--001a1141c8364fd14e052b953e7e-- From nobody Fri Feb 12 08:35:00 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4826B1A6F86 for ; Fri, 12 Feb 2016 08:34:47 -0800 (PST) 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] autolearn=ham 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 FGzvyeIdODed for ; Fri, 12 Feb 2016 08:34:45 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 03F1D1A6F77 for ; Fri, 12 Feb 2016 08:34:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 50C94D0F; Fri, 12 Feb 2016 16:34:43 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JbwYNtmYKIm; Fri, 12 Feb 2016 16:34:43 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 3B974439; Fri, 12 Feb 2016 16:34:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56BDFE46.9000802@cisco.com> Date: Fri, 12 Feb 2016 11:34:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56BDE83F.1030102@restena.lu> <56BDFE46.9000802@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:34:47 -0000 > On Feb 12, 2016, at 10:46 AM, Eliot Lear wrote: >=20 > Hi Stefan, >=20 > Unless it is absolutely determined that the current work can't doesn't = meet criteria for an IETF standard, I would be opposed to such an = exercise. For one thing, we all have other things to do. For another, = and as or more important, we would be denying the reality of the = situation. The reality is that the TLS portion documented in the draft isn't = implemented anywhere. I find it telling that the work is important enough to push through = the WG, but not important enough that (as you say) the authors have = other things to do... and don't have the time to document old work as = different from new work. Alan DeKok. From nobody Fri Feb 12 08:38:30 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8351A6F90 for ; Fri, 12 Feb 2016 08:38:29 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 n-mlUePK22lD for ; Fri, 12 Feb 2016 08:38:26 -0800 (PST) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4836D1A6F88 for ; Fri, 12 Feb 2016 08:38:26 -0800 (PST) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id E0375BB74C; Fri, 12 Feb 2016 17:38:22 +0100 (CET) To: Eliot Lear , opsawg@ietf.org References: <56BDE83F.1030102@restena.lu> <56BDFE46.9000802@cisco.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <56BE0A7A.1020509@restena.lu> Date: Fri, 12 Feb 2016 17:38:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BDFE46.9000802@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CrFvLJBrIglfQmOLUP51KxKln1ReQ619a" Archived-At: Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:38:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CrFvLJBrIglfQmOLUP51KxKln1ReQ619a Content-Type: multipart/mixed; boundary="------------020504010503080401050807" This is a multi-part message in MIME format. --------------020504010503080401050807 Content-Type: multipart/alternative; boundary="------------040100050909060404070401" --------------040100050909060404070401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > Unless it is absolutely determined that the current work can't doesn't > meet criteria for an IETF standard, I would be opposed to such an > exercise. For one thing, we all have other things to do. Contrary to that, many people on this list are arguing for their life on the do's or don't's in this area; it seems like they actually have *nothing* better to do than to fight for (or against) TACACS+. Which is a great start for a future working group, BTW; people with dedication and attitude are the fuel for IETF work. > For another, and as or more important, we would be denying the > reality of the situation. I would rather understand now what sort of > changes are being proposed in order for the current work to come up to > snuff. Sorry, I don't understand. The reality is that there's a TACACS+ protocol out there, and that there is a desirable TACACS+-to-be in some people's heads. I'm suggesting to split the documents exactly like reality does: one document for the TACACS+ protocol as it exists, one (or more, depending on the amount of things to be changed) for the future state of it. How is that denying reality? It's much more working with reality as I see it. Maybe my reality is different to yours. Stefan > > Eliot > > > > On 2/12/16 3:12 PM, Stefan Winter wrote: >> Hello, >> >> this debate has been going on for quite a while. It's multi-faceted, >> which doesn't help coming to conclusions. >> >> Maybe we can un-entangle one point: there are suggestions to either ma= ke >> this Standards Track or Informational; and one wheteher the protocol >> should be documented vs. improved. >> >> Maybe there should be two (or more) drafts instead: >> >> 1) The TACACS+ Protocol as Deployed in 2016 >> (Informational, *no changes*) >> >> 2-n) The New Feature X for TACACS+ >> (possibly Standards Track, one document per bolt-on feature) >> >> (one of the Xes being TLS encryption, but I'm sure there are more) >> >> Those voices on the list who demanded documentation can then happily >> accept Informational; the documentation is done either way. Those who >> opposed Standards Track for the durrent draft because it's about a >> protocol coming in from outside IETF can now go silent, because >> Informational addresses their concern. >> >> Those who demand new features can then put all their energy into a >> proper, per-feature argument with all those arguments collated in a >> per-topic document. Those who opposed the current draft for Standards >> Track can continue to oppose those new documents; this time in a focus= ed >> discussion with less broadsides fired. >> >> If you can follow my line of thinking to this point, let's take it eve= n >> one step further: we are now discussing a larger effort, involving >> multiple RFCs, taking an existing technology to a level it wasn't >> before. This is usually much rather a job for a working group in its o= wn >> right, with a charter detailing which work happens when; not a job for= a >> one-shot effort in the opsawg. >> >> So my ultimate suggestion would be: have a BoF at IETF95, try to form = a >> working group, work on all issues that were brought up individually. >> >> (FWIW, this is exactly how RADIUS came to be... from an undocumented >> proprietary protcol to a successful IETF one. And guess what, even we >> had lengthy discussions about TLS encryption; debating is simply part = of >> the culture) >> >> Greetings, >> >> Stefan Winter >> >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > --------------040100050909060404070401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

Unless it is absolutely determined that the current work can't doesn't meet criteria for an IETF standard, I would be opposed to such an exercise.=C2=A0 For one thing, we all have other things to = do.

Contrary to that, many people on this list are arguing for their life on the do's or don't's in this area; it seems like they actually have *nothing* better to do than to fight for (or against) TACACS+. Which is a great start for a future working group, BTW; people with dedication and attitude are the fuel for IETF work.

=C2= =A0 For another, and as or more important, we would be denying the reality of the situation.=C2=A0 I would rather understand now what sort of changes are being proposed in order for the current work to come up to snuff.

Sorry, I don't understand. The reality is that there's a TACACS+ protocol out there, and that there is a desirable TACACS+-to-be in some people's heads.

I'm suggesting to split the documents exactly like reality does: one document for the TACACS+ protocol as it exists, one (or more, depending on the amount of things to be changed) for the future state of it.

How is that denying reality? It's much more working with reality as I see it. Maybe my reality is different to yours.

Stefan

Eliot



On 2/12/16 3:12 PM, Stefan Winter wrote:
= 
Hello,

this debate has been going on for quite a while. It's multi-faceted,
which doesn't help coming to conclusions.

Maybe we can un-entangle one point: there are suggestions to either make
this Standards Track or Informational; and one wheteher the protocol
should be documented vs. improved.

Maybe there should be two (or more) drafts instead:

1) The TACACS+ Protocol as Deployed in 2016
   (Informational, *no changes*)

2-n) The New Feature X for TACACS+
   (possibly Standards Track, one document per bolt-on feature)

(one of the Xes being TLS encryption, but I'm sure there are more)

Those voices on the list who demanded documentation can then happily
accept Informational; the documentation is done either way. Those who
opposed Standards Track for the durrent draft because it's about a
protocol coming in from outside IETF can now go silent, because
Informational addresses their concern.

Those who demand new features can then put all their energy into a
proper, per-feature argument with all those arguments collated in a
per-topic document. Those who opposed the current draft for Standards
Track can continue to oppose those new documents; this time in a focused
discussion with less broadsides fired.

If you can follow my line of thinking to this point, let's take it even
one step further: we are now discussing a larger effort, involving
multiple RFCs, taking an existing technology to a level it wasn't
before. This is usually much rather a job for a working group in its own
right, with a charter detailing which work happens when; not a job for a
one-shot effort in the opsawg.

So my ultimate suggestion would be: have a BoF at IETF95, try to form a
working group, work on all issues that were brought up individually.

(FWIW, this is exactly how RADIUS came to be... from an undocumented
proprietary protcol to a successful IETF one. And guess what, even we
had lengthy discussions about TLS encryption; debating is simply part of
the culture)

Greetings,

Stefan Winter




_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/opsawg


--------------040100050909060404070401-- --------------020504010503080401050807 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG/MacGPG2 v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020504010503080401050807-- --CrFvLJBrIglfQmOLUP51KxKln1ReQ619a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJWvgp/AAoJEMDeajWKOdxm0XUP/3Ky35+A6JmTbGdBZMQOlhRI nvWFCAqX/mOe79LELCHqhbGA5GEdXdj+GGIghJ+PEllM0krH0bsA+KoNmNz4Ekfg /5GnyFbryIEwNvBOi0MN3acWSZze5Bp1+nslqgIaZsWVi/qQtldiDMKdri6jDmQ4 TwyWHEfnKPqcYfN68ZsvbDn2gDWVwTGfmNbmgnHoec91c0Gd6BrWZT1dY7KfPIE0 nNlpJtrkZsOeClW7s59Soj9Bp7Z89LkIjMrl1NnS0yAjLfag4v23S39kvNScQitH 4SzT9P0h2lNc2BINelNPZ31KMQPGDRTOudvZzqS2m6MUNCw70y71fZwmdvfxhtYg WJt6eKs2M3dZOhQ79AFOd/ipUIn3bH7BNc7k2jY8fyXDeZGG8Fh3HyM3tevMzeZs 3ft3uvlMJ0dchWijlltn3O2QXIhCy4xeotzmP4/hMZmUeRl90JDz08W2l7lQqZeq QCAJtFk8qtqdPjqbRjkHOEc1TlymH4c64GIpY1HhjvihI0Shtl7ZuagJv+6+gEyB Ou6YXa9Cco5ZVXePFtifRQZg5xh6D662K0vCCIuQsf+M7DHO1MgYEbbBzsIOcC+7 1GZY/8mhioHrj1Zab7GjlBAvD1MeTC8n+lPPWsZ1lWjwFDMZCNlGBlPYwSq41caH zd2s8cFJzssA5RZnS33y =eyYJ -----END PGP SIGNATURE----- --CrFvLJBrIglfQmOLUP51KxKln1ReQ619a-- From nobody Fri Feb 12 08:46:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DF71A6FB5 for ; Fri, 12 Feb 2016 08:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.564 X-Spam-Level: **** X-Spam-Status: No, score=4.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 FNbBwE2Zm_jt for ; Fri, 12 Feb 2016 08:46:08 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0092.outbound.protection.outlook.com [65.55.169.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512BC1A6F93 for ; Fri, 12 Feb 2016 08:46:07 -0800 (PST) Received: from BLUPR07MB386.namprd07.prod.outlook.com (10.141.27.22) by BLUPR07MB385.namprd07.prod.outlook.com (10.141.27.18) with Microsoft SMTP Server (TLS) id 15.1.403.16; Fri, 12 Feb 2016 16:46:05 +0000 Received: from BLUPR07MB386.namprd07.prod.outlook.com ([169.254.14.252]) by BLUPR07MB386.namprd07.prod.outlook.com ([169.254.14.252]) with mapi id 15.01.0403.016; Fri, 12 Feb 2016 16:46:04 +0000 From: "Bradner, Scott" To: "opsawg@ietf.org" Thread-Topic: appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic Thread-Index: AQHRZbTd2tJIIHL7eE6xjTs8slFg5Q== Date: Fri, 12 Feb 2016 16:46:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=harvard.edu; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [128.103.229.199] x-microsoft-exchange-diagnostics: 1; BLUPR07MB385; 5:lEjxPQVVsg8utL3CfOBPGjjKut2qovnvCwI2iKChPj5IJSPnkZu61DpGhFq6rzgkG6jh7Rvi0pSS0JjmzQH08FecTsVafaIUq9g7l0w2DO2u9khpRNMJzxw/5mB8Vi6dot8O3wj7oFJ3ejdoDE/t9g==; 24:ymMaTTlnk4nAir/OQpycQGHVxUI/4ace+qiBI0uTNA8DUFZx7XbVZdkQU24BQh0hXglHjja0B1QKOZWpQkCLI/oVYlx59Y4HKKHenkKjEYc= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:BLUPR07MB385; x-ms-office365-filtering-correlation-id: b133267b-8514-4e6f-f316-08d333cbffa3 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228675835342607)(35762410373642)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR07MB385; BCL:0; PCL:0; RULEID:; SRVR:BLUPR07MB385; x-forefront-prvs: 0850800A29 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(66654002)(377424004)(377454003)(479174004)(1220700001)(5002640100001)(36756003)(54356999)(561944003)(99286002)(4326007)(230783001)(122556002)(40100003)(16601075003)(575784001)(19580395003)(1096002)(83716003)(50986999)(86362001)(33656002)(5008740100001)(102836003)(106116001)(75432002)(10400500002)(1730700002)(87936001)(2906002)(5004730100002)(2501003)(110136002)(6116002)(229853001)(5001960100002)(18950595002)(16236675004)(3660700001)(90282001)(586003)(92566002)(19580405001)(189998001)(3846002)(19617315012)(82746002)(15975445007)(66066001)(3280700002)(2900100001)(2351001)(89122001)(88552002)(104396002)(579004)(559001)(336705003)(2657375003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR07MB385; H:BLUPR07MB386.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EA0DF28481B54F5C99E850CD2B878EACharvardedu_" MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2016 16:46:04.8748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR07MB385 Archived-At: Cc: "opsawg-chairs@tools.ietf.org" Subject: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:46:14 -0000 --_000_EA0DF28481B54F5C99E850CD2B878EACharvardedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNoYWlycyBvZiB0aGUgb3BzYXdnIHJlY2VpdmVkIGFuIGFwcGVhbCBmcm9tIEFsYW4gRGVL b2sgb24gMTEgRmVicnVhcnkNCjIwMTYgY29uY2VybmluZyB0aGUgaGFuZGxpbmcgYW5kIHBvc3Np YmxlIGRpc3Bvc2l0aW9uIG9mDQpkcmFmdC1pZXRmLW9wc2F3Zy10YWNhY3MtMDAudHh0IChUQUNB Q1MrKS4gVGhpcyBtZXNzYWdlIHdhcyBhIGZvbGxvdyB1cCBvZg0KYSBudW1iZXIgb2YgIGVtYWls IG1lc3NhZ2VzIHNlbnQgdG8gdGhlIG9wc2F3ZyBtYWlsaW5nIGxpc3Qgc3RhcnRpbmcgb24gMTAN CkZlYnJ1YXJ5Lg0KDQpUaGUgdG9waWNzIG9mIHRoZSBhcHBlYWwgYW5kIG90aGVyIG1lc3NhZ2Vz IGZyb20gTXIuIERlS29rIGluY2x1ZGVkOg0KMS8gVGhlIGFkb3B0aW9uIG9mIHRoZSBUQUNBQ1Mr IEludGVybmV0IERyYWZ0IGFzIGEgd29ya2luZyBncm91cCBpdGVtLg0KMi8gVGhlIGFwcHJvcHJp YXRlbmVzcyBvZiBwdWJsaXNoaW5nIHRoZSBUQUNBQ1MrIEludGVybmV0IERyYWZ0IGFzDQphIFJG QyB0aHJvdWdoIHRoZSBJRVRGIHRyYWNrLg0KMy8gVGhlIGFwcHJvcHJpYXRlbmVzcyBvZiBwdWJs aXNoaW5nIHRoZSBUQUNBQ1MrIEludGVybmV0IERyYWZ0IGFzDQphIHN0YW5kYXJkcyB0cmFjayBS RkMuDQoNClRoaXMgbWVtbyBjb25jZXJucyB0aGUgZmlyc3QgdG9waWMsIHRoZSBvdGhlciB0d28g dG9waWNzIGFyZSBwcm9wZXIgdG9waWNzDQpmb3IgYSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dCB3aGVuIGFuIEludGVybmV0IERyYWZ0IGlzIHVuZGVyDQpjb25zaWRlcmF0aW9uLg0KDQpGaXJz dCBzb21lIGhpc3Rvcnk6DQoNCkFmdGVyIHNvbWUgaW5pdGlhbCBjb25mdXNpb24sIHRoZSBJbnRl cm5ldCBEcmFmdCBkcmFmdC1ncmFudC10YWNhY3MtMDAudHh0DQp3YXMgcHVibGlzaGVkIG9uIDEy IEp1bmUgMjAxNS4gIEluIGFuIGVtYWlsIG1lc3NhZ2UgdG8gdGhlIG9wc2F3ZyBsaXN0DQpEb3Vn IEdhc2ggc2FpZDoNCg0KIiBUQUNBQ1MrIGlzIGEgcHJvdG9jb2wgd2lkZWx5IGRlcGxveWVkLCBi YXNlZCB1cG9uIGEgZHJhZnQgc3BlY2lmaWNhdGlvbg0KdGhhdCBDaXNjbyBzdWJtaXR0ZWQgaW4g MTk5OCwgYnV0IG5ldmVyIGNvbXBsZXRlZCB0byBSRkMgc3RhdHVzLiBUaGUNCm9yaWdpbmFsIGRy YWZ0IGhhcyBiZWVuIHRpZGllZCBhbmQgbGlnaHRseSBlbmhhbmNlZCBhbmQgcmVzdWJtaXR0ZWQs IHdpdGgNCnRoZSBpbnRlbnQgdG8gZmluYWxseSBnZXQgaXQgcHVibGlzaGVkIGFzIGEgc3RhbmRh cmQuIg0KDQpIZSB0aGVuIGZvbGxvd2VkIHVwIHdpdGggYW4gZW1haWwgbWVzc2FnZSBkZXNjcmli aW5nIHRoZSB1cGRhdGVzIHRvIHRoZQ0Kb2xkIElELg0KDQoxIEp1bHkgMjAxNTogdGhlIE9QUyBB ZHMgcHV0IFRBQ0FDUysgb24gdGhlIGFnZW5kYSBmb3Igb3BzIGFyZWEgc2Vzc2lvbg0KZHVyaW5n IElFVEYgOTMNCg0KMjAgSnVseSAyMDE1OiBUaGUgb3BzIGFyZWEgc2Vzc2lvbiB3YXMgaGVsZC4g VGhlIFRBQ0FDUysgc2xpZGVzIHVzZWQNCmR1cmluZyB0aGUgc2Vzc2lvbiBhcmUgYXQ6DQpodHRw czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLW9wc2FyZWEt Mi5wZGYNCg0KTWludXRlcyBvZiB0aGUgc2Vzc2lvbiBhcmUgcXVpdGUgc3BhcnNlLiAgVGhleSBu b3RlIHRoYXQgdGhlIHByZXNlbnRhdGlvbg0Kb2NjdXJyZWQgYW5kIHRoYXQgQWxhbiBEZUtvayBv YmplY3RlZCB0byB0aGUgcHJvcG9zYWwuDQoNClRoZSBhdWRpbyByZWNvcmRpbmcgb2YgdGhlIHNl c3Npb24gaXMgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9hdWRpby9pZXRmOTMvaWV0ZjkzLWNv bmdyZXNzaGFsbGktMjAxNTA3MjAtMTc0MC5tcDMNCg0KVGhlIGF1ZGlvIG9mIHRoZSBzcGVha2Vy cyBhbmQgdGhlIGNvbW1lbnRhdG9ycyBhdCB0aGUgbWljIGxpbmUgYXJlIHF1aXRlDQpjbGVhciBi dXQsIHVuZm9ydHVuYXRlbHksIHRoZSBhdWRpbyBvZiB0aGUgQUQgaXMgdW5pbnRlbGxpZ2libGUu ICAgVGhlDQpyZWNvcmRpbmcgc2hvd3MgdGhhdCB0aGVyZSB3YXMgbGl0dGxlIGRpc2N1c3Npb24g b2YgdGhlIG1lcml0cyBvZiB0aGUNCnByb3Bvc2FsIG90aGVyIHRoYW4gTXIuIERlS29rJ3Mgb2Jq ZWN0aW9ucy4gIE9uZSBvZiB0aGUgY2hhaXJzIChTY290dCkNCnJlY2FsbHMgdGhhdCB0aGUgQUQg ZGlkIHNvbWUgZm9ybSBvZiBhc3Nlc3NtZW50IHRvIGdhZ2UgaW50ZXJlc3QgaW4NCndvcmtpbmcg b24gdGhlIElEIGFuZCBmb3VuZCBzdXBwb3J0Lg0KDQoyIE9jdG9iZXIgIDIwMTU6ICB1cGRhdGVk IElEIHB1Ymxpc2hlZA0KDQo0IE9jdG9iZXIgMjAxNTogIERvdWcgR2FzaCBzZW50IG5vdGUgdG8g b3BzYXdnIGxpc3QgYXNraW5nIGZvciBvcGluaW9ucyBvZg0KdGhlIGxpc3QgZm9yIHB1YmxpY2F0 aW9uDQoNCjEzIE5vdmVtYmVyIDIwMTU6IFdhcnJlbiBzZW50IHRoZSBmb2xsb3dpbmcgbWVzc2Fn ZSBhc2tpbmcgZm9yIGlucHV0IG9uDQp0aGUgSUQgKA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9vcHNhd2cvY3VycmVudC9tc2cwNDEyNC5odG1sKQ0KDQpEZWFyIE9wc0FX RyBXRywNCg0KICAgV2Ugd291bGQgcmVhbGx5IGFwcHJlY2lhdGUgYW55IGZlZWRiYWNrIG9uIHRo aXMgZG9jdW1lbnQuIFBlcnNvbmFsbHkgSQ0KICAgdGhpbmsgaXQgaXMgcmVhbGx5IHVzZWZ1bCwg YnV0IHdlIG5lZWQgdGhlIFdHIHRvIHJldmlldyBhbmQgcHJvdmlkZQ0KICAgZmVlZGJhY2suDQoN CiAgIE92ZXIgdGhlIHllYXJzIEkndmUgaGVhcmQgYSBudW1iZXIgb2YgcGVvcGxlIGt2ZXRjaCB0 aGF0IFRBQ0FDUysgaXNuJ3QNCiAgIGRvY3VtZW50ZWQgLS0gd2VsbCwgbm93IHlvdSBjYW4sIHlv dSBrbm93LCBhY3R1YWxseSBkbyBzb21ldGhpbmcgYWJvdXQNCiAgIHRoaXMuLi4NCg0KICAgVw0K DQoNClRoZXJlIHdlcmUgYSBudW1iZXIgb2YgcmVzcG9uc2VzIGluIHN1cHBvcnQgb2YgcHVibGlj YXRpb24gYW5kIHRoZSBXRw0Kd29ya2luZyBvbiB0aGUgSUQgYWxvbmcgd2l0aCBzb21lIHRlY2hu aWNhbCBkaXNjdXNzaW9uLg0KDQpUaGUgY2hhaXJzIGNvbmNsdWRlZCB0aGF0IHRoZXJlIHdhcyBl bm91Z2ggaW50ZXJlc3QgdG8gYWRvcHQgdGhlIElEIGFzIGENCndvcmtpbmcgZ3JvdXAgdG9waWMu DQoNCjMwIE5vdmVtYmVyOiAyMDE1OiBXYXJyZW4gc2VudCB0aGUgZm9sbG93aW5nIG1lc3NhZ2Ug dG8gdGhlIG9wc2F3ZzoNCihmb3Igc29tZSByZWFzb24gdGhpcyBtZXNzYWdlIGRvZXMgbm90IHNo b3cgdXAgaW4gdGhlIGFyY2hpdmUgYnV0IGEgY29weSBpcw0KYXBwZW5kZWQgdG8gdGhpcyBtZXNz YWdlKQ0KDQogICAgVGhlIGNoYWlycyBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgc3VmZmljaWVudCBp bnRlcmVzdCBhbmQgc3VwcG9ydCB0byBhZG9wdA0KICAgIHRoaXMgZG9jdW1lbnQgYXMgYW4gT3Bz QVdHIGRvY3VtZW50Lg0KDQogICAgQXV0aG9ycywgcGxlYXNlIHJlc3VibWl0IGFzIGRyYWZ0LWll dGYtb3BzYXdnLXRhY2Fjcy0wMQ0KDQoxNiBEZWNlbWJlciAyMDE1IC0gcmVuYW1lZCBJRCBwdWJs aXNoZWQNCg0KDQpCeSBhc2tpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgbGlzdCBmb3IgaW5wdXQgb24g dGhlIHF1ZXN0aW9uIG9mIGFkb3B0aW5nIGFuDQpJRCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1l bnQgdGhlIG9wc2F3ZyBjaGFpcnMgZm9sbG93ZWQgb25lIG9mIHRoZQ0Kbm9ybWFsIElFVEYgcHJv Y2VzcyB0byBkZXRlcm1pbmUgaWYgdGhlcmUgd2FzIGVub3VnaCBpbnRlcmVzdCBmb3IgdGhlDQp3 b3JraW5nIGdyb3VwIHRvIGFkb3B0IHRoZSBUQUNBQ1MrIElEIGFzIGEgd29ya2luZyBncm91cCB0 b3BpYy4gIFdlIG5vdGUNCmluIHBhc3NpbmcgdGhhdCBzdWNoIGFub3RoZXIgbm9ybWFsIHByb2Nl c3MgaXMgZm9yIHRoZSBXRyBjaGFpcnMgdG8gZGVjaWRlDQpvbiB0aGVpciBvd24gdG8gYWRvcHQg YSBkb2N1bWVudCBhcyBhIHdvcmtpbmcgZ3JvdXAgdG9waWMuICBXZSBhbHNvIGZlbHQNCnRoYXQg dGhlIHRvcGljIHdhcyBzdWZmaWNpZW50bHkgd2l0aGluIHRoZSB3b3JraW5nIGdyb3VwIGNoYXJ0 ZXIgdG8gZG8gc28NCndpdGhvdXQgYSBzcGVjaWZpYyBjaGFydGVyIHVwZGF0ZS4NCg0KVGh1cyBN ci4gRGVLb2sncyBhcHBlYWwgYXMgdG8gdGhlIGFkb3B0aW9uIG9mIHRoZSBJRCBhcyBhIHdvcmtp bmcgZ3JvdXANCnRvcGljIGlzIHJlamVjdGVkLiBJZiBNci4gRGVLb2sgYmVsaWV2ZXMgdGhhdCB0 aGlzIGRvZXMgbm90IHNhdGlzZnkgaGlzDQpjb25jZXJucywgd2UgcmVmZXIgaGltIHRvIFJGQyAy MDI2LCBTZWN0aW9uIDYuNSBmb3IgdGhlIG5leHQgc3RlcHMgaW4gdGhlDQphcHBlYWwgcHJvY2Vz cy4NCg0KU2NvdHQgQnJhZG5lcg0KV2FycmVuIEt1bWFyaQ0KMTIgRmVicnVhcnkgMjAxNg0KDQoN CuKAlC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUbzogb3BzYXdnQGlldGYub3JnPG1h aWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpYLU1zLUV4Y2hhbmdlLVRyYW5zcG9ydC1FbmR0b2VuZGxh dGVuY3k6IDAwOjAwOjAxLjgwOTM0NDUNClgtRm9yZWZyb250LUFudGlzcGFtLVJlcG9ydDogQ0lQ OjY3LjIzMS4xNTYuMjc7Q1RSWTpVUztJUFY6Q0FMO0lQVjpOTEk7RUZWOk5MSTtTRlY6U0tOO1NG Uzo7RElSOklOQjtTRlA6O1NDTDotMTtTUlZSOkNZMVBSMDcwMU1CMTA4MTtIOm14MGItMDAxNzEx MDEucHBob3N0ZWQuY29tPGh0dHA6Ly8wMDE3MTEwMS5wcGhvc3RlZC5jb20+O0ZQUjo7U1BGOk5v bmU7TEFORzplbjsNClNwYW1kaWFnbm9zdGljbWV0YWRhdGE6IDc0NjA5NjZiMmZkMjQ4NDY5ZGVh ZTAyY2I4ZjgyNzMwDQpYLU1zLUV4Y2hhbmdlLUNyb3NzdGVuYW50LUlkOiA2ZmZhMjJmNC00NTY4 LTQxMDUtYWQ0My0yZTNhZDQ3MjY5NTcNCkxpc3QtSWQ6IE9QU0EgV29ya2luZyBHcm91cCBNYWls IExpc3QgPG9wc2F3Zy5pZXRmLm9yZzxodHRwOi8vb3BzYXdnLmlldGYub3JnPj4NClgtRXhjaGFu Z2UtQW50aXNwYW0tUmVwb3J0LVRlc3Q6IFVyaVNjYW46KDk1NjkyNTM1NzM5MDE0KTsNCkFyY2hp dmVkLUF0OiA8aHR0cDovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29wc2F3Zy8xaEIz Tmt3MUtjc1N2ck5sT2NlbEdWMmRKZk0+DQpYLVZpcnVzLVNjYW5uZWQ6IGFtYXZpc2QtbmV3IGF0 IGFtc2wuY29tPGh0dHA6Ly9hbXNsLmNvbT4NClgtTXMtRXhjaGFuZ2UtT3JnYW5pemF0aW9uLUF1 dGhzb3VyY2U6IEJOMUJGRk8xMUZEMDUwLnByb3RlY3Rpb24uZ2JsDQpYLUdvb2dsZS1Ea2ltLVNp Z25hdHVyZTogdj0xOyBhPXJzYS1zaGEyNTY7IGM9cmVsYXhlZC9yZWxheGVkOyBkPTFlMTAwLm5l dDxodHRwOi8vMWUxMDAubmV0Pjsgcz0yMDEzMDgyMDsgaD14LWdtLW1lc3NhZ2Utc3RhdGU6bWlt ZS12ZXJzaW9uOnJlZmVyZW5jZXM6aW4tcmVwbHktdG86ZnJvbTpkYXRlIDptZXNzYWdlLWlkOnN1 YmplY3Q6dG86Y29udGVudC10eXBlOyBiaD1JVmd6blVBTjRkS1cxSzR1dEF1N2xBeUhpRUYyb2Vs cXdFdHljR0MrT0M0PTsgYj1Qc1BSa0xhQ3RBdVdjUTl1aDZsNHFBeXJJOGtvbzRhNWhiVGJpSitY QytGZlFmdnlGOHhUYWJpMmk0MXk0YXJRTUogWUNnMG8wSWd4VkdDY0NNYWVvY0hnN2psMjNyQmxj NVErU1NTUHlVTnlOQlM2cGxOOHVUWEdXcnVSNDg3TEZQRFVKL2YgUEVGa3lnYTNtU1BVL0xSM05x RkpkWncxdnhOdDBKWFFqWEh0N2NLZkRmREdzMUtEL3l6aUwzYUZXSldFRHBEM2lxQXMgMkV6NHoz YW5ta01WZ0xheFVUblFEZjlzZ1Bqd1lOVWxDUmJnZm9IU08vTDlrS1FwclZROWR1VVZkbjdBK0tt ekhXR0wgV0h0ckc4UXN5U2o4aGo1SjJZMU9KU0Z2eXozd0JFTEdnUVIvWGw0aEdpeW9HWmR3TDA2 Ukt2dU83RnFvRkhBL0txNU0gc0ZBZz09DQpYLU1zLUV4Y2hhbmdlLUNyb3NzdGVuYW50LU9yaWdp bmFsYXJyaXZhbHRpbWU6IDAxIERlYyAyMDE1IDAwOjE1OjA0LjUxNzAgKFVUQykNClgtUHJvb2Zw b2ludC1TcGFtLURldGFpbHM6IHJ1bGU9bm90c3BhbSBwb2xpY3k9ZGVmYXVsdCBzY29yZT0wIGtz Y29yZS5pczxodHRwOi8va3Njb3JlLmlzPl9idWxrc2NvcmU9MCBrc2NvcmUuY29tcG9zaXRlc2Nv cmU9MSBjb21wb3NpdGVzY29yZT0wLjkgc3VzcGVjdHNjb3JlPTIgbWFsd2FyZXNjb3JlPTAgcGhp c2hzY29yZT0wIGJ1bGtzY29yZT0wIGtzY29yZS5pczxodHRwOi8va3Njb3JlLmlzPl9zcGFtc2Nv cmU9MCByYnNzY29yZT0wLjkgc3BhbXNjb3JlPTAgdXJsc3VzcGVjdHNjb3JlPTAuOSBhZHVsdHNj b3JlPTAgY2xhc3NpZmllcj1zcGFtIGFkanVzdD0wIHJlYXNvbj1tbHggc2NhbmNvdW50PTEgZW5n aW5lPTguMC4xLTE1MDczMTAwMDAgZGVmaW5pdGlvbnM9bWFpbi0xNTEyMDEwMDAyDQpTZW5kZXI6 ICJPUFNBV0ciIDxvcHNhd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWJvdW5jZXNA aWV0Zi5vcmc+Pg0KTGlzdC1IZWxwOiA8bWFpbHRvOm9wc2F3Zy1yZXF1ZXN0QGlldGYub3JnP3N1 YmplY3Q9aGVscD4NClgtTXMtRXhjaGFuZ2UtT3JnYW5pemF0aW9uLU5ldHdvcmstTWVzc2FnZS1J ZDogZDU1NjE4ZjItNzQ3NS00NTMwLWM0NTYtMDhkMmY5ZTQ3NjYwDQpMaXN0LVBvc3Q6IDxtYWls dG86b3BzYXdnQGlldGYub3JnPg0KQXV0aGVudGljYXRpb24tUmVzdWx0czogc3BmPWZhaWwgKHNl bmRlciBJUCBpcyA2Ny4yMzEuMTU2LjI3KSBzbXRwLm1haWxmcm9tPWlldGYub3JnPGh0dHA6Ly9p ZXRmLm9yZz47IGhhcnZhcmQuZWR1PGh0dHA6Ly9oYXJ2YXJkLmVkdT47IGRraW09ZmFpbCAoYm9k eSBoYXNoIGRpZCBub3QgdmVyaWZ5KSBoZWFkZXIuZD1pZXRmLm9yZzxodHRwOi8vaWV0Zi5vcmc+ O2hhcnZhcmQuZWR1PGh0dHA6Ly9oYXJ2YXJkLmVkdT47IGRtYXJjPW5vbmUgYWN0aW9uPW5vbmUg aGVhZGVyLmZyb209a3VtYXJpLm5ldDxodHRwOi8va3VtYXJpLm5ldD47DQpTcGFtZGlhZ25vc3Rp Y291dHB1dDogMToyDQpYLUJlZW50aGVyZTogb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dA aWV0Zi5vcmc+DQpSZXR1cm4tUGF0aDogb3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9w c2F3Zy1ib3VuY2VzQGlldGYub3JnPg0KUmVmZXJlbmNlczogPDIwMTUxMDAyMTUyNTA1LjI2NTk0 Ljc0OTI1LmlkdHJhY2tlckBpZXRmYS5hbXNsLmNvbTxtYWlsdG86MjAxNTEwMDIxNTI1MDUuMjY1 OTQuNzQ5MjUuaWR0cmFja2VyQGlldGZhLmFtc2wuY29tPj4gPEQyMzc0NTVGLkJDMDBGJWRjbWdh c2hAY2lzY28uY29tPG1haWx0bzpkY21nYXNoQGNpc2NvLmNvbT4+IDxDQUh3OV9pS09NNU4zLUhT M1pPRkZhREhZVFY3ckRhZjNZSG8tZEVtZFRVOS00VzQ5YXdAbWFpbC5nbWFpbC5jb208bWFpbHRv OkNBSHc5X2lLT001TjMtSFMzWk9GRmFESFlUVjdyRGFmM1lIby1kRW1kVFU5LTRXNDlhd0BtYWls LmdtYWlsLmNvbT4+DQpEa2ltLVNpZ25hdHVyZTogdj0xOyBhPXJzYS1zaGEyNTY7IGM9cmVsYXhl ZC9zaW1wbGU7IGQ9aWV0Zi5vcmc8aHR0cDovL2lldGYub3JnPjsgcz1pZXRmMTsgdD0xNDQ4OTI4 OTAxOyBiaD1wdnQxa1NWWHVFcnRmVTVaV0lTUWlrTVJQUVlmRHAwNW1HTVlzYitTRmNJPTsgaD1N SU1FLVZlcnNpb246UmVmZXJlbmNlczpJbi1SZXBseS1UbzpGcm9tOkRhdGU6TWVzc2FnZS1JRDpU bzogU3ViamVjdDpMaXN0LUlkOkxpc3QtVW5zdWJzY3JpYmU6TGlzdC1BcmNoaXZlOkxpc3QtUG9z dDpMaXN0LUhlbHA6IExpc3QtU3Vic2NyaWJlOkNvbnRlbnQtVHlwZTpTZW5kZXI7IGI9WlJ3ZU83 VHAzWHEvdjdNd3RRWTdCcTZKYnA1dFUrMisrK0YwZEVRQUxQRVZYVGJRKytoNDVKenhMWnlFUzhp a0kgb2s2aWJGQ1IwTWt3MVAxTzZFUU0zdEl3UWxMRDZYbDFLbnNEbjc0YVVVRDZSdlErZEQ1UDBn Y3RybjFTdUdpUThUIGpZNVJENUIxWUU3Z3B2eU1vRVlvRHZlM0dpRG9sV3V1eWNsUUZka289DQpE a2ltLVNpZ25hdHVyZTogdj0xOyBhPXJzYS1zaGEyNTY7IGM9cmVsYXhlZC9yZWxheGVkOyBkPWt1 bWFyaS1uZXQuMjAxNTA2MjMuZ2FwcHNzbXRwLmNvbTxodHRwOi8va3VtYXJpLW5ldC4yMDE1MDYy My5nYXBwc3NtdHAuY29tPjsgcz0yMDE1MDYyMzsgaD1taW1lLXZlcnNpb246cmVmZXJlbmNlczpp bi1yZXBseS10bzpmcm9tOmRhdGU6bWVzc2FnZS1pZDpzdWJqZWN0OnRvIDpjb250ZW50LXR5cGU7 IGJoPUlWZ3puVUFONGRLVzFLNHV0QXU3bEF5SGlFRjJvZWxxd0V0eWNHQytPQzQ9OyBiPXRSbThN VEhOclZNTHdpUXJIZDdYTXRlVDJraHoxTEN2bFNyS1FIazNFTEM1Q0NPVUt5YmZKVUNVd1Z3eGly RXFuWCBmUnBxaXdPNXBSUHZTcitIeXZuRWY3ZTBSRHBteFdud25lN0gzNU54a21NSHBieFZRUCtX MTVzQi9OQmNHa2hwVGMvSiB3Uy90VEd3eHhPZW1weHBYQ2tWd0daMDhRWHJmTXRDazZCa3pZV0dX aEFocHdtVk8rSkNwZ2x2YVpYZTRrSDdiaGg1ZyBoT0FaSldwL3VTek8vbDFGbTI3eGd0NTd2ZVQx THlab0l3UXBjQ1JoemFBL2pLT25maVV0MGk0azA3bWMxNlU1TFdvUyB4NE9hMjdWbUhxMXN6TkFV NmhJd0NxVkpiZ2FjdUNCLyt2ak5NMlN5T0x1U0JjdFdISjVsZFRZNjYyWERrZUJsN2tOdSBZRUFn PT0NClgtTWF0Y2hpbmctQ29ubmVjdG9yczogMTMwOTM0MDI1MDQ2NzMwMTY1OyhkOTNkMDE4MC0y MjdlLTQ1N2MtNDQ5OS0wOGQyZWFlYzk3MDMsMjU2YjJmMTItNGVkZi00YmJhLWNhOGEtMDhkMTc2 NmE3NjdmLDRjMmZiODgxLWZkNjAtNDdjNC0yN2RlLTA4ZDFhOTQ2NGFhZixkOGJiYmYwZC04ZTE5 LTQyNzItOTM0NS0wOGQxYjY1Y2I3OTMsNzUxYjRlOWUtZDRmYi00NGJmLWExMzEtMDhkMWRjOTgy M2U0LGUwMDY4ZWJmLTAxNGItNGM3My03OTNhLTA4ZDJmMWRjYzc0MyxhYzAxY2YwYy1lOTY3LTQ5 NWMtM2ZhOS0wOGQxZTcwMTQxY2QsMjgwOGYxYzItMmMyZi00ODNlLTNkODAtMDhkMWRmYjJmZTk5 LGY5ZTg5OWJiLTFjYzItNDFkYi01ZmEwLTA4ZDA3MWExYTc2ZSwzZGZhMDY1ZC02ZDA5LTQxZTQt MDNkNi0wOGQxOTk5NDM0ZTEsOGY3MmYzNDktZWFjNy00Y2EyLTU5MDktMDhkMWY0ZDZiZDhmKTso ZmM0MGI3YjMtOWQ5Mi00YmFkLTUxMWItMDhkMTQyOTY3MWYwLGYwNDRhNmQ3LTk4YjktNGMxMC05 MWI0LTA4ZDIxMDQxM2ZlOSwyN2JkMmRiYS1lOGMxLTRmNjEtNWJjYi0wOGQyZTYzYTFmMjQsNjQz N2QyYTUtNzgzMC00ODdhLWI2MTMtMDhkMmQ1YTBkMzU0LGQzODA2MjMyLTVkMTMtNDE0OS0yOGZm LTA4ZDFkZWM2MDQ3MyxkYmMwMGQzZi1jZjM5LTRkNzMtZmQzNC0wOGQxYmEyNTIxMzgsOWFkYjI4 MGYtNGZiZS00OWFiLTE3YWQtMDhkMGM4YjFmZWIyLDcwZmI0MmExLTk2ODgtNDFiNi1kODEwLTA4 ZDFiMDdiNDkyNCkNCkVycm9ycy1Ubzogb3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9w c2F3Zy1ib3VuY2VzQGlldGYub3JnPg0KUmVjZWl2ZWQtU3BmOiBGYWlsIChwcm90ZWN0aW9uLm91 dGxvb2suY29tPGh0dHA6Ly9wcm90ZWN0aW9uLm91dGxvb2suY29tPjogZG9tYWluIG9mIGlldGYu b3JnPGh0dHA6Ly9pZXRmLm9yZz4gZG9lcyBub3QgZGVzaWduYXRlIDY3LjIzMS4xNTYuMjcgYXMg cGVybWl0dGVkIHNlbmRlcikgcmVjZWl2ZXI9cHJvdGVjdGlvbi5vdXRsb29rLmNvbTxodHRwOi8v cHJvdGVjdGlvbi5vdXRsb29rLmNvbT47IGNsaWVudC1pcD02Ny4yMzEuMTU2LjI3OyBoZWxvPW14 MGItMDAxNzExMDEucHBob3N0ZWQuY29tPGh0dHA6Ly9teDBiLTAwMTcxMTAxLnBwaG9zdGVkLmNv bT47DQpYLU1pY3Jvc29mdC1FeGNoYW5nZS1EaWFnbm9zdGljczogMTtCTjFCRkZPMTFGRDA1MDsx OjdaTjlZSzd4REYvWU9GcWdTRi9LdDdTRXVSbDZtODJURUVGUzVwamowTDlXWjJYc2pzb0swNlJI UW9xcDB6WkpPcXpITHNLN3A2MnNSQy8rZGwwTkhld254V0hqbFlrRmxFck8wUXhQdTNia01NTVdG REwwRDFnTmtOTkFMUU1FY0NFd01OMUUrc0hmdldxZlNodE9wUGJzZVdBSVUwd0ZiZitUSE5Bc1ow cG9VcXl3VlBJZUpSVEoyN0tock16ZHZmQ0JkSWg4SXZaNVVGK2k1LzMwTHd1OTBUd2hIQnlkUWo5 aW1wSFhoSnp6NmNjaHd5QytjWkJ5SGR4Ymhia2lrYUZVMk9SZjl4d0J4L2R3QTZhY25JWXVyY1p4 WEU2ckk0bmw2WisxajJwVG1UUm92L3UrNjk2NUduNDdrVjFxU2ptZWVXUXExK0pzcWcwblFQMExx dldYNkN5Z2Q0L0tnY1lFeGlzaEU3bml2S1ZacTcycjRsSmIrMGVhTXN3VC82M0dwZmlUcVZ4MjEr VUJ4M05Ldk11bFFTcUc5R2l6azZhQm5zLzNCSnJSbVlpMGo1aUdyK2RmYngwTHltemRPZE9GVWZt Z1RJWUdKR2hqTzcwMSthTG5RSEQ3VnJCMUZCRDJXNy96SmlXbkpyNXJ4SE5lMHVQMjhKVW5iNis1 bHIvZmV3R0VaWjRqSW1RK1JiZlpidz09DQpYLU1pY3Jvc29mdC1FeGNoYW5nZS1EaWFnbm9zdGlj czogMTtDWTFQUjA3MDFNQjEwODE7MjpXMWkwdDRQR0hwV1pwWkduMGd3cWNjYU9WdjJ1NDlua0ZT b2YzSkJsclF1UUp3Y0tsOVkyd0RlVmw1QTlpRXJ6cU9KSXRUeVB6aXFmQXQ3S3lHRWF4OXJNOTV0 aUt0amN4Z3p3empRamlxUUZwR2dUSEYxUS9tWSt3MW9nNkdFUWdTNFhnTURsaklBdW13NHRTcGlR TEE9PTszOkJLUmJQbVJNNXErNHBySGJNTWwxcGwxWloydFMwclZHaXc3YUVIMUNxN0hQVk54YVlk aUpPUGM0L0JKWXZvZFZZMXZicjY3cXd3QVRJRHRYZlZpZTlkYjJSakJEanhRV1BSWTV6WHdsbkk1 ODJKdnZTZDN1eEFJMVlaekFGZ2NXa3Q3c0NHMlp1RDJOeW05dkJ4dkhsN1dENXNVZHgydHI4aXpM Qzg2ZE11Z01ERzBJeWh6UEZFZnI5QjBtc3dyclh0RDNYUGprb0NpL05BQy9paHNEeVY0TG9NMy9L ZDRoZTJBYXlUTnJ4cTcraXRCbWV2K1JJNm04NGlSUnpJeHVLL1FiZDV2Q2ZTYklzckNrbWN4cVZs Z3pYa014clVhenVoZVRRRHNHTTBnSzJNYVphTVRCaGRrKzhLeUQ0dTJiOzI1Ojc4TUl0aTJZTHY5 aTAzOEtVVGZTdnNwWEhGUzFKdEpZUWdXVXl6eW9pQjRiM00rc3pKeWloKzU4ejgxYVV2WXJOVG1a Q1lXeGVOYkp4T3FjU0VuRkQvdEZMRjdsRW9kMnY4RGh6TnhBZFhmSmxBY3YvMzVBcVU5OWl3TDBN emRlaUdkVjBoV0lmSW9WR0VNNnJuMTJJbm1OTlo1K0g0bUZzcFpscEZKQm1DOTl5bFlIaG5ZZVJU dnBDamhFMjZEOXJ5ODVVcTh2TlE3VDd2RzFxV1Q4c0I4WllGUmdkbm1PWmxFWmlEcm1PTWxGSWMr NGh0c2VtS1J1ZmdmY1pHaENhWk0yMThQd1BrOVlxcnJLYURBUE5nPT0NClgtTWljcm9zb2Z0LUV4 Y2hhbmdlLURpYWdub3N0aWNzOiAxO0NZMVBSMDcwMU1CMTA4MTsyMDpQZEx1Q0N5aUNGc2hXME5k UG5DOGVCb2poTnZtUFRzSHYvNFVGbnEyL0FwMTNDaFlvekdjZEVxa1ZVb0NEZ1Y2eENuYlYyc2No ODRHOVlxY2lDckFxcEJPQytQK0phZGIveFdvc3FpcERqQ3paelFCMzhhaDNWKzRCZG5ibTM3YVdz NTI3UVRkRlg3NG8zMTlya1JrcGZRVzVsWkJVRS8rYWthTGszaVBPU0RHa2xMT2NNTXprNUU2TVVr ZzFGQ3hlVFNDUmJFSkk3QzhHY2ZrcDRaMzNzV3daNGw0blpzVHJ5UWpGTndVbktEMzVLM3ZWWENT VFVyOW1IRWVkODZCOzQ6WmtkWVAwYityZUFBdGNTUFIvczZncy80eHRsMkJkdVFxY3V4TVdoblBB cmpGc3lJN0Q4cXhoSnplZ0xKSW1tSXVyd3ZHTnVBdVBBRUJWbnpmS2s3VWs4S21YdXJ6NVZyTldX WHo5SDlrWDVJMmlTb1k4MmhiT0dxcHhvS1pON1p2VDRlTm5rZnRmd0VCQmI2Y0pXYkxYMndKcjFH aFpRU3RLSGhuS09YQ3RuV1RHMWJDT3NBbFVGek80ZmNRcksxODcxem1KWWNWTEZlWHMyc294cTZ6 UlZpZG5VVng1YVZjejFmYlVXMXBZWWk3U1ZUbUtVeEhnREhwQmxoRTJNN0lzUUNmMi96OGpzcHdI UjIvQ2E0UXdmVHNCT3dyemxCZUhyeWp4akd3RExhaDBTcTVXOWZ5NWRvWExXajZacDVIZCs3OEFu UUtRalRMSm9KemV5cE84SlZ0eWVYcXYweS9VcFBqWEVOcGhiQzY3NGNSUUV5RWhveUxPV3lwdUpl VVA5WHVrSU5BVHZWRWRnSm5DSGVwa0pTT0hTWlFlYTl6R0tuVEhhellqb0c3OWVLMWxzTGd4MlVl cnNteHR3ejsyMzo0RUtwRVIvV2V4N2w3eUpqTnU2TkNmL09MOEdVdkZjVGZIMDNWNmYxa3l2QUQr MWkzck1oTUlNVVRhUzVSdUZWRUJJVCsxaFYyWWVtbk50TkNlamJRc3NjSks0N012cllmZnUxWTRG V3lzWkh3bXVXNVo4WVkxOVo1NWdnL2JCamdlSHd1Yy9FQ2lHK0c1NG1aR0t0ZGt1TjFmNlhra0pS bGs5YjVtaUVlTVl5ZVNhL0RlRWkrMVgrLzY5QlRhSGhWbWRzT25FSWlYT0Vtd0ttVVJCVWJBPT0N ClgtTWljcm9zb2Z0LUV4Y2hhbmdlLURpYWdub3N0aWNzOiAxO0NZMVBSMDcwMU1CMTA4MTs1Ok5E bVNVTmtGWmlqQndQZkVDSU4zOS9uS0w5U1pwWlFvWGY4M0RkWWRHNmM2dXF2S3E5cEZMMTF6Q0ls dUdCZmJmcjdqOEdIV29IakNGcGJ4N1ZZRzErcEpXc2J3M3VLbXgxMndvTXB4VlUyb2F4b1Y4VGI0 NHYwem9hQjFPMkZoRTlzWmJjcDVFK2srVkZwalQ3bXhJUT09OzI0Om9SWFFjd0VXeFBDdXFuNVVB ek5VcTZBQnV1dlFZTElzdTVJYnRLeVQ4SThzZWxXZmZZdm5FWmdYRjZjT1JOWnFTN0IyeHlETHk1 Rmp6bWNtRVZMSVhPeU9pWHVISTFRV0R1YWdabnJ5QXdzPQ0KSW4tUmVwbHktVG86IDxDQUh3OV9p S09NNU4zLUhTM1pPRkZhREhZVFY3ckRhZjNZSG8tZEVtZFRVOS00VzQ5YXdAbWFpbC5nbWFpbC5j b208bWFpbHRvOkNBSHc5X2lLT001TjMtSFMzWk9GRmFESFlUVjdyRGFmM1lIby1kRW1kVFU5LTRX NDlhd0BtYWlsLmdtYWlsLmNvbT4+DQpYLURraW1yZXN1bHQtVGVzdDogRmFpbGVkDQpYLUdtLU1l c3NhZ2UtU3RhdGU6IEFMb0NvUWtQTE5nT010NEZNT0NXQUtsMk1MWURTWlJ1Ti9Vb0JqQlNHMFZS b3IyUys1RkVKT0pvZExOLzZyOWdFWlUwRHBETTd4WWENCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0 L21peGVkOyBib3VuZGFyeT0iPT09PT09PT09PT09PT09ODA4Nzc2NzQzNTM2MTg2NjY1MD09Ig0K WC1PcmlnaW5hbC1Ubzogb3BzYXdnQGlldGZhLmFtc2wuY29tPG1haWx0bzpvcHNhd2dAaWV0ZmEu YW1zbC5jb20+DQpYLUV4Y2hhbmdlLUFudGlzcGFtLVJlcG9ydC1DZmEtVGVzdDogQkNMOjc7UENM OjA7UlVMRUlEOig2MDEwMDQpKDc2MzAwNDYpKDI0MDEwNDcpKDUyMDA3OCkoODEyMTUwMTA0Niko NzYzMTA0NikoMzAwMjAwMSkoMTAyMDE1MDEwNDYpO1NSVlI6Q1kxUFIwNzAxTUIxMDgxO0JDTDo3 O1BDTDowO1JVTEVJRDo7U1JWUjpDWTFQUjA3MDFNQjEwODE7DQpYLU1zLUV4Y2hhbmdlLVRyYW5z cG9ydC1Dcm9zc3RlbmFudGhlYWRlcnNzdGFtcGVkOiBDWTFQUjA3MDFNQjEwODENClgtTXMtRXhj aGFuZ2UtT3JnYW5pemF0aW9uLUF1dGhhczogQW5vbnltb3VzDQpYLU1zLUV4Y2hhbmdlLU9yZ2Fu aXphdGlvbi1BdnN0YW1wLVNlcnZpY2U6IDEuMA0KWC1TcGFtLUZsYWc6IE5PDQpYLU1haWxtYW4t VmVyc2lvbjogMi4xLjE1DQpMaXN0LUFyY2hpdmU6IDxodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvYnJvd3NlL29wc2F3Zy8+DQpMaXN0LVVuc3Vic2NyaWJlOiA8aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9vcHRpb25zL29wc2F3Zz4sIDxtYWlsdG86b3BzYXdnLXJlcXVlc3RA aWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZT4NClByZWNlZGVuY2U6IGxpc3QNCkRlbGl2ZXJl ZC1Ubzogb3BzYXdnQGlldGZhLmFtc2wuY29tPG1haWx0bzpvcHNhd2dAaWV0ZmEuYW1zbC5jb20+ DQpYLVByb29mcG9pbnQtVmlydXMtVmVyc2lvbjogdmVuZG9yPWZzZWN1cmUgZW5naW5lPTIuNTAu MTA0MzI6LCwgZGVmaW5pdGlvbnM9MjAxNS0xMS0zMF8wOTosLCBzaWduYXR1cmVzPTANClgtU3Bh bS1MZXZlbDoNClgtTXMtRXhjaGFuZ2UtQ3Jvc3N0ZW5hbnQtRnJvbWVudGl0eWhlYWRlcjogSW50 ZXJuZXQNClgtTWljcm9zb2Z0LUFudGlzcGFtOiBVcmlTY2FuOjtCQ0w6NztQQ0w6MDtSVUxFSUQ6 KDQyMTI1MjAwMSkoMzAwMjAxNSkoNzE3MDEwMDMpKDcxNzAyMDAxKTtTUlZSOkNZMVBSMDcwMU1C MTA4MTsNClgtRW9wYXR0cmlidXRlZG1lc3NhZ2U6IDANClJlY2VpdmVkOiBmcm9tIENZMVBSMDcw MU1CMTA4MS5uYW1wcmQwNy5wcm9kLm91dGxvb2suY29tPGh0dHA6Ly9jeTFwcjA3MDFtYjEwODEu bmFtcHJkMDcucHJvZC5vdXRsb29rLmNvbT4gKDEwLjE2MC4xNDUuMTUzKSBieSBDWTFQUjA3MDFN QjEwODIubmFtcHJkMDcucHJvZC5vdXRsb29rLmNvbTxodHRwOi8vY3kxcHIwNzAxbWIxMDgyLm5h bXByZDA3LnByb2Qub3V0bG9vay5jb20+ICgxMC4xNjAuMTQ1LjE1NCkgd2l0aCBNaWNyb3NvZnQg U01UUCBTZXJ2ZXIgKFRMUykgaWQgMTUuMS4zMzEuMjAgdmlhIE1haWxib3ggVHJhbnNwb3J0OyBU dWUsIDEgRGVjIDIwMTUgMDA6MTU6MDYgKzAwMDANClJlY2VpdmVkOiBmcm9tIEJZMlBSMDdDQTA1 NC5uYW1wcmQwNy5wcm9kLm91dGxvb2suY29tPGh0dHA6Ly9ieTJwcjA3Y2EwNTQubmFtcHJkMDcu cHJvZC5vdXRsb29rLmNvbT4gKDEwLjE0MS4yNTEuMjkpIGJ5IENZMVBSMDcwMU1CMTA4MS5uYW1w cmQwNy5wcm9kLm91dGxvb2suY29tPGh0dHA6Ly9jeTFwcjA3MDFtYjEwODEubmFtcHJkMDcucHJv ZC5vdXRsb29rLmNvbT4gKDEwLjE2MC4xNDUuMTUzKSB3aXRoIE1pY3Jvc29mdCBTTVRQIFNlcnZl ciAoVExTKSBpZCAxNS4xLjMzMS4yMDsgVHVlLCAxIERlYyAyMDE1IDAwOjE1OjA1ICswMDAwDQpS ZWNlaXZlZDogZnJvbSBCTjFCRkZPMTFGRDA1MC5wcm90ZWN0aW9uLmdibCAoMmEwMToxMTE6ZjQw MDo3YzEwOjoxOjE3MSkgYnkgQlkyUFIwN0NBMDU0Lm91dGxvb2sub2ZmaWNlMzY1LmNvbTxodHRw Oi8vYnkycHIwN2NhMDU0Lm91dGxvb2sub2ZmaWNlMzY1LmNvbT4gKDJhMDE6MTExOmU0MDA6MmM2 MTo6MjkpIHdpdGggTWljcm9zb2Z0IFNNVFAgU2VydmVyIChUTFMpIGlkIDE1LjEuMzMxLjIwIHZp YSBGcm9udGVuZCBUcmFuc3BvcnQ7IFR1ZSwgMSBEZWMgMjAxNSAwMDoxNTowNCArMDAwMA0KUmVj ZWl2ZWQ6IGZyb20gbXgwYi0wMDE3MTEwMS5wcGhvc3RlZC5jb208aHR0cDovL214MGItMDAxNzEx MDEucHBob3N0ZWQuY29tPiAoNjcuMjMxLjE1Ni4yNykgYnkgQk4xQkZGTzExRkQwNTAubWFpbC5w cm90ZWN0aW9uLm91dGxvb2suY29tPGh0dHA6Ly9ibjFiZmZvMTFmZDA1MC5tYWlsLnByb3RlY3Rp b24ub3V0bG9vay5jb20+ICgxMC41OC4xNDUuNSkgd2l0aCBNaWNyb3NvZnQgU01UUCBTZXJ2ZXIg KFRMUykgaWQgMTUuMS4zMzEuMTEgdmlhIEZyb250ZW5kIFRyYW5zcG9ydDsgVHVlLCAxIERlYyAy MDE1IDAwOjE1OjA0ICswMDAwDQpSZWNlaXZlZDogZnJvbSBwcHMuZmlsdGVyZCAobTAwNDQ5MDUu cHBvcHMubmV0PGh0dHA6Ly9tMDA0NDkwNS5wcG9wcy5uZXQ+IFsxMjcuMC4wLjFdKSBieSBteDBi LTAwMTcxMTAxLnBwaG9zdGVkLmNvbTxodHRwOi8vbXgwYi0wMDE3MTEwMS5wcGhvc3RlZC5jb20+ ICg4LjE1LjAuNTkvOC4xNS4wLjU5KSB3aXRoIFNNVFAgaWQgdEIxMEJSVUkwMjIzMjggZm9yIDxz b2JAaGFydmFyZC5lZHU8bWFpbHRvOnNvYkBoYXJ2YXJkLmVkdT4+OyBNb24sIDMwIE5vdiAyMDE1 IDE5OjE1OjA0IC0wNTAwDQpSZWNlaXZlZDogZnJvbSBtYWlsLmlldGYub3JnPGh0dHA6Ly9tYWls LmlldGYub3JnPiAobWFpbC5pZXRmLm9yZzxodHRwOi8vbWFpbC5pZXRmLm9yZz4gWzQuMzEuMTk4 LjQ0XSkgYnkgbXgwYi0wMDE3MTEwMS5wcGhvc3RlZC5jb208aHR0cDovL214MGItMDAxNzExMDEu cHBob3N0ZWQuY29tPiB3aXRoIEVTTVRQIGlkIDF5ZjhraDk3czAtMSAodmVyc2lvbj1UTFN2MS9T U0x2MyBjaXBoZXI9RUNESEUtUlNBLUFFUzI1Ni1HQ00tU0hBMzg0IGJpdHM9MjU2IHZlcmlmeT1O T1QpIGZvciA8c29iQGhhcnZhcmQuZWR1PG1haWx0bzpzb2JAaGFydmFyZC5lZHU+PjsgTW9uLCAz MCBOb3YgMjAxNSAxOToxNTowMyAtMDUwMA0KUmVjZWl2ZWQ6IGZyb20gaWV0ZmEuYW1zbC5jb208 aHR0cDovL2lldGZhLmFtc2wuY29tPiAobG9jYWxob3N0IFtJUHY2Ojo6MV0pIGJ5IGlldGZhLmFt c2wuY29tPGh0dHA6Ly9pZXRmYS5hbXNsLmNvbT4gKFBvc3RmaXgpIHdpdGggRVNNVFAgaWQgN0I1 MEYxQjJBRjI7IE1vbiwgMzAgTm92IDIwMTUgMTY6MTU6MDEgLTA4MDAgKFBTVCkNClJlY2VpdmVk OiBmcm9tIGxvY2FsaG9zdCAoaWV0ZmEuYW1zbC5jb208aHR0cDovL2lldGZhLmFtc2wuY29tPiBb MTI3LjAuMC4xXSkgYnkgaWV0ZmEuYW1zbC5jb208aHR0cDovL2lldGZhLmFtc2wuY29tPiAoUG9z dGZpeCkgd2l0aCBFU01UUCBpZCBFMzBCODFCMzNCMSBmb3IgPG9wc2F3Z0BpZXRmYS5hbXNsLmNv bTxtYWlsdG86b3BzYXdnQGlldGZhLmFtc2wuY29tPj47IE1vbiwgMzAgTm92IDIwMTUgMTY6MTU6 MDAgLTA4MDAgKFBTVCkNClJlY2VpdmVkOiBmcm9tIG1haWwuaWV0Zi5vcmc8aHR0cDovL21haWwu aWV0Zi5vcmc+IChbNC4zMS4xOTguNDRdKSBieSBsb2NhbGhvc3QgKGlldGZhLmFtc2wuY29tPGh0 dHA6Ly9pZXRmYS5hbXNsLmNvbT4gWzEyNy4wLjAuMV0pIChhbWF2aXNkLW5ldywgcG9ydCAxMDAy NCkgd2l0aCBFU01UUCBpZCBQQUtVTzdtNnB1N0IgZm9yIDxvcHNhd2dAaWV0ZmEuYW1zbC5jb208 bWFpbHRvOm9wc2F3Z0BpZXRmYS5hbXNsLmNvbT4+OyBNb24sIDMwIE5vdiAyMDE1IDE2OjE0OjU5 IC0wODAwIChQU1QpDQpSZWNlaXZlZDogZnJvbSBtYWlsLXlrMC14MjJjLmdvb2dsZS5jb208aHR0 cDovL21haWwteWswLXgyMmMuZ29vZ2xlLmNvbT4gKG1haWwteWswLXgyMmMuZ29vZ2xlLmNvbTxo dHRwOi8vbWFpbC15azAteDIyYy5nb29nbGUuY29tPiBbSVB2NjoyNjA3OmY4YjA6NDAwMjpjMDc6 OjIyY10pICh1c2luZyBUTFN2MS4yIHdpdGggY2lwaGVyIEVDREhFLVJTQS1BRVMxMjgtR0NNLVNI QTI1NiAoMTI4LzEyOCBiaXRzKSkgKE5vIGNsaWVudCBjZXJ0aWZpY2F0ZSByZXF1ZXN0ZWQpIGJ5 IGlldGZhLmFtc2wuY29tPGh0dHA6Ly9pZXRmYS5hbXNsLmNvbT4gKFBvc3RmaXgpIHdpdGggRVNN VFBTIGlkIEYxNzBEMUIyQUYyIGZvciA8b3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0 Zi5vcmc+PjsgTW9uLCAzMCBOb3YgMjAxNSAxNjoxNDo1OCAtMDgwMCAoUFNUKQ0KUmVjZWl2ZWQ6 IGJ5IHlrZHI4MiB3aXRoIFNNVFAgaWQgcjgyc28yMDQ5NzgwMTV5a2QuMyBmb3IgPG9wc2F3Z0Bp ZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPj47IE1vbiwgMzAgTm92IDIwMTUgMTY6MTQ6 NTggLTA4MDAgKFBTVCkNClgtU3BhbS1TdGF0dXM6IE5vLCBzY29yZT0tMS4yNzcgdGFnZ2VkX2Fi b3ZlPS05OTkgcmVxdWlyZWQ9NSB0ZXN0cz1bQkFZRVNfMDA9LTEuOSwgREtJTV9TSUdORUQ9MC4x LCBES0lNX1ZBTElEPS0wLjEsIEZNX0ZPUkdFRF9HTUFJTD0wLjYyMiwgSFRNTF9NRVNTQUdFPTAu MDAxXSBhdXRvbGVhcm49bm8NClgtTXMtRXhjaGFuZ2UtT3JnYW5pemF0aW9uLU1lc3NhZ2VkaXJl Y3Rpb25hbGl0eTogSW5jb21pbmcNClgtTXMtRXhjaGFuZ2UtT3JnYW5pemF0aW9uLVNjbDogLTEN ClgtUmVjZWl2ZWQ6IGJ5IDEwLjEyOS45My4xMzMgd2l0aCBTTVRQIGlkIHIxMjdtcjU0OTYyNTAx eXdiLjEwOS4xNDQ4OTI4ODk4MTE2OyAgTW9uLCAzMCBOb3YgMjAxNSAxNjoxNDo1OCAtMDgwMCAo UFNUKQ0KTWVzc2FnZS1JZDogPENBSHc5X2lLZWJIaG5FMHdTckFWR3l6OHNWSFg3Z01vUEZ5K3Jr cjVTb1d5QXFFZnhGUUBtYWlsLmdtYWlsLmNvbTxtYWlsdG86Q0FIdzlfaUtlYkhobkUwd1NyQVZH eXo4c1ZIWDdnTW9QRnkrcmtyNVNvV3lBcUVmeEZRQG1haWwuZ21haWwuY29tPj4NCk1pbWUtVmVy c2lvbjogMS4wDQpYLVNwYW0tU2NvcmU6IC0xLjI3Nw0KTGlzdC1TdWJzY3JpYmU6IDxodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zz4sIDxtYWlsdG86b3BzYXdnLXJl cXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+DQpSZTogW09QU0FXR10gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGFobS1vcHNhd2ctdGFjYWNzLTAxLnR4dA0K DQpEZWFyIE9wc0FXRywNCg0KVGhlIGNoYWlycyBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgc3VmZmlj aWVudCBpbnRlcmVzdCBhbmQgc3VwcG9ydCB0byBhZG9wdCB0aGlzIGRvY3VtZW50IGFzIGFuIE9w c0FXRyBkb2N1bWVudC4NCg0KQXV0aG9ycywgcGxlYXNlIHJlc3VibWl0IGFzIGRyYWZ0LWlldGYt b3BzYXdnLXRhY2Fjcy0wMQ0KDQpXb3JraW5nIGdyb3VwOg0KV2Ugd291bGQgbGlrZSB0byBzZWUg dGhpcyBkb2N1bWVudCBwcm9ncmVzcywgYW5kIGFyZSBob3BpbmcgdG8gV0dMQyBpdCBzb29uLiBQ bGVhc2UgcmV2aWV3IHRoaXMgYW5kIHByb3ZpZGUgZmVlZGJhY2suLi4uDQoNClcNCg0KT24gRnJp LCBOb3YgMTMsIDIwMTUgYXQgMTozNyBQTSBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3VtYXJpLm5l dDxtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQ+PiB3cm90ZToNCldlIHdvdWxkIHJlYWxseSBhcHBy ZWNpYXRlIGFueSBmZWVkYmFjayBvbiB0aGlzIGRvY3VtZW50LiBQZXJzb25hbGx5IEkNCnRoaW5r IGl0IGlzIHJlYWxseSB1c2VmdWwsIGJ1dCB3ZSBuZWVkIHRoZSBXRyB0byByZXZpZXcgYW5kIHBy b3ZpZGUNCmZlZWRiYWNrLg0KDQpPdmVyIHRoZSB5ZWFycyBJJ3ZlIGhlYXJkIGEgbnVtYmVyIG9m IHBlb3BsZSBrdmV0Y2ggdGhhdCBUQUNBQ1MrIGlzbid0DQpkb2N1bWVudGVkIC0tIHdlbGwsIG5v dyB5b3UgY2FuLCB5b3Uga25vdywgYWN0dWFsbHkgZG8gc29tZXRoaW5nIGFib3V0DQp0aGlzLi4u DQoNClcNCg0KT24gU3VuLCBPY3QgNCwgMjAxNSBhdCA0OjE4IFBNLCBEb3VnbGFzIEdhc2ggKGRj bWdhc2gpDQo8ZGNtZ2FzaEBjaXNjby5jb208bWFpbHRvOmRjbWdhc2hAY2lzY28uY29tPj4gd3Jv dGU6DQo+IERlYXIgT3BzYXdnIExpc3QsDQo+DQo+IFdlIGhhdmUgdXBsb2FkZWQgYSBzZWNvbmQg cmV2aXNpb24gb2YgdGhlIFRBQ0FDUysgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbg0KPiB3aGljaCB3 ZSBiZWxpZXZlIGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBzdWJqZWN0IHN1YmplY3QgdG8gcG9y dA0KPiBhbGxvY2F0aW9uLg0KPg0KPiBQbGVhc2Ugc2VlIGRldGFpbHMgYmVsb3cuDQo+DQo+IFRo ZSBlc3NlbnRpYWwgZGlmZmVyZW5jZSBmcm9tIHRoZSBmaXJzdCByZXZpc2lvbiBpcyB0aGUgY2hh bmdlIG9mIFRMUw0KPiBvcHRpb24gc3VwcG9ydCB1c2luZyBhIHNlcGFyYXRlIHBvcnQgYXMgb3Bw b3NlZCB0byB0aGUgb3JpZ2luYWwgU3RhcnQgVExTDQo+IG1lY2hhbmlzbS4NCj4NCj4gV2Ugd291 bGQgYmUgdmVyeSBncmF0ZWZ1bCBmb3IgdGhlIG9waW5pb24gb2YgdGhlIGxpc3QgcmVnYXJkaW5n IHRoZQ0KPiBzdWl0YWJpbGl0eSBvZiBkb2N1bWVudCBmb3IgcHVibGljYXRpb24gYXMgYW4gUkZD Lg0KPg0KPiBNYW55IHRoYW5rcywNCj4NCj4gVGhvcnN0ZW4sIEFuZHJlaiwgRG91Zy4NCj4NCj4N Cj4gT24gMDIvMTAvMjAxNSAxNjoyNSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCj4gd3JvdGU6DQo+DQo+Pg0KPj5BIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGFobS1vcHNhd2ctdGFjYWNzLTAxLnR4dA0KPj5oYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERvdWdsYXMgQy4gTWVkd2F5IEdhc2ggYW5kIHBv c3RlZCB0bw0KPj50aGUNCj4+SUVURiByZXBvc2l0b3J5Lg0KPj4NCj4+TmFtZTogICAgICAgICAg ZHJhZnQtZGFobS1vcHNhd2ctdGFjYWNzDQo+PlJldmlzaW9uOiAgICAgIDAxDQo+PlRpdGxlOiAg ICAgICAgIFRoZSBUQUNBQ1MrIFByb3RvY29sDQo+PkRvY3VtZW50IGRhdGU6IDIwMTUtMTAtMDIN Cj4+R3JvdXA6ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+PlBhZ2VzOiAgICAgICAg IDM4DQo+PlVSTDoNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWRhaG0tb3BzYXdnLXRhY2Fjcy0wMS50eHQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaW50ZXJuZXQtMkRkcmFmdHNfZHJh ZnQtMkRkYWhtLTJEb3BzYXdnLTJEdGFjYWNzLTJEMDEudHh0JmQ9Q3dNRmFRJmM9V08tUkd2ZWZp YmhIQlpxM2ZMODVoUSZyPXlxZlAzSDlXNU13SEd3ZnVqYXl2encmbT1kMnprYkVLdE03enJKdVFK NFB2WXR2cFpIRzRoY3ZodWN1aE9iMDN5MUFFJnM9dnl5cHNnTHY0eFU5WlJYS0RjOFpraHZzNWxD YUhsZUZ0R2Y1cmpZazU0dyZlPT4NCj4+U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRhaG0tb3BzYXdnLXRhY2Fjcy88aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9y Z19kb2NfZHJhZnQtMkRkYWhtLTJEb3BzYXdnLTJEdGFjYWNzXyZkPUN3TUZhUSZjPVdPLVJHdmVm aWJoSEJacTNmTDg1aFEmcj15cWZQM0g5VzVNd0hHd2Z1amF5dnp3Jm09ZDJ6a2JFS3RNN3pySnVR SjRQdll0dnBaSEc0aGN2aHVjdWhPYjAzeTFBRSZzPXBpMnVvU1I4Q0V1QUpWWl80ZEdUY1JPTGI4 Q0J2WFkwLVh1M0VzbDdhakkmZT0+DQo+Pkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZGFobS1vcHNhd2ctdGFjYWNzLTAxPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9k cmFmdC0yRGRhaG0tMkRvcHNhd2ctMkR0YWNhY3MtMkQwMSZkPUN3TUZhUSZjPVdPLVJHdmVmaWJo SEJacTNmTDg1aFEmcj15cWZQM0g5VzVNd0hHd2Z1amF5dnp3Jm09ZDJ6a2JFS3RNN3pySnVRSjRQ dll0dnBaSEc0aGN2aHVjdWhPYjAzeTFBRSZzPU16czI0RUptSzRMaXpRZDlwWm02MERHRVU5Vkw4 bFBEdTRnNE00c2VDTlUmZT0+DQo+PkRpZmY6DQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1kYWhtLW9wc2F3Zy10YWNhY3MtMDE8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfcmZjZGlmZi0zRnVy bDItM0RkcmFmdC0yRGRhaG0tMkRvcHNhd2ctMkR0YWNhY3MtMkQwMSZkPUN3TUZhUSZjPVdPLVJH dmVmaWJoSEJacTNmTDg1aFEmcj15cWZQM0g5VzVNd0hHd2Z1amF5dnp3Jm09ZDJ6a2JFS3RNN3py SnVRSjRQdll0dnBaSEc0aGN2aHVjdWhPYjAzeTFBRSZzPWd6SXZvQVJKR1RkT3NLVXYtQkdvNlZy ckx4aUdwa2xkRnh1R3ZFcnByRDAmZT0+DQo+Pg0KPj5BYnN0cmFjdDoNCj4+ICAgVEFDQUNTKyBw cm92aWRlcyBhY2Nlc3MgY29udHJvbCBmb3Igcm91dGVycywgbmV0d29yayBhY2Nlc3Mgc2VydmVy cw0KPj4gICBhbmQgb3RoZXIgbmV0d29ya2VkIGNvbXB1dGluZyBkZXZpY2VzIHZpYSBvbmUgb3Ig bW9yZSBjZW50cmFsaXplZA0KPj4gICBzZXJ2ZXJzLiAgVEFDQUNTKyBwcm92aWRlcyBzZXBhcmF0 ZSBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiBhbmQNCj4+ICAgYWNjb3VudGluZyBzZXJ2 aWNlcy4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBwcm90b2NvbCB0aGF0IGlzDQo+PiAg IHVzZWQgYnkgVEFDQUNTKy4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj5QbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj5zdWJt aXNzaW9uDQo+PnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3Rvb2xzLmlldGYub3JnJmQ9Q3dNRmFRJmM9V08tUkd2ZWZpYmhIQlpx M2ZMODVoUSZyPXlxZlAzSDlXNU13SEd3ZnVqYXl2encmbT1kMnprYkVLdE03enJKdVFKNFB2WXR2 cFpIRzRoY3ZodWN1aE9iMDN5MUFFJnM9alAzVll5c2RFRW1EYXNzQVVybG55NF9aWWI0WTY5cWla eUs0X1A2TzBwUSZlPT4uDQo+Pg0KPj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4NCj4NCg0KDQoN Ci0tDQpJIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMg b2J2aW91c2x5IGEgYmFkDQppZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NClRoaXMgaXMgbGlrZSBw dXR0aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcN CnJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBh bmQgdGhhdCBwYWlyDQpvZiBwYW50cy4NCiAgIC0tLW1hZg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0Bp ZXRmLm9yZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vcHNhd2cNCg== --_000_EA0DF28481B54F5C99E850CD2B878EACharvardedu_ Content-Type: text/html; charset="utf-8" Content-ID: <1BFF5FDCE54FB142A6063EDC3E6F905F@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KVGhlIGNoYWlycyBvZiB0aGUgb3BzYXdn IHJlY2VpdmVkIGFuIGFwcGVhbCBmcm9tIEFsYW4gRGVLb2sgb24gMTEgRmVicnVhcnk8L2Rpdj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KMjAxNiBjb25jZXJuaW5nIHRo ZSBoYW5kbGluZyBhbmQgcG9zc2libGUgZGlzcG9zaXRpb24gb2Y8L2Rpdj4NCjxkaXYgY2xhc3M9 IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KZHJhZnQtaWV0Zi1vcHNhd2ctdGFjYWNzLTAwLnR4 dCAoVEFDQUNTJiM0MzspLiBUaGlzIG1lc3NhZ2Ugd2FzIGEgZm9sbG93IHVwIG9mPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhl aWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCmEgbnVtYmVyIG9mJm5ic3A7IGVt YWlsIG1lc3NhZ2VzIHNlbnQgdG8gdGhlIG9wc2F3ZyBtYWlsaW5nIGxpc3Qgc3RhcnRpbmcgb24g MTA8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDEx cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KRmVicnVhcnku PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4 OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEz cHg7Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 IE1lbmxvOyI+DQpUaGUgdG9waWNzIG9mIHRoZSBhcHBlYWwgYW5kIG90aGVyIG1lc3NhZ2VzIGZy b20gTXIuIERlS29rIGluY2x1ZGVkOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 IE1lbmxvOyI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFj ZTogcHJlOyI+PC9zcGFuPjEvIFRoZSBhZG9wdGlvbiBvZiB0aGUgVEFDQUNTJiM0MzsgSW50ZXJu ZXQgRHJhZnQgYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogTWVubG87Ij4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOiBwcmU7Ij48L3NwYW4+Mi8gVGhlIGFwcHJvcHJpYXRlbmVzcyBvZiBwdWJs aXNoaW5nIHRoZSBUQUNBQ1MmIzQzOyBJbnRlcm5ldCBEcmFmdCBhczwvZGl2Pg0KPGRpdiBjbGFz cz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQphIFJGQyB0aHJvdWdoIHRoZSBJRVRGIHRyYWNr LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQo8c3BhbiBjbGFz cz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+PC9zcGFuPjMvIFRo ZSBhcHByb3ByaWF0ZW5lc3Mgb2YgcHVibGlzaGluZyB0aGUgVEFDQUNTJiM0MzsgSW50ZXJuZXQg RHJhZnQgYXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNp emU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KYSBz dGFuZGFyZHMgdHJhY2sgUkZDLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAw cHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1l bmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KVGhpcyBtZW1vIGNvbmNlcm5zIHRoZSBmaXJz dCB0b3BpYywgdGhlIG90aGVyIHR3byB0b3BpY3MgYXJlIHByb3BlciB0b3BpY3M8L2Rpdj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KZm9yIGEgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3Qgd2hlbiBhbiBJbnRlcm5ldCBEcmFmdCBpcyB1bmRlcjwvZGl2Pg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQpjb25zaWRlcmF0aW9uLiAmbmJzcDs8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiIGNsYXNzPSIi Pg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsi Pjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KRmlyc3Qgc29tZSBoaXN0b3J5Ojwv ZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4 OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBN ZW5sbzsiPg0KQWZ0ZXIgc29tZSBpbml0aWFsIGNvbmZ1c2lvbiwgdGhlIEludGVybmV0IERyYWZ0 IGRyYWZ0LWdyYW50LXRhY2Fjcy0wMC50eHQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1h cmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiBNZW5sbzsiPg0Kd2FzIHB1Ymxpc2hlZCBvbiAxMiBKdW5lIDIwMTUuJm5ic3A7IEluIGFu IGVtYWlsIG1lc3NhZ2UgdG8gdGhlIG9wc2F3ZyBsaXN0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogTWVubG87Ij4NCkRvdWcgR2FzaCBzYWlkOjwvZGl2Pg0KPGRpdiBjbGFzcz0i IiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDEx cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KJnF1b3Q7IFRB Q0FDUyYjNDM7IGlzIGEgcHJvdG9jb2wgd2lkZWx5IGRlcGxveWVkLCBiYXNlZCB1cG9uIGEgZHJh ZnQgc3BlY2lmaWNhdGlvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxv OyI+DQp0aGF0IENpc2NvIHN1Ym1pdHRlZCBpbiAxOTk4LCBidXQgbmV2ZXIgY29tcGxldGVkIHRv IFJGQyBzdGF0dXMuIFRoZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxv OyI+DQpvcmlnaW5hbCBkcmFmdCBoYXMgYmVlbiB0aWRpZWQgYW5kIGxpZ2h0bHkgZW5oYW5jZWQg YW5kIHJlc3VibWl0dGVkLCB3aXRoPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87Ij4NCnRoZSBpbnRlbnQgdG8gZmluYWxseSBnZXQgaXQgcHVibGlzaGVkIGFzIGEgc3Rh bmRhcmQuJnF1b3Q7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IG1p bi1oZWlnaHQ6IDEzcHg7Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6IE1lbmxvOyI+DQpIZSB0aGVuIGZvbGxvd2VkIHVwIHdpdGggYW4gZW1haWwg bWVzc2FnZSBkZXNjcmliaW5nIHRoZSB1cGRhdGVzIHRvIHRoZTwvZGl2Pg0KPGRpdiBjbGFzcz0i IiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQpvbGQgSUQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQoxIEp1bHkgMjAxNTog dGhlIE9QUyBBZHMgcHV0IFRBQ0FDUyYjNDM7IG9uIHRoZSBhZ2VuZGEgZm9yIG9wcyBhcmVhIHNl c3Npb248L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6 IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KZHVyaW5n IElFVEYgOTM8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNp emU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhl aWdodDogMTNweDsiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogTWVubG87Ij4NCjIwIEp1bHkgMjAxNTogVGhlIG9wcyBhcmVhIHNlc3Npb24gd2Fz IGhlbGQuIFRoZSBUQUNBQ1MmIzQzOyBzbGlkZXMgdXNlZDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6IE1lbmxvOyI+DQpkdXJpbmcgdGhlIHNlc3Npb24gYXJlIGF0OiZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLW9wc2FyZWEt Mi5wZGYiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkzL3NsaWRl cy9zbGlkZXMtOTMtb3BzYXJlYS0yLnBkZjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCk1pbnV0ZXMgb2YgdGhlIHNl c3Npb24gYXJlIHF1aXRlIHNwYXJzZS4mbmJzcDsgVGhleSBub3RlIHRoYXQgdGhlIHByZXNlbnRh dGlvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTog MTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQpvY2N1cnJl ZCBhbmQgdGhhdCBBbGFuIERlS29rIG9iamVjdGVkIHRvIHRoZSBwcm9wb3NhbC48L2Rpdj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4N ClRoZSBhdWRpbyByZWNvcmRpbmcgb2YgdGhlIHNlc3Npb24gaXMgYXQ6PC9kaXY+DQo8ZGl2IGNs YXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2F1ZGlvL2lldGY5My9pZXRmOTMtY29uZ3Jlc3NoYWxsaS0yMDE1MDcyMC0xNzQwLm1wMyIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXVkaW8vaWV0ZjkzL2lldGY5My1jb25ncmVz c2hhbGxpLTIwMTUwNzIwLTE3NDAubXAzPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KVGhlIGF1ZGlvIG9mIHRoZSBz cGVha2VycyBhbmQgdGhlIGNvbW1lbnRhdG9ycyBhdCB0aGUgbWljIGxpbmUgYXJlIHF1aXRlPC9k aXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCmNsZWFyIGJ1dCwgdW5m b3J0dW5hdGVseSwgdGhlIGF1ZGlvIG9mIHRoZSBBRCBpcyB1bmludGVsbGlnaWJsZS4gJm5ic3A7 IFRoZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTog MTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQpyZWNvcmRp bmcgc2hvd3MgdGhhdCB0aGVyZSB3YXMgbGl0dGxlIGRpc2N1c3Npb24gb2YgdGhlIG1lcml0cyBv ZiB0aGU8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6 IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KcHJvcG9z YWwgb3RoZXIgdGhhbiBNci4gRGVLb2sncyBvYmplY3Rpb25zLiZuYnNwOyBPbmUgb2YgdGhlIGNo YWlycyAoU2NvdHQpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4N CnJlY2FsbHMgdGhhdCB0aGUgQUQgZGlkIHNvbWUgZm9ybSBvZiBhc3Nlc3NtZW50IHRvIGdhZ2Ug aW50ZXJlc3QgaW48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250 LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0K d29ya2luZyBvbiB0aGUgSUQgYW5kIGZvdW5kIHN1cHBvcnQuICZuYnNwOzwvZGl2Pg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNp emU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KMiBP Y3RvYmVyJm5ic3A7IDIwMTU6Jm5ic3A7IHVwZGF0ZWQgSUQgcHVibGlzaGVkPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdo dDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQt c2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQo0 IE9jdG9iZXIgMjAxNTombmJzcDsgRG91ZyBHYXNoIHNlbnQgbm90ZSB0byBvcHNhd2cgbGlzdCBh c2tpbmcgZm9yIG9waW5pb25zIG9mPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87Ij4NCnRoZSBsaXN0IGZvciBwdWJsaWNhdGlvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KMTMgTm92ZW1iZXIg MjAxNTogV2FycmVuIHNlbnQgdGhlIGZvbGxvd2luZyBtZXNzYWdlIGFza2luZyBmb3IgaW5wdXQg b248L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDEx cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KdGhlIElEICg8 L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vcHNhd2cvY3VycmVudC9tc2cwNDEy NC5odG1sIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29w c2F3Zy9jdXJyZW50L21zZzA0MTI0Lmh0bWw8L2E+KTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KPHNwYW4gY2xhc3M9IkFw cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPjwvc3Bhbj5EZWFyIE9wc0FX RyBXRyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6 IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdo dDogMTNweDsiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogTWVubG87Ij4NCiZuYnNwOyZuYnNwOyBXZSB3b3VsZCByZWFsbHkgYXBwcmVjaWF0ZSBh bnkgZmVlZGJhY2sgb24gdGhpcyBkb2N1bWVudC4gUGVyc29uYWxseSBJPC9kaXY+DQo8ZGl2IGNs YXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCiZuYnNwOyZuYnNwOyB0aGluayBpdCBpcyBy ZWFsbHkgdXNlZnVsLCBidXQgd2UgbmVlZCB0aGUgV0cgdG8gcmV2aWV3IGFuZCBwcm92aWRlPC9k aXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCiZuYnNwOyZuYnNwOyBm ZWVkYmFjay48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNp emU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhl aWdodDogMTNweDsiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogTWVubG87Ij4NCiZuYnNwOyZuYnNwOyBPdmVyIHRoZSB5ZWFycyBJJ3ZlIGhlYXJk IGEgbnVtYmVyIG9mIHBlb3BsZSBrdmV0Y2ggdGhhdCBUQUNBQ1MmIzQzOyBpc24ndDwvZGl2Pg0K PGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQombmJzcDsmbmJzcDsgZG9jdW1l bnRlZCAtLSB3ZWxsLCBub3cgeW91IGNhbiwgeW91IGtub3csIGFjdHVhbGx5IGRvIHNvbWV0aGlu ZyBhYm91dDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6 ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQombmJz cDsmbmJzcDsgdGhpcy4uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxv OyBtaW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KJm5ic3A7Jm5ic3A7IFc8L2Rpdj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXpl OiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWln aHQ6IDEzcHg7Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6IE1lbmxvOyI+DQpUaGVyZSB3ZXJlIGEgbnVtYmVyIG9mIHJlc3BvbnNlcyBpbiBzdXBw b3J0IG9mIHB1YmxpY2F0aW9uIGFuZCB0aGUgV0c8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiBNZW5sbzsiPg0Kd29ya2luZyBvbiB0aGUgSUQgYWxvbmcgd2l0aCBzb21lIHRlY2hu aWNhbCBkaXNjdXNzaW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxv OyBtaW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KVGhlIGNoYWlycyBjb25jbHVkZWQgdGhhdCB0aGVy ZSB3YXMgZW5vdWdoIGludGVyZXN0IHRvIGFkb3B0IHRoZSBJRCBhcyBhPC9kaXY+DQo8ZGl2IGNs YXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCndvcmtpbmcgZ3JvdXAgdG9waWMuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxv OyI+DQozMCBOb3ZlbWJlcjogMjAxNTogV2FycmVuIHNlbnQgdGhlIGZvbGxvd2luZyBtZXNzYWdl IHRvIHRoZSBvcHNhd2c6Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87Ij4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNl OiBwcmU7Ij48L3NwYW4+KGZvciBzb21lIHJlYXNvbiB0aGlzIG1lc3NhZ2UgZG9lcyBub3Qgc2hv dyB1cCBpbiB0aGUgYXJjaGl2ZSBidXQgYSBjb3B5IGlzJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9y bWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIg c3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij48L3NwYW4+YXBwZW5kZWQgdG8gdGhpcyBtZXNzYWdl KTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6 IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KJm5ic3A7 ICZuYnNwOyBUaGUgY2hhaXJzIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBzdWZmaWNpZW50IGludGVy ZXN0IGFuZCBzdXBwb3J0IHRvIGFkb3B0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJn aW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWls eTogTWVubG87Ij4NCiZuYnNwOyAmbmJzcDsgdGhpcyBkb2N1bWVudCBhcyBhbiBPcHNBV0cgZG9j dW1lbnQuICZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZv bnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyBt aW4taGVpZ2h0OiAxM3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KJm5ic3A7ICZuYnNwOyBBdXRob3JzLCBwbGVhc2UgcmVz dWJtaXQgYXMgZHJhZnQtaWV0Zi1vcHNhd2ctdGFjYWNzLTAxPC9kaXY+DQo8ZGl2IGNsYXNzPSIi IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQoxNiBEZWNlbWJl ciAyMDE1IC0gcmVuYW1lZCBJRCBwdWJsaXNoZWQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxv OyI+DQpCeSBhc2tpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgbGlzdCBmb3IgaW5wdXQgb24gdGhlIHF1 ZXN0aW9uIG9mIGFkb3B0aW5nIGFuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87Ij4NCklEIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudCB0aGUgb3BzYXdnIGNoYWly cyBmb2xsb3dlZCBvbmUgb2YgdGhlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87Ij4NCm5vcm1hbCBJRVRGIHByb2Nlc3MgdG8gZGV0ZXJtaW5lIGlmIHRoZXJlIHdhcyBl bm91Z2ggaW50ZXJlc3QgZm9yIHRoZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 IE1lbmxvOyI+DQp3b3JraW5nIGdyb3VwIHRvIGFkb3B0IHRoZSBUQUNBQ1MmIzQzOyBJRCBhcyBh IHdvcmtpbmcgZ3JvdXAgdG9waWMuJm5ic3A7IFdlIG5vdGU8L2Rpdj4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KaW4gcGFzc2luZyB0aGF0IHN1Y2ggYW5vdGhlciBub3Jt YWwgcHJvY2VzcyBpcyBmb3IgdGhlIFdHIGNoYWlycyB0byBkZWNpZGU8L2Rpdj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0Kb24gdGhlaXIgb3duIHRvIGFkb3B0IGEgZG9j dW1lbnQgYXMgYSB3b3JraW5nIGdyb3VwIHRvcGljLiZuYnNwOyBXZSBhbHNvIGZlbHQ8L2Rpdj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KdGhhdCB0aGUgdG9waWMgd2Fz IHN1ZmZpY2llbnRseSB3aXRoaW4gdGhlIHdvcmtpbmcgZ3JvdXAgY2hhcnRlciB0byBkbyBzbzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQp3aXRob3V0IGEgc3Bl Y2lmaWMgY2hhcnRlciB1cGRhdGUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQpUaHVzIE1yLiBEZUtvaydzIGFwcGVhbCBh cyB0byB0aGUgYWRvcHRpb24gb2YgdGhlIElEIGFzIGEgd29ya2luZyBncm91cDwvZGl2Pg0KPGRp diBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQp0b3BpYyBpcyByZWplY3RlZC4gSWYg TXIuIERlS29rIGJlbGlldmVzIHRoYXQgdGhpcyBkb2VzIG5vdCBzYXRpc2Z5IGhpczwvZGl2Pg0K PGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQpjb25jZXJucywgd2UgcmVmZXIg aGltIHRvIFJGQyAyMDI2LCBTZWN0aW9uIDYuNSBmb3IgdGhlIG5leHQgc3RlcHMgaW4gdGhlPC9k aXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCmFwcGVhbCBwcm9jZXNz LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAx M3B4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiBNZW5sbzsiPg0KU2NvdHQgQnJhZG5lcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6IE1lbmxvOyI+DQpXYXJyZW4gS3VtYXJpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogTWVubG87Ij4NCjEyIEZlYnJ1YXJ5IDIwMTY8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBsaW5lLWhl aWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4NCuKAlC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zaXplOiAxMXB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87Ij4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4OyB0ZXh0LWluZGVudDogNnB4OyBmb250 LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNh IE5ldWUnOyBjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgpOyI+DQpUbzombmJzcDs8YSBocmVmPSJt YWlsdG86b3BzYXdnQGlldGYub3JnIiBjbGFzcz0iIj5vcHNhd2dAaWV0Zi5vcmc8L2E+Jm5ic3A7 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9u dC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGlj YSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1Ncy1FeGNoYW5nZS1UcmFuc3Bv cnQtRW5kdG9lbmRsYXRlbmN5OiAwMDowMDowMS44MDkzNDQ1PC9kaXY+DQo8ZGl2IGNsYXNzPSIi IHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhl aWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3 NiwgNzYsIDc2KTsiPg0KWC1Gb3JlZnJvbnQtQW50aXNwYW0tUmVwb3J0OiBDSVA6NjcuMjMxLjE1 Ni4yNztDVFJZOlVTO0lQVjpDQUw7SVBWOk5MSTtFRlY6TkxJO1NGVjpTS047U0ZTOjtESVI6SU5C O1NGUDo7U0NMOi0xO1NSVlI6Q1kxUFIwNzAxTUIxMDgxO0g6bXgwYi08YSBocmVmPSJodHRwOi8v MDAxNzExMDEucHBob3N0ZWQuY29tIiBjbGFzcz0iIj4wMDE3MTEwMS5wcGhvc3RlZC5jb208L2E+ O0ZQUjo7U1BGOk5vbmU7TEFORzplbjs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdp bjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+ DQpTcGFtZGlhZ25vc3RpY21ldGFkYXRhOiA3NDYwOTY2YjJmZDI0ODQ2OWRlYWUwMmNiOGY4Mjcz MDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZv bnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRp Y2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClgtTXMtRXhjaGFuZ2UtQ3Jvc3N0 ZW5hbnQtSWQ6IDZmZmEyMmY0LTQ1NjgtNDEwNS1hZDQzLTJlM2FkNDcyNjk1NzwvZGl2Pg0KPGRp diBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNv bG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NCkxpc3QtSWQ6IE9QU0EgV29ya2luZyBHcm91cCBNYWls IExpc3QgJmx0OzxhIGhyZWY9Imh0dHA6Ly9vcHNhd2cuaWV0Zi5vcmciIGNsYXNzPSIiPm9wc2F3 Zy5pZXRmLm9yZzwvYT4mZ3Q7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBw eCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1F eGNoYW5nZS1BbnRpc3BhbS1SZXBvcnQtVGVzdDogVXJpU2NhbjooOTU2OTI1MzU3MzkwMTQpOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQt c2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2Eg TmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NCkFyY2hpdmVkLUF0OiAmbHQ7PGEgaHJl Zj0iaHR0cDovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29wc2F3Zy8xaEIzTmt3MUtj c1N2ck5sT2NlbEdWMmRKZk0iIGNsYXNzPSIiPmh0dHA6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy9vcHNhd2cvMWhCM05rdzFLY3NTdnJObE9jZWxHVjJkSmZNPC9hPiZndDs8L2Rpdj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6 IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUn OyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpYLVZpcnVzLVNjYW5uZWQ6IGFtYXZpc2QtbmV3 IGF0Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2Ftc2wuY29tIiBjbGFzcz0iIj5hbXNsLmNvbTwvYT48 L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250 LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNh IE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpYLU1zLUV4Y2hhbmdlLU9yZ2FuaXph dGlvbi1BdXRoc291cmNlOiBCTjFCRkZPMTFGRDA1MC5wcm90ZWN0aW9uLmdibDwvZGl2Pg0KPGRp diBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNv bG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClgtR29vZ2xlLURraW0tU2lnbmF0dXJlOiB2PTE7IGE9 cnNhLXNoYTI1NjsgYz1yZWxheGVkL3JlbGF4ZWQ7IGQ9PGEgaHJlZj0iaHR0cDovLzFlMTAwLm5l dCIgY2xhc3M9IiI+MWUxMDAubmV0PC9hPjsgcz0yMDEzMDgyMDsgaD14LWdtLW1lc3NhZ2Utc3Rh dGU6bWltZS12ZXJzaW9uOnJlZmVyZW5jZXM6aW4tcmVwbHktdG86ZnJvbTpkYXRlIDptZXNzYWdl LWlkOnN1YmplY3Q6dG86Y29udGVudC10eXBlOyBiaD1JVmd6blVBTjRkS1cxSzR1dEF1N2xBeUhp RUYyb2VscXdFdHljR0MmIzQzO09DND07DQogYj1Qc1BSa0xhQ3RBdVdjUTl1aDZsNHFBeXJJOGtv bzRhNWhiVGJpSiYjNDM7WEMmIzQzO0ZmUWZ2eUY4eFRhYmkyaTQxeTRhclFNSiBZQ2cwbzBJZ3hW R0NjQ01hZW9jSGc3amwyM3JCbGM1USYjNDM7U1NTUHlVTnlOQlM2cGxOOHVUWEdXcnVSNDg3TEZQ RFVKL2YgUEVGa3lnYTNtU1BVL0xSM05xRkpkWncxdnhOdDBKWFFqWEh0N2NLZkRmREdzMUtEL3l6 aUwzYUZXSldFRHBEM2lxQXMgMkV6NHozYW5ta01WZ0xheFVUblFEZjlzZ1Bqd1lOVWxDUmJnZm9I U08vTDlrS1FwclZROWR1VVZkbjdBJiM0MztLbXpIV0dMDQogV0h0ckc4UXN5U2o4aGo1SjJZMU9K U0Z2eXozd0JFTEdnUVIvWGw0aEdpeW9HWmR3TDA2Ukt2dU83RnFvRkhBL0txNU0gc0ZBZz09PC9k aXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9udC1z aXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBO ZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1Ncy1FeGNoYW5nZS1Dcm9zc3RlbmFu dC1PcmlnaW5hbGFycml2YWx0aW1lOiAwMSBEZWMgMjAxNSAwMDoxNTowNC41MTcwIChVVEMpPC9k aXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9udC1z aXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBO ZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1Qcm9vZnBvaW50LVNwYW0tRGV0YWls czogcnVsZT1ub3RzcGFtIHBvbGljeT1kZWZhdWx0IHNjb3JlPTAmbmJzcDs8YSBocmVmPSJodHRw Oi8va3Njb3JlLmlzIiBjbGFzcz0iIj5rc2NvcmUuaXM8L2E+X2J1bGtzY29yZT0wIGtzY29yZS5j b21wb3NpdGVzY29yZT0xIGNvbXBvc2l0ZXNjb3JlPTAuOSBzdXNwZWN0c2NvcmU9MiBtYWx3YXJl c2NvcmU9MCBwaGlzaHNjb3JlPTAgYnVsa3Njb3JlPTAmbmJzcDs8YSBocmVmPSJodHRwOi8va3Nj b3JlLmlzIiBjbGFzcz0iIj5rc2NvcmUuaXM8L2E+X3NwYW1zY29yZT0wDQogcmJzc2NvcmU9MC45 IHNwYW1zY29yZT0wIHVybHN1c3BlY3RzY29yZT0wLjkgYWR1bHRzY29yZT0wIGNsYXNzaWZpZXI9 c3BhbSBhZGp1c3Q9MCByZWFzb249bWx4IHNjYW5jb3VudD0xIGVuZ2luZT04LjAuMS0xNTA3MzEw MDAwIGRlZmluaXRpb25zPW1haW4tMTUxMjAxMDAwMjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2 LCA3Nik7Ij4NClNlbmRlcjogJnF1b3Q7T1BTQVdHJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiPm9wc2F3Zy1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHgg NnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAn SGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpMaXN0LUhlbHA6ICZs dDs8YSBocmVmPSJtYWlsdG86b3BzYXdnLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1oZWxwIiBj bGFzcz0iIj5tYWlsdG86b3BzYXdnLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1oZWxwPC9hPiZn dDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBm b250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0 aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpYLU1zLUV4Y2hhbmdlLU9yZ2Fu aXphdGlvbi1OZXR3b3JrLU1lc3NhZ2UtSWQ6IGQ1NTYxOGYyLTc0NzUtNDUzMC1jNDU2LTA4ZDJm OWU0NzY2MDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2 cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdI ZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NCkxpc3QtUG9zdDogJmx0 OzxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpvcHNhd2dA aWV0Zi5vcmc8L2E+Jmd0OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHgg MHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NCkF1dGhl bnRpY2F0aW9uLVJlc3VsdHM6IHNwZj1mYWlsIChzZW5kZXIgSVAgaXMgNjcuMjMxLjE1Ni4yNykg c210cC5tYWlsZnJvbT08YSBocmVmPSJodHRwOi8vaWV0Zi5vcmciIGNsYXNzPSIiPmlldGYub3Jn PC9hPjsmbmJzcDs8YSBocmVmPSJodHRwOi8vaGFydmFyZC5lZHUiIGNsYXNzPSIiPmhhcnZhcmQu ZWR1PC9hPjsgZGtpbT1mYWlsIChib2R5IGhhc2ggZGlkIG5vdCB2ZXJpZnkpIGhlYWRlci5kPTxh IGhyZWY9Imh0dHA6Ly9pZXRmLm9yZyIgY2xhc3M9IiI+aWV0Zi5vcmc8L2E+OzxhIGhyZWY9Imh0 dHA6Ly9oYXJ2YXJkLmVkdSIgY2xhc3M9IiI+aGFydmFyZC5lZHU8L2E+Ow0KIGRtYXJjPW5vbmUg YWN0aW9uPW5vbmUgaGVhZGVyLmZyb209PGEgaHJlZj0iaHR0cDovL2t1bWFyaS5uZXQiIGNsYXNz PSIiPmt1bWFyaS5uZXQ8L2E+OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAw cHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClNw YW1kaWFnbm9zdGljb3V0cHV0OiAxOjI8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdp bjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+ DQpYLUJlZW50aGVyZTombmJzcDs8YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIiBjbGFz cz0iIj5vcHNhd2dAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJn aW46IDBweCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsi Pg0KUmV0dXJuLVBhdGg6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYu b3JnIiBjbGFzcz0iIj5vcHNhd2ctYm91bmNlc0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjog cmdiKDc2LCA3NiwgNzYpOyI+DQpSZWZlcmVuY2VzOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOjIwMTUx MDAyMTUyNTA1LjI2NTk0Ljc0OTI1LmlkdHJhY2tlckBpZXRmYS5hbXNsLmNvbSIgY2xhc3M9IiI+ MjAxNTEwMDIxNTI1MDUuMjY1OTQuNzQ5MjUuaWR0cmFja2VyQGlldGZhLmFtc2wuY29tPC9hPiZn dDsgJmx0O0QyMzc0NTVGLkJDMDBGJTxhIGhyZWY9Im1haWx0bzpkY21nYXNoQGNpc2NvLmNvbSIg Y2xhc3M9IiI+ZGNtZ2FzaEBjaXNjby5jb208L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkNB SHc5X2lLT001TjMtSFMzWk9GRmFESFlUVjdyRGFmM1lIby1kRW1kVFU5LTRXNDlhd0BtYWlsLmdt YWlsLmNvbSIgY2xhc3M9IiI+Q0FIdzlfaUtPTTVOMy1IUzNaT0ZGYURIWVRWN3JEYWYzWUhvLWRF bWRUVTktNFc0OWF3QG1haWwuZ21haWwuY29tPC9hPiZndDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2 LCA3NiwgNzYpOyI+DQpEa2ltLVNpZ25hdHVyZTogdj0xOyBhPXJzYS1zaGEyNTY7IGM9cmVsYXhl ZC9zaW1wbGU7IGQ9PGEgaHJlZj0iaHR0cDovL2lldGYub3JnIiBjbGFzcz0iIj5pZXRmLm9yZzwv YT47IHM9aWV0ZjE7IHQ9MTQ0ODkyODkwMTsgYmg9cHZ0MWtTVlh1RXJ0ZlU1WldJU1Fpa01SUFFZ ZkRwMDVtR01Zc2ImIzQzO1NGY0k9OyBoPU1JTUUtVmVyc2lvbjpSZWZlcmVuY2VzOkluLVJlcGx5 LVRvOkZyb206RGF0ZTpNZXNzYWdlLUlEOlRvOiBTdWJqZWN0Okxpc3QtSWQ6TGlzdC1VbnN1YnNj cmliZTpMaXN0LUFyY2hpdmU6TGlzdC1Qb3N0Okxpc3QtSGVscDoNCiBMaXN0LVN1YnNjcmliZTpD b250ZW50LVR5cGU6U2VuZGVyOyBiPVpSd2VPN1RwM1hxL3Y3TXd0UVk3QnE2SmJwNXRVJiM0Mzsy JiM0MzsmIzQzOyYjNDM7RjBkRVFBTFBFVlhUYlEmIzQzOyYjNDM7aDQ1Snp4TFp5RVM4aWtJIG9r NmliRkNSME1rdzFQMU82RVFNM3RJd1FsTEQ2WGwxS25zRG43NGFVVUQ2UnZRJiM0MztkRDVQMGdj dHJuMVN1R2lROFQgalk1UkQ1QjFZRTdncHZ5TW9FWW9EdmUzR2lEb2xXdXV5Y2xRRmRrbz08L2Rp dj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNp emU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5l dWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpEa2ltLVNpZ25hdHVyZTogdj0xOyBhPXJz YS1zaGEyNTY7IGM9cmVsYXhlZC9yZWxheGVkOyBkPTxhIGhyZWY9Imh0dHA6Ly9rdW1hcmktbmV0 LjIwMTUwNjIzLmdhcHBzc210cC5jb20iIGNsYXNzPSIiPmt1bWFyaS1uZXQuMjAxNTA2MjMuZ2Fw cHNzbXRwLmNvbTwvYT47IHM9MjAxNTA2MjM7IGg9bWltZS12ZXJzaW9uOnJlZmVyZW5jZXM6aW4t cmVwbHktdG86ZnJvbTpkYXRlOm1lc3NhZ2UtaWQ6c3ViamVjdDp0byA6Y29udGVudC10eXBlOyBi aD1JVmd6blVBTjRkS1cxSzR1dEF1N2xBeUhpRUYyb2VscXdFdHljR0MmIzQzO09DND07DQogYj10 Um04TVRITnJWTUx3aVFySGQ3WE10ZVQya2h6MUxDdmxTcktRSGszRUxDNUNDT1VLeWJmSlVDVXdW d3hpckVxblggZlJwcWl3TzVwUlB2U3ImIzQzO0h5dm5FZjdlMFJEcG14V253bmU3SDM1TnhrbU1I cGJ4VlFQJiM0MztXMTVzQi9OQmNHa2hwVGMvSiB3Uy90VEd3eHhPZW1weHBYQ2tWd0daMDhRWHJm TXRDazZCa3pZV0dXaEFocHdtVk8mIzQzO0pDcGdsdmFaWGU0a0g3YmhoNWcgaE9BWkpXcC91U3pP L2wxRm0yN3hndDU3dmVUMUx5Wm9Jd1FwY0NSaHphQS9qS09uZmlVdDBpNGswN21jMTZVNUxXb1MN CiB4NE9hMjdWbUhxMXN6TkFVNmhJd0NxVkpiZ2FjdUNCLyYjNDM7dmpOTTJTeU9MdVNCY3RXSEo1 bGRUWTY2MlhEa2VCbDdrTnUgWUVBZz09PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJn aW46IDBweCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsi Pg0KWC1NYXRjaGluZy1Db25uZWN0b3JzOiAxMzA5MzQwMjUwNDY3MzAxNjU7KGQ5M2QwMTgwLTIy N2UtNDU3Yy00NDk5LTA4ZDJlYWVjOTcwMywyNTZiMmYxMi00ZWRmLTRiYmEtY2E4YS0wOGQxNzY2 YTc2N2YsNGMyZmI4ODEtZmQ2MC00N2M0LTI3ZGUtMDhkMWE5NDY0YWFmLGQ4YmJiZjBkLThlMTkt NDI3Mi05MzQ1LTA4ZDFiNjVjYjc5Myw3NTFiNGU5ZS1kNGZiLTQ0YmYtYTEzMS0wOGQxZGM5ODIz ZTQsZTAwNjhlYmYtMDE0Yi00YzczLTc5M2EtMDhkMmYxZGNjNzQzLGFjMDFjZjBjLWU5NjctNDk1 Yy0zZmE5LTA4ZDFlNzAxNDFjZCwyODA4ZjFjMi0yYzJmLTQ4M2UtM2Q4MC0wOGQxZGZiMmZlOTks ZjllODk5YmItMWNjMi00MWRiLTVmYTAtMDhkMDcxYTFhNzZlLDNkZmEwNjVkLTZkMDktNDFlNC0w M2Q2LTA4ZDE5OTk0MzRlMSw4ZjcyZjM0OS1lYWM3LTRjYTItNTkwOS0wOGQxZjRkNmJkOGYpOyhm YzQwYjdiMy05ZDkyLTRiYWQtNTExYi0wOGQxNDI5NjcxZjAsZjA0NGE2ZDctOThiOS00YzEwLTkx YjQtMDhkMjEwNDEzZmU5LDI3YmQyZGJhLWU4YzEtNGY2MS01YmNiLTA4ZDJlNjNhMWYyNCw2NDM3 ZDJhNS03ODMwLTQ4N2EtYjYxMy0wOGQyZDVhMGQzNTQsZDM4MDYyMzItNWQxMy00MTQ5LTI4ZmYt MDhkMWRlYzYwNDczLGRiYzAwZDNmLWNmMzktNGQ3My1mZDM0LTA4ZDFiYTI1MjEzOCw5YWRiMjgw Zi00ZmJlLTQ5YWItMTdhZC0wOGQwYzhiMWZlYjIsNzBmYjQyYTEtOTY4OC00MWI2LWQ4MTAtMDhk MWIwN2I0OTI0KTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBw eCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NCkVycm9ycy1Ubzom bmJzcDs8YSBocmVmPSJtYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiPm9w c2F3Zy1ib3VuY2VzQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFy Z2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7 Ij4NClJlY2VpdmVkLVNwZjogRmFpbCAoPGEgaHJlZj0iaHR0cDovL3Byb3RlY3Rpb24ub3V0bG9v ay5jb20iIGNsYXNzPSIiPnByb3RlY3Rpb24ub3V0bG9vay5jb208L2E+OiBkb21haW4gb2YmbmJz cDs8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmciIGNsYXNzPSIiPmlldGYub3JnPC9hPiZuYnNwO2Rv ZXMgbm90IGRlc2lnbmF0ZSA2Ny4yMzEuMTU2LjI3IGFzIHBlcm1pdHRlZCBzZW5kZXIpIHJlY2Vp dmVyPTxhIGhyZWY9Imh0dHA6Ly9wcm90ZWN0aW9uLm91dGxvb2suY29tIiBjbGFzcz0iIj5wcm90 ZWN0aW9uLm91dGxvb2suY29tPC9hPjsNCiBjbGllbnQtaXA9NjcuMjMxLjE1Ni4yNzsgaGVsbz08 YSBocmVmPSJodHRwOi8vbXgwYi0wMDE3MTEwMS5wcGhvc3RlZC5jb20iIGNsYXNzPSIiPm14MGIt MDAxNzExMDEucHBob3N0ZWQuY29tPC9hPjs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1h cmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYp OyI+DQpYLU1pY3Jvc29mdC1FeGNoYW5nZS1EaWFnbm9zdGljczogMTtCTjFCRkZPMTFGRDA1MDsx OjdaTjlZSzd4REYvWU9GcWdTRi9LdDdTRXVSbDZtODJURUVGUzVwamowTDlXWjJYc2pzb0swNlJI UW9xcDB6WkpPcXpITHNLN3A2MnNSQy8mIzQzO2RsME5IZXdueFdIamxZa0ZsRXJPMFF4UHUzYmtN TU1XRkRMMEQxZ05rTk5BTFFNRWNDRXdNTjFFJiM0MztzSGZ2V3FmU2h0T3BQYnNlV0FJVTB3RmJm JiM0MztUSE5Bc1owcG9VcXl3VlBJZUpSVEoyN0tock16ZHZmQ0JkSWg4SXZaNVVGJiM0MztpNS8z MEx3dTkwVHdoSEJ5ZFFqOWltcEhYaEp6ejZjY2h3eUMmIzQzO2NaQnlIZHhiaGJraWthRlUyT1Jm OXh3QngvZHdBNmFjbklZdXJjWnhYRTZySTRubDZaJiM0MzsxajJwVG1UUm92L3UmIzQzOzY5NjVH bjQ3a1YxcVNqbWVlV1FxMSYjNDM7SnNxZzBuUVAwTHF2V1g2Q3lnZDQvS2djWUV4aXNoRTduaXZL VlpxNzJyNGxKYiYjNDM7MGVhTXN3VC82M0dwZmlUcVZ4MjEmIzQzO1VCeDNOS3ZNdWxRU3FHOUdp ems2YUJucy8zQkpyUm1ZaTBqNWlHciYjNDM7ZGZieDBMeW16ZE9kT0ZVZm1nVElZR0pHaGpPNzAx JiM0MzthTG5RSEQ3VnJCMUZCRDJXNy96SmlXbkpyNXJ4SE5lMHVQMjhKVW5iNiYjNDM7NWxyL2Zl d0dFWlo0akltUSYjNDM7UmJmWmJ3PT08L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdp bjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+ DQpYLU1pY3Jvc29mdC1FeGNoYW5nZS1EaWFnbm9zdGljczogMTtDWTFQUjA3MDFNQjEwODE7MjpX MWkwdDRQR0hwV1pwWkduMGd3cWNjYU9WdjJ1NDlua0ZTb2YzSkJsclF1UUp3Y0tsOVkyd0RlVmw1 QTlpRXJ6cU9KSXRUeVB6aXFmQXQ3S3lHRWF4OXJNOTV0aUt0amN4Z3p3empRamlxUUZwR2dUSEYx US9tWSYjNDM7dzFvZzZHRVFnUzRYZ01EbGpJQXVtdzR0U3BpUUxBPT07MzpCS1JiUG1STTVxJiM0 Mzs0cHJIYk1NbDFwbDFaWjJ0UzByVkdpdzdhRUgxQ3E3SFBWTnhhWWRpSk9QYzQvQkpZdm9kVlkx dmJyNjdxd3dBVElEdFhmVmllOWRiMlJqQkRqeFFXUFJZNXpYd2xuSTU4Mkp2dlNkM3V4QUkxWVp6 QUZnY1drdDdzQ0cyWnVEMk55bTl2Qnh2SGw3V0Q1c1VkeDJ0cjhpekxDODZkTXVnTURHMEl5aHpQ RkVmcjlCMG1zd3JyWHREM1hQamtvQ2kvTkFDL2loc0R5VjRMb00zL0tkNGhlMkFheVROcnhxNyYj NDM7aXRCbWV2JiM0MztSSTZtODRpUlJ6SXh1Sy9RYmQ1dkNmU2JJc3JDa21jeHFWbGd6WGtNeHJV YXp1aGVUUURzR00wZ0syTWFaYU1UQmhkayYjNDM7OEt5RDR1MmI7MjU6NzhNSXRpMllMdjlpMDM4 S1VUZlN2c3BYSEZTMUp0SllRZ1dVeXp5b2lCNGIzTSYjNDM7c3pKeWloJiM0Mzs1OHo4MWFVdlly TlRtWkNZV3hlTmJKeE9xY1NFbkZEL3RGTEY3bEVvZDJ2OERoek54QWRYZkpsQWN2LzM1QXFVOTlp d0wwTXpkZWlHZFYwaFdJZklvVkdFTTZybjEySW5tTk5aNSYjNDM7SDRtRnNwWmxwRkpCbUM5OXls WUhoblllUlR2cENqaEUyNkQ5cnk4NVVxOHZOUTdUN3ZHMXFXVDhzQjhaWUZSZ2RubU9abEVaaURy bU9NbEZJYyYjNDM7NGh0c2VtS1J1ZmdmY1pHaENhWk0yMThQd1BrOVlxcnJLYURBUE5nPT08L2Rp dj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNp emU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5l dWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpYLU1pY3Jvc29mdC1FeGNoYW5nZS1EaWFn bm9zdGljczogMTtDWTFQUjA3MDFNQjEwODE7MjA6UGRMdUNDeWlDRnNoVzBOZFBuQzhlQm9qaE52 bVBUc0h2LzRVRm5xMi9BcDEzQ2hZb3pHY2RFcWtWVW9DRGdWNnhDbmJWMnNjaDg0RzlZcWNpQ3JB cXBCT0MmIzQzO1AmIzQzO0phZGIveFdvc3FpcERqQ3paelFCMzhhaDNWJiM0Mzs0QmRuYm0zN2FX czUyN1FUZEZYNzRvMzE5cmtSa3BmUVc1bFpCVUUvJiM0Mztha2FMazNpUE9TREdrbExPY01Nems1 RTZNVWtnMUZDeGVUU0NSYkVKSTdDOEdjZmtwNFozM3NXd1o0bDRuWnNUcnlRakZOd1VuS0QzNUsz dlZYQ1NUVXI5bUhFZWQ4NkI7NDpaa2RZUDBiJiM0MztyZUFBdGNTUFIvczZncy80eHRsMkJkdVFx Y3V4TVdoblBBcmpGc3lJN0Q4cXhoSnplZ0xKSW1tSXVyd3ZHTnVBdVBBRUJWbnpmS2s3VWs4S21Y dXJ6NVZyTldXWHo5SDlrWDVJMmlTb1k4MmhiT0dxcHhvS1pON1p2VDRlTm5rZnRmd0VCQmI2Y0pX YkxYMndKcjFHaFpRU3RLSGhuS09YQ3RuV1RHMWJDT3NBbFVGek80ZmNRcksxODcxem1KWWNWTEZl WHMyc294cTZ6UlZpZG5VVng1YVZjejFmYlVXMXBZWWk3U1ZUbUtVeEhnREhwQmxoRTJNN0lzUUNm Mi96OGpzcHdIUjIvQ2E0UXdmVHNCT3dyemxCZUhyeWp4akd3RExhaDBTcTVXOWZ5NWRvWExXajZa cDVIZCYjNDM7NzhBblFLUWpUTEpvSnpleXBPOEpWdHllWHF2MHkvVXBQalhFTnBoYkM2NzRjUlFF eUVob3lMT1d5cHVKZVVQOVh1a0lOQVR2VkVkZ0puQ0hlcGtKU09IU1pRZWE5ekdLblRIYXpZam9H NzllSzFsc0xneDJVZXJzbXh0d3o7MjM6NEVLcEVSL1dleDdsN3lKak51Nk5DZi9PTDhHVXZGY1Rm SDAzVjZmMWt5dkFEJiM0MzsxaTNyTWhNSU1VVGFTNVJ1RlZFQklUJiM0MzsxaFYyWWVtbk50TkNl amJRc3NjSks0N012cllmZnUxWTRGV3lzWkh3bXVXNVo4WVkxOVo1NWdnL2JCamdlSHd1Yy9FQ2lH JiM0MztHNTRtWkdLdGRrdU4xZjZYa2tKUmxrOWI1bWlFZU1ZeWVTYS9EZUVpJiM0MzsxWCYjNDM7 LzY5QlRhSGhWbWRzT25FSWlYT0Vtd0ttVVJCVWJBPT08L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5 bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3 NiwgNzYpOyI+DQpYLU1pY3Jvc29mdC1FeGNoYW5nZS1EaWFnbm9zdGljczogMTtDWTFQUjA3MDFN QjEwODE7NTpORG1TVU5rRlppakJ3UGZFQ0lOMzkvbktMOVNacFpRb1hmODNEZFlkRzZjNnVxdktx OXBGTDExekNJbHVHQmZiZnI3ajhHSFdvSGpDRnBieDdWWUcxJiM0MztwSldzYnczdUtteDEyd29N cHhWVTJvYXhvVjhUYjQ0djB6b2FCMU8yRmhFOXNaYmNwNUUmIzQzO2smIzQzO1ZGcGpUN214SVE9 PTsyNDpvUlhRY3dFV3hQQ3VxbjVVQXpOVXE2QUJ1dXZRWUxJc3U1SWJ0S3lUOEk4c2VsV2ZmWXZu RVpnWEY2Y09STlpxUzdCMnh5REx5NUZqem1jbUVWTElYT3lPaVh1SEkxUVdEdWFnWm5yeUF3cz08 L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250 LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNh IE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpJbi1SZXBseS1UbzogJmx0OzxhIGhy ZWY9Im1haWx0bzpDQUh3OV9pS09NNU4zLUhTM1pPRkZhREhZVFY3ckRhZjNZSG8tZEVtZFRVOS00 VzQ5YXdAbWFpbC5nbWFpbC5jb20iIGNsYXNzPSIiPkNBSHc5X2lLT001TjMtSFMzWk9GRmFESFlU VjdyRGFmM1lIby1kRW1kVFU5LTRXNDlhd0BtYWlsLmdtYWlsLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAx MnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsg Y29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1Ea2ltcmVzdWx0LVRlc3Q6IEZhaWxlZDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6 ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1 ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClgtR20tTWVzc2FnZS1TdGF0ZTogQUxvQ29R a1BMTmdPTXQ0Rk1PQ1dBS2wyTUxZRFNaUnVOL1VvQmpCU0cwVlJvcjJTJiM0Mzs1RkVKT0pvZExO LzZyOWdFWlUwRHBETTd4WWE8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4 IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpDb250 ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9JnF1b3Q7PT09PT09PT09PT09PT09 ODA4Nzc2NzQzNTM2MTg2NjY1MD09JnF1b3Q7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJt YXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9y bWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2 KTsiPg0KWC1PcmlnaW5hbC1UbzombmJzcDs8YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGZhLmFt c2wuY29tIiBjbGFzcz0iIj5vcHNhd2dAaWV0ZmEuYW1zbC5jb208L2E+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6 IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1FeGNoYW5nZS1BbnRpc3BhbS1SZXBvcnQtQ2ZhLVRlc3Q6 IEJDTDo3O1BDTDowO1JVTEVJRDooNjAxMDA0KSg3NjMwMDQ2KSgyNDAxMDQ3KSg1MjAwNzgpKDgx MjE1MDEwNDYpKDc2MzEwNDYpKDMwMDIwMDEpKDEwMjAxNTAxMDQ2KTtTUlZSOkNZMVBSMDcwMU1C MTA4MTtCQ0w6NztQQ0w6MDtSVUxFSUQ6O1NSVlI6Q1kxUFIwNzAxTUIxMDgxOzwvZGl2Pg0KPGRp diBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNv bG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClgtTXMtRXhjaGFuZ2UtVHJhbnNwb3J0LUNyb3NzdGVu YW50aGVhZGVyc3N0YW1wZWQ6IENZMVBSMDcwMU1CMTA4MTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBz dHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYs IDc2LCA3Nik7Ij4NClgtTXMtRXhjaGFuZ2UtT3JnYW5pemF0aW9uLUF1dGhhczogQW5vbnltb3Vz PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9u dC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGlj YSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1Ncy1FeGNoYW5nZS1Pcmdhbml6 YXRpb24tQXZzdGFtcC1TZXJ2aWNlOiAxLjA8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1h cmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYp OyI+DQpYLVNwYW0tRmxhZzogTk88L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjog MHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpY LU1haWxtYW4tVmVyc2lvbjogMi4xLjE1PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJn aW46IDBweCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsi Pg0KTGlzdC1BcmNoaXZlOiAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL2Jyb3dzZS9vcHNhd2cvIiBjbGFzcz0iIj5odHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvYnJvd3NlL29wc2F3Zy88L2E+Jmd0OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2 LCA3Nik7Ij4NCkxpc3QtVW5zdWJzY3JpYmU6ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL29wdGlvbnMvb3BzYXdnIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL29wdGlvbnMvb3BzYXdnPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86b3Bz YXdnLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZSIgY2xhc3M9IiI+bWFpbHRv Om9wc2F3Zy1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmU8L2E+Jmd0OzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6 ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1 ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClByZWNlZGVuY2U6IGxpc3Q8L2Rpdj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEy cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBj b2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpEZWxpdmVyZWQtVG86Jm5ic3A7PGEgaHJlZj0ibWFp bHRvOm9wc2F3Z0BpZXRmYS5hbXNsLmNvbSIgY2xhc3M9IiI+b3BzYXdnQGlldGZhLmFtc2wuY29t PC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7 IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2 ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClgtUHJvb2Zwb2ludC1WaXJ1 cy1WZXJzaW9uOiB2ZW5kb3I9ZnNlY3VyZSBlbmdpbmU9Mi41MC4xMDQzMjosLCBkZWZpbml0aW9u cz0yMDE1LTExLTMwXzA5OiwsIHNpZ25hdHVyZXM9MDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2 LCA3Nik7Ij4NClgtU3BhbS1MZXZlbDombmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9 Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3Niwg NzYpOyI+DQpYLU1zLUV4Y2hhbmdlLUNyb3NzdGVuYW50LUZyb21lbnRpdHloZWFkZXI6IEludGVy bmV0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsg Zm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZl dGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1NaWNyb3NvZnQtQW50aXNw YW06IFVyaVNjYW46O0JDTDo3O1BDTDowO1JVTEVJRDooNDIxMjUyMDAxKSgzMDAyMDE1KSg3MTcw MTAwMykoNzE3MDIwMDEpO1NSVlI6Q1kxUFIwNzAxTUIxMDgxOzwvZGl2Pg0KPGRpdiBjbGFzcz0i IiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2Io NzYsIDc2LCA3Nik7Ij4NClgtRW9wYXR0cmlidXRlZG1lc3NhZ2U6IDA8L2Rpdj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjog cmdiKDc2LCA3NiwgNzYpOyI+DQpSZWNlaXZlZDogZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9j eTFwcjA3MDFtYjEwODEubmFtcHJkMDcucHJvZC5vdXRsb29rLmNvbSIgY2xhc3M9IiI+Q1kxUFIw NzAxTUIxMDgxLm5hbXByZDA3LnByb2Qub3V0bG9vay5jb208L2E+Jm5ic3A7KDEwLjE2MC4xNDUu MTUzKSBieSZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9jeTFwcjA3MDFtYjEwODIubmFtcHJkMDcucHJv ZC5vdXRsb29rLmNvbSIgY2xhc3M9IiI+Q1kxUFIwNzAxTUIxMDgyLm5hbXByZDA3LnByb2Qub3V0 bG9vay5jb208L2E+Jm5ic3A7KDEwLjE2MC4xNDUuMTU0KQ0KIHdpdGggTWljcm9zb2Z0IFNNVFAg U2VydmVyIChUTFMpIGlkIDE1LjEuMzMxLjIwIHZpYSBNYWlsYm94IFRyYW5zcG9ydDsgVHVlLCAx IERlYyAyMDE1IDAwOjE1OjA2ICYjNDM7MDAwMDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i bWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3 Nik7Ij4NClJlY2VpdmVkOiBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cDovL2J5MnByMDdjYTA1NC5u YW1wcmQwNy5wcm9kLm91dGxvb2suY29tIiBjbGFzcz0iIj5CWTJQUjA3Q0EwNTQubmFtcHJkMDcu cHJvZC5vdXRsb29rLmNvbTwvYT4mbmJzcDsoMTAuMTQxLjI1MS4yOSkgYnkmbmJzcDs8YSBocmVm PSJodHRwOi8vY3kxcHIwNzAxbWIxMDgxLm5hbXByZDA3LnByb2Qub3V0bG9vay5jb20iIGNsYXNz PSIiPkNZMVBSMDcwMU1CMTA4MS5uYW1wcmQwNy5wcm9kLm91dGxvb2suY29tPC9hPiZuYnNwOygx MC4xNjAuMTQ1LjE1MykNCiB3aXRoIE1pY3Jvc29mdCBTTVRQIFNlcnZlciAoVExTKSBpZCAxNS4x LjMzMS4yMDsgVHVlLCAxIERlYyAyMDE1IDAwOjE1OjA1ICYjNDM7MDAwMDwvZGl2Pg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9y OiByZ2IoNzYsIDc2LCA3Nik7Ij4NClJlY2VpdmVkOiBmcm9tIEJOMUJGRk8xMUZEMDUwLnByb3Rl Y3Rpb24uZ2JsICgyYTAxOjExMTpmNDAwOjdjMTA6OjE6MTcxKSBieSZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly9ieTJwcjA3Y2EwNTQub3V0bG9vay5vZmZpY2UzNjUuY29tIiBjbGFzcz0iIj5CWTJQUjA3 Q0EwNTQub3V0bG9vay5vZmZpY2UzNjUuY29tPC9hPiZuYnNwOygyYTAxOjExMTplNDAwOjJjNjE6 OjI5KSB3aXRoIE1pY3Jvc29mdCBTTVRQIFNlcnZlciAoVExTKSBpZCAxNS4xLjMzMS4yMCB2aWEg RnJvbnRlbmQNCiBUcmFuc3BvcnQ7IFR1ZSwgMSBEZWMgMjAxNSAwMDoxNTowNCAmIzQzOzAwMDA8 L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250 LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNh IE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpSZWNlaXZlZDogZnJvbSZuYnNwOzxh IGhyZWY9Imh0dHA6Ly9teDBiLTAwMTcxMTAxLnBwaG9zdGVkLmNvbSIgY2xhc3M9IiI+bXgwYi0w MDE3MTEwMS5wcGhvc3RlZC5jb208L2E+Jm5ic3A7KDY3LjIzMS4xNTYuMjcpIGJ5Jm5ic3A7PGEg aHJlZj0iaHR0cDovL2JuMWJmZm8xMWZkMDUwLm1haWwucHJvdGVjdGlvbi5vdXRsb29rLmNvbSIg Y2xhc3M9IiI+Qk4xQkZGTzExRkQwNTAubWFpbC5wcm90ZWN0aW9uLm91dGxvb2suY29tPC9hPiZu YnNwOygxMC41OC4xNDUuNSkgd2l0aCBNaWNyb3NvZnQNCiBTTVRQIFNlcnZlciAoVExTKSBpZCAx NS4xLjMzMS4xMSB2aWEgRnJvbnRlbmQgVHJhbnNwb3J0OyBUdWUsIDEgRGVjIDIwMTUgMDA6MTU6 MDQgJiM0MzswMDAwPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHgg MHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWls eTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KUmVjZWl2ZWQ6 IGZyb20gcHBzLmZpbHRlcmQgKDxhIGhyZWY9Imh0dHA6Ly9tMDA0NDkwNS5wcG9wcy5uZXQiIGNs YXNzPSIiPm0wMDQ0OTA1LnBwb3BzLm5ldDwvYT4mbmJzcDtbMTI3LjAuMC4xXSkgYnkmbmJzcDs8 YSBocmVmPSJodHRwOi8vbXgwYi0wMDE3MTEwMS5wcGhvc3RlZC5jb20iIGNsYXNzPSIiPm14MGIt MDAxNzExMDEucHBob3N0ZWQuY29tPC9hPiZuYnNwOyg4LjE1LjAuNTkvOC4xNS4wLjU5KSB3aXRo IFNNVFAgaWQgdEIxMEJSVUkwMjIzMjggZm9yICZsdDs8YSBocmVmPSJtYWlsdG86c29iQGhhcnZh cmQuZWR1IiBjbGFzcz0iIj5zb2JAaGFydmFyZC5lZHU8L2E+Jmd0OzsNCiBNb24sIDMwIE5vdiAy MDE1IDE5OjE1OjA0IC0wNTAwPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBw eCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KUmVj ZWl2ZWQ6IGZyb20mbmJzcDs8YSBocmVmPSJodHRwOi8vbWFpbC5pZXRmLm9yZyIgY2xhc3M9IiI+ bWFpbC5pZXRmLm9yZzwvYT4mbmJzcDsoPGEgaHJlZj0iaHR0cDovL21haWwuaWV0Zi5vcmciIGNs YXNzPSIiPm1haWwuaWV0Zi5vcmc8L2E+Jm5ic3A7WzQuMzEuMTk4LjQ0XSkgYnkmbmJzcDs8YSBo cmVmPSJodHRwOi8vbXgwYi0wMDE3MTEwMS5wcGhvc3RlZC5jb20iIGNsYXNzPSIiPm14MGItMDAx NzExMDEucHBob3N0ZWQuY29tPC9hPiZuYnNwO3dpdGggRVNNVFAgaWQgMXlmOGtoOTdzMC0xDQog KHZlcnNpb249VExTdjEvU1NMdjMgY2lwaGVyPUVDREhFLVJTQS1BRVMyNTYtR0NNLVNIQTM4NCBi aXRzPTI1NiB2ZXJpZnk9Tk9UKSBmb3IgJmx0OzxhIGhyZWY9Im1haWx0bzpzb2JAaGFydmFyZC5l ZHUiIGNsYXNzPSIiPnNvYkBoYXJ2YXJkLmVkdTwvYT4mZ3Q7OyBNb24sIDMwIE5vdiAyMDE1IDE5 OjE1OjAzIC0wNTAwPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHgg MHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWls eTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KUmVjZWl2ZWQ6 IGZyb20mbmJzcDs8YSBocmVmPSJodHRwOi8vaWV0ZmEuYW1zbC5jb20iIGNsYXNzPSIiPmlldGZh LmFtc2wuY29tPC9hPiZuYnNwOyhsb2NhbGhvc3QgW0lQdjY6OjoxXSkgYnkmbmJzcDs8YSBocmVm PSJodHRwOi8vaWV0ZmEuYW1zbC5jb20iIGNsYXNzPSIiPmlldGZhLmFtc2wuY29tPC9hPiZuYnNw OyhQb3N0Zml4KSB3aXRoIEVTTVRQIGlkIDdCNTBGMUIyQUYyOyBNb24sIDMwIE5vdiAyMDE1IDE2 OjE1OjAxIC0wODAwIChQU1QpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBw eCAwcHggMHB4IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KUmVj ZWl2ZWQ6IGZyb20gbG9jYWxob3N0ICg8YSBocmVmPSJodHRwOi8vaWV0ZmEuYW1zbC5jb20iIGNs YXNzPSIiPmlldGZhLmFtc2wuY29tPC9hPiZuYnNwO1sxMjcuMC4wLjFdKSBieSZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly9pZXRmYS5hbXNsLmNvbSIgY2xhc3M9IiI+aWV0ZmEuYW1zbC5jb208L2E+Jm5i c3A7KFBvc3RmaXgpIHdpdGggRVNNVFAgaWQgRTMwQjgxQjMzQjEgZm9yICZsdDs8YSBocmVmPSJt YWlsdG86b3BzYXdnQGlldGZhLmFtc2wuY29tIiBjbGFzcz0iIj5vcHNhd2dAaWV0ZmEuYW1zbC5j b208L2E+Jmd0OzsNCiBNb24sIDMwIE5vdiAyMDE1IDE2OjE1OjAwIC0wODAwIChQU1QpPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsgZm9udC1zaXpl OiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVl JzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KUmVjZWl2ZWQ6IGZyb20mbmJzcDs8YSBocmVm PSJodHRwOi8vbWFpbC5pZXRmLm9yZyIgY2xhc3M9IiI+bWFpbC5pZXRmLm9yZzwvYT4mbmJzcDso WzQuMzEuMTk4LjQ0XSkgYnkgbG9jYWxob3N0ICg8YSBocmVmPSJodHRwOi8vaWV0ZmEuYW1zbC5j b20iIGNsYXNzPSIiPmlldGZhLmFtc2wuY29tPC9hPiZuYnNwO1sxMjcuMC4wLjFdKSAoYW1hdmlz ZC1uZXcsIHBvcnQgMTAwMjQpIHdpdGggRVNNVFAgaWQgUEFLVU83bTZwdTdCIGZvciAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmYS5hbXNsLmNvbSIgY2xhc3M9IiI+b3BzYXdnQGlldGZh LmFtc2wuY29tPC9hPiZndDs7DQogTW9uLCAzMCBOb3YgMjAxNSAxNjoxNDo1OSAtMDgwMCAoUFNU KTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZv bnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRp Y2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClJlY2VpdmVkOiBmcm9tJm5ic3A7 PGEgaHJlZj0iaHR0cDovL21haWwteWswLXgyMmMuZ29vZ2xlLmNvbSIgY2xhc3M9IiI+bWFpbC15 azAteDIyYy5nb29nbGUuY29tPC9hPiZuYnNwOyg8YSBocmVmPSJodHRwOi8vbWFpbC15azAteDIy Yy5nb29nbGUuY29tIiBjbGFzcz0iIj5tYWlsLXlrMC14MjJjLmdvb2dsZS5jb208L2E+Jm5ic3A7 W0lQdjY6MjYwNzpmOGIwOjQwMDI6YzA3OjoyMmNdKSAodXNpbmcgVExTdjEuMiB3aXRoIGNpcGhl ciBFQ0RIRS1SU0EtQUVTMTI4LUdDTS1TSEEyNTYNCiAoMTI4LzEyOCBiaXRzKSkgKE5vIGNsaWVu dCBjZXJ0aWZpY2F0ZSByZXF1ZXN0ZWQpIGJ5Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2lldGZhLmFt c2wuY29tIiBjbGFzcz0iIj5pZXRmYS5hbXNsLmNvbTwvYT4mbmJzcDsoUG9zdGZpeCkgd2l0aCBF U01UUFMgaWQgRjE3MEQxQjJBRjIgZm9yICZsdDs8YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYu b3JnIiBjbGFzcz0iIj5vcHNhd2dAaWV0Zi5vcmc8L2E+Jmd0OzsgTW9uLCAzMCBOb3YgMjAxNSAx NjoxNDo1OCAtMDgwMCAoUFNUKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAw cHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClJl Y2VpdmVkOiBieSB5a2RyODIgd2l0aCBTTVRQIGlkIHI4MnNvMjA0OTc4MDE1eWtkLjMgZm9yICZs dDs8YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIiBjbGFzcz0iIj5vcHNhd2dAaWV0Zi5v cmc8L2E+Jmd0OzsgTW9uLCAzMCBOb3YgMjAxNSAxNjoxNDo1OCAtMDgwMCAoUFNUKTwvZGl2Pg0K PGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTog MTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7 IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClgtU3BhbS1TdGF0dXM6IE5vLCBzY29yZT0tMS4y NzcgdGFnZ2VkX2Fib3ZlPS05OTkgcmVxdWlyZWQ9NSB0ZXN0cz1bQkFZRVNfMDA9LTEuOSwgREtJ TV9TSUdORUQ9MC4xLCBES0lNX1ZBTElEPS0wLjEsIEZNX0ZPUkdFRF9HTUFJTD0wLjYyMiwgSFRN TF9NRVNTQUdFPTAuMDAxXSBhdXRvbGVhcm49bm88L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9 Im1hcmdpbjogMHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3Niwg NzYpOyI+DQpYLU1zLUV4Y2hhbmdlLU9yZ2FuaXphdGlvbi1NZXNzYWdlZGlyZWN0aW9uYWxpdHk6 IEluY29taW5nPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4 IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog J0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KWC1Ncy1FeGNoYW5n ZS1Pcmdhbml6YXRpb24tU2NsOiAtMTwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2lu OiAwcHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4N ClgtUmVjZWl2ZWQ6IGJ5IDEwLjEyOS45My4xMzMgd2l0aCBTTVRQIGlkIHIxMjdtcjU0OTYyNTAx eXdiLjEwOS4xNDQ4OTI4ODk4MTE2OyZuYnNwOyBNb24sIDMwIE5vdiAyMDE1IDE2OjE0OjU4IC0w ODAwIChQU1QpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4 IDZweDsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog J0hlbHZldGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KTWVzc2FnZS1JZDog Jmx0OzxhIGhyZWY9Im1haWx0bzpDQUh3OV9pS2ViSGhuRTB3U3JBVkd5ejhzVkhYN2dNb1BGeSYj NDM7cmtyNVNvV3lBcUVmeEZRQG1haWwuZ21haWwuY29tIiBjbGFzcz0iIj5DQUh3OV9pS2ViSGhu RTB3U3JBVkd5ejhzVkhYN2dNb1BGeSYjNDM7cmtyNVNvV3lBcUVmeEZRQG1haWwuZ21haWwuY29t PC9hPiZndDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHgg NnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAn SGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpNaW1lLVZlcnNpb246 IDEuMDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCA2cHg7 IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdIZWx2 ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NClgtU3BhbS1TY29yZTogLTEu Mjc3PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDZweDsg Zm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZl dGljYSBOZXVlJzsgY29sb3I6IHJnYig3NiwgNzYsIDc2KTsiPg0KTGlzdC1TdWJzY3JpYmU6ICZs dDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L2E+ Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzpvcHNhd2ctcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0 PXN1YnNjcmliZSIgY2xhc3M9IiI+bWFpbHRvOm9wc2F3Zy1yZXF1ZXN0QGlldGYub3JnP3N1Ympl Y3Q9c3Vic2NyaWJlPC9hPiZndDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjog MHB4IDBweCAwcHggNnB4OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyBjb2xvcjogcmdiKDc2LCA3NiwgNzYpOyI+DQpS ZTogW09QU0FXR10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGFobS1v cHNhd2ctdGFjYWNzLTAxLnR4dDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAw cHggMHB4IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4 IDBweCA2cHg7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IGNvbG9yOiByZ2IoNzYsIDc2LCA3Nik7Ij4NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSIiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyI+RGVhciBPcHNBV0csDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgY2hhaXJzIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBzdWZm aWNpZW50IGludGVyZXN0IGFuZCBzdXBwb3J0IHRvIGFkb3B0IHRoaXMgZG9jdW1lbnQgYXMgYW4g T3BzQVdHIGRvY3VtZW50LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+QXV0aG9ycywgcGxlYXNlIHJlc3VibWl0IGFzJm5ic3A7ZHJhZnQt aWV0Zi1vcHNhd2ctdGFjYWNzLTAxPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV29ya2lu ZyBncm91cDombmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2Ugd291bGQgbGlrZSB0byBzZWUg dGhpcyBkb2N1bWVudCBwcm9ncmVzcywgYW5kIGFyZSBob3BpbmcgdG8gV0dMQyBpdCBzb29uLiBQ bGVhc2UgcmV2aWV3IHRoaXMgYW5kIHByb3ZpZGUgZmVlZGJhY2suLi4uPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9IiI+T24gRnJpLCBOb3YgMTMsIDIwMTUgYXQgMTozNyBQTSBXYXJyZW4gS3VtYXJp ICZsdDs8YSBocmVmPSJtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQiIGNsYXNzPSIiPndhcnJlbkBr dW1hcmkubmV0PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBi b3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAy MDQpOyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDogMWV4OyI+DQpXZSB3 b3VsZCByZWFsbHkgYXBwcmVjaWF0ZSBhbnkgZmVlZGJhY2sgb24gdGhpcyBkb2N1bWVudC4gUGVy c29uYWxseSBJPGJyIGNsYXNzPSIiPg0KdGhpbmsgaXQgaXMgcmVhbGx5IHVzZWZ1bCwgYnV0IHdl IG5lZWQgdGhlIFdHIHRvIHJldmlldyBhbmQgcHJvdmlkZTxiciBjbGFzcz0iIj4NCmZlZWRiYWNr LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk92ZXIgdGhlIHllYXJzIEkndmUgaGVhcmQg YSBudW1iZXIgb2YgcGVvcGxlIGt2ZXRjaCB0aGF0IFRBQ0FDUyYjNDM7IGlzbid0PGJyIGNsYXNz PSIiPg0KZG9jdW1lbnRlZCAtLSB3ZWxsLCBub3cgeW91IGNhbiwgeW91IGtub3csIGFjdHVhbGx5 IGRvIHNvbWV0aGluZyBhYm91dDxiciBjbGFzcz0iIj4NCnRoaXMuLi48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpXPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gU3VuLCBPY3Qg NCwgMjAxNSBhdCA0OjE4IFBNLCBEb3VnbGFzIEdhc2ggKGRjbWdhc2gpPGJyIGNsYXNzPSIiPg0K Jmx0OzxhIGhyZWY9Im1haWx0bzpkY21nYXNoQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPmRjbWdhc2hAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0 OyBEZWFyIE9wc2F3ZyBMaXN0LDxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 IFdlIGhhdmUgdXBsb2FkZWQgYSBzZWNvbmQgcmV2aXNpb24gb2YgdGhlIFRBQ0FDUyYjNDM7IHBy b3RvY29sIHNwZWNpZmljYXRpb248YnIgY2xhc3M9IiI+DQomZ3Q7IHdoaWNoIHdlIGJlbGlldmUg aXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIHN1YmplY3Qgc3ViamVjdCB0byBwb3J0PGJyIGNsYXNz PSIiPg0KJmd0OyBhbGxvY2F0aW9uLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7IFBsZWFzZSBzZWUgZGV0YWlscyBiZWxvdy48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyBUaGUgZXNzZW50aWFsIGRpZmZlcmVuY2UgZnJvbSB0aGUgZmlyc3QgcmV2aXNp b24gaXMgdGhlIGNoYW5nZSBvZiBUTFM8YnIgY2xhc3M9IiI+DQomZ3Q7IG9wdGlvbiBzdXBwb3J0 IHVzaW5nIGEgc2VwYXJhdGUgcG9ydCBhcyBvcHBvc2VkIHRvIHRoZSBvcmlnaW5hbCBTdGFydCBU TFM8YnIgY2xhc3M9IiI+DQomZ3Q7IG1lY2hhbmlzbS48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyBXZSB3b3VsZCBiZSB2ZXJ5IGdyYXRlZnVsIGZvciB0aGUgb3BpbmlvbiBv ZiB0aGUgbGlzdCByZWdhcmRpbmcgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyBzdWl0YWJpbGl0eSBv ZiBkb2N1bWVudCBmb3IgcHVibGljYXRpb24gYXMgYW4gUkZDLjxiciBjbGFzcz0iIj4NCiZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7IE1hbnkgdGhhbmtzLDxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7IFRob3JzdGVuLCBBbmRyZWosIERvdWcuPGJyIGNsYXNzPSIiPg0KJmd0Ozxi ciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IE9uIDAyLzEwLzIwMTUgMTY6MjUs ICZxdW90OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIiBjbGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRhaG0tb3BzYXdn LXRhY2Fjcy0wMS50eHQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2hhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgRG91Z2xhcyBDLiBNZWR3YXkgR2FzaCBhbmQgcG9zdGVkIHRvPGJyIGNs YXNzPSIiPg0KJmd0OyZndDt0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O0lFVEYgcmVwb3NpdG9y eS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7TmFtZTombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWRhaG0tb3BzYXdnLXRhY2Fjczxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7UmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMDE8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0O1RpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtUaGUgVEFDQUNTJiM0MzsgUHJvdG9jb2w8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O0RvY3VtZW50 IGRhdGU6IDIwMTUtMTAtMDI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O0dyb3VwOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0O1BhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszODxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7VVJMOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfaW50ZXJuZXQtMkRkcmFmdHNfZHJhZnQtMkRkYWhtLTJEb3BzYXdnLTJEdGFjYWNzLTJE MDEudHh0JmFtcDtkPUN3TUZhUSZhbXA7Yz1XTy1SR3ZlZmliaEhCWnEzZkw4NWhRJmFtcDtyPXlx ZlAzSDlXNU13SEd3ZnVqYXl2encmYW1wO209ZDJ6a2JFS3RNN3pySnVRSjRQdll0dnBaSEc0aGN2 aHVjdWhPYjAzeTFBRSZhbXA7cz12eXlwc2dMdjR4VTlaUlhLRGM4WmtodnM1bENhSGxlRnRHZjVy allrNTR3JmFtcDtlPSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRhaG0tb3BzYXdnLXRh Y2Fjcy0wMS50eHQ8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDtTdGF0dXM6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0 LTJEZGFobS0yRG9wc2F3Zy0yRHRhY2Fjc18mYW1wO2Q9Q3dNRmFRJmFtcDtjPVdPLVJHdmVmaWJo SEJacTNmTDg1aFEmYW1wO3I9eXFmUDNIOVc1TXdIR3dmdWpheXZ6dyZhbXA7bT1kMnprYkVLdE03 enJKdVFKNFB2WXR2cFpIRzRoY3ZodWN1aE9iMDN5MUFFJmFtcDtzPXBpMnVvU1I4Q0V1QUpWWl80 ZEdUY1JPTGI4Q0J2WFkwLVh1M0VzbDdhakkmYW1wO2U9IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1kYWhtLW9wc2F3Zy10YWNhY3MvPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7SHRtbGl6ZWQ6 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0 LTJEZGFobS0yRG9wc2F3Zy0yRHRhY2Fjcy0yRDAxJmFtcDtkPUN3TUZhUSZhbXA7Yz1XTy1SR3Zl ZmliaEhCWnEzZkw4NWhRJmFtcDtyPXlxZlAzSDlXNU13SEd3ZnVqYXl2encmYW1wO209ZDJ6a2JF S3RNN3pySnVRSjRQdll0dnBaSEc0aGN2aHVjdWhPYjAzeTFBRSZhbXA7cz1NenMyNEVKbUs0TGl6 UWQ5cFptNjBER0VVOVZMOGxQRHU0ZzRNNHNlQ05VJmFtcDtlPSIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWRhaG0tb3BzYXdnLXRhY2Fjcy0wMTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O0RpZmY6PGJy IGNsYXNzPSIiPg0KJmd0OyZndDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19yZmNkaWZmLTNGdXJsMi0zRGRy YWZ0LTJEZGFobS0yRG9wc2F3Zy0yRHRhY2Fjcy0yRDAxJmFtcDtkPUN3TUZhUSZhbXA7Yz1XTy1S R3ZlZmliaEhCWnEzZkw4NWhRJmFtcDtyPXlxZlAzSDlXNU13SEd3ZnVqYXl2encmYW1wO209ZDJ6 a2JFS3RNN3pySnVRSjRQdll0dnBaSEc0aGN2aHVjdWhPYjAzeTFBRSZhbXA7cz1nekl2b0FSSkdU ZE9zS1V2LUJHbzZWcnJMeGlHcGtsZEZ4dUd2RXJwckQwJmFtcDtlPSIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWRhaG0tb3BzYXdnLXRhY2Fjcy0wMTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7QWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7VEFDQUNTJiM0MzsgcHJvdmlkZXMgYWNjZXNzIGNvbnRyb2wgZm9yIHJvdXRl cnMsIG5ldHdvcmsgYWNjZXNzIHNlcnZlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDthbmQgb3RoZXIgbmV0d29ya2VkIGNvbXB1dGluZyBkZXZpY2VzIHZpYSBvbmUgb3IgbW9y ZSBjZW50cmFsaXplZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO3NlcnZlcnMu Jm5ic3A7IFRBQ0FDUyYjNDM7IHByb3ZpZGVzIHNlcGFyYXRlIGF1dGhlbnRpY2F0aW9uLCBhdXRo b3JpemF0aW9uIGFuZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO2FjY291bnRp bmcgc2VydmljZXMuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBwcm90b2NvbCB0 aGF0IGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7dXNlZCBieSBUQUNBQ1Mm IzQzOy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDtQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7c3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7dW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190b29scy5pZXRmLm9yZyZh bXA7ZD1Dd01GYVEmYW1wO2M9V08tUkd2ZWZpYmhIQlpxM2ZMODVoUSZhbXA7cj15cWZQM0g5VzVN d0hHd2Z1amF5dnp3JmFtcDttPWQyemtiRUt0TTd6ckp1UUo0UHZZdHZwWkhHNGhjdmh1Y3VoT2Iw M3kxQUUmYW1wO3M9alAzVll5c2RFRW1EYXNzQVVybG55NF9aWWI0WTY5cWlaeUs0X1A2TzBwUSZh bXA7ZT0iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnRvb2xzLmll dGYub3JnPC9hPi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 VGhlIElFVEYgU2VjcmV0YXJpYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQotLTxiciBjbGFzcz0iIj4NCkkgZG9uJ3QgdGhpbmsgdGhlIGV4ZWN1dGlvbiBpcyBy ZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQ8YnIgY2xhc3M9IiI+DQppZGVhIGlu IHRoZSBmaXJzdCBwbGFjZS48YnIgY2xhc3M9IiI+DQpUaGlzIGlzIGxpa2UgcHV0dGluZyByYWJp ZCB3ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nPGJyIGNsYXNzPSIi Pg0KcmVncmV0IGF0IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxz IGFuZCB0aGF0IHBhaXI8YnIgY2xhc3M9IiI+DQpvZiBwYW50cy48YnIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7LS0tbWFmPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvc3Bhbj48YnIgY2xhc3M9IiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7Ij4NCjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyI+T1BTQVdHIG1haWxpbmcg bGlzdDwvc3Bhbj48YnIgY2xhc3M9IiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7Ij4NCjxhIGhyZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciIGNs YXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyI+T1BTQVdHQGlldGYub3JnPC9h PjxiciBjbGFzcz0iIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vcHNhd2ciIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L2E+PC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EA0DF28481B54F5C99E850CD2B878EACharvardedu_-- From nobody Fri Feb 12 08:47:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89EC1A6FB0 for ; Fri, 12 Feb 2016 08:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ILFg2kAc2fx3 for ; Fri, 12 Feb 2016 08:47:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6391A6FCA for ; Fri, 12 Feb 2016 08:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2499; q=dns/txt; s=iport; t=1455295619; x=1456505219; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Jz742KRMSS9RMePJ7XBF3Dfycnt9ta0ZykCtRSv7Zew=; b=dX5+vEct9KeW28beJt4qft1IJFENOOZ6e6Uk29NeW4Mx5iy0B1gBYw4r FiR8zfwDN9yssdQxk1nRbIcEO5PUrkZlolXgjBItoMDwvwVxF7wQxoGmd 3SIjRELhDkgYJiGH/eAMy2lSJXpGKXNWuG6UgC2W6ODZirzPth0MkJRKd w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDTC75W/4sNJK1egzpSbQaIVbEyA?= =?us-ascii?q?Q2BZxcKhSJKAoE4OBQBAQEBAQEBfwuEQQEBAQQBAQFLIBsCAQgRAwECAQwiJwo?= =?us-ascii?q?BHQgCBBMdBId5DsFsAQEBAQEBAQEBAQEBAQEBAQEBARMEikeEAhEBJIQ0BYdTh?= =?us-ascii?q?gyJGAGNVIFehEOIVY49AR4BAUKDZGqGejR8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,436,1449532800"; d="scan'208";a="76422135" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2016 16:46:59 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1CGkwVB030911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 Feb 2016 16:46:58 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 12 Feb 2016 10:46:58 -0600 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.1104.009; Fri, 12 Feb 2016 10:46:58 -0600 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: OPSAWG Digest, Vol 105, Issue 92 Thread-Index: AQHRZbNVrn4JXdHy7U2ZhSqtY4kzrJ8pAx+A Date: Fri, 12 Feb 2016 16:46:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.108.248] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <36F5396E70170A489521CEBF3E0CEBA5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 92 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:47:13 -0000 We=B9d be more than happy to split into two documents, the first being a tidy up of the current deployed protocol, but focussed towards the device admin use case as we discussed yesterday, and a second to deal with the crypto issue in a backwards-compatible way. It sounds like this would help de-muddy some waters. On 12/02/2016 16:34, "OPSAWG on behalf of opsawg-request@ietf.org" wrote: >Send OPSAWG mailing list submissions to > opsawg@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsawg >or, via email, send a message with subject or body 'help' to > opsawg-request@ietf.org > >You can reach the person managing the list at > opsawg-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OPSAWG digest..." > > >Today's Topics: > > 1. Re: TACACS+, a suggestion (Alan DeKok) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 12 Feb 2016 11:34:40 -0500 >From: Alan DeKok >To: Eliot Lear >Cc: opsawg@ietf.org >Subject: Re: [OPSAWG] TACACS+, a suggestion >Message-ID: >Content-Type: text/plain; charset=3Dus-ascii > > >> On Feb 12, 2016, at 10:46 AM, Eliot Lear wrote: >>=20 >> Hi Stefan, >>=20 >> Unless it is absolutely determined that the current work can't doesn't >>meet criteria for an IETF standard, I would be opposed to such an >>exercise. For one thing, we all have other things to do. For another, >>and as or more important, we would be denying the reality of the >>situation. > > The reality is that the TLS portion documented in the draft isn't >implemented anywhere. > > I find it telling that the work is important enough to push through the >WG, but not important enough that (as you say) the authors have other >things to do... and don't have the time to document old work as different >from new work. > > Alan DeKok. > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 105, Issue 92 >*************************************** From nobody Fri Feb 12 08:51:56 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5899E1A6FD9 for ; Fri, 12 Feb 2016 08:51:54 -0800 (PST) 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] autolearn=ham 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 Eb6FV88AEq8b for ; Fri, 12 Feb 2016 08:51:52 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id B56E61A6FD0 for ; Fri, 12 Feb 2016 08:51:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 1B405CAC; Fri, 12 Feb 2016 16:51:52 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtrrcXUOSXsZ; Fri, 12 Feb 2016 16:51:52 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 641CE490; Fri, 12 Feb 2016 16:51:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Fri, 12 Feb 2016 11:51:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> <56BCE503.7000107@direcpath.com> <484DE7E8-363F-45EE-B521-78E53E0582C1@deployingradius.com> <56BDDD6A.8040902@restena.lu> To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:51:54 -0000 On Feb 12, 2016, at 11:34 AM, Warren Kumari wrote: > That is working on the assumption that the reason that operators are = using TACACS+ instead of RADIUS is /only/ because of this feature. In = many cases it is also because operators already have TACACS servers = installed and / or find TACACS+ *much* simpler to deploy and manage. Please suggest which operators use TACACS+ for general user = authentication, roaming, etc. I'm unaware of any TACACS+ roaming consortium. I'm aware of multiple = RADIUS / Diameter roaming consortium. Please suggest *why* TACACS+ is simpler to deploy and manage than = RADIUS servers. That statement is... surprising, to be polite. = Installing and configuring a new networking daemon is a matter of a few = minutes on any modern Unix distribution. > RADIUS is a grand protocol - it has many bells and whistles and extra = functionality, but e.g: shrubbery's tac_plus is free, comes with many = distributions, and is dead simply to install and configure. So? As a biased person, FreeRADIUS is free, comes with *all* = distributions, and is dead simple to install and configure. It's = packaged with every single Unix distribution on the planet. It's = shipped by essentially every network equipment manufacturer other than = Cisco, Alcatel-Lucent, and Juniper as their embedded RADIUS solution. = It supports all of the relevant RADIUS RFCs. It *alone* has probably = 10x the install base of all of the TACACS+ servers, combined, = world-wide. Simple "it's popular" is no argument. I say this as the author of the = most popular RADIUS server on the planet. Heck, it supports DHCP, BFD, and we're working on Diameter support. Again.. so? Alan DeKok. =20 From nobody Fri Feb 12 09:16:46 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2AF1A702E for ; Fri, 12 Feb 2016 09:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.564 X-Spam-Level: **** X-Spam-Status: No, score=4.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 CKRfaqfA6SSv for ; Fri, 12 Feb 2016 09:16:35 -0800 (PST) Received: from smtp.restena.lu (legolas.restena.lu [158.64.1.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C751A701A for ; Fri, 12 Feb 2016 09:16:34 -0800 (PST) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id BB999BB74C; Fri, 12 Feb 2016 18:16:32 +0100 (CET) To: "Bradner, Scott" , "opsawg@ietf.org" References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 X-Enigmail-Draft-Status: N0111 Message-ID: <56BE136F.7030905@restena.lu> Date: Fri, 12 Feb 2016 18:16:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9vHw3VxG0sODmdntKLwGhjp6UF9ec3fn3" Archived-At: Cc: "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 17:16:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9vHw3VxG0sODmdntKLwGhjp6UF9ec3fn3 Content-Type: multipart/mixed; boundary="------------040507000800030709030305" This is a multi-part message in MIME format. --------------040507000800030709030305 Content-Type: multipart/alternative; boundary="------------010006090306080903070704" --------------010006090306080903070704 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > 30 November: 2015: Warren sent the following message to the opsawg:=20 > (for some reason this message does not show up in the archive but a > copy is=20 > appended to this message) > > The chairs believe that there is sufficient interest and support > to adopt > this document as an OpsAWG document. =20 > > Authors, please resubmit as draft-ietf-opsawg-tacacs-01 This appears to be factually incorrect. My mail folder for opsawg has no mail on the day of 30 Nov 2015. Given that the mail headers contain lots of SPF: fail verdicts, I also checked my spam folder. Nothing. If the mail is not in the archive, maybe it actually didn't reach a significant fraction of the subscribers? In that case, it should not come as a surprise that some people feel like this was conducted in a ... strange... manner. I do see Warren's mail from 13 Nov BTW, and that one has no SPF fail headers (at least for me, that one did not look like an adoption call so it missed my brain filter; but that's just me). Maybe others could check their archives to see what has or has not arrived on the list. I would also appreciate if the actual reason why the archive did not get/reject the message. "For some reason" is a bit too unspecific to be useful IMHO... Greetings, Stefan Winter > > 16 December 2015 - renamed ID published > > > By asking the working group list for input on the question of adopting = an > ID as a working group document the opsawg chairs followed one of the > normal IETF process to determine if there was enough interest for the > working group to adopt the TACACS+ ID as a working group topic. We not= e > in passing that such another normal process is for the WG chairs to dec= ide > on their own to adopt a document as a working group topic. We also fel= t > that the topic was sufficiently within the working group charter to do = so > without a specific charter update. > > Thus Mr. DeKok's appeal as to the adoption of the ID as a working group= > topic is rejected. If Mr. DeKok believes that this does not satisfy his= > concerns, we refer him to RFC 2026, Section 6.5 for the next steps in t= he > appeal process. > > Scott Bradner > Warren Kumari > 12 February 2016 > > > =97----------------------------- > To: opsawg@ietf.org =20 > X-Ms-Exchange-Transport-Endtoendlatency: 00:00:01.8093445 > X-Forefront-Antispam-Report: > CIP:67.231.156.27;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:SKN;SFS:;DIR:INB;= SFP:;SCL:-1;SRVR:CY1PR0701MB1081;H:mx0b-00171101.pphosted.com > ;FPR:;SPF:None;LANG:en; > Spamdiagnosticmetadata: 7460966b2fd248469deae02cb8f82730 > X-Ms-Exchange-Crosstenant-Id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 > List-Id: OPSA Working Group Mail List > > X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); > Archived-At: > > X-Virus-Scanned: amavisd-new at amsl.com > X-Ms-Exchange-Organization-Authsource: BN1BFFO11FD050.protection.gbl > X-Google-Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; > d=3D1e100.net ; s=3D20130820; > h=3Dx-gm-message-state:mime-version:references:in-reply-to:from:date > :message-id:subject:to:content-type; > bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; > b=3DPsPRkLaCtAuWcQ9uh6l4qAyrI8koo4a5hbTbiJ+XC+FfQfvyF8xTabi2i41y4arQMJ > YCg0o0IgxVGCcCMaeocHg7jl23rBlc5Q+SSSPyUNyNBS6plN8uTXGWruR487LFPDUJ/f > PEFkyga3mSPU/LR3NqFJdZw1vxNt0JXQjXHt7cKfDfDGs1KD/yziL3aFWJWEDpD3iqAs > 2Ez4z3anmkMVgLaxUTnQDf9sgPjwYNUlCRbgfoHSO/L9kKQprVQ9duUVdn7A+KmzHWGL > WHtrG8QsySj8hj5J2Y1OJSFvyz3wBELGgQR/Xl4hGiyoGZdwL06RKvuO7FqoFHA/Kq5M > sFAg=3D=3D > X-Ms-Exchange-Crosstenant-Originalarrivaltime: 01 Dec 2015 > 00:15:04.5170 (UTC) > X-Proofpoint-Spam-Details: rule=3Dnotspam policy=3Ddefault > score=3D0 kscore.is _bulkscore=3D0 > kscore.compositescore=3D1 compositescore=3D0.9 suspectscore=3D2 > malwarescore=3D0 phishscore=3D0 bulkscore=3D0 kscore.is > _spamscore=3D0 rbsscore=3D0.9 spamscore=3D0 > urlsuspectscore=3D0.9 adultscore=3D0 classifier=3Dspam adjust=3D0 reaso= n=3Dmlx > scancount=3D1 engine=3D8.0.1-1507310000 definitions=3Dmain-1512010002 > Sender: "OPSAWG" > > List-Help: > X-Ms-Exchange-Organization-Network-Message-Id: > d55618f2-7475-4530-c456-08d2f9e47660 > List-Post: > Authentication-Results: spf=3Dfail (sender IP is 67.231.156.27) > smtp.mailfrom=3Dietf.org ; harvard.edu > ; dkim=3Dfail (body hash did not verify) > header.d=3Dietf.org ;harvard.edu ;= > dmarc=3Dnone action=3Dnone header.from=3Dkumari.net = ; > Spamdiagnosticoutput: 1:2 > X-Beenthere: opsawg@ietf.org > Return-Path: opsawg-bounces@ietf.org > References: <20151002152505.26594.74925.idtracker@ietfa.amsl.com > > > > > > > Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org= > ; s=3Dietf1; t=3D1448928901; > bh=3Dpvt1kSVXuErtfU5ZWISQikMRPQYfDp05mGMYsb+SFcI=3D; > h=3DMIME-Version:References:In-Reply-To:From:Date:Message-ID:To: > Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: > List-Subscribe:Content-Type:Sender; > b=3DZRweO7Tp3Xq/v7MwtQY7Bq6Jbp5tU+2+++F0dEQALPEVXTbQ++h45JzxLZyES8ikI > ok6ibFCR0Mkw1P1O6EQM3tIwQlLD6Xl1KnsDn74aUUD6RvQ+dD5P0gctrn1SuGiQ8T > jY5RD5B1YE7gpvyMoEYoDve3GiDolWuuyclQFdko=3D > Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; > d=3Dkumari-net.20150623.gappssmtp.com > ; s=3D20150623; > h=3Dmime-version:references:in-reply-to:from:date:message-id:subject:to= > :content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; > b=3DtRm8MTHNrVMLwiQrHd7XMteT2khz1LCvlSrKQHk3ELC5CCOUKybfJUCUwVwxirEqnX > fRpqiwO5pRPvSr+HyvnEf7e0RDpmxWnwne7H35NxkmMHpbxVQP+W15sB/NBcGkhpTc/J > wS/tTGwxxOempxpXCkVwGZ08QXrfMtCk6BkzYWGWhAhpwmVO+JCpglvaZXe4kH7bhh5g > hOAZJWp/uSzO/l1Fm27xgt57veT1LyZoIwQpcCRhzaA/jKOnfiUt0i4k07mc16U5LWoS > x4Oa27VmHq1szNAU6hIwCqVJbgacuCB/+vjNM2SyOLuSBctWHJ5ldTY662XDkeBl7kNu > YEAg=3D=3D > X-Matching-Connectors: > 130934025046730165;(d93d0180-227e-457c-4499-08d2eaec9703,256b2f12-4edf-= 4bba-ca8a-08d1766a767f,4c2fb881-fd60-47c4-27de-08d1a9464aaf,d8bbbf0d-8e19= -4272-9345-08d1b65cb793,751b4e9e-d4fb-44bf-a131-08d1dc9823e4,e0068ebf-014= b-4c73-793a-08d2f1dcc743,ac01cf0c-e967-495c-3fa9-08d1e70141cd,2808f1c2-2c= 2f-483e-3d80-08d1dfb2fe99,f9e899bb-1cc2-41db-5fa0-08d071a1a76e,3dfa065d-6= d09-41e4-03d6-08d1999434e1,8f72f349-eac7-4ca2-5909-08d1f4d6bd8f);(fc40b7b= 3-9d92-4bad-511b-08d1429671f0,f044a6d7-98b9-4c10-91b4-08d210413fe9,27bd2d= ba-e8c1-4f61-5bcb-08d2e63a1f24,6437d2a5-7830-487a-b613-08d2d5a0d354,d3806= 232-5d13-4149-28ff-08d1dec60473,dbc00d3f-cf39-4d73-fd34-08d1ba252138,9adb= 280f-4fbe-49ab-17ad-08d0c8b1feb2,70fb42a1-9688-41b6-d810-08d1b07b4924) > Errors-To: opsawg-bounces@ietf.org > Received-Spf: Fail (protection.outlook.com > : domain of ietf.org > does not designate 67.231.156.27 as permitted > sender) receiver=3Dprotection.outlook.com > ; client-ip=3D67.231.156.27; > helo=3Dmx0b-00171101.pphosted.com ; > X-Microsoft-Exchange-Diagnostics: > 1;BN1BFFO11FD050;1:7ZN9YK7xDF/YOFqgSF/Kt7SEuRl6m82TEEFS5pjj0L9WZ2XsjsoK= 06RHQoqp0zZJOqzHLsK7p62sRC/+dl0NHewnxWHjlYkFlErO0QxPu3bkMMMWFDL0D1gNkNNAL= QMEcCEwMN1E+sHfvWqfShtOpPbseWAIU0wFbf+THNAsZ0poUqywVPIeJRTJ27KhrMzdvfCBdI= h8IvZ5UF+i5/30Lwu90TwhHBydQj9impHXhJzz6cchwyC+cZByHdxbhbkikaFU2ORf9xwBx/d= wA6acnIYurcZxXE6rI4nl6Z+1j2pTmTRov/u+6965Gn47kV1qSjmeeWQq1+Jsqg0nQP0LqvWX= 6Cygd4/KgcYExishE7nivKVZq72r4lJb+0eaMswT/63GpfiTqVx21+UBx3NKvMulQSqG9Gizk= 6aBns/3BJrRmYi0j5iGr+dfbx0LymzdOdOFUfmgTIYGJGhjO701+aLnQHD7VrB1FBD2W7/zJi= WnJr5rxHNe0uP28JUnb6+5lr/fewGEZZ4jImQ+RbfZbw=3D=3D > X-Microsoft-Exchange-Diagnostics: > 1;CY1PR0701MB1081;2:W1i0t4PGHpWZpZGn0gwqccaOVv2u49nkFSof3JBlrQuQJwcKl9Y= 2wDeVl5A9iErzqOJItTyPziqfAt7KyGEax9rM95tiKtjcxgzwzjQjiqQFpGgTHF1Q/mY+w1og= 6GEQgS4XgMDljIAumw4tSpiQLA=3D=3D;3:BKRbPmRM5q+4prHbMMl1pl1ZZ2tS0rVGiw7aEH= 1Cq7HPVNxaYdiJOPc4/BJYvodVY1vbr67qwwATIDtXfVie9db2RjBDjxQWPRY5zXwlnI582Jv= vSd3uxAI1YZzAFgcWkt7sCG2ZuD2Nym9vBxvHl7WD5sUdx2tr8izLC86dMugMDG0IyhzPFEfr= 9B0mswrrXtD3XPjkoCi/NAC/ihsDyV4LoM3/Kd4he2AayTNrxq7+itBmev+RI6m84iRRzIxuK= /Qbd5vCfSbIsrCkmcxqVlgzXkMxrUazuheTQDsGM0gK2MaZaMTBhdk+8KyD4u2b;25:78MIti= 2YLv9i038KUTfSvspXHFS1JtJYQgWUyzyoiB4b3M+szJyih+58z81aUvYrNTmZCYWxeNbJxOq= cSEnFD/tFLF7lEod2v8DhzNxAdXfJlAcv/35AqU99iwL0MzdeiGdV0hWIfIoVGEM6rn12InmN= NZ5+H4mFspZlpFJBmC99ylYHhnYeRTvpCjhE26D9ry85Uq8vNQ7T7vG1qWT8sB8ZYFRgdnmOZ= lEZiDrmOMlFIc+4htsemKRufgfcZGhCaZM218PwPk9YqrrKaDAPNg=3D=3D > X-Microsoft-Exchange-Diagnostics: > 1;CY1PR0701MB1081;20:PdLuCCyiCFshW0NdPnC8eBojhNvmPTsHv/4UFnq2/Ap13ChYoz= GcdEqkVUoCDgV6xCnbV2sch84G9YqciCrAqpBOC+P+Jadb/xWosqipDjCzZzQB38ah3V+4Bdn= bm37aWs527QTdFX74o319rkRkpfQW5lZBUE/+akaLk3iPOSDGklLOcMMzk5E6MUkg1FCxeTSC= RbEJI7C8Gcfkp4Z33sWwZ4l4nZsTryQjFNwUnKD35K3vVXCSTUr9mHEed86B;4:ZkdYP0b+re= AAtcSPR/s6gs/4xtl2BduQqcuxMWhnPArjFsyI7D8qxhJzegLJImmIurwvGNuAuPAEBVnzfKk= 7Uk8KmXurz5VrNWWXz9H9kX5I2iSoY82hbOGqpxoKZN7ZvT4eNnkftfwEBBb6cJWbLX2wJr1G= hZQStKHhnKOXCtnWTG1bCOsAlUFzO4fcQrK1871zmJYcVLFeXs2soxq6zRVidnUVx5aVcz1fb= UW1pYYi7SVTmKUxHgDHpBlhE2M7IsQCf2/z8jspwHR2/Ca4QwfTsBOwrzlBeHryjxjGwDLah0= Sq5W9fy5doXLWj6Zp5Hd+78AnQKQjTLJoJzeypO8JVtyeXqv0y/UpPjXENphbC674cRQEyEho= yLOWypuJeUP9XukINATvVEdgJnCHepkJSOHSZQea9zGKnTHazYjoG79eK1lsLgx2Uersmxtwz= ;23:4EKpER/Wex7l7yJjNu6NCf/OL8GUvFcTfH03V6f1kyvAD+1i3rMhMIMUTaS5RuFVEBIT+= 1hV2YemnNtNCejbQsscJK47MvrYffu1Y4FWysZHwmuW5Z8YY19Z55gg/bBjgeHwuc/ECiG+G5= 4mZGKtdkuN1f6XkkJRlk9b5miEeMYyeSa/DeEi+1X+/69BTaHhVmdsOnEIiXOEmwKmURBUbA=3D= =3D > X-Microsoft-Exchange-Diagnostics: > 1;CY1PR0701MB1081;5:NDmSUNkFZijBwPfECIN39/nKL9SZpZQoXf83DdYdG6c6uqvKq9p= FL11zCIluGBfbfr7j8GHWoHjCFpbx7VYG1+pJWsbw3uKmx12woMpxVU2oaxoV8Tb44v0zoaB1= O2FhE9sZbcp5E+k+VFpjT7mxIQ=3D=3D;24:oRXQcwEWxPCuqn5UAzNUq6ABuuvQYLIsu5Ibt= KyT8I8selWffYvnEZgXF6cORNZqS7B2xyDLy5FjzmcmEVLIXOyOiXuHI1QWDuagZnryAws=3D= > In-Reply-To: > > > X-Dkimresult-Test: Failed > X-Gm-Message-State: > ALoCoQkPLNgOMt4FMOCWAKl2MLYDSZRuN/UoBjBSG0VRor2S+5FEJOJodLN/6r9gEZU0DpD= M7xYa > Content-Type: multipart/mixed; > boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D80877674353618= 66650=3D=3D" > X-Original-To: opsawg@ietfa.amsl.com > X-Exchange-Antispam-Report-Cfa-Test: > BCL:7;PCL:0;RULEID:(601004)(7630046)(2401047)(520078)(8121501046)(76310= 46)(3002001)(10201501046);SRVR:CY1PR0701MB1081;BCL:7;PCL:0;RULEID:;SRVR:C= Y1PR0701MB1081; > X-Ms-Exchange-Transport-Crosstenantheadersstamped: CY1PR0701MB1081 > X-Ms-Exchange-Organization-Authas: Anonymous > X-Ms-Exchange-Organization-Avstamp-Service: 1.0 > X-Spam-Flag: NO > X-Mailman-Version: 2.1.15 > List-Archive: > List-Unsubscribe: , > > Precedence: list > Delivered-To: opsawg@ietfa.amsl.com > X-Proofpoint-Virus-Version: vendor=3Dfsecure engine=3D2.50.10432:,, > definitions=3D2015-11-30_09:,, signatures=3D0 > X-Spam-Level:=20 > X-Ms-Exchange-Crosstenant-Fromentityheader: Internet > X-Microsoft-Antispam: > UriScan:;BCL:7;PCL:0;RULEID:(421252001)(3002015)(71701003)(71702001);SR= VR:CY1PR0701MB1081; > X-Eopattributedmessage: 0 > Received: from CY1PR0701MB1081.namprd07.prod.outlook.com > (10.160.145.153) > by CY1PR0701MB1082.namprd07.prod.outlook.com > (10.160.145.154) > with Microsoft SMTP Server (TLS) id 15.1.331.20 via Mailbox Transport; > Tue, 1 Dec 2015 00:15:06 +0000 > Received: from BY2PR07CA054.namprd07.prod.outlook.com > (10.141.251.29) > by CY1PR0701MB1081.namprd07.prod.outlook.com > (10.160.145.153) > with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 > 00:15:05 +0000 > Received: from BN1BFFO11FD050.protection.gbl > (2a01:111:f400:7c10::1:171) by BY2PR07CA054.outlook.office365.com > (2a01:111:e400:2c61::29) > with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend > Transport; Tue, 1 Dec 2015 00:15:04 +0000 > Received: from mx0b-00171101.pphosted.com > (67.231.156.27) > by BN1BFFO11FD050.mail.protection.outlook.com > (10.58.145.5) with > Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; > Tue, 1 Dec 2015 00:15:04 +0000 > Received: from pps.filterd (m0044905.ppops.net > [127.0.0.1]) by mx0b-00171101.pphosted.com > (8.15.0.59/8.15.0.59) with SMTP id > tB10BRUI022328 for >; Mon, 30 > Nov 2015 19:15:04 -0500 > Received: from mail.ietf.org (mail.ietf.org > [4.31.198.44]) by mx0b-00171101.pphosted.com > with ESMTP id 1yf8kh97s0-1 > (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES256-GCM-SHA384 bits=3D256 > verify=3DNOT) for >; Mon, 30 > Nov 2015 19:15:03 -0500 > Received: from ietfa.amsl.com (localhost > [IPv6:::1]) by ietfa.amsl.com (Postfix) with > ESMTP id 7B50F1B2AF2; Mon, 30 Nov 2015 16:15:01 -0800 (PST) > Received: from localhost (ietfa.amsl.com > [127.0.0.1]) by ietfa.amsl.com > (Postfix) with ESMTP id E30B81B33B1 for > >; Mon, 30 Nov > 2015 16:15:00 -0800 (PST) > 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 PAKUO7m6pu7B for > >; Mon, 30 Nov > 2015 16:14:59 -0800 (PST) > Received: from mail-yk0-x22c.google.com > (mail-yk0-x22c.google.com > [IPv6:2607:f8b0:4002:c07::22c]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) > (No client certificate requested) by ietfa.amsl.com > (Postfix) with ESMTPS id F170D1B2AF2 for > >; Mon, 30 Nov 2015 16:14:58 > -0800 (PST) > Received: by ykdr82 with SMTP id r82so204978015ykd.3 for > >; Mon, 30 Nov 2015 16:14:58 > -0800 (PST) > X-Spam-Status: No, score=3D-1.277 tagged_above=3D-999 required=3D5 > tests=3D[BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, > FM_FORGED_GMAIL=3D0.622, HTML_MESSAGE=3D0.001] autolearn=3Dno > X-Ms-Exchange-Organization-Messagedirectionality: Incoming > X-Ms-Exchange-Organization-Scl: -1 > X-Received: by 10.129.93.133 with SMTP id > r127mr54962501ywb.109.1448928898116; Mon, 30 Nov 2015 16:14:58 -0800 > (PST) > Message-Id: > > > Mime-Version: 1.0 > X-Spam-Score: -1.277 > List-Subscribe: , > > Re: [OPSAWG] FW: New Version Notification for > draft-dahm-opsawg-tacacs-01.txt > > Dear OpsAWG, > > The chairs believe that there is sufficient interest and support to > adopt this document as an OpsAWG document. > > Authors, please resubmit as draft-ietf-opsawg-tacacs-01 > > Working group:=20 > We would like to see this document progress, and are hoping to WGLC it > soon. Please review this and provide feedback.... > > W > > On Fri, Nov 13, 2015 at 1:37 PM Warren Kumari > wrote: > > We would really appreciate any feedback on this document. Personall= y I > think it is really useful, but we need the WG to review and provide= > feedback. > > Over the years I've heard a number of people kvetch that TACACS+ is= n't > documented -- well, now you can, you know, actually do something ab= out > this... > > W > > On Sun, Oct 4, 2015 at 4:18 PM, Douglas Gash (dcmgash) > > wrote: > > Dear Opsawg List, > > > > We have uploaded a second revision of the TACACS+ protocol > specification > > which we believe is ready for publication subject subject to port= > > allocation. > > > > Please see details below. > > > > The essential difference from the first revision is the change > of TLS > > option support using a separate port as opposed to the original > Start TLS > > mechanism. > > > > We would be very grateful for the opinion of the list regarding t= he > > suitability of document for publication as an RFC. > > > > Many thanks, > > > > Thorsten, Andrej, Doug. > > > > > > On 02/10/2015 16:25, "internet-drafts@ietf.org > " > > > wrote: > > > >> > >>A new version of I-D, draft-dahm-opsawg-tacacs-01.txt > >>has been successfully submitted by Douglas C. Medway Gash and > posted to > >>the > >>IETF repository. > >> > >>Name: draft-dahm-opsawg-tacacs > >>Revision: 01 > >>Title: The TACACS+ Protocol > >>Document date: 2015-10-02 > >>Group: Individual Submission > >>Pages: 38 > >>URL: > >>https://www.ietf.org/internet-drafts/draft-dahm-opsawg-tacacs-01.= txt > > >>Status: =20 > https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/ > > >>Htmlized: =20 > https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01 > > >>Diff: > >>https://www.ietf.org/rfcdiff?url2=3Ddraft-dahm-opsawg-tacacs-01 > > >> > >>Abstract: > >> TACACS+ provides access control for routers, network access > servers > >> and other networked computing devices via one or more centrali= zed > >> servers. TACACS+ provides separate authentication, > authorization and > >> accounting services. This document describes the protocol > that is > >> used by TACACS+. > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of= > >>submission > >>until the htmlized version and diff are available > at tools.ietf.org > . > >> > >>The IETF Secretariat > >> > > > > > > -- > I don't think the execution is relevant when it was obviously a bad= > idea in the first place. > This is like putting rabid weasels in your pants, and later express= ing > regret at having chosen those particular rabid weasels and that pai= r > of pants. > ---maf > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------010006090306080903070704 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello,

30 November: 2015: Warren sent the following message to the opsawg:=A0
(for some reason this message does not show up in the archive but a copy is=A0
appended to this message)

=A0 =A0 The chairs believe that there is sufficient interest an= d support to adopt
=A0 =A0 this document as an OpsAWG document. =A0

=A0 =A0 Authors, please resubmit as draft-ietf-opsawg-tacacs-01=

This appears to be factually incorrect. My mail folder for opsawg has no mail on the day of 30 Nov 2015. Given that the mail headers contain lots of SPF: fail verdicts, I also checked my spam folder. Nothing.

If the mail is not in the archive, maybe it actually didn't reach a significant fraction of the subscribers?

In that case, it should not come as a surprise that some people feel like this was conducted in a ... strange... manner.

I do see Warren's mail from 13 Nov BTW, and that one has no SPF fail headers (at least for me, that one did not look like an adoption call so it missed my brain filter; but that's just me).

Maybe others could check their archives to see what has or has not arrived on the list.

I would also appreciate if the actual reason why the archive did not get/reject the message. "For some reason" is a bit too unspecific to be useful IMHO...

Greetings,

Stefan Winter


16 December 2015 - renamed ID published


By asking the working group list for input on the question of adopting an
ID as a working group document the opsawg chairs followed one of the
normal IETF process to determine if there was enough interest for the
working group to adopt the TACACS+ ID as a working group topic.=A0 We note
in passing that such another normal process is for the WG chairs to decide
on their own to adopt a document as a working group topic.=A0 W= e also felt
that the topic was sufficiently within the working group charter to do so
without a specific charter update.

Thus Mr. DeKok's appeal as to the adoption of the ID as a working group
topic is rejected. If Mr. DeKok believes that this does not satisfy his
concerns, we refer him to RFC 2026, Section 6.5 for the next steps in the
appeal process.

Scott Bradner
Warren Kumari
12 February 2016


=97-----------------------------
To:=A0opsawg@ietf.org=A0
X-Ms-Exchange-Transport-Endtoendlatency: 00:00:01.8093445
=
X-Forefront-Antispam-Report: CIP:67.231.156.27;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:SKN;SFS:;DIR:INB;SF= P:;SCL:-1;SRVR:CY1PR0701MB1081;H:mx0b-00171101.pphosted.com;FPR:;SPF:None;LANG:en;
Spamdiagnosticmetadata: 7460966b2fd248469deae02cb8f82730
X-Ms-Exchange-Crosstenant-Id: 6ffa22f4-4568-4105-ad43-2e3ad4726957
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsawg/1hB3Nk= w1KcsSvrNlOcelGV2dJfM>
X-Virus-Scanned: amavisd-new at=A0amsl.com
X-Ms-Exchange-Organization-Authsource: BN1BFFO11FD050.protection.gbl
X-Google-Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/rel= axed; d=3D1e100.net; s=3D20130820; h=3Dx-gm-message-state:mime-version:references:in-reply-to:from= :date :message-id:subject:to:content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; b=3DPsPRkLaCtAuWcQ9uh6l4qAyrI8koo4a5hbTbiJ+XC+FfQfvyF8xTabi2i41= y4arQMJ YCg0o0IgxVGCcCMaeocHg7jl23rBlc5Q+SSSPyUNyNBS6plN8uTXGWruR487LFP= DUJ/f PEFkyga3mSPU/LR3NqFJdZw1vxNt0JXQjXHt7cKfDfDGs1KD/yziL3aFWJWEDpD= 3iqAs 2Ez4z3anmkMVgLaxUTnQDf9sgPjwYNUlCRbgfoHSO/L9kKQprVQ9duUVdn7A+Km= zHWGL WHtrG8QsySj8hj5J2Y1OJSFvyz3wBELGgQR/Xl4hGiyoGZdwL06RKvuO7FqoFHA= /Kq5M sFAg=3D=3D
X-Ms-Exchange-Crosstenant-Originalarrivaltime: 01 Dec 2015 00:15:04.5170 (UTC)
X-Proofpoint-Spam-Details: rule=3Dnotspam policy=3Ddefault score=3D0=A0kscore.is_bulkscore=3D0 kscore.compositescore=3D= 1 compositescore=3D0.9 suspectscore=3D2 malwarescore=3D0 phishsco= re=3D0 bulkscore=3D0=A0kscore.is_spamscore=3D0 rbsscore=3D0.9 spamsco= re=3D0 urlsuspectscore=3D0.9 adultscore=3D0 classifier=3Dspam adjust=3D= 0 reason=3Dmlx scancount=3D1 engine=3D8.0.1-1507310000 definitions=3Dmain-1512010002
Sender: "OPSAWG" <opsawg-bou= nces@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=3Dhelp>
X-Ms-Exchange-Organization-Network-Message-Id: d55618f2-7475-4530-c456-08d2f9e47660
List-Post: <mailto:opsawg@ietf= =2Eorg>
Authentication-Results: spf=3Dfail (sender IP is 67.231.156.27)= smtp.mailfrom=3Dietf.org;=A0harvard.edu; dkim=3Dfail (body hash did not verify) header.d=3D= ietf.org;harvard.edu; dmarc=3Dnone action=3Dnone header.from=3Dkumari.net;
Spamdiagnosticoutput: 1:2
X-Beenthere:=A0opsawg@ietf.org
Return-Path:=A0opsawg-bou= nces@ietf.org
References: <20151002152505.26594.74925.idtracker@ietfa.amsl.co= m> <D237455F.BC00F%dcmgash@cisco.co= m> <CAHw9_iKOM5N3-HS3ZOFFaDHYTV7rDaf3YHo-dEmdTU9-4W49a= w@mail.gmail.com>
Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3D= = ietf.org; s=3Dietf1; t=3D1448928901; bh=3Dpvt1kSVXuErtfU5ZWISQikMRPQYfDp05mGMYsb+SFcI=3D; h=3DMIME-Version:References:In-Reply-To:From:Date:Message-ID:To= : Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-He= lp: List-Subscribe:Content-Type:Sender; b=3DZRweO7Tp3Xq/v7MwtQY7Bq6Jbp5tU+2+++F0dEQALPEVXTbQ++h45JzxLZy= ES8ikI ok6ibFCR0Mkw1P1O6EQM3tIwQlLD6Xl1KnsDn74aUUD6RvQ+dD5P0gctrn1SuGi= Q8T jY5RD5B1YE7gpvyMoEYoDve3GiDolWuuyclQFdko=3D
Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D= = kumari-net.20150623.gappssmtp.com; s=3D20150623; h=3Dmime-version:references:in-reply-to:from:date:message-id:su= bject:to :content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; b=3DtRm8MTHNrVMLwiQrHd7XMteT2khz1LCvlSrKQHk3ELC5CCOUKybfJUCUwVw= xirEqnX fRpqiwO5pRPvSr+HyvnEf7e0RDpmxWnwne7H35NxkmMHpbxVQP+W15sB/NBcGkh= pTc/J wS/tTGwxxOempxpXCkVwGZ08QXrfMtCk6BkzYWGWhAhpwmVO+JCpglvaZXe4kH7= bhh5g hOAZJWp/uSzO/l1Fm27xgt57veT1LyZoIwQpcCRhzaA/jKOnfiUt0i4k07mc16U= 5LWoS x4Oa27VmHq1szNAU6hIwCqVJbgacuCB/+vjNM2SyOLuSBctWHJ5ldTY662XDkeB= l7kNu YEAg=3D=3D
X-Matching-Connectors: 130934025046730165;(d93d0180-227e-457c-4499-08d2eaec9703,256b2f12-4edf-4b= ba-ca8a-08d1766a767f,4c2fb881-fd60-47c4-27de-08d1a9464aaf,d8bbbf0d-8e19-4= 272-9345-08d1b65cb793,751b4e9e-d4fb-44bf-a131-08d1dc9823e4,e0068ebf-014b-= 4c73-793a-08d2f1dcc743,ac01cf0c-e967-495c-3fa9-08d1e70141cd,2808f1c2-2c2f= -483e-3d80-08d1dfb2fe99,f9e899bb-1cc2-41db-5fa0-08d071a1a76e,3dfa065d-6d0= 9-41e4-03d6-08d1999434e1,8f72f349-eac7-4ca2-5909-08d1f4d6bd8f);(fc40b7b3-= 9d92-4bad-511b-08d1429671f0,f044a6d7-98b9-4c10-91b4-08d210413fe9,27bd2dba= -e8c1-4f61-5bcb-08d2e63a1f24,6437d2a5-7830-487a-b613-08d2d5a0d354,d380623= 2-5d13-4149-28ff-08d1dec60473,dbc00d3f-cf39-4d73-fd34-08d1ba252138,9adb28= 0f-4fbe-49ab-17ad-08d0c8b1feb2,70fb42a1-9688-41b6-d810-08d1b07b4924)
Errors-To:=A0opsawg-bou= nces@ietf.org
Received-Spf: Fail (protection.= outlook.com: domain of=A0ietf.org=A0does not designate 67.231.156.27 as= permitted sender) receiver=3Dprotection.= outlook.com; client-ip=3D67.231.156.27; helo=3Dmx0b-00= 171101.pphosted.com;
X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD050;1:7ZN9YK7xDF/YOFqgSF/Kt7SEuRl6m82TEEFS5pjj0L9WZ2XsjsoK06= RHQoqp0zZJOqzHLsK7p62sRC/+dl0NHewnxWHjlYkFlErO0QxPu3bkMMMWFDL0D1gNkNNALQM= EcCEwMN1E+sHfvWqfShtOpPbseWAIU0wFbf+THNAsZ0poUqywVPIeJRTJ27KhrMzdvfCBdIh8= IvZ5UF+i5/30Lwu90TwhHBydQj9impHXhJzz6cchwyC+cZByHdxbhbkikaFU2ORf9xwBx/dwA= 6acnIYurcZxXE6rI4nl6Z+1j2pTmTRov/u+6965Gn47kV1qSjmeeWQq1+Jsqg0nQP0LqvWX6C= ygd4/KgcYExishE7nivKVZq72r4lJb+0eaMswT/63GpfiTqVx21+UBx3NKvMulQSqG9Gizk6a= Bns/3BJrRmYi0j5iGr+dfbx0LymzdOdOFUfmgTIYGJGhjO701+aLnQHD7VrB1FBD2W7/zJiWn= Jr5rxHNe0uP28JUnb6+5lr/fewGEZZ4jImQ+RbfZbw=3D=3D
X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1081;2:W1i0t4PGHpWZpZGn0gwqccaOVv2u49nkFSof3JBlrQuQJwcKl9Y2w= DeVl5A9iErzqOJItTyPziqfAt7KyGEax9rM95tiKtjcxgzwzjQjiqQFpGgTHF1Q/mY+w1og6G= EQgS4XgMDljIAumw4tSpiQLA=3D=3D;3:BKRbPmRM5q+4prHbMMl1pl1ZZ2tS0rVGiw7aEH1C= q7HPVNxaYdiJOPc4/BJYvodVY1vbr67qwwATIDtXfVie9db2RjBDjxQWPRY5zXwlnI582JvvS= d3uxAI1YZzAFgcWkt7sCG2ZuD2Nym9vBxvHl7WD5sUdx2tr8izLC86dMugMDG0IyhzPFEfr9B= 0mswrrXtD3XPjkoCi/NAC/ihsDyV4LoM3/Kd4he2AayTNrxq7+itBmev+RI6m84iRRzIxuK/Q= bd5vCfSbIsrCkmcxqVlgzXkMxrUazuheTQDsGM0gK2MaZaMTBhdk+8KyD4u2b;25:78MIti2Y= Lv9i038KUTfSvspXHFS1JtJYQgWUyzyoiB4b3M+szJyih+58z81aUvYrNTmZCYWxeNbJxOqcS= EnFD/tFLF7lEod2v8DhzNxAdXfJlAcv/35AqU99iwL0MzdeiGdV0hWIfIoVGEM6rn12InmNNZ= 5+H4mFspZlpFJBmC99ylYHhnYeRTvpCjhE26D9ry85Uq8vNQ7T7vG1qWT8sB8ZYFRgdnmOZlE= ZiDrmOMlFIc+4htsemKRufgfcZGhCaZM218PwPk9YqrrKaDAPNg=3D=3D
X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1081;20:PdLuCCyiCFshW0NdPnC8eBojhNvmPTsHv/4UFnq2/Ap13ChYozGc= dEqkVUoCDgV6xCnbV2sch84G9YqciCrAqpBOC+P+Jadb/xWosqipDjCzZzQB38ah3V+4Bdnbm= 37aWs527QTdFX74o319rkRkpfQW5lZBUE/+akaLk3iPOSDGklLOcMMzk5E6MUkg1FCxeTSCRb= EJI7C8Gcfkp4Z33sWwZ4l4nZsTryQjFNwUnKD35K3vVXCSTUr9mHEed86B;4:ZkdYP0b+reAA= tcSPR/s6gs/4xtl2BduQqcuxMWhnPArjFsyI7D8qxhJzegLJImmIurwvGNuAuPAEBVnzfKk7U= k8KmXurz5VrNWWXz9H9kX5I2iSoY82hbOGqpxoKZN7ZvT4eNnkftfwEBBb6cJWbLX2wJr1GhZ= QStKHhnKOXCtnWTG1bCOsAlUFzO4fcQrK1871zmJYcVLFeXs2soxq6zRVidnUVx5aVcz1fbUW= 1pYYi7SVTmKUxHgDHpBlhE2M7IsQCf2/z8jspwHR2/Ca4QwfTsBOwrzlBeHryjxjGwDLah0Sq= 5W9fy5doXLWj6Zp5Hd+78AnQKQjTLJoJzeypO8JVtyeXqv0y/UpPjXENphbC674cRQEyEhoyL= OWypuJeUP9XukINATvVEdgJnCHepkJSOHSZQea9zGKnTHazYjoG79eK1lsLgx2Uersmxtwz;2= 3:4EKpER/Wex7l7yJjNu6NCf/OL8GUvFcTfH03V6f1kyvAD+1i3rMhMIMUTaS5RuFVEBIT+1h= V2YemnNtNCejbQsscJK47MvrYffu1Y4FWysZHwmuW5Z8YY19Z55gg/bBjgeHwuc/ECiG+G54m= ZGKtdkuN1f6XkkJRlk9b5miEeMYyeSa/DeEi+1X+/69BTaHhVmdsOnEIiXOEmwKmURBUbA=3D= =3D
X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1081;5:NDmSUNkFZijBwPfECIN39/nKL9SZpZQoXf83DdYdG6c6uqvKq9pFL= 11zCIluGBfbfr7j8GHWoHjCFpbx7VYG1+pJWsbw3uKmx12woMpxVU2oaxoV8Tb44v0zoaB1O2= FhE9sZbcp5E+k+VFpjT7mxIQ=3D=3D;24:oRXQcwEWxPCuqn5UAzNUq6ABuuvQYLIsu5IbtKy= T8I8selWffYvnEZgXF6cORNZqS7B2xyDLy5FjzmcmEVLIXOyOiXuHI1QWDuagZnryAws=3D
In-Reply-To: <CAHw9_iKOM5N3-HS3ZOFFaDHYTV7rDaf3YHo-dEmdTU9-4W49a= w@mail.gmail.com>
X-Dkimresult-Test: Failed
X-Gm-Message-State: ALoCoQkPLNgOMt4FMOCWAKl2MLYDSZRuN/UoBjBSG0VRor2S+5FEJOJodLN/6r9gEZU0DpDM7= xYa
Content-Type: multipart/mixed; boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D808776= 7435361866650=3D=3D"
X-Original-To:=A0opsawg@ietfa= =2Eamsl.com
X-Exchange-Antispam-Report-Cfa-Test: BCL:7;PCL:0;RULEID:(601004)(7630046)(2401047)(520078)(8121501046)(7631046= )(3002001)(10201501046);SRVR:CY1PR0701MB1081;BCL:7;PCL:0;RULEID:;SRVR:CY1= PR0701MB1081;
X-Ms-Exchange-Transport-Crosstenantheadersstamped: CY1PR0701MB1081
X-Ms-Exchange-Organization-Authas: Anonymous
X-Ms-Exchange-Organization-Avstamp-Service: 1.0
X-Spam-Flag: NO
X-Mailman-Version: 2.1.15
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=3Dunsubscri= be>
Precedence: list
Delivered-To:=A0opsawg@ietfa= =2Eamsl.com
X-Proofpoint-Virus-Version: vendor=3Dfsecure engine=3D2.50.10432:,, definitions=3D2015-11-30_09:,, signature= s=3D0
X-Spam-Level:=A0
X-Ms-Exchange-Crosstenant-Fromentityheader: Internet
X-Microsoft-Antispam: UriScan:;BCL:7;PCL:0;RULEID:(421252001)(3002015)(71701003)(71702001);SRVR= :CY1PR0701MB1081;
X-Eopattributedmessage: 0
Received: from=A0CY1PR0701MB1081.namprd07.prod.outlook.com=A0(1= 0.160.145.153) by=A0CY1PR0701MB1082.namprd07.prod.outlook.com=A0(1= 0.160.145.154) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Mailbox Transport; Tue, 1 Dec 2015 00:15:06 +0000
Received: from=A0BY2PR07CA054.namprd07.prod.outlook.com=A0(10.1= 41.251.29) by=A0CY1PR0701MB1081.namprd07.prod.outlook.com=A0(1= 0.160.145.153) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 00:15:05 +0000
Received: from BN1BFFO11FD050.protection.gbl (2a01:111:f400:7c10::1:171) by=A0BY2PR07CA054.outlook.office365.com=A0(2a01:111:e400:2c61::29) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Tue, 1 Dec 2015 00:15:04 +0000
Received: from=A0mx0b-00= 171101.pphosted.com=A0(67.231.156.27) by=A0BN1BFFO11FD050.mail.protection.outlook.com=A0(= 10.58.145.5) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Tue, 1 Dec 2015 00:15:04 +0000
Received: from pps.filterd (m0044905.ppops.= net=A0[127.0.0.1]) by=A0mx0b-00= 171101.pphosted.com=A0(8.15.0.59/8.15.0.59) with SMTP id tB10BRUI022328 for <sob@harvard.edu>; Mon, 30 Nov 2015 19:15:04 -0500
Received: from=A0mail.ietf.org=A0= (mail.ietf.org=A0[4.31.198.44]) by=A0mx0b-00= 171101.pphosted.com=A0with ESMTP id 1yf8kh97s0-1 (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES256-GCM-SHA384 bits=3D256 verify=3DNOT) f= or <sob@harvard.edu>; Mon, 30 Nov 2015 19:15:03= -0500
Received: from=A0ietfa.amsl.com=A0= (localhost [IPv6:::1]) by=A0ietfa.amsl.com=A0= (Postfix) with ESMTP id 7B50F1B2AF2; Mon, 30 Nov 2015 16:15:01 -0800 (PST)
Received: from localhost (ietfa.amsl.com=A0= [127.0.0.1]) by=A0ietfa.amsl.com=A0(Postfix) with ESMTP id E30B81B33B1 for <opsawg@ietfa= =2Eamsl.com>; Mon, 30 Nov 2015 16:15:00 -0800 (PST)
Received: from=A0mail.ietf.org=A0= ([4.31.198.44]) by localhost (ietfa.amsl.com=A0= [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAKUO7m6pu7B for <opsawg@ietfa.amsl.com>; Mon, 30 Nov = 2015 16:14:59 -0800 (PST)
Received: from=A0mail-yk0-= x22c.google.com=A0(mail-yk0-= x22c.google.com=A0[IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by=A0ietfa.amsl.com=A0(Postfix) with ESMTPS id F170D1B2AF2 for <opsawg@ietf.org>; Mon, 30 Nov 2015 16:14:58 -0800 (PST)
Received: by ykdr82 with SMTP id r82so204978015ykd.3 for <opsawg@ietf.org>; Mon, 30 Nov 2015 16:14:5= 8 -0800 (PST)
X-Spam-Status: No, score=3D-1.277 tagged_above=3D-999 required=3D= 5 tests=3D[BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1,= FM_FORGED_GMAIL=3D0.622, HTML_MESSAGE=3D0.001] autolearn=3Dno
X-Ms-Exchange-Organization-Messagedirectionality: Incoming
X-Ms-Exchange-Organization-Scl: -1
X-Received: by 10.129.93.133 with SMTP id r127mr54962501ywb.109.1448928898116;=A0 Mon, 30 Nov 2015 16:14:58 -0800 (PST)
Message-Id: <CAHw9_iKebHhnE0wSrAVGyz8sVHX7gMoPFy+rkr5SoWyAqEfxF= Q@mail.gmail.com>
Mime-Version: 1.0
X-Spam-Score: -1.277
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=3Dsubscribe= >
Re: [OPSAWG] FW: New Version Notification for draft-dahm-opsawg-tacacs-01.txt

Dear OpsAWG,

The chairs believe that there is sufficient interest and support to adopt this document as an OpsAWG document.

Authors, please resubmit as=A0draft-ietf-opsawg-tacacs-01

Working group:=A0
We would like to see this document progress, and are hoping to WGLC it soon. Please review this and provide feedback....

W

On Fri, Nov 13, 2015 at 1:37 = PM Warren Kumari <warren@k= umari.net> wrote:
We would really appreciate any feedback on this document. Personally I
think it is really useful, but we need the WG to review and provide
feedback.

Over the years I've heard a number of people kvetch that TACACS+ isn't
documented -- well, now you can, you know, actually do something about
this...

W

On Sun, Oct 4, 2015 at 4:18 PM, Douglas Gash (dcmgash)<= br class=3D""> <dcmgash@cisco.com> wrote:
> Dear Opsawg List,
>
> We have uploaded a second revision of the TACACS+ protocol specification
> which we believe is ready for publication subject subject to port
> allocation.
>
> Please see details below.
>
> The essential difference from the first revision is the change of TLS
> option support using a separate port as opposed to the original Start TLS
> mechanism.
>
> We would be very grateful for the opinion of the list regarding the
> suitability of document for publication as an RFC.
>
> Many thanks,
>
> Thorsten, Andrej, Doug.
>
>
> On 02/10/2015 16:25, "internet-drafts@ietf.org= " <internet-drafts@ietf.org= >
> wrote:
>
>>
>>A new version of I-D, draft-dahm-opsawg-tacacs-01.txt
>>has been successfully submitted by Douglas C. Medway Gash and posted to
>>the
>>IETF repository.
>>
>>Name:=A0 =A0 =A0 =A0 =A0 draft-dahm-opsawg-taca= cs
>>Revision:=A0 =A0 =A0 01
>>Title:=A0 =A0 =A0 =A0 =A0The TACACS+ Protocol >>Document date: 2015-10-02
>>Group:=A0 =A0 =A0 =A0 =A0Individual Submission<= br class=3D""> >>Pages:=A0 =A0 =A0 =A0 =A038
>>URL:
>>https= ://www.ietf.org/internet-drafts/draft-dahm-opsawg-tacacs-01.txt
>>Status:=A0 =A0 =A0 =A0 =A0https= ://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/
>>Htmlized:=A0 =A0 =A0 =A0https= ://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01
>>Diff:
>>https= ://www.ietf.org/rfcdiff?url2=3Ddraft-dahm-opsawg-tacacs-01
>>
>>Abstract:
>>=A0 =A0TACACS+ provides access control for routers, network access servers
>>=A0 =A0and other networked computing devices vi= a one or more centralized
>>=A0 =A0servers.=A0 TACACS+ provides separate authentication, authorization and
>>=A0 =A0accounting services.=A0 This document describes the protocol that is
>>=A0 =A0used by TACACS+.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at=A0tools= =2Eietf.org.
>>
>>The IETF Secretariat
>>
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=A0 =A0---maf
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org<= /a>
https://www.ietf.org/mailma= n/listinfo/opsawg


_______________________________________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------010006090306080903070704-- --------------040507000800030709030305 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG/MacGPG2 v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040507000800030709030305-- --9vHw3VxG0sODmdntKLwGhjp6UF9ec3fn3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJWvhNvAAoJEMDeajWKOdxma3gQALPhZGdr8H8rCf/3GleoRDxq j1zjIroaw4PkDFCkImmTIk60NaPjWK2pdfCe34EaswMDl2lwncQiIG4uxn+KPmNX jLnU2iu2jHRpLv+/hVl21tH5bUeJDh7KJDj5tz7KRCo7LpkotKDzHvIJg/Sz8714 TxOmj7i9G3qfIb75uFc7herPMPhEVS3eZ+4PHs12uItlAHeuuZsiNIZL8xNq98MZ wIf9Nz2AKiHzF2ghCWyhsCfiniSsZoRrGR4gZxXYDA34FhcyBmmVW+ZSngZWCWFs 8oWAHRXyNi8/CO9LVW1z7iuguR5Y5OZuK9mFB0vQfdJkk8Fxk1rNLi3XHKyNHAo4 fK+6v6j+Kb7aRH+RtlC83uCtrRTn93nXqCz/BGTpTdBUjA5EnMzkgTEsgDlJ4OCm 0qGdNCNpcVe4ftMY74MDBBwFP6vuBb1FZnHY0hRpcRmlTU9u6K45QR1yAdwYKB/7 ZbsxzGZDa7Glk5ZwtcOOyDjKqk1Z54Bz7g8aNX+MYEDH3sqs0+ww8gPB/iSNFpDL bLJHz0At6AYcFQAOD9oe9myfKNxFED2wHt0i1/wMUrzdojUcwkTspvu/bTtHQVRg BTmC8+tZeVYax3HTJD8NKcCCtvJsI7k6PfZspKrPEZv6Gak2LcJAdryvespAD0r0 pZnNxCNFXX2rizE2AD4H =2H8A -----END PGP SIGNATURE----- --9vHw3VxG0sODmdntKLwGhjp6UF9ec3fn3-- From nobody Fri Feb 12 09:29:26 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6141A86F2 for ; Fri, 12 Feb 2016 09:29:24 -0800 (PST) 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] autolearn=ham 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 H4U_OvJpWyi8 for ; Fri, 12 Feb 2016 09:29:23 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 78A331A86F0 for ; Fri, 12 Feb 2016 09:29:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D9BE4D0F; Fri, 12 Feb 2016 17:29:22 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTFM74zACt-L; Fri, 12 Feb 2016 17:29:22 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 30DD3C17; Fri, 12 Feb 2016 17:29:22 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Fri, 12 Feb 2016 12:29:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 92 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 17:29:25 -0000 On Feb 12, 2016, at 11:46 AM, Douglas Gash (dcmgash) = wrote: >=20 > We=B9d be more than happy to split into two documents, the first being = a > tidy up of the current deployed protocol, but focussed towards the = device > admin use case as we discussed yesterday, and a second to deal with = the > crypto issue in a backwards-compatible way. I believe that would be a positive way forward. Alan DeKok. From nobody Fri Feb 12 09:29:49 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17061A86F0 for ; Fri, 12 Feb 2016 09:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.563 X-Spam-Level: **** X-Spam-Status: No, score=4.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, NUMERIC_HTTP_ADDR=1.242, RP_MATCHES_RCVD=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 6sT6TmmD4xbP for ; Fri, 12 Feb 2016 09:29:42 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8590D1A86EA for ; Fri, 12 Feb 2016 09:29:42 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:8cb9:c853:d5dd:341e]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1CHTatD008148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 12 Feb 2016 17:29:37 GMT (envelope-from joelja@bogus.com) To: Stefan Winter , "Bradner, Scott" , "opsawg@ietf.org" References: <56BE136F.7030905@restena.lu> From: joel jaeggli Message-ID: <56BE1680.9060507@bogus.com> Date: Fri, 12 Feb 2016 09:29:36 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <56BE136F.7030905@restena.lu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OELOppdEeSMqPwMrOKoRsdeCqsxjDb44O" Archived-At: Cc: "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 17:29:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OELOppdEeSMqPwMrOKoRsdeCqsxjDb44O Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/12/16 9:16 AM, Stefan Winter wrote: > Hello, >=20 >> 30 November: 2015: Warren sent the following message to the opsawg:=20 >> (for some reason this message does not show up in the archive but a >> copy is=20 >> appended to this message) >> >> The chairs believe that there is sufficient interest and support >> to adopt >> this document as an OpsAWG document. =20 >> >> Authors, please resubmit as draft-ietf-opsawg-tacacs-01 >=20 > This appears to be factually incorrect. My mail folder for opsawg has n= o > mail on the day of 30 Nov 2015. Given that the mail headers contain lot= s > of SPF: fail verdicts, I also checked my spam folder. Nothing. Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on nagasaki.bogus.com X-Spam-Level: X-Spam-Status: No, score=3D-6.9 required=3D4.5 tests=3DBAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_FAIL, T_SPF_HELO_PERMERROR autolearn=3Dunavailable autolearn_force=3Dno versio= n=3D3.4.1 Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tB10F74R032237 (version=3DTLSv1/SSLv3 cipher=3DDHE-RSA-AES256-GCM-SHA384 bits=3D256 ver= ify=3DNOT) for ; Tue, 1 Dec 2015 00:15:08 GMT (envelope-from opsawg-bounces@ietf.org) Received: from mail.ietf.org ([2001:1900:3001:11::2c]) by psg.com with esmtps (TLSv1.2:AECDH-AES256-SHA:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a3Yb0-0008OR-8o for joelja@bogus.com; Tue, 01 Dec 2015 00:15:02 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE34B1B33D1; Mon, 30 Nov 2015 16:15:01 -0800 (PST) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org; = s=3Dietf1; t=3D1448928901; bh=3Dpvt1kSVXuErtfU5ZWISQikMRPQYfDp05mGMYsb+SFcI=3D; h=3DMIME-Version:References:In-Reply-To:From:Date:Message-ID:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=3DZRweO7Tp3Xq/v7MwtQY7Bq6Jbp5tU+2+++F0dEQALPEVXTbQ++h45JzxLZyES8ikI ok6ibFCR0Mkw1P1O6EQM3tIwQlLD6Xl1KnsDn74aUUD6RvQ+dD5P0gctrn1SuGiQ8T jY5RD5B1YE7gpvyMoEYoDve3GiDolWuuyclQFdko=3D X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30B81B33B1 for ; Mon, 30 Nov 2015 16:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.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 PAKUO7m6pu7B for ; Mon, 30 Nov 2015 16:14:59 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F170D1B2AF2 for ; Mon, 30 Nov 2015 16:14:58 -0800 (PST) Received: by ykdr82 with SMTP id r82so204978015ykd.3 for ; Mon, 30 Nov 2015 16:14:58 -0800 (PST) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dkumari-net.20150623.gappssmtp.com; s=3D20150623; h=3Dmime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; b=3DtRm8MTHNrVMLwiQrHd7XMteT2khz1LCvlSrKQHk3ELC5CCOUKybfJUCUwVwxirEqnX fRpqiwO5pRPvSr+HyvnEf7e0RDpmxWnwne7H35NxkmMHpbxVQP+W15sB/NBcGkhpTc/J wS/tTGwxxOempxpXCkVwGZ08QXrfMtCk6BkzYWGWhAhpwmVO+JCpglvaZXe4kH7bhh5g hOAZJWp/uSzO/l1Fm27xgt57veT1LyZoIwQpcCRhzaA/jKOnfiUt0i4k07mc16U5LWoS x4Oa27VmHq1szNAU6hIwCqVJbgacuCB/+vjNM2SyOLuSBctWHJ5ldTY662XDkeBl7kNu YEAg=3D=3D X-Google-DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D1e100.net; s=3D20130820; h=3Dx-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; b=3DPsPRkLaCtAuWcQ9uh6l4qAyrI8koo4a5hbTbiJ+XC+FfQfvyF8xTabi2i41y4arQMJ YCg0o0IgxVGCcCMaeocHg7jl23rBlc5Q+SSSPyUNyNBS6plN8uTXGWruR487LFPDUJ/f PEFkyga3mSPU/LR3NqFJdZw1vxNt0JXQjXHt7cKfDfDGs1KD/yziL3aFWJWEDpD3iqAs 2Ez4z3anmkMVgLaxUTnQDf9sgPjwYNUlCRbgfoHSO/L9kKQprVQ9duUVdn7A+KmzHWGL WHtrG8QsySj8hj5J2Y1OJSFvyz3wBELGgQR/Xl4hGiyoGZdwL06RKvuO7FqoFHA/Kq5M sFAg=3D=3D X-Gm-Message-State: ALoCoQkPLNgOMt4FMOCWAKl2MLYDSZRuN/UoBjBSG0VRor2S+5FEJOJodLN/6r9gEZU0DpDM7= xYa X-Received: by 10.129.93.133 with SMTP id r127mr54962501ywb.109.1448928898116; Mon, 30 Nov 2015 16:14:58 -0800 (PST) MIME-Version: 1.0 References: <20151002152505.26594.74925.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Tue, 01 Dec 2015 00:14:48 +0000 Message-ID: To: "opsawg@ietf.org" Archived-At: = Subject: Re: [OPSAWG] FW: New Version Notification for draft-dahm-opsawg-tacacs-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8087767435361866= 650=3D=3D" Errors-To: opsawg-bounces@ietf.org Sender: "OPSAWG" --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8087767435361866650=3D=3D Content-Type: multipart/alternative; boundary=3D001a114d8bc64720290525cb0= ced --001a114d8bc64720290525cb0ced Content-Type: text/plain; charset=3DUTF-8 Dear OpsAWG, The chairs believe that there is sufficient interest and support to adopt= this document as an OpsAWG document. Authors, please resubmit as draft-ietf-opsawg-tacacs-01 Working group: We would like to see this document progress, and are hoping to WGLC it soon. Please review this and provide feedback.... W On Fri, Nov 13, 2015 at 1:37 PM Warren Kumari wrote: > We would really appreciate any feedback on this document. Personally I > think it is really useful, but we need the WG to review and provide > feedback. > > Over the years I've heard a number of people kvetch that TACACS+ isn't > documented -- well, now you can, you know, actually do something about > this... > > W > > On Sun, Oct 4, 2015 at 4:18 PM, Douglas Gash (dcmgash) > wrote: > > Dear Opsawg List, > > > > We have uploaded a second revision of the TACACS+ protocol specificat= ion > > which we believe is ready for publication subject subject to port > > allocation. > > > > Please see details below. > > > > The essential difference from the first revision is the change of TLS= > > option support using a separate port as opposed to the original Start TLS > > mechanism. > > > > We would be very grateful for the opinion of the list regarding the > > suitability of document for publication as an RFC. > > > > Many thanks, > > > > Thorsten, Andrej, Doug. > > > > > > On 02/10/2015 16:25, "internet-drafts@ietf.org" < > internet-drafts@ietf.org> > > wrote: > > > >> > >>A new version of I-D, draft-dahm-opsawg-tacacs-01.txt > >>has been successfully submitted by Douglas C. Medway Gash and posted = to > >>the > >>IETF repository. > >> > >>Name: draft-dahm-opsawg-tacacs > >>Revision: 01 > >>Title: The TACACS+ Protocol > >>Document date: 2015-10-02 > >>Group: Individual Submission > >>Pages: 38 > >>URL: > >>https://www.ietf.org/internet-drafts/draft-dahm-opsawg-tacacs-01.txt > >>Status: > https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/ > >>Htmlized: https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-= 01 > >>Diff: > >>https://www.ietf.org/rfcdiff?url2=3Ddraft-dahm-opsawg-tacacs-01 > >> > >>Abstract: > >> TACACS+ provides access control for routers, network access server= s > >> and other networked computing devices via one or more centralized > >> servers. TACACS+ provides separate authentication, authorization = and > >> accounting services. This document describes the protocol that is= > >> used by TACACS+. > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of > >>submission > >>until the htmlized version and diff are available at tools.ietf.org. > >> > >>The IETF Secretariat > >> > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > --001a114d8bc64720290525cb0ced Content-Type: text/html; charset=3DUTF-8 Content-Transfer-Encoding: quoted-printable
Dear OpsAWG,

The chairs believe tha= t th=3D ere is sufficient interest and support to adopt this document as an OpsAW= G =3D document.

Authors, please resubmit as=3DC2=3DA0d= raft-i=3D etf-opsawg-tacacs-01

Working group:=3DC2=3DA0
We would l= ike to=3D see this document progress, and are hoping to WGLC it soon. Please revie= w =3D this and provide feedback....

W

On Fri, Nov 13, 2015 at 1:37 PM War= ren Ku=3D mari <warren@kumari.net>= wro=3D te:
We would really appreciate an= y =3D feedback on this document. Personally I
think it is really useful, but we need the WG to review and provide
feedback.

Over the years I've heard a number of people kvetch that TACACS+ isn&= #3=3D 9;t
documented -- well, now you can, you know, actually do something about this...

W

On Sun, Oct 4, 2015 at 4:18 PM, Douglas Gash (dcmgash)
<dcmgash@ci= sco.co=3D m> wrote:
> Dear Opsawg List,
>
> We have uploaded a second revision of the TACACS+ protocol specifica= ti=3D on
> which we believe is ready for publication subject subject to port > allocation.
>
> Please see details below.
>
> The essential difference from the first revision is the change of TL= S<=3D br> > option support using a separate port as opposed to the original Star= t =3D TLS
> mechanism.
>
> We would be very grateful for the opinion of the list regarding the<= br=3D > > suitability of document for publication as an RFC.
>
> Many thanks,
>
> Thorsten, Andrej, Doug.
>
>
> On 02/10/2015 16:25, "internet-drafts@ietf.org" <internet-drafts@ietf.org&g=3D t;
> wrote:
>
>>
>>A new version of I-D, draft-dahm-opsawg-tacacs-01.txt
>>has been successfully submitted by Douglas C. Medway Gash and pos= te=3D d to
>>the
>>IETF repository.
>>
>>Name:=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 draft= -dahm-opsawg-tacacs >>Revision:=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 01
>>Title:=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0The T= ACACS+ Protocol
>>Document date: 2015-10-02
>>Group:=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0Indiv= idual Submission
>>Pages:=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA038 >>URL:
>>https://www.ietf.o= rg/int=3D ernet-drafts/draft-dahm-opsawg-tacacs-01.txt
>>Status:=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/
= >>Htmlized:=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0h=3D ttps://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01
>>Diff:
>>https://www.ietf.org/rf= cdiff?=3D url2=3D3Ddraft-dahm-opsawg-tacacs-01
>>
>>Abstract:
>>=3DC2=3DA0 =3DC2=3DA0TACACS+ provides access control for routers,= network a=3D ccess servers
>>=3DC2=3DA0 =3DC2=3DA0and other networked computing devices via on= e or more =3D centralized
>>=3DC2=3DA0 =3DC2=3DA0servers.=3DC2=3DA0 TACACS+ provides separate= authenticatio=3D n, authorization and
>>=3DC2=3DA0 =3DC2=3DA0accounting services.=3DC2=3DA0 This document= describes the=3D protocol that is
>>=3DC2=3DA0 =3DC2=3DA0used by TACACS+.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of= >>submission
>>until the htmlized version and diff are available at tools.ietf.o= rg=3D =2E
>>
>>The IETF Secretariat
>>
>



--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair
of pants.
=3DC2=3DA0 =3DC2=3DA0---maf
--001a114d8bc64720290525cb0ced-- --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8087767435361866650=3D=3D Content-Type: text/plain; charset=3D"us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8087767435361866650=3D=3D-= - > If the mail is not in the archive, maybe it actually didn't reach a > significant fraction of the subscribers? >=20 > In that case, it should not come as a surprise that some people feel > like this was conducted in a ... strange... manner. >=20 > I do see Warren's mail from 13 Nov BTW, and that one has no SPF fail > headers (at least for me, that one did not look like an adoption call s= o > it missed my brain filter; but that's just me). >=20 > Maybe others could check their archives to see what has or has not > arrived on the list. >=20 > I would also appreciate if the actual reason why the archive did not > get/reject the message. "For some reason" is a bit too unspecific to be= > useful IMHO... >=20 > Greetings, >=20 > Stefan Winter >=20 >> >> 16 December 2015 - renamed ID published >> >> >> By asking the working group list for input on the question of adopting= an >> ID as a working group document the opsawg chairs followed one of the >> normal IETF process to determine if there was enough interest for the >> working group to adopt the TACACS+ ID as a working group topic. We no= te >> in passing that such another normal process is for the WG chairs to de= cide >> on their own to adopt a document as a working group topic. We also fe= lt >> that the topic was sufficiently within the working group charter to do= so >> without a specific charter update. >> >> Thus Mr. DeKok's appeal as to the adoption of the ID as a working grou= p >> topic is rejected. If Mr. DeKok believes that this does not satisfy hi= s >> concerns, we refer him to RFC 2026, Section 6.5 for the next steps in = the >> appeal process. >> >> Scott Bradner >> Warren Kumari >> 12 February 2016 >> >> >> =97----------------------------- >> To: opsawg@ietf.org =20 >> X-Ms-Exchange-Transport-Endtoendlatency: 00:00:01.8093445 >> X-Forefront-Antispam-Report: >> CIP:67.231.156.27;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:SKN;SFS:;DIR:INB= ;SFP:;SCL:-1;SRVR:CY1PR0701MB1081;H:mx0b-00171101.pphosted.com >> ;FPR:;SPF:None;LANG:en; >> Spamdiagnosticmetadata: 7460966b2fd248469deae02cb8f82730 >> X-Ms-Exchange-Crosstenant-Id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 >> List-Id: OPSA Working Group Mail List > > >> X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); >> Archived-At: >> >> X-Virus-Scanned: amavisd-new at amsl.com >> X-Ms-Exchange-Organization-Authsource: BN1BFFO11FD050.protection.gbl >> X-Google-Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; >> d=3D1e100.net ; s=3D20130820; >> h=3Dx-gm-message-state:mime-version:references:in-reply-to:from:date >> :message-id:subject:to:content-type; >> bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; >> b=3DPsPRkLaCtAuWcQ9uh6l4qAyrI8koo4a5hbTbiJ+XC+FfQfvyF8xTabi2i41y4arQMJ= >> YCg0o0IgxVGCcCMaeocHg7jl23rBlc5Q+SSSPyUNyNBS6plN8uTXGWruR487LFPDUJ/f >> PEFkyga3mSPU/LR3NqFJdZw1vxNt0JXQjXHt7cKfDfDGs1KD/yziL3aFWJWEDpD3iqAs >> 2Ez4z3anmkMVgLaxUTnQDf9sgPjwYNUlCRbgfoHSO/L9kKQprVQ9duUVdn7A+KmzHWGL >> WHtrG8QsySj8hj5J2Y1OJSFvyz3wBELGgQR/Xl4hGiyoGZdwL06RKvuO7FqoFHA/Kq5M >> sFAg=3D=3D >> X-Ms-Exchange-Crosstenant-Originalarrivaltime: 01 Dec 2015 >> 00:15:04.5170 (UTC) >> X-Proofpoint-Spam-Details: rule=3Dnotspam policy=3Ddefault >> score=3D0 kscore.is _bulkscore=3D0 >> kscore.compositescore=3D1 compositescore=3D0.9 suspectscore=3D2 >> malwarescore=3D0 phishscore=3D0 bulkscore=3D0 kscore.is >> _spamscore=3D0 rbsscore=3D0.9 spamscore=3D0 >> urlsuspectscore=3D0.9 adultscore=3D0 classifier=3Dspam adjust=3D0 reas= on=3Dmlx >> scancount=3D1 engine=3D8.0.1-1507310000 definitions=3Dmain-1512010002 >> Sender: "OPSAWG" > > >> List-Help: >> X-Ms-Exchange-Organization-Network-Message-Id: >> d55618f2-7475-4530-c456-08d2f9e47660 >> List-Post: >> Authentication-Results: spf=3Dfail (sender IP is 67.231.156.27) >> smtp.mailfrom=3Dietf.org ; harvard.edu >> ; dkim=3Dfail (body hash did not verify) >> header.d=3Dietf.org ;harvard.edu = ; >> dmarc=3Dnone action=3Dnone header.from=3Dkumari.net ; >> Spamdiagnosticoutput: 1:2 >> X-Beenthere: opsawg@ietf.org >> Return-Path: opsawg-bounces@ietf.org >> References: <20151002152505.26594.74925.idtracker@ietfa.amsl.com >> > >> > >> > > >> Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.or= g >> ; s=3Dietf1; t=3D1448928901; >> bh=3Dpvt1kSVXuErtfU5ZWISQikMRPQYfDp05mGMYsb+SFcI=3D; >> h=3DMIME-Version:References:In-Reply-To:From:Date:Message-ID:To: >> Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: >> List-Subscribe:Content-Type:Sender; >> b=3DZRweO7Tp3Xq/v7MwtQY7Bq6Jbp5tU+2+++F0dEQALPEVXTbQ++h45JzxLZyES8ikI >> ok6ibFCR0Mkw1P1O6EQM3tIwQlLD6Xl1KnsDn74aUUD6RvQ+dD5P0gctrn1SuGiQ8T >> jY5RD5B1YE7gpvyMoEYoDve3GiDolWuuyclQFdko=3D >> Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; >> d=3Dkumari-net.20150623.gappssmtp.com >> ; s=3D20150623; >> h=3Dmime-version:references:in-reply-to:from:date:message-id:subject:t= o >> :content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; >> b=3DtRm8MTHNrVMLwiQrHd7XMteT2khz1LCvlSrKQHk3ELC5CCOUKybfJUCUwVwxirEqnX= >> fRpqiwO5pRPvSr+HyvnEf7e0RDpmxWnwne7H35NxkmMHpbxVQP+W15sB/NBcGkhpTc/J >> wS/tTGwxxOempxpXCkVwGZ08QXrfMtCk6BkzYWGWhAhpwmVO+JCpglvaZXe4kH7bhh5g >> hOAZJWp/uSzO/l1Fm27xgt57veT1LyZoIwQpcCRhzaA/jKOnfiUt0i4k07mc16U5LWoS >> x4Oa27VmHq1szNAU6hIwCqVJbgacuCB/+vjNM2SyOLuSBctWHJ5ldTY662XDkeBl7kNu >> YEAg=3D=3D >> X-Matching-Connectors: >> 130934025046730165;(d93d0180-227e-457c-4499-08d2eaec9703,256b2f12-4edf= -4bba-ca8a-08d1766a767f,4c2fb881-fd60-47c4-27de-08d1a9464aaf,d8bbbf0d-8e1= 9-4272-9345-08d1b65cb793,751b4e9e-d4fb-44bf-a131-08d1dc9823e4,e0068ebf-01= 4b-4c73-793a-08d2f1dcc743,ac01cf0c-e967-495c-3fa9-08d1e70141cd,2808f1c2-2= c2f-483e-3d80-08d1dfb2fe99,f9e899bb-1cc2-41db-5fa0-08d071a1a76e,3dfa065d-= 6d09-41e4-03d6-08d1999434e1,8f72f349-eac7-4ca2-5909-08d1f4d6bd8f);(fc40b7= b3-9d92-4bad-511b-08d1429671f0,f044a6d7-98b9-4c10-91b4-08d210413fe9,27bd2= dba-e8c1-4f61-5bcb-08d2e63a1f24,6437d2a5-7830-487a-b613-08d2d5a0d354,d380= 6232-5d13-4149-28ff-08d1dec60473,dbc00d3f-cf39-4d73-fd34-08d1ba252138,9ad= b280f-4fbe-49ab-17ad-08d0c8b1feb2,70fb42a1-9688-41b6-d810-08d1b07b4924) >> Errors-To: opsawg-bounces@ietf.org >> Received-Spf: Fail (protection.outlook.com >> : domain of ietf.org >> does not designate 67.231.156.27 as permitted >> sender) receiver=3Dprotection.outlook.com >> ; client-ip=3D67.231.156.27; >> helo=3Dmx0b-00171101.pphosted.com ;= >> X-Microsoft-Exchange-Diagnostics: >> 1;BN1BFFO11FD050;1:7ZN9YK7xDF/YOFqgSF/Kt7SEuRl6m82TEEFS5pjj0L9WZ2Xsjso= K06RHQoqp0zZJOqzHLsK7p62sRC/+dl0NHewnxWHjlYkFlErO0QxPu3bkMMMWFDL0D1gNkNNA= LQMEcCEwMN1E+sHfvWqfShtOpPbseWAIU0wFbf+THNAsZ0poUqywVPIeJRTJ27KhrMzdvfCBd= Ih8IvZ5UF+i5/30Lwu90TwhHBydQj9impHXhJzz6cchwyC+cZByHdxbhbkikaFU2ORf9xwBx/= dwA6acnIYurcZxXE6rI4nl6Z+1j2pTmTRov/u+6965Gn47kV1qSjmeeWQq1+Jsqg0nQP0LqvW= X6Cygd4/KgcYExishE7nivKVZq72r4lJb+0eaMswT/63GpfiTqVx21+UBx3NKvMulQSqG9Giz= k6aBns/3BJrRmYi0j5iGr+dfbx0LymzdOdOFUfmgTIYGJGhjO701+aLnQHD7VrB1FBD2W7/zJ= iWnJr5rxHNe0uP28JUnb6+5lr/fewGEZZ4jImQ+RbfZbw=3D=3D >> X-Microsoft-Exchange-Diagnostics: >> 1;CY1PR0701MB1081;2:W1i0t4PGHpWZpZGn0gwqccaOVv2u49nkFSof3JBlrQuQJwcKl9= Y2wDeVl5A9iErzqOJItTyPziqfAt7KyGEax9rM95tiKtjcxgzwzjQjiqQFpGgTHF1Q/mY+w1o= g6GEQgS4XgMDljIAumw4tSpiQLA=3D=3D;3:BKRbPmRM5q+4prHbMMl1pl1ZZ2tS0rVGiw7aE= H1Cq7HPVNxaYdiJOPc4/BJYvodVY1vbr67qwwATIDtXfVie9db2RjBDjxQWPRY5zXwlnI582J= vvSd3uxAI1YZzAFgcWkt7sCG2ZuD2Nym9vBxvHl7WD5sUdx2tr8izLC86dMugMDG0IyhzPFEf= r9B0mswrrXtD3XPjkoCi/NAC/ihsDyV4LoM3/Kd4he2AayTNrxq7+itBmev+RI6m84iRRzIxu= K/Qbd5vCfSbIsrCkmcxqVlgzXkMxrUazuheTQDsGM0gK2MaZaMTBhdk+8KyD4u2b;25:78MIt= i2YLv9i038KUTfSvspXHFS1JtJYQgWUyzyoiB4b3M+szJyih+58z81aUvYrNTmZCYWxeNbJxO= qcSEnFD/tFLF7lEod2v8DhzNxAdXfJlAcv/35AqU99iwL0MzdeiGdV0hWIfIoVGEM6rn12Inm= NNZ5+H4mFspZlpFJBmC99ylYHhnYeRTvpCjhE26D9ry85Uq8vNQ7T7vG1qWT8sB8ZYFRgdnmO= ZlEZiDrmOMlFIc+4htsemKRufgfcZGhCaZM218PwPk9YqrrKaDAPNg=3D=3D >> X-Microsoft-Exchange-Diagnostics: >> 1;CY1PR0701MB1081;20:PdLuCCyiCFshW0NdPnC8eBojhNvmPTsHv/4UFnq2/Ap13ChYo= zGcdEqkVUoCDgV6xCnbV2sch84G9YqciCrAqpBOC+P+Jadb/xWosqipDjCzZzQB38ah3V+4Bd= nbm37aWs527QTdFX74o319rkRkpfQW5lZBUE/+akaLk3iPOSDGklLOcMMzk5E6MUkg1FCxeTS= CRbEJI7C8Gcfkp4Z33sWwZ4l4nZsTryQjFNwUnKD35K3vVXCSTUr9mHEed86B;4:ZkdYP0b+r= eAAtcSPR/s6gs/4xtl2BduQqcuxMWhnPArjFsyI7D8qxhJzegLJImmIurwvGNuAuPAEBVnzfK= k7Uk8KmXurz5VrNWWXz9H9kX5I2iSoY82hbOGqpxoKZN7ZvT4eNnkftfwEBBb6cJWbLX2wJr1= GhZQStKHhnKOXCtnWTG1bCOsAlUFzO4fcQrK1871zmJYcVLFeXs2soxq6zRVidnUVx5aVcz1f= bUW1pYYi7SVTmKUxHgDHpBlhE2M7IsQCf2/z8jspwHR2/Ca4QwfTsBOwrzlBeHryjxjGwDLah= 0Sq5W9fy5doXLWj6Zp5Hd+78AnQKQjTLJoJzeypO8JVtyeXqv0y/UpPjXENphbC674cRQEyEh= oyLOWypuJeUP9XukINATvVEdgJnCHepkJSOHSZQea9zGKnTHazYjoG79eK1lsLgx2Uersmxtw= z;23:4EKpER/Wex7l7yJjNu6NCf/OL8GUvFcTfH03V6f1kyvAD+1i3rMhMIMUTaS5RuFVEBIT= +1hV2YemnNtNCejbQsscJK47MvrYffu1Y4FWysZHwmuW5Z8YY19Z55gg/bBjgeHwuc/ECiG+G= 54mZGKtdkuN1f6XkkJRlk9b5miEeMYyeSa/DeEi+1X+/69BTaHhVmdsOnEIiXOEmwKmURBUbA= =3D=3D >> X-Microsoft-Exchange-Diagnostics: >> 1;CY1PR0701MB1081;5:NDmSUNkFZijBwPfECIN39/nKL9SZpZQoXf83DdYdG6c6uqvKq9= pFL11zCIluGBfbfr7j8GHWoHjCFpbx7VYG1+pJWsbw3uKmx12woMpxVU2oaxoV8Tb44v0zoaB= 1O2FhE9sZbcp5E+k+VFpjT7mxIQ=3D=3D;24:oRXQcwEWxPCuqn5UAzNUq6ABuuvQYLIsu5Ib= tKyT8I8selWffYvnEZgXF6cORNZqS7B2xyDLy5FjzmcmEVLIXOyOiXuHI1QWDuagZnryAws=3D= >> In-Reply-To: >> > > >> X-Dkimresult-Test: Failed >> X-Gm-Message-State: >> ALoCoQkPLNgOMt4FMOCWAKl2MLYDSZRuN/UoBjBSG0VRor2S+5FEJOJodLN/6r9gEZU0Dp= DM7xYa >> Content-Type: multipart/mixed; >> boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8087767435361= 866650=3D=3D" >> X-Original-To: opsawg@ietfa.amsl.com >> X-Exchange-Antispam-Report-Cfa-Test: >> BCL:7;PCL:0;RULEID:(601004)(7630046)(2401047)(520078)(8121501046)(7631= 046)(3002001)(10201501046);SRVR:CY1PR0701MB1081;BCL:7;PCL:0;RULEID:;SRVR:= CY1PR0701MB1081; >> X-Ms-Exchange-Transport-Crosstenantheadersstamped: CY1PR0701MB1081 >> X-Ms-Exchange-Organization-Authas: Anonymous >> X-Ms-Exchange-Organization-Avstamp-Service: 1.0 >> X-Spam-Flag: NO >> X-Mailman-Version: 2.1.15 >> List-Archive: >> List-Unsubscribe: , >> >> Precedence: list >> Delivered-To: opsawg@ietfa.amsl.com >> X-Proofpoint-Virus-Version: vendor=3Dfsecure engine=3D2.50.10432:,, >> definitions=3D2015-11-30_09:,, signatures=3D0 >> X-Spam-Level:=20 >> X-Ms-Exchange-Crosstenant-Fromentityheader: Internet >> X-Microsoft-Antispam: >> UriScan:;BCL:7;PCL:0;RULEID:(421252001)(3002015)(71701003)(71702001);S= RVR:CY1PR0701MB1081; >> X-Eopattributedmessage: 0 >> Received: from CY1PR0701MB1081.namprd07.prod.outlook.com >> (10.160.145.153) >> by CY1PR0701MB1082.namprd07.prod.outlook.com >> (10.160.145.154) >> with Microsoft SMTP Server (TLS) id 15.1.331.20 via Mailbox Transport;= >> Tue, 1 Dec 2015 00:15:06 +0000 >> Received: from BY2PR07CA054.namprd07.prod.outlook.com >> (10.141.251.29) >> by CY1PR0701MB1081.namprd07.prod.outlook.com >> (10.160.145.153) >> with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 >> 00:15:05 +0000 >> Received: from BN1BFFO11FD050.protection.gbl >> (2a01:111:f400:7c10::1:171) by BY2PR07CA054.outlook.office365.com >> (2a01:111:e400:2c61::29) >> with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend >> Transport; Tue, 1 Dec 2015 00:15:04 +0000 >> Received: from mx0b-00171101.pphosted.com >> (67.231.156.27) >> by BN1BFFO11FD050.mail.protection.outlook.com >> (10.58.145.5) with= >> Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; >> Tue, 1 Dec 2015 00:15:04 +0000 >> Received: from pps.filterd (m0044905.ppops.net >> [127.0.0.1]) by mx0b-00171101.pphosted.com= >> (8.15.0.59/8.15.0.59) with SMTP id= >> tB10BRUI022328 for >; Mon, 30= >> Nov 2015 19:15:04 -0500 >> Received: from mail.ietf.org (mail.ietf.org >> [4.31.198.44]) by mx0b-00171101.pphosted.com >> with ESMTP id 1yf8kh97s0-1 >> (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES256-GCM-SHA384 bits=3D256= >> verify=3DNOT) for >; Mon, 30 >> Nov 2015 19:15:03 -0500 >> Received: from ietfa.amsl.com (localhost >> [IPv6:::1]) by ietfa.amsl.com (Postfix) with >> ESMTP id 7B50F1B2AF2; Mon, 30 Nov 2015 16:15:01 -0800 (PST) >> Received: from localhost (ietfa.amsl.com >> [127.0.0.1]) by ietfa.amsl.com >> (Postfix) with ESMTP id E30B81B33B1 for >> >; Mon, 30 Nov >> 2015 16:15:00 -0800 (PST) >> 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 PAKUO7m6pu7B for >> <opsawg@ietfa.amsl.com>; Mon, 30 Nov >> 2015 16:14:59 -0800 (PST) >> Received: from mail-yk0-x22c.google.com >> (mail-yk0-x22c.google.com >> [IPv6:2607:f8b0:4002:c07::22c]) >> (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))= >> (No client certificate requested) by ietfa.amsl.com >> (Postfix) with ESMTPS id F170D1B2AF2 for >> >; Mon, 30 Nov 2015 16:14:58 >> -0800 (PST) >> Received: by ykdr82 with SMTP id r82so204978015ykd.3 for >> <opsawg@ietf.org>; Mon, 30 Nov 2015 16:14:58 >> -0800 (PST) >> X-Spam-Status: No, score=3D-1.277 tagged_above=3D-999 required=3D5 >> tests=3D[BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, >> FM_FORGED_GMAIL=3D0.622, HTML_MESSAGE=3D0.001] autolearn=3Dno >> X-Ms-Exchange-Organization-Messagedirectionality: Incoming >> X-Ms-Exchange-Organization-Scl: -1 >> X-Received: by 10.129.93.133 with SMTP id >> r127mr54962501ywb.109.1448928898116; Mon, 30 Nov 2015 16:14:58 -0800 >> (PST) >> Message-Id: >> > > >> Mime-Version: 1.0 >> X-Spam-Score: -1.277 >> List-Subscribe: , >> >> Re: [OPSAWG] FW: New Version Notification for >> draft-dahm-opsawg-tacacs-01.txt >> >> Dear OpsAWG, >> >> The chairs believe that there is sufficient interest and support to >> adopt this document as an OpsAWG document. >> >> Authors, please resubmit as draft-ietf-opsawg-tacacs-01 >> >> Working group:=20 >> We would like to see this document progress, and are hoping to WGLC it= >> soon. Please review this and provide feedback.... >> >> W >> >> On Fri, Nov 13, 2015 at 1:37 PM Warren Kumari > > wrote: >> >> We would really appreciate any feedback on this document. Personal= ly I >> think it is really useful, but we need the WG to review and provid= e >> feedback. >> >> Over the years I've heard a number of people kvetch that TACACS+ i= sn't >> documented -- well, now you can, you know, actually do something a= bout >> this... >> >> W >> >> On Sun, Oct 4, 2015 at 4:18 PM, Douglas Gash (dcmgash) >> > wrote: >> > Dear Opsawg List, >> > >> > We have uploaded a second revision of the TACACS+ protocol >> specification >> > which we believe is ready for publication subject subject to por= t >> > allocation. >> > >> > Please see details below. >> > >> > The essential difference from the first revision is the change >> of TLS >> > option support using a separate port as opposed to the original >> Start TLS >> > mechanism. >> > >> > We would be very grateful for the opinion of the list regarding = the >> > suitability of document for publication as an RFC. >> > >> > Many thanks, >> > >> > Thorsten, Andrej, Doug. >> > >> > >> > On 02/10/2015 16:25, "internet-drafts@ietf.org >> " > > >> > wrote: >> > >> >> >> >>A new version of I-D, draft-dahm-opsawg-tacacs-01.txt >> >>has been successfully submitted by Douglas C. Medway Gash and >> posted to >> >>the >> >>IETF repository. >> >> >> >>Name: draft-dahm-opsawg-tacacs >> >>Revision: 01 >> >>Title: The TACACS+ Protocol >> >>Document date: 2015-10-02 >> >>Group: Individual Submission >> >>Pages: 38 >> >>URL: >> >>https://www.ietf.org/internet-drafts/draft-dahm-opsawg-tacacs-01= =2Etxt >> >> >>Status: =20 >> https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/ >> >> >>Htmlized: =20 >> https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01 >> >> >>Diff: >> >>https://www.ietf.org/rfcdiff?url2=3Ddraft-dahm-opsawg-tacacs-01 >> >> >> >> >>Abstract: >> >> TACACS+ provides access control for routers, network access >> servers >> >> and other networked computing devices via one or more central= ized >> >> servers. TACACS+ provides separate authentication, >> authorization and >> >> accounting services. This document describes the protocol >> that is >> >> used by TACACS+. >> >> >> >> >> >> >> >> >> >> >> >>Please note that it may take a couple of minutes from the time o= f >> >>submission >> >>until the htmlized version and diff are available >> at tools.ietf.org >> . >> >> >> >>The IETF Secretariat >> >> >> > >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a ba= d >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expres= sing >> regret at having chosen those particular rabid weasels and that pa= ir >> of pants. >> ---maf >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --OELOppdEeSMqPwMrOKoRsdeCqsxjDb44O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAla+FoAACgkQ8AA1q7Z/VrLYVwCeKSK2xacvK1w+3tKwqcYaZlsO ++UAnRPlld5/W0exaTqRaI/69YrSfMWA =26f1 -----END PGP SIGNATURE----- --OELOppdEeSMqPwMrOKoRsdeCqsxjDb44O-- From nobody Fri Feb 12 09:40:59 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27A11A8711 for ; Fri, 12 Feb 2016 09:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.564 X-Spam-Level: **** X-Spam-Status: No, score=4.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, NUMERIC_HTTP_ADDR=1.242, RP_MATCHES_RCVD=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 v_FcAguCXNnK for ; Fri, 12 Feb 2016 09:40:50 -0800 (PST) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189371A7030 for ; Fri, 12 Feb 2016 09:40:50 -0800 (PST) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id 2703DBB748; Fri, 12 Feb 2016 18:40:48 +0100 (CET) To: "Bradner, Scott" , "opsawg@ietf.org" References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <56BE191E.2040205@restena.lu> Date: Fri, 12 Feb 2016 18:40:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d84xw0lQX9miPv76HH7nKeIEPt6beafcM" Archived-At: Cc: "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 17:40:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d84xw0lQX9miPv76HH7nKeIEPt6beafcM Content-Type: multipart/mixed; boundary="------------050000020803060401030409" This is a multi-part message in MIME format. --------------050000020803060401030409 Content-Type: multipart/alternative; boundary="------------010501080900060007070804" --------------010501080900060007070804 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > The chairs of the opsawg received an appeal from Alan DeKok on 11 Febru= ary > 2016 concerning the handling and possible disposition of > draft-ietf-opsawg-tacacs-00.txt (TACACS+). This message was a follow up= of > a number of email messages sent to the opsawg mailing list starting on= 10 > February. > > The topics of the appeal and other messages from Mr. DeKok included: > 1/ The adoption of the TACACS+ Internet Draft as a working group item. > 2/ The appropriateness of publishing the TACACS+ Internet Draft as > a RFC through the IETF track. > 3/ The appropriateness of publishing the TACACS+ Internet Draft as > a standards track RFC. > > This memo concerns the first topic, the other two topics are proper top= ics > for a working group mailing list when an Internet Draft is under > consideration. =20 > > First some history: > > After some initial confusion, the Internet Draft draft-grant-tacacs-00.= txt > was published on 12 June 2015. In an email message to the opsawg list > Doug Gash said: > > " TACACS+ is a protocol widely deployed, based upon a draft specificati= on > that Cisco submitted in 1998, but never completed to RFC status. The > original draft has been tidied and lightly enhanced and resubmitted, wi= th > the intent to finally get it published as a standard." > > He then followed up with an email message describing the updates to the= > old ID. > > 1 July 2015: the OPS Ads put TACACS+ on the agenda for ops area session= > during IETF 93 > > 20 July 2015: The ops area session was held. The TACACS+ slides used > during the session are at:=20 > https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf > > Minutes of the session are quite sparse. They note that the presentati= on > occurred and that Alan DeKok objected to the proposal. > > The audio recording of the session is at: > https://www.ietf.org/audio/ietf93/ietf93-congresshalli-20150720-1740.mp= 3 > > The audio of the speakers and the commentators at the mic line are quit= e > clear but, unfortunately, the audio of the AD is unintelligible. The > recording shows that there was little discussion of the merits of the > proposal other than Mr. DeKok's objections. One of the chairs (Scott) > recalls that the AD did some form of assessment to gage interest in > working on the ID and found support. =20 > > 2 October 2015: updated ID published > > 4 October 2015: Doug Gash sent note to opsawg list asking for opinions= of > the list for publication > > 13 November 2015: Warren sent the following message asking for input on= > the ID ( > https://www.ietf.org/mail-archive/web/opsawg/current/msg04124.html) > > Dear OpsAWG WG, > > We would really appreciate any feedback on this document. Personally= I > think it is really useful, but we need the WG to review and provide > feedback. > > Over the years I've heard a number of people kvetch that TACACS+ isn= 't > documented -- well, now you can, you know, actually do something abo= ut > this... > > W > > > There were a number of responses in support of publication and the WG > working on the ID along with some technical discussion. > > The chairs concluded that there was enough interest to adopt the ID as = a > working group topic. > > 30 November: 2015: Warren sent the following message to the opsawg:=20 > (for some reason this message does not show up in the archive but a > copy is=20 > appended to this message) > > The chairs believe that there is sufficient interest and support > to adopt > this document as an OpsAWG document. =20 > > Authors, please resubmit as draft-ietf-opsawg-tacacs-01 Argh. It would help to indicate time zones in this... the mail arrived just fine on 01 Dec! (CET). Stefan > > 16 December 2015 - renamed ID published > > > By asking the working group list for input on the question of adopting = an > ID as a working group document the opsawg chairs followed one of the > normal IETF process to determine if there was enough interest for the > working group to adopt the TACACS+ ID as a working group topic. We not= e > in passing that such another normal process is for the WG chairs to dec= ide > on their own to adopt a document as a working group topic. We also fel= t > that the topic was sufficiently within the working group charter to do = so > without a specific charter update. > > Thus Mr. DeKok's appeal as to the adoption of the ID as a working group= > topic is rejected. If Mr. DeKok believes that this does not satisfy his= > concerns, we refer him to RFC 2026, Section 6.5 for the next steps in t= he > appeal process. > > Scott Bradner > Warren Kumari > 12 February 2016 > > > =97----------------------------- > To: opsawg@ietf.org =20 > X-Ms-Exchange-Transport-Endtoendlatency: 00:00:01.8093445 > X-Forefront-Antispam-Report: > CIP:67.231.156.27;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:SKN;SFS:;DIR:INB;= SFP:;SCL:-1;SRVR:CY1PR0701MB1081;H:mx0b-00171101.pphosted.com > ;FPR:;SPF:None;LANG:en; > Spamdiagnosticmetadata: 7460966b2fd248469deae02cb8f82730 > X-Ms-Exchange-Crosstenant-Id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 > List-Id: OPSA Working Group Mail List > > X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); > Archived-At: > > X-Virus-Scanned: amavisd-new at amsl.com > X-Ms-Exchange-Organization-Authsource: BN1BFFO11FD050.protection.gbl > X-Google-Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; > d=3D1e100.net ; s=3D20130820; > h=3Dx-gm-message-state:mime-version:references:in-reply-to:from:date > :message-id:subject:to:content-type; > bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; > b=3DPsPRkLaCtAuWcQ9uh6l4qAyrI8koo4a5hbTbiJ+XC+FfQfvyF8xTabi2i41y4arQMJ > YCg0o0IgxVGCcCMaeocHg7jl23rBlc5Q+SSSPyUNyNBS6plN8uTXGWruR487LFPDUJ/f > PEFkyga3mSPU/LR3NqFJdZw1vxNt0JXQjXHt7cKfDfDGs1KD/yziL3aFWJWEDpD3iqAs > 2Ez4z3anmkMVgLaxUTnQDf9sgPjwYNUlCRbgfoHSO/L9kKQprVQ9duUVdn7A+KmzHWGL > WHtrG8QsySj8hj5J2Y1OJSFvyz3wBELGgQR/Xl4hGiyoGZdwL06RKvuO7FqoFHA/Kq5M > sFAg=3D=3D > X-Ms-Exchange-Crosstenant-Originalarrivaltime: 01 Dec 2015 > 00:15:04.5170 (UTC) > X-Proofpoint-Spam-Details: rule=3Dnotspam policy=3Ddefault > score=3D0 kscore.is _bulkscore=3D0 > kscore.compositescore=3D1 compositescore=3D0.9 suspectscore=3D2 > malwarescore=3D0 phishscore=3D0 bulkscore=3D0 kscore.is > _spamscore=3D0 rbsscore=3D0.9 spamscore=3D0 > urlsuspectscore=3D0.9 adultscore=3D0 classifier=3Dspam adjust=3D0 reaso= n=3Dmlx > scancount=3D1 engine=3D8.0.1-1507310000 definitions=3Dmain-1512010002 > Sender: "OPSAWG" > > List-Help: > X-Ms-Exchange-Organization-Network-Message-Id: > d55618f2-7475-4530-c456-08d2f9e47660 > List-Post: > Authentication-Results: spf=3Dfail (sender IP is 67.231.156.27) > smtp.mailfrom=3Dietf.org ; harvard.edu > ; dkim=3Dfail (body hash did not verify) > header.d=3Dietf.org ;harvard.edu ;= > dmarc=3Dnone action=3Dnone header.from=3Dkumari.net = ; > Spamdiagnosticoutput: 1:2 > X-Beenthere: opsawg@ietf.org > Return-Path: opsawg-bounces@ietf.org > References: <20151002152505.26594.74925.idtracker@ietfa.amsl.com > > > > > > > Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org= > ; s=3Dietf1; t=3D1448928901; > bh=3Dpvt1kSVXuErtfU5ZWISQikMRPQYfDp05mGMYsb+SFcI=3D; > h=3DMIME-Version:References:In-Reply-To:From:Date:Message-ID:To: > Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: > List-Subscribe:Content-Type:Sender; > b=3DZRweO7Tp3Xq/v7MwtQY7Bq6Jbp5tU+2+++F0dEQALPEVXTbQ++h45JzxLZyES8ikI > ok6ibFCR0Mkw1P1O6EQM3tIwQlLD6Xl1KnsDn74aUUD6RvQ+dD5P0gctrn1SuGiQ8T > jY5RD5B1YE7gpvyMoEYoDve3GiDolWuuyclQFdko=3D > Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; > d=3Dkumari-net.20150623.gappssmtp.com > ; s=3D20150623; > h=3Dmime-version:references:in-reply-to:from:date:message-id:subject:to= > :content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; > b=3DtRm8MTHNrVMLwiQrHd7XMteT2khz1LCvlSrKQHk3ELC5CCOUKybfJUCUwVwxirEqnX > fRpqiwO5pRPvSr+HyvnEf7e0RDpmxWnwne7H35NxkmMHpbxVQP+W15sB/NBcGkhpTc/J > wS/tTGwxxOempxpXCkVwGZ08QXrfMtCk6BkzYWGWhAhpwmVO+JCpglvaZXe4kH7bhh5g > hOAZJWp/uSzO/l1Fm27xgt57veT1LyZoIwQpcCRhzaA/jKOnfiUt0i4k07mc16U5LWoS > x4Oa27VmHq1szNAU6hIwCqVJbgacuCB/+vjNM2SyOLuSBctWHJ5ldTY662XDkeBl7kNu > YEAg=3D=3D > X-Matching-Connectors: > 130934025046730165;(d93d0180-227e-457c-4499-08d2eaec9703,256b2f12-4edf-= 4bba-ca8a-08d1766a767f,4c2fb881-fd60-47c4-27de-08d1a9464aaf,d8bbbf0d-8e19= -4272-9345-08d1b65cb793,751b4e9e-d4fb-44bf-a131-08d1dc9823e4,e0068ebf-014= b-4c73-793a-08d2f1dcc743,ac01cf0c-e967-495c-3fa9-08d1e70141cd,2808f1c2-2c= 2f-483e-3d80-08d1dfb2fe99,f9e899bb-1cc2-41db-5fa0-08d071a1a76e,3dfa065d-6= d09-41e4-03d6-08d1999434e1,8f72f349-eac7-4ca2-5909-08d1f4d6bd8f);(fc40b7b= 3-9d92-4bad-511b-08d1429671f0,f044a6d7-98b9-4c10-91b4-08d210413fe9,27bd2d= ba-e8c1-4f61-5bcb-08d2e63a1f24,6437d2a5-7830-487a-b613-08d2d5a0d354,d3806= 232-5d13-4149-28ff-08d1dec60473,dbc00d3f-cf39-4d73-fd34-08d1ba252138,9adb= 280f-4fbe-49ab-17ad-08d0c8b1feb2,70fb42a1-9688-41b6-d810-08d1b07b4924) > Errors-To: opsawg-bounces@ietf.org > Received-Spf: Fail (protection.outlook.com > : domain of ietf.org > does not designate 67.231.156.27 as permitted > sender) receiver=3Dprotection.outlook.com > ; client-ip=3D67.231.156.27; > helo=3Dmx0b-00171101.pphosted.com ; > X-Microsoft-Exchange-Diagnostics: > 1;BN1BFFO11FD050;1:7ZN9YK7xDF/YOFqgSF/Kt7SEuRl6m82TEEFS5pjj0L9WZ2XsjsoK= 06RHQoqp0zZJOqzHLsK7p62sRC/+dl0NHewnxWHjlYkFlErO0QxPu3bkMMMWFDL0D1gNkNNAL= QMEcCEwMN1E+sHfvWqfShtOpPbseWAIU0wFbf+THNAsZ0poUqywVPIeJRTJ27KhrMzdvfCBdI= h8IvZ5UF+i5/30Lwu90TwhHBydQj9impHXhJzz6cchwyC+cZByHdxbhbkikaFU2ORf9xwBx/d= wA6acnIYurcZxXE6rI4nl6Z+1j2pTmTRov/u+6965Gn47kV1qSjmeeWQq1+Jsqg0nQP0LqvWX= 6Cygd4/KgcYExishE7nivKVZq72r4lJb+0eaMswT/63GpfiTqVx21+UBx3NKvMulQSqG9Gizk= 6aBns/3BJrRmYi0j5iGr+dfbx0LymzdOdOFUfmgTIYGJGhjO701+aLnQHD7VrB1FBD2W7/zJi= WnJr5rxHNe0uP28JUnb6+5lr/fewGEZZ4jImQ+RbfZbw=3D=3D > X-Microsoft-Exchange-Diagnostics: > 1;CY1PR0701MB1081;2:W1i0t4PGHpWZpZGn0gwqccaOVv2u49nkFSof3JBlrQuQJwcKl9Y= 2wDeVl5A9iErzqOJItTyPziqfAt7KyGEax9rM95tiKtjcxgzwzjQjiqQFpGgTHF1Q/mY+w1og= 6GEQgS4XgMDljIAumw4tSpiQLA=3D=3D;3:BKRbPmRM5q+4prHbMMl1pl1ZZ2tS0rVGiw7aEH= 1Cq7HPVNxaYdiJOPc4/BJYvodVY1vbr67qwwATIDtXfVie9db2RjBDjxQWPRY5zXwlnI582Jv= vSd3uxAI1YZzAFgcWkt7sCG2ZuD2Nym9vBxvHl7WD5sUdx2tr8izLC86dMugMDG0IyhzPFEfr= 9B0mswrrXtD3XPjkoCi/NAC/ihsDyV4LoM3/Kd4he2AayTNrxq7+itBmev+RI6m84iRRzIxuK= /Qbd5vCfSbIsrCkmcxqVlgzXkMxrUazuheTQDsGM0gK2MaZaMTBhdk+8KyD4u2b;25:78MIti= 2YLv9i038KUTfSvspXHFS1JtJYQgWUyzyoiB4b3M+szJyih+58z81aUvYrNTmZCYWxeNbJxOq= cSEnFD/tFLF7lEod2v8DhzNxAdXfJlAcv/35AqU99iwL0MzdeiGdV0hWIfIoVGEM6rn12InmN= NZ5+H4mFspZlpFJBmC99ylYHhnYeRTvpCjhE26D9ry85Uq8vNQ7T7vG1qWT8sB8ZYFRgdnmOZ= lEZiDrmOMlFIc+4htsemKRufgfcZGhCaZM218PwPk9YqrrKaDAPNg=3D=3D > X-Microsoft-Exchange-Diagnostics: > 1;CY1PR0701MB1081;20:PdLuCCyiCFshW0NdPnC8eBojhNvmPTsHv/4UFnq2/Ap13ChYoz= GcdEqkVUoCDgV6xCnbV2sch84G9YqciCrAqpBOC+P+Jadb/xWosqipDjCzZzQB38ah3V+4Bdn= bm37aWs527QTdFX74o319rkRkpfQW5lZBUE/+akaLk3iPOSDGklLOcMMzk5E6MUkg1FCxeTSC= RbEJI7C8Gcfkp4Z33sWwZ4l4nZsTryQjFNwUnKD35K3vVXCSTUr9mHEed86B;4:ZkdYP0b+re= AAtcSPR/s6gs/4xtl2BduQqcuxMWhnPArjFsyI7D8qxhJzegLJImmIurwvGNuAuPAEBVnzfKk= 7Uk8KmXurz5VrNWWXz9H9kX5I2iSoY82hbOGqpxoKZN7ZvT4eNnkftfwEBBb6cJWbLX2wJr1G= hZQStKHhnKOXCtnWTG1bCOsAlUFzO4fcQrK1871zmJYcVLFeXs2soxq6zRVidnUVx5aVcz1fb= UW1pYYi7SVTmKUxHgDHpBlhE2M7IsQCf2/z8jspwHR2/Ca4QwfTsBOwrzlBeHryjxjGwDLah0= Sq5W9fy5doXLWj6Zp5Hd+78AnQKQjTLJoJzeypO8JVtyeXqv0y/UpPjXENphbC674cRQEyEho= yLOWypuJeUP9XukINATvVEdgJnCHepkJSOHSZQea9zGKnTHazYjoG79eK1lsLgx2Uersmxtwz= ;23:4EKpER/Wex7l7yJjNu6NCf/OL8GUvFcTfH03V6f1kyvAD+1i3rMhMIMUTaS5RuFVEBIT+= 1hV2YemnNtNCejbQsscJK47MvrYffu1Y4FWysZHwmuW5Z8YY19Z55gg/bBjgeHwuc/ECiG+G5= 4mZGKtdkuN1f6XkkJRlk9b5miEeMYyeSa/DeEi+1X+/69BTaHhVmdsOnEIiXOEmwKmURBUbA=3D= =3D > X-Microsoft-Exchange-Diagnostics: > 1;CY1PR0701MB1081;5:NDmSUNkFZijBwPfECIN39/nKL9SZpZQoXf83DdYdG6c6uqvKq9p= FL11zCIluGBfbfr7j8GHWoHjCFpbx7VYG1+pJWsbw3uKmx12woMpxVU2oaxoV8Tb44v0zoaB1= O2FhE9sZbcp5E+k+VFpjT7mxIQ=3D=3D;24:oRXQcwEWxPCuqn5UAzNUq6ABuuvQYLIsu5Ibt= KyT8I8selWffYvnEZgXF6cORNZqS7B2xyDLy5FjzmcmEVLIXOyOiXuHI1QWDuagZnryAws=3D= > In-Reply-To: > > > X-Dkimresult-Test: Failed > X-Gm-Message-State: > ALoCoQkPLNgOMt4FMOCWAKl2MLYDSZRuN/UoBjBSG0VRor2S+5FEJOJodLN/6r9gEZU0DpD= M7xYa > Content-Type: multipart/mixed; > boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D80877674353618= 66650=3D=3D" > X-Original-To: opsawg@ietfa.amsl.com > X-Exchange-Antispam-Report-Cfa-Test: > BCL:7;PCL:0;RULEID:(601004)(7630046)(2401047)(520078)(8121501046)(76310= 46)(3002001)(10201501046);SRVR:CY1PR0701MB1081;BCL:7;PCL:0;RULEID:;SRVR:C= Y1PR0701MB1081; > X-Ms-Exchange-Transport-Crosstenantheadersstamped: CY1PR0701MB1081 > X-Ms-Exchange-Organization-Authas: Anonymous > X-Ms-Exchange-Organization-Avstamp-Service: 1.0 > X-Spam-Flag: NO > X-Mailman-Version: 2.1.15 > List-Archive: > List-Unsubscribe: , > > Precedence: list > Delivered-To: opsawg@ietfa.amsl.com > X-Proofpoint-Virus-Version: vendor=3Dfsecure engine=3D2.50.10432:,, > definitions=3D2015-11-30_09:,, signatures=3D0 > X-Spam-Level:=20 > X-Ms-Exchange-Crosstenant-Fromentityheader: Internet > X-Microsoft-Antispam: > UriScan:;BCL:7;PCL:0;RULEID:(421252001)(3002015)(71701003)(71702001);SR= VR:CY1PR0701MB1081; > X-Eopattributedmessage: 0 > Received: from CY1PR0701MB1081.namprd07.prod.outlook.com > (10.160.145.153) > by CY1PR0701MB1082.namprd07.prod.outlook.com > (10.160.145.154) > with Microsoft SMTP Server (TLS) id 15.1.331.20 via Mailbox Transport; > Tue, 1 Dec 2015 00:15:06 +0000 > Received: from BY2PR07CA054.namprd07.prod.outlook.com > (10.141.251.29) > by CY1PR0701MB1081.namprd07.prod.outlook.com > (10.160.145.153) > with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 > 00:15:05 +0000 > Received: from BN1BFFO11FD050.protection.gbl > (2a01:111:f400:7c10::1:171) by BY2PR07CA054.outlook.office365.com > (2a01:111:e400:2c61::29) > with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend > Transport; Tue, 1 Dec 2015 00:15:04 +0000 > Received: from mx0b-00171101.pphosted.com > (67.231.156.27) > by BN1BFFO11FD050.mail.protection.outlook.com > (10.58.145.5) with > Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; > Tue, 1 Dec 2015 00:15:04 +0000 > Received: from pps.filterd (m0044905.ppops.net > [127.0.0.1]) by mx0b-00171101.pphosted.com > (8.15.0.59/8.15.0.59) with SMTP id > tB10BRUI022328 for >; Mon, 30 > Nov 2015 19:15:04 -0500 > Received: from mail.ietf.org (mail.ietf.org > [4.31.198.44]) by mx0b-00171101.pphosted.com > with ESMTP id 1yf8kh97s0-1 > (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES256-GCM-SHA384 bits=3D256 > verify=3DNOT) for >; Mon, 30 > Nov 2015 19:15:03 -0500 > Received: from ietfa.amsl.com (localhost > [IPv6:::1]) by ietfa.amsl.com (Postfix) with > ESMTP id 7B50F1B2AF2; Mon, 30 Nov 2015 16:15:01 -0800 (PST) > Received: from localhost (ietfa.amsl.com > [127.0.0.1]) by ietfa.amsl.com > (Postfix) with ESMTP id E30B81B33B1 for > >; Mon, 30 Nov > 2015 16:15:00 -0800 (PST) > 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 PAKUO7m6pu7B for > >; Mon, 30 Nov > 2015 16:14:59 -0800 (PST) > Received: from mail-yk0-x22c.google.com > (mail-yk0-x22c.google.com > [IPv6:2607:f8b0:4002:c07::22c]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) > (No client certificate requested) by ietfa.amsl.com > (Postfix) with ESMTPS id F170D1B2AF2 for > >; Mon, 30 Nov 2015 16:14:58 > -0800 (PST) > Received: by ykdr82 with SMTP id r82so204978015ykd.3 for > >; Mon, 30 Nov 2015 16:14:58 > -0800 (PST) > X-Spam-Status: No, score=3D-1.277 tagged_above=3D-999 required=3D5 > tests=3D[BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, > FM_FORGED_GMAIL=3D0.622, HTML_MESSAGE=3D0.001] autolearn=3Dno > X-Ms-Exchange-Organization-Messagedirectionality: Incoming > X-Ms-Exchange-Organization-Scl: -1 > X-Received: by 10.129.93.133 with SMTP id > r127mr54962501ywb.109.1448928898116; Mon, 30 Nov 2015 16:14:58 -0800 > (PST) > Message-Id: > > > Mime-Version: 1.0 > X-Spam-Score: -1.277 > List-Subscribe: , > > Re: [OPSAWG] FW: New Version Notification for > draft-dahm-opsawg-tacacs-01.txt > > Dear OpsAWG, > > The chairs believe that there is sufficient interest and support to > adopt this document as an OpsAWG document. > > Authors, please resubmit as draft-ietf-opsawg-tacacs-01 > > Working group:=20 > We would like to see this document progress, and are hoping to WGLC it > soon. Please review this and provide feedback.... > > W > > On Fri, Nov 13, 2015 at 1:37 PM Warren Kumari > wrote: > > We would really appreciate any feedback on this document. Personall= y I > think it is really useful, but we need the WG to review and provide= > feedback. > > Over the years I've heard a number of people kvetch that TACACS+ is= n't > documented -- well, now you can, you know, actually do something ab= out > this... > > W > > On Sun, Oct 4, 2015 at 4:18 PM, Douglas Gash (dcmgash) > > wrote: > > Dear Opsawg List, > > > > We have uploaded a second revision of the TACACS+ protocol > specification > > which we believe is ready for publication subject subject to port= > > allocation. > > > > Please see details below. > > > > The essential difference from the first revision is the change > of TLS > > option support using a separate port as opposed to the original > Start TLS > > mechanism. > > > > We would be very grateful for the opinion of the list regarding t= he > > suitability of document for publication as an RFC. > > > > Many thanks, > > > > Thorsten, Andrej, Doug. > > > > > > On 02/10/2015 16:25, "internet-drafts@ietf.org > " > > > wrote: > > > >> > >>A new version of I-D, draft-dahm-opsawg-tacacs-01.txt > >>has been successfully submitted by Douglas C. Medway Gash and > posted to > >>the > >>IETF repository. > >> > >>Name: draft-dahm-opsawg-tacacs > >>Revision: 01 > >>Title: The TACACS+ Protocol > >>Document date: 2015-10-02 > >>Group: Individual Submission > >>Pages: 38 > >>URL: > >>https://www.ietf.org/internet-drafts/draft-dahm-opsawg-tacacs-01.= txt > > >>Status: =20 > https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/ > > >>Htmlized: =20 > https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01 > > >>Diff: > >>https://www.ietf.org/rfcdiff?url2=3Ddraft-dahm-opsawg-tacacs-01 > > >> > >>Abstract: > >> TACACS+ provides access control for routers, network access > servers > >> and other networked computing devices via one or more centrali= zed > >> servers. TACACS+ provides separate authentication, > authorization and > >> accounting services. This document describes the protocol > that is > >> used by TACACS+. > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of= > >>submission > >>until the htmlized version and diff are available > at tools.ietf.org > . > >> > >>The IETF Secretariat > >> > > > > > > -- > I don't think the execution is relevant when it was obviously a bad= > idea in the first place. > This is like putting rabid weasels in your pants, and later express= ing > regret at having chosen those particular rabid weasels and that pai= r > of pants. > ---maf > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------010501080900060007070804 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

The chairs of the opsawg received an appeal from Alan DeKok on 11 February
2016 concerning the handling and possible disposition of
draft-ietf-opsawg-tacacs-00.txt (TACACS+). This message was a follow up of
a number of=A0 email messages sent to the opsawg mailing list starting on 10
February.

The topics of the appeal and other messages from Mr. DeKok included:
1/ The adoption of the TACACS+ Internet Draft as a working group item.
2/ The appropriateness of publishing the TACACS+ Internet Draft as
a RFC through the IETF track.
3/ The appropriateness of publishing the TACACS+ Internet Draft as
a standards track RFC.

This memo concerns the first topic, the other two topics are proper topics
for a working group mailing list when an Internet Draft is under
consideration. =A0

First some history:

After some initial confusion, the Internet Draft draft-grant-tacacs-00.txt
was published on 12 June 2015.=A0 In an email message to the opsawg list
Doug Gash said:

" TACACS+ is a protocol widely deployed, based upon a draft specification
that Cisco submitted in 1998, but never completed to RFC status. The
original draft has been tidied and lightly enhanced and resubmitted, with
the intent to finally get it published as a standard."

He then followed up with an email message describing the updates to the
old ID.

1 July 2015: the OPS Ads put TACACS+ on the agenda for ops area session
during IETF 93

20 July 2015: The ops area session was held. The TACACS+ slides used
during the session are at:=A0
https://www.ietf.org/proceedings/93/slides/slides-= 93-opsarea-2.pdf

Minutes of the session are quite sparse.=A0 They note that the presentation
occurred and that Alan DeKok objected to the proposal.

The audio recording of the session is at:
https://www.ietf.org/audio/ietf93/ietf93-congressh= alli-20150720-1740.mp3

The audio of the speakers and the commentators at the mic line are quite
clear but, unfortunately, the audio of the AD is unintelligible. =A0 The
recording shows that there was little discussion of the merits of the
proposal other than Mr. DeKok's objections.=A0 One of the chair= s (Scott)
recalls that the AD did some form of assessment to gage interest in
working on the ID and found support. =A0

2 October=A0 2015:=A0 updated ID published

4 October 2015:=A0 Doug Gash sent note to opsawg list asking fo= r opinions of
the list for publication

13 November 2015: Warren sent the following message asking for input on
the ID (
https://www.ietf.org/mail-archive/web/opsawg/curre= nt/msg04124.html)

Dear OpsAWG WG,

=A0=A0 We would really appreciate any feedback on this document= =2E Personally I
=A0=A0 think it is really useful, but we need the WG to review = and provide
=A0=A0 feedback.

=A0=A0 Over the years I've heard a number of people kvetch that= TACACS+ isn't
=A0=A0 documented -- well, now you can, you know, actually do something about
=A0=A0 this...

=A0=A0 W


There were a number of responses in support of publication and the WG
working on the ID along with some technical discussion.

The chairs concluded that there was enough interest to adopt the ID as a
working group topic.

30 November: 2015: Warren sent the following message to the opsawg:=A0
(for some reason this message does not show up in the archive but a copy is=A0
appended to this message)

=A0 =A0 The chairs believe that there is sufficient interest an= d support to adopt
=A0 =A0 this document as an OpsAWG document. =A0

=A0 =A0 Authors, please resubmit as draft-ietf-opsawg-tacacs-01=

Argh. It would help to indicate time zones in this... the mail arrived just fine on 01 Dec! (CET).

Stefan


16 December 2015 - renamed ID published


By asking the working group list for input on the question of adopting an
ID as a working group document the opsawg chairs followed one of the
normal IETF process to determine if there was enough interest for the
working group to adopt the TACACS+ ID as a working group topic.=A0 We note
in passing that such another normal process is for the WG chairs to decide
on their own to adopt a document as a working group topic.=A0 W= e also felt
that the topic was sufficiently within the working group charter to do so
without a specific charter update.

Thus Mr. DeKok's appeal as to the adoption of the ID as a working group
topic is rejected. If Mr. DeKok believes that this does not satisfy his
concerns, we refer him to RFC 2026, Section 6.5 for the next steps in the
appeal process.

Scott Bradner
Warren Kumari
12 February 2016


=97-----------------------------
To:=A0opsawg@ietf.org=A0
X-Ms-Exchange-Transport-Endtoendlatency: 00:00:01.8093445
=
X-Forefront-Antispam-Report: CIP:67.231.156.27;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:SKN;SFS:;DIR:INB;SF= P:;SCL:-1;SRVR:CY1PR0701MB1081;H:mx0b-00171101.pphosted.com;FPR:;SPF:None;LANG:en;
Spamdiagnosticmetadata: 7460966b2fd248469deae02cb8f82730
X-Ms-Exchange-Crosstenant-Id: 6ffa22f4-4568-4105-ad43-2e3ad4726957
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsawg/1hB3Nk= w1KcsSvrNlOcelGV2dJfM>
X-Virus-Scanned: amavisd-new at=A0amsl.com
X-Ms-Exchange-Organization-Authsource: BN1BFFO11FD050.protection.gbl
X-Google-Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/rel= axed; d=3D1e100.net; s=3D20130820; h=3Dx-gm-message-state:mime-version:references:in-reply-to:from= :date :message-id:subject:to:content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; b=3DPsPRkLaCtAuWcQ9uh6l4qAyrI8koo4a5hbTbiJ+XC+FfQfvyF8xTabi2i41= y4arQMJ YCg0o0IgxVGCcCMaeocHg7jl23rBlc5Q+SSSPyUNyNBS6plN8uTXGWruR487LFP= DUJ/f PEFkyga3mSPU/LR3NqFJdZw1vxNt0JXQjXHt7cKfDfDGs1KD/yziL3aFWJWEDpD= 3iqAs 2Ez4z3anmkMVgLaxUTnQDf9sgPjwYNUlCRbgfoHSO/L9kKQprVQ9duUVdn7A+Km= zHWGL WHtrG8QsySj8hj5J2Y1OJSFvyz3wBELGgQR/Xl4hGiyoGZdwL06RKvuO7FqoFHA= /Kq5M sFAg=3D=3D
X-Ms-Exchange-Crosstenant-Originalarrivaltime: 01 Dec 2015 00:15:04.5170 (UTC)
X-Proofpoint-Spam-Details: rule=3Dnotspam policy=3Ddefault score=3D0=A0kscore.is_bulkscore=3D0 kscore.compositescore=3D= 1 compositescore=3D0.9 suspectscore=3D2 malwarescore=3D0 phishsco= re=3D0 bulkscore=3D0=A0kscore.is_spamscore=3D0 rbsscore=3D0.9 spamsco= re=3D0 urlsuspectscore=3D0.9 adultscore=3D0 classifier=3Dspam adjust=3D= 0 reason=3Dmlx scancount=3D1 engine=3D8.0.1-1507310000 definitions=3Dmain-1512010002
Sender: "OPSAWG" <opsawg-bou= nces@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=3Dhelp>
X-Ms-Exchange-Organization-Network-Message-Id: d55618f2-7475-4530-c456-08d2f9e47660
List-Post: <mailto:opsawg@ietf= =2Eorg>
Authentication-Results: spf=3Dfail (sender IP is 67.231.156.27)= smtp.mailfrom=3Dietf.org;=A0harvard.edu; dkim=3Dfail (body hash did not verify) header.d=3D= ietf.org;harvard.edu; dmarc=3Dnone action=3Dnone header.from=3Dkumari.net;
Spamdiagnosticoutput: 1:2
X-Beenthere:=A0opsawg@ietf.org
Return-Path:=A0opsawg-bou= nces@ietf.org
References: <20151002152505.26594.74925.idtracker@ietfa.amsl.co= m> <D237455F.BC00F%dcmgash@cisco.co= m> <CAHw9_iKOM5N3-HS3ZOFFaDHYTV7rDaf3YHo-dEmdTU9-4W49a= w@mail.gmail.com>
Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3D= = ietf.org; s=3Dietf1; t=3D1448928901; bh=3Dpvt1kSVXuErtfU5ZWISQikMRPQYfDp05mGMYsb+SFcI=3D; h=3DMIME-Version:References:In-Reply-To:From:Date:Message-ID:To= : Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-He= lp: List-Subscribe:Content-Type:Sender; b=3DZRweO7Tp3Xq/v7MwtQY7Bq6Jbp5tU+2+++F0dEQALPEVXTbQ++h45JzxLZy= ES8ikI ok6ibFCR0Mkw1P1O6EQM3tIwQlLD6Xl1KnsDn74aUUD6RvQ+dD5P0gctrn1SuGi= Q8T jY5RD5B1YE7gpvyMoEYoDve3GiDolWuuyclQFdko=3D
Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D= = kumari-net.20150623.gappssmtp.com; s=3D20150623; h=3Dmime-version:references:in-reply-to:from:date:message-id:su= bject:to :content-type; bh=3DIVgznUAN4dKW1K4utAu7lAyHiEF2oelqwEtycGC+OC4=3D; b=3DtRm8MTHNrVMLwiQrHd7XMteT2khz1LCvlSrKQHk3ELC5CCOUKybfJUCUwVw= xirEqnX fRpqiwO5pRPvSr+HyvnEf7e0RDpmxWnwne7H35NxkmMHpbxVQP+W15sB/NBcGkh= pTc/J wS/tTGwxxOempxpXCkVwGZ08QXrfMtCk6BkzYWGWhAhpwmVO+JCpglvaZXe4kH7= bhh5g hOAZJWp/uSzO/l1Fm27xgt57veT1LyZoIwQpcCRhzaA/jKOnfiUt0i4k07mc16U= 5LWoS x4Oa27VmHq1szNAU6hIwCqVJbgacuCB/+vjNM2SyOLuSBctWHJ5ldTY662XDkeB= l7kNu YEAg=3D=3D
X-Matching-Connectors: 130934025046730165;(d93d0180-227e-457c-4499-08d2eaec9703,256b2f12-4edf-4b= ba-ca8a-08d1766a767f,4c2fb881-fd60-47c4-27de-08d1a9464aaf,d8bbbf0d-8e19-4= 272-9345-08d1b65cb793,751b4e9e-d4fb-44bf-a131-08d1dc9823e4,e0068ebf-014b-= 4c73-793a-08d2f1dcc743,ac01cf0c-e967-495c-3fa9-08d1e70141cd,2808f1c2-2c2f= -483e-3d80-08d1dfb2fe99,f9e899bb-1cc2-41db-5fa0-08d071a1a76e,3dfa065d-6d0= 9-41e4-03d6-08d1999434e1,8f72f349-eac7-4ca2-5909-08d1f4d6bd8f);(fc40b7b3-= 9d92-4bad-511b-08d1429671f0,f044a6d7-98b9-4c10-91b4-08d210413fe9,27bd2dba= -e8c1-4f61-5bcb-08d2e63a1f24,6437d2a5-7830-487a-b613-08d2d5a0d354,d380623= 2-5d13-4149-28ff-08d1dec60473,dbc00d3f-cf39-4d73-fd34-08d1ba252138,9adb28= 0f-4fbe-49ab-17ad-08d0c8b1feb2,70fb42a1-9688-41b6-d810-08d1b07b4924)
Errors-To:=A0opsawg-bou= nces@ietf.org
Received-Spf: Fail (protection.= outlook.com: domain of=A0ietf.org=A0does not designate 67.231.156.27 as= permitted sender) receiver=3Dprotection.= outlook.com; client-ip=3D67.231.156.27; helo=3Dmx0b-00= 171101.pphosted.com;
X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD050;1:7ZN9YK7xDF/YOFqgSF/Kt7SEuRl6m82TEEFS5pjj0L9WZ2XsjsoK06= RHQoqp0zZJOqzHLsK7p62sRC/+dl0NHewnxWHjlYkFlErO0QxPu3bkMMMWFDL0D1gNkNNALQM= EcCEwMN1E+sHfvWqfShtOpPbseWAIU0wFbf+THNAsZ0poUqywVPIeJRTJ27KhrMzdvfCBdIh8= IvZ5UF+i5/30Lwu90TwhHBydQj9impHXhJzz6cchwyC+cZByHdxbhbkikaFU2ORf9xwBx/dwA= 6acnIYurcZxXE6rI4nl6Z+1j2pTmTRov/u+6965Gn47kV1qSjmeeWQq1+Jsqg0nQP0LqvWX6C= ygd4/KgcYExishE7nivKVZq72r4lJb+0eaMswT/63GpfiTqVx21+UBx3NKvMulQSqG9Gizk6a= Bns/3BJrRmYi0j5iGr+dfbx0LymzdOdOFUfmgTIYGJGhjO701+aLnQHD7VrB1FBD2W7/zJiWn= Jr5rxHNe0uP28JUnb6+5lr/fewGEZZ4jImQ+RbfZbw=3D=3D
X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1081;2:W1i0t4PGHpWZpZGn0gwqccaOVv2u49nkFSof3JBlrQuQJwcKl9Y2w= DeVl5A9iErzqOJItTyPziqfAt7KyGEax9rM95tiKtjcxgzwzjQjiqQFpGgTHF1Q/mY+w1og6G= EQgS4XgMDljIAumw4tSpiQLA=3D=3D;3:BKRbPmRM5q+4prHbMMl1pl1ZZ2tS0rVGiw7aEH1C= q7HPVNxaYdiJOPc4/BJYvodVY1vbr67qwwATIDtXfVie9db2RjBDjxQWPRY5zXwlnI582JvvS= d3uxAI1YZzAFgcWkt7sCG2ZuD2Nym9vBxvHl7WD5sUdx2tr8izLC86dMugMDG0IyhzPFEfr9B= 0mswrrXtD3XPjkoCi/NAC/ihsDyV4LoM3/Kd4he2AayTNrxq7+itBmev+RI6m84iRRzIxuK/Q= bd5vCfSbIsrCkmcxqVlgzXkMxrUazuheTQDsGM0gK2MaZaMTBhdk+8KyD4u2b;25:78MIti2Y= Lv9i038KUTfSvspXHFS1JtJYQgWUyzyoiB4b3M+szJyih+58z81aUvYrNTmZCYWxeNbJxOqcS= EnFD/tFLF7lEod2v8DhzNxAdXfJlAcv/35AqU99iwL0MzdeiGdV0hWIfIoVGEM6rn12InmNNZ= 5+H4mFspZlpFJBmC99ylYHhnYeRTvpCjhE26D9ry85Uq8vNQ7T7vG1qWT8sB8ZYFRgdnmOZlE= ZiDrmOMlFIc+4htsemKRufgfcZGhCaZM218PwPk9YqrrKaDAPNg=3D=3D
X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1081;20:PdLuCCyiCFshW0NdPnC8eBojhNvmPTsHv/4UFnq2/Ap13ChYozGc= dEqkVUoCDgV6xCnbV2sch84G9YqciCrAqpBOC+P+Jadb/xWosqipDjCzZzQB38ah3V+4Bdnbm= 37aWs527QTdFX74o319rkRkpfQW5lZBUE/+akaLk3iPOSDGklLOcMMzk5E6MUkg1FCxeTSCRb= EJI7C8Gcfkp4Z33sWwZ4l4nZsTryQjFNwUnKD35K3vVXCSTUr9mHEed86B;4:ZkdYP0b+reAA= tcSPR/s6gs/4xtl2BduQqcuxMWhnPArjFsyI7D8qxhJzegLJImmIurwvGNuAuPAEBVnzfKk7U= k8KmXurz5VrNWWXz9H9kX5I2iSoY82hbOGqpxoKZN7ZvT4eNnkftfwEBBb6cJWbLX2wJr1GhZ= QStKHhnKOXCtnWTG1bCOsAlUFzO4fcQrK1871zmJYcVLFeXs2soxq6zRVidnUVx5aVcz1fbUW= 1pYYi7SVTmKUxHgDHpBlhE2M7IsQCf2/z8jspwHR2/Ca4QwfTsBOwrzlBeHryjxjGwDLah0Sq= 5W9fy5doXLWj6Zp5Hd+78AnQKQjTLJoJzeypO8JVtyeXqv0y/UpPjXENphbC674cRQEyEhoyL= OWypuJeUP9XukINATvVEdgJnCHepkJSOHSZQea9zGKnTHazYjoG79eK1lsLgx2Uersmxtwz;2= 3:4EKpER/Wex7l7yJjNu6NCf/OL8GUvFcTfH03V6f1kyvAD+1i3rMhMIMUTaS5RuFVEBIT+1h= V2YemnNtNCejbQsscJK47MvrYffu1Y4FWysZHwmuW5Z8YY19Z55gg/bBjgeHwuc/ECiG+G54m= ZGKtdkuN1f6XkkJRlk9b5miEeMYyeSa/DeEi+1X+/69BTaHhVmdsOnEIiXOEmwKmURBUbA=3D= =3D
X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1081;5:NDmSUNkFZijBwPfECIN39/nKL9SZpZQoXf83DdYdG6c6uqvKq9pFL= 11zCIluGBfbfr7j8GHWoHjCFpbx7VYG1+pJWsbw3uKmx12woMpxVU2oaxoV8Tb44v0zoaB1O2= FhE9sZbcp5E+k+VFpjT7mxIQ=3D=3D;24:oRXQcwEWxPCuqn5UAzNUq6ABuuvQYLIsu5IbtKy= T8I8selWffYvnEZgXF6cORNZqS7B2xyDLy5FjzmcmEVLIXOyOiXuHI1QWDuagZnryAws=3D
In-Reply-To: <CAHw9_iKOM5N3-HS3ZOFFaDHYTV7rDaf3YHo-dEmdTU9-4W49a= w@mail.gmail.com>
X-Dkimresult-Test: Failed
X-Gm-Message-State: ALoCoQkPLNgOMt4FMOCWAKl2MLYDSZRuN/UoBjBSG0VRor2S+5FEJOJodLN/6r9gEZU0DpDM7= xYa
Content-Type: multipart/mixed; boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D808776= 7435361866650=3D=3D"
X-Original-To:=A0opsawg@ietfa= =2Eamsl.com
X-Exchange-Antispam-Report-Cfa-Test: BCL:7;PCL:0;RULEID:(601004)(7630046)(2401047)(520078)(8121501046)(7631046= )(3002001)(10201501046);SRVR:CY1PR0701MB1081;BCL:7;PCL:0;RULEID:;SRVR:CY1= PR0701MB1081;
X-Ms-Exchange-Transport-Crosstenantheadersstamped: CY1PR0701MB1081
X-Ms-Exchange-Organization-Authas: Anonymous
X-Ms-Exchange-Organization-Avstamp-Service: 1.0
X-Spam-Flag: NO
X-Mailman-Version: 2.1.15
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=3Dunsubscri= be>
Precedence: list
Delivered-To:=A0opsawg@ietfa= =2Eamsl.com
X-Proofpoint-Virus-Version: vendor=3Dfsecure engine=3D2.50.10432:,, definitions=3D2015-11-30_09:,, signature= s=3D0
X-Spam-Level:=A0
X-Ms-Exchange-Crosstenant-Fromentityheader: Internet
X-Microsoft-Antispam: UriScan:;BCL:7;PCL:0;RULEID:(421252001)(3002015)(71701003)(71702001);SRVR= :CY1PR0701MB1081;
X-Eopattributedmessage: 0
Received: from=A0CY1PR0701MB1081.namprd07.prod.outlook.com=A0(1= 0.160.145.153) by=A0CY1PR0701MB1082.namprd07.prod.outlook.com=A0(1= 0.160.145.154) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Mailbox Transport; Tue, 1 Dec 2015 00:15:06 +0000
Received: from=A0BY2PR07CA054.namprd07.prod.outlook.com=A0(10.1= 41.251.29) by=A0CY1PR0701MB1081.namprd07.prod.outlook.com=A0(1= 0.160.145.153) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 00:15:05 +0000
Received: from BN1BFFO11FD050.protection.gbl (2a01:111:f400:7c10::1:171) by=A0BY2PR07CA054.outlook.office365.com=A0(2a01:111:e400:2c61::29) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Tue, 1 Dec 2015 00:15:04 +0000
Received: from=A0mx0b-00= 171101.pphosted.com=A0(67.231.156.27) by=A0BN1BFFO11FD050.mail.protection.outlook.com=A0(= 10.58.145.5) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Tue, 1 Dec 2015 00:15:04 +0000
Received: from pps.filterd (m0044905.ppops.= net=A0[127.0.0.1]) by=A0mx0b-00= 171101.pphosted.com=A0(8.15.0.59/8.15.0.59) with SMTP id tB10BRUI022328 for <sob@harvard.edu>; Mon, 30 Nov 2015 19:15:04 -0500
Received: from=A0mail.ietf.org=A0= (mail.ietf.org=A0[4.31.198.44]) by=A0mx0b-00= 171101.pphosted.com=A0with ESMTP id 1yf8kh97s0-1 (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES256-GCM-SHA384 bits=3D256 verify=3DNOT) f= or <sob@harvard.edu>; Mon, 30 Nov 2015 19:15:03= -0500
Received: from=A0ietfa.amsl.com=A0= (localhost [IPv6:::1]) by=A0ietfa.amsl.com=A0= (Postfix) with ESMTP id 7B50F1B2AF2; Mon, 30 Nov 2015 16:15:01 -0800 (PST)
Received: from localhost (ietfa.amsl.com=A0= [127.0.0.1]) by=A0ietfa.amsl.com=A0(Postfix) with ESMTP id E30B81B33B1 for <opsawg@ietfa= =2Eamsl.com>; Mon, 30 Nov 2015 16:15:00 -0800 (PST)
Received: from=A0mail.ietf.org=A0= ([4.31.198.44]) by localhost (ietfa.amsl.com=A0= [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAKUO7m6pu7B for <opsawg@ietfa.amsl.com>; Mon, 30 Nov = 2015 16:14:59 -0800 (PST)
Received: from=A0mail-yk0-= x22c.google.com=A0(mail-yk0-= x22c.google.com=A0[IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by=A0ietfa.amsl.com=A0(Postfix) with ESMTPS id F170D1B2AF2 for <opsawg@ietf.org>; Mon, 30 Nov 2015 16:14:58 -0800 (PST)
Received: by ykdr82 with SMTP id r82so204978015ykd.3 for <opsawg@ietf.org>; Mon, 30 Nov 2015 16:14:5= 8 -0800 (PST)
X-Spam-Status: No, score=3D-1.277 tagged_above=3D-999 required=3D= 5 tests=3D[BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1,= FM_FORGED_GMAIL=3D0.622, HTML_MESSAGE=3D0.001] autolearn=3Dno
X-Ms-Exchange-Organization-Messagedirectionality: Incoming
X-Ms-Exchange-Organization-Scl: -1
X-Received: by 10.129.93.133 with SMTP id r127mr54962501ywb.109.1448928898116;=A0 Mon, 30 Nov 2015 16:14:58 -0800 (PST)
Message-Id: <CAHw9_iKebHhnE0wSrAVGyz8sVHX7gMoPFy+rkr5SoWyAqEfxF= Q@mail.gmail.com>
Mime-Version: 1.0
X-Spam-Score: -1.277
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=3Dsubscribe= >
Re: [OPSAWG] FW: New Version Notification for draft-dahm-opsawg-tacacs-01.txt

Dear OpsAWG,

The chairs believe that there is sufficient interest and support to adopt this document as an OpsAWG document.

Authors, please resubmit as=A0draft-ietf-opsawg-tacacs-01

Working group:=A0
We would like to see this document progress, and are hoping to WGLC it soon. Please review this and provide feedback....

W

On Fri, Nov 13, 2015 at 1:37 = PM Warren Kumari <warren@k= umari.net> wrote:
We would really appreciate any feedback on this document. Personally I
think it is really useful, but we need the WG to review and provide
feedback.

Over the years I've heard a number of people kvetch that TACACS+ isn't
documented -- well, now you can, you know, actually do something about
this...

W

On Sun, Oct 4, 2015 at 4:18 PM, Douglas Gash (dcmgash)<= br class=3D""> <dcmgash@cisco.com> wrote:
> Dear Opsawg List,
>
> We have uploaded a second revision of the TACACS+ protocol specification
> which we believe is ready for publication subject subject to port
> allocation.
>
> Please see details below.
>
> The essential difference from the first revision is the change of TLS
> option support using a separate port as opposed to the original Start TLS
> mechanism.
>
> We would be very grateful for the opinion of the list regarding the
> suitability of document for publication as an RFC.
>
> Many thanks,
>
> Thorsten, Andrej, Doug.
>
>
> On 02/10/2015 16:25, "internet-drafts@ietf.org= " <internet-drafts@ietf.org= >
> wrote:
>
>>
>>A new version of I-D, draft-dahm-opsawg-tacacs-01.txt
>>has been successfully submitted by Douglas C. Medway Gash and posted to
>>the
>>IETF repository.
>>
>>Name:=A0 =A0 =A0 =A0 =A0 draft-dahm-opsawg-taca= cs
>>Revision:=A0 =A0 =A0 01
>>Title:=A0 =A0 =A0 =A0 =A0The TACACS+ Protocol >>Document date: 2015-10-02
>>Group:=A0 =A0 =A0 =A0 =A0Individual Submission<= br class=3D""> >>Pages:=A0 =A0 =A0 =A0 =A038
>>URL:
>>https= ://www.ietf.org/internet-drafts/draft-dahm-opsawg-tacacs-01.txt
>>Status:=A0 =A0 =A0 =A0 =A0https= ://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/
>>Htmlized:=A0 =A0 =A0 =A0https= ://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01
>>Diff:
>>https= ://www.ietf.org/rfcdiff?url2=3Ddraft-dahm-opsawg-tacacs-01
>>
>>Abstract:
>>=A0 =A0TACACS+ provides access control for routers, network access servers
>>=A0 =A0and other networked computing devices vi= a one or more centralized
>>=A0 =A0servers.=A0 TACACS+ provides separate authentication, authorization and
>>=A0 =A0accounting services.=A0 This document describes the protocol that is
>>=A0 =A0used by TACACS+.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at=A0tools= =2Eietf.org.
>>
>>The IETF Secretariat
>>
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=A0 =A0---maf
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org<= /a>
https://www.ietf.org/mailma= n/listinfo/opsawg


_______________________________________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------010501080900060007070804-- --------------050000020803060401030409 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG/MacGPG2 v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------050000020803060401030409-- --d84xw0lQX9miPv76HH7nKeIEPt6beafcM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJWvhkeAAoJEMDeajWKOdxmpyIQAJpprEoI9ekoGvnq46kLIQG6 VpH1pRkQQVC4l7Rbfj/7McngHROkebmaQeKVAIn8+cPjNlRC+LaOyB6pVWvMjvGS ZauaN+oqlvLD3ClVnNoEx8quwnX1JY2rK6tyJ8HBWfFwGcgHGpPT3jbCzJWGzDlL eexwhz6XE3PYR4k8nNTUwiMGj5EZ72lmFjQapJIuFUkKksnv07FArLl0kLXbE2cy bZLNehHxplFv1hbDNvxdghEJfQsRjjmaZFI0PQ12CfrLhIPbvofytoyBEEl8NbT4 ai65mwF14AmLf1P6zKnfDd2ThLMIkOfGHUtMSb9JXVwVOAN3tFDTUpy/v7WgdOi1 EQX9quz+K8e7n8J8n5kRHK6IFzSD3lvPsdnPmGItx9BZXtAN4BqbQ5Gin64oGi+g gqprWdYl3GOlL8wAU2eXziJ4yDKTtGR2wp974Dmpw292w7cx9yD/9K/+s1kwp3Ny Wu1CqYQ+ltHTTabCjTTB552fNyXC84ydd+f9aQj7W1p2uwtakGndeXkUjltmrBYK dM9E6nfgwdnfwd+VdrGMl4f28PPEGGe2GJlDUBv2KdIa86UyogWHJhpqwy+c0KRl uMyiY3gw2lgtOKI32BRWL3ibOOUEJsKMubKFzt/GobtajMJ7cVuFVK7OB6Ht1pr/ xG3lgpX2qpFluGV3oKAE =MdcD -----END PGP SIGNATURE----- --d84xw0lQX9miPv76HH7nKeIEPt6beafcM-- From nobody Fri Feb 12 10:32:39 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA461A8822 for ; Fri, 12 Feb 2016 10:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 YJFB1ZC3m1r1 for ; Fri, 12 Feb 2016 10:32:36 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E331A8797 for ; Fri, 12 Feb 2016 10:32:36 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id r207so37722120ykd.2 for ; Fri, 12 Feb 2016 10:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=VZVmMbiJ4XxCAPsSL+Hf6Afeq/da7fGp8E3LCUzxzUU=; b=RId+08J5mAYE2eWPrqGaievrWy+shTl+aee8J5F2arghahCWPf0EXFN5epChTlw+3x 4QNaR/zmMYy6Zv4yjUfZ7RZuIqLUOa1lUMgC1cgaiRi38TSpowN/dNZ51IpF5n1SHwY+ l/k0IkvldVOC/oCfGj9M+HS1Q5byS+EIBbsZcv3VFfL+mydNjz5jOjlQ6+ak8XhY+kqh Bp5GOgY1BmNuyHa982NQ7GxMyU+qTFAHdr2sbrLw4bUguKFlZU3qIYdfbV/nJrnEyhP6 QDmDrbVHfkIIw5XXOJZVaivFwu7Epdg3XF/pumYShEvrcdwLV504LykX7CQx5xdTskYm +EKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=VZVmMbiJ4XxCAPsSL+Hf6Afeq/da7fGp8E3LCUzxzUU=; b=GpBA8RUoAvuxCHlWMf5zg8CT84V18P0i62HrjsCm0q5jo94PAlTz2zkOb/KOfx0ghy zy7Jdb4ISMgHDeAUsG6CWT4pB1HnwCwUz3aRDBMF8VnUnWmQt/xxUCBTYfaBU6UNvQeQ vtMYL4lbKVoq/gQ4+DNAaig4+wYeB7cJLGqe/MKPeQimqmawwUsBoeLplJgS+dK+WpCl kyQELs+jUpWlybb21GAo0pzqlynUmjiTSPy37x1svlc9Rj8wKrfXpLcT2x8VEy5z9p9h WIKP5FKUpMdgeN6sQXnPT/MXORqIXbDuG47o2RKrD3+1o+UIPiA7qMBRJu2uZrBOJuoQ ZiAg== X-Gm-Message-State: AG10YOSLlcVZ1NOUU0al/qaXLEuXWvXXpCtRksCSysOBzf/NVL+NIaVFAgLf6kMO3ODyzhBwPNIRoXa2EVwQMwPp X-Received: by 10.37.77.131 with SMTP id a125mr1960803ybb.174.1455301955797; Fri, 12 Feb 2016 10:32:35 -0800 (PST) MIME-Version: 1.0 References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> <56BCE503.7000107@direcpath.com> <484DE7E8-363F-45EE-B521-78E53E0582C1@deployingradius.com> <56BDDD6A.8040902@restena.lu> In-Reply-To: From: Warren Kumari Date: Fri, 12 Feb 2016 18:32:26 +0000 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a113c5fc01df554052b96e433 Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 18:32:38 -0000 --001a113c5fc01df554052b96e433 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 12, 2016 at 11:51 AM Alan DeKok wrote: > On Feb 12, 2016, at 11:34 AM, Warren Kumari wrote: > > That is working on the assumption that the reason that operators are > using TACACS+ instead of RADIUS is /only/ because of this feature. In many > cases it is also because operators already have TACACS servers installed > and / or find TACACS+ *much* simpler to deploy and manage. > > Please suggest which operators use TACACS+ for general user > authentication, roaming, etc. > Still no hats.... You are right -- I left out the important "for engineer authentication to network devices". > > I'm unaware of any TACACS+ roaming consortium. I'm aware of multiple > RADIUS / Diameter roaming consortium. > > Please suggest *why* TACACS+ is simpler to deploy and manage than RADIUS > servers. I said that operators find it simpler to deploy and manage -- perhaps this is because it is what many operators are used to, or because it has fewer knobs and whistles. That statement is... surprising, to be polite. Installing and configuring > a new networking daemon is a matter of a few minutes on any modern Unix > distribution. > Having installed and run both RADIUS (mainly FreeRADIUS, but a little bit of Radiator) and have written a few TACACS servers, and installed and run tac_plus for a number in large (and small) deployments, *I* find it much simpler -- and, seeing as lots of network operators choose TACACS+ for their network device authentication, I suspect that others do too. > > RADIUS is a grand protocol - it has many bells and whistles and extra > functionality, but e.g: shrubbery's tac_plus is free, comes with many > distributions, and is dead simply to install and configure. > > So? > > As a biased person, FreeRADIUS is free, comes with *all* distributions, > and is dead simple to install and configure. It's packaged with every > single Unix distribution on the planet. It's shipped by essentially every > network equipment manufacturer other than Cisco, Alcatel-Lucent, and > Juniper as their embedded RADIUS solution. It supports all of the relevant > RADIUS RFCs. It *alone* has probably 10x the install base of all of the > TACACS+ servers, combined, world-wide. > > Simple "it's popular" is no argument. I say this as the author of the > most popular RADIUS server on the planet. > Heck, it supports DHCP, BFD, and we're working on Diameter support. As part of the IETF NOC team - "Thanks!" We've used FreeRADIUS and it works -- I think I've even submitted a patch or two (sometime around the IETF meeting in Beijing). It does *many* things, and does them well -- but sometimes you don't really need a tool that does many things, you just want something simple and easy. This isn't (and doesn't need to be turned into) RADIUS versus TACACS+ -- lots of people use TACACS+ (for whatever reason), and having it documented seems (to me) like a good idea. Telling people that they are wrong for wanting to use a tool *that they have chosen to use* seems unhelpful. > Again.. so? > > Alan DeKok. > > > --001a113c5fc01df554052b96e433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 12= , 2016 at 11:51 AM Alan DeKok <aland@deployingradius.com> wrote:
On Feb 12, 2016, at 11:34 AM, Warren Kumari <= ;warren@kumari.net> wrote:
> That is working on the assumption that the reason that operators are u= sing TACACS+ instead of RADIUS is /only/ because of this feature. In many c= ases it is also because operators already have TACACS servers installed and= / or find TACACS+ *much* simpler to deploy and manage.

=C2=A0 Please suggest which operators use TACACS+ for general user authenti= cation, roaming, etc.
Still no hats....

=


=
That statement is... surprising, to be polit= e.=C2=A0 Installing and configuring a new networking daemon is a matter of = a few minutes on any modern Unix distribution.



> RADIUS is a grand protocol - it has many bells and whistles and extra = functionality, but e.g: shrubbery's tac_plus is free, comes with many d= istributions, and is dead simply to install and configure.

=C2=A0 So?

=C2=A0 As a biased person, FreeRADIUS is free, comes with *all* distributio= ns, and is dead simple to install and configure.=C2=A0 It's packaged wi= th every single Unix distribution on the planet.=C2=A0 It's shipped by = essentially every network equipment manufacturer other than Cisco, Alcatel-= Lucent, and Juniper as their embedded RADIUS solution.=C2=A0 It supports al= l of the relevant RADIUS RFCs.=C2=A0 It *alone* has probably 10x the instal= l base of all of the TACACS+ servers, combined, world-wide.

=C2=A0 Simple "it's popular" is no argument.=C2=A0 I say this= as the author of the most popular RADIUS server on the planet.=C2=A0
--001a113c5fc01df554052b96e433-- From nobody Fri Feb 12 10:51:45 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D861A889C for ; Fri, 12 Feb 2016 10:51:44 -0800 (PST) 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] autolearn=ham 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 wVRKPPbgt1Li for ; Fri, 12 Feb 2016 10:51:43 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id F30961A8899 for ; Fri, 12 Feb 2016 10:51:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 55FAAC7D; Fri, 12 Feb 2016 18:51:42 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjQ9WSiNoMu1; Fri, 12 Feb 2016 18:51:42 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 7E39E488; Fri, 12 Feb 2016 18:51:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Fri, 12 Feb 2016 13:51:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4B57B92F-917D-4B9D-8473-EBFFB6F3CC8C@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <67FB6BEB-7217-4D39-91EA-CBC97706F568@deployingradius.com> <56BCE503.7000107@direcpath.com> <484DE7E8-363F-45EE-B521-78E53E0582C1@deployingradius.com> <56BDDD6A.8040902@restena.lu> To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 18:51:45 -0000 On Feb 12, 2016, at 1:32 PM, Warren Kumari wrote: > ... *I* find it much simpler -- and, seeing as lots of network = operators choose TACACS+ for their network device authentication, I = suspect that others do too. i.e. people find a TACACS+ daemon easier to deploy, because they = choose TACACS+ as a protocol, because the features they need are only = implemented in TACACS+ I don't see that one follows from the other. > We've used FreeRADIUS and it works -- I think I've even submitted a = patch or two (sometime around the IETF meeting in Beijing). It does = *many* things, and does them well -- but sometimes you don't really need = a tool that does many things, you just want something simple and easy. We're getting off-topic here... but people use that particular tool = for non-standard uses because they find it easier to install and deploy = than other tools. And because it has features that other tools don't = have. So I'm entirely sympathetic to the argument that TACACS+ has features = RADIUS doesn't have. i still have many, many, concerns about it. > This isn't (and doesn't need to be turned into) RADIUS versus TACACS+ = -- lots of people use TACACS+ (for whatever reason), and having it = documented seems (to me) like a good idea. > Telling people that they are wrong for wanting to use a tool *that = they have chosen to use* seems unhelpful. As I've argued, they don't have a choice. The vendors made the choice = for them, via proprietary protocol and functionality lock-in. Claiming = "free choice" is just... odd. I'm not telling people they're wrong, please don't make this argument = a personal one. I'm happy for them to use TACACS+. I'm happy to see the protocol = documented as an informational RFC. I'm *not* happy with pretty much everything else around the subject. Alan DeKok. From nobody Fri Feb 12 11:03:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713201A88C0 for ; Fri, 12 Feb 2016 11:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 4rqVsflS5GQV for ; Fri, 12 Feb 2016 11:03:39 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2411A88C2 for ; Fri, 12 Feb 2016 11:03:38 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id e127so51762063pfe.3 for ; Fri, 12 Feb 2016 11:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=L1j6xS9W/9qhj5KuFuLWoBia7Hw0P9dUrf32Pka4s/4=; b=O3/ENFMBmtr0jn0I5jngcIOHIzloGFD/5hFPHk30CyjiSreh12KyRrlDyEhlEf810S 0NfRpyCRuTCPkEciuClnARTifqAX1ET+erOWzrLUBjEv4q1o388jR7pcydnLgarU6wnc lmY9Yv5dHlI8tgJ0MeSkkjqEvSV1NUpKM7J2Eo0HMFI6fa0uzxNhxwqrPMlPr3R499wY 9Pfxle6V2RCxte0YcohYpzTtHkTFrWSmkC/4Ukg/T40VpILM8JUvPSg4R6McGtaxt/z3 DxGR6JQZuVkNuBKGXwPsF94AGJ5rIv2q08eZGGA+agE3H3ursJciKHuFdkYnLkwv8ofT w+9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=L1j6xS9W/9qhj5KuFuLWoBia7Hw0P9dUrf32Pka4s/4=; b=ZNfZqAxMIBF0tPN7i0bHRX/l6fHKyuSrt05j+qOZhteB4uS30CxHpJfKXAACkeUUJD b+pbkOLfP9aP+wOHef8BAVuzllUmHEqaWMG4sFKv108iplWvnqcFK1WphR9eH63Jjjqi 2sQfbcfIcj3GeWPkwcXzavkkq4lbtLTIxOjZf8Sl0V77mt7XYc2779kX6pq8G2mv8MBQ SkARKEdOn711LCyy8fcqs5kH2/tUeUsNTCT2cjH86rAFsBlCx/g67P5piek8B/WfLKff xCa53wdfy2Xt1qZdddfOIzkls8Zp0vXBFjalH/eX0CL+SsKHpElx6ziX/rR6ozpUx+2F WbJA== X-Gm-Message-State: AG10YOSlwEYKaBHTKw1SsjXlFaRsyY7Fegfw1L3bWDCsCqjRYYkovXlu8n/xFkyvZnOqWQ== X-Received: by 10.98.8.74 with SMTP id c71mr4485816pfd.155.1455303818578; Fri, 12 Feb 2016 11:03:38 -0800 (PST) Received: from ?IPv6:2406:e007:7084:1:28cc:dc4c:9703:6781? ([2406:e007:7084:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t12sm21112663pfa.54.2016.02.12.11.03.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 11:03:37 -0800 (PST) To: Alan DeKok References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> <56BCE1A7.6050807@gmail.com> <9B53AFCE-8792-4CB4-AC47-A2F0D986D759@deployingradius.com> <56BD1113.2010106@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56BE2C93.7070406@gmail.com> Date: Sat, 13 Feb 2016 08:03:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 19:03:40 -0000 Alan, Since you keep repeating yourself, forgive me if I do the same. On 13/02/2016 02:32, Alan DeKok wrote: > On Feb 11, 2016, at 5:54 PM, Brian E Carpenter wrote: >> Charter updates are formal step, but the OPSAWG charter is already written >> to encompass work of this kind. > > Except that the charter says new work will require IESG approval. Several days ago I answered this point: >>> I've always read that to mean new work items that fall outside the existing charter, >>> which covers "development and publication of RFCs dealing with operational and >>> management topics that are not in scope of an existing working group". TACACS+ >>> clearly lies within that chartered scope. >>> >>> However, it might be wise to delete that sentence from the charter. It's >>> unnecessary to say that rechartering requires approval, because that is a >>> basic IETF procedure. > >> As I hinted before, it's unfortunate that >> the WG milestones haven't been updated recently, but that's true of many WGs. > > That's a non sequitur. I never discussed milestones. Milestones are part of the WG charter. >> We are collectively sloppy on that. > > Speaking for myself, I don't work for a large company. I don't have a CEO who can apply "behind the scenes" pressure to get things pushed ahead. My main involvement is in a small WG that most people don't care about. > > As such, my main protection and guidance is the documented IETF process. If we ignore that process, then we're letting large companies do what they want, simply because they're large companies. > >> TACACS+ is used by IP operators, so it seems relevant in a way that IPX isn't. >> But if you want to propose an IPX BOF in the Internet Area, or request a slot >> in a future INTAREA WG meeting for IPX, you're obviously free to do so. > > Which pretty much misses the point of my argument. > > There are many protocols used on the wider internet which have many more deployments across more vendors than TACACS+. Those protocols are not documented in RFCs. > > So... why this one? > > The only answer so far is that "it's supported by large companies". No, that it's *used* by many operators. However, the real point about putting it on the standards track is that it would move change control of the text to the IETF. That's a valid point to debate. Is there any win in that for the community, as opposed to leaving it entirely in the hands of "large companies"? If this was only about rubber-stamping I would agree with you. Brian From nobody Fri Feb 12 12:38:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CFD1A897F for ; Fri, 12 Feb 2016 12:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 imjyKbi4Rpt7 for ; Fri, 12 Feb 2016 12:38:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546EF1A899C for ; Fri, 12 Feb 2016 12:38:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aUKTr-0005P4-PP for opsawg@ietf.org; Fri, 12 Feb 2016 20:38:20 +0000 Date: Sat, 13 Feb 2016 09:38:18 +1300 Message-ID: From: Randy Bush To: opsawg In-Reply-To: <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 20:38:22 -0000 does this wg have a chair? randy From nobody Fri Feb 12 12:44:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CD31A89B5 for ; Fri, 12 Feb 2016 12:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 j1chp7XLCOSf for ; Fri, 12 Feb 2016 12:44:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564F91A89B0 for ; Fri, 12 Feb 2016 12:44:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aUKZX-0005QX-Gz for opsawg@ietf.org; Fri, 12 Feb 2016 20:44:11 +0000 Date: Sat, 13 Feb 2016 09:44:09 +1300 Message-ID: From: Randy Bush To: opsawg In-Reply-To: References: <88E65A95-AA68-4D7C-AA3A-3822520051AB@deployingradius.com> <56BBB51F.4080303@bogus.com> <1C896D00-7818-429F-915E-F209D2ABFCFB@deployingradius.com> <5C8E7E96-920C-481B-A396-D978252EC550@deployingradius.com> <56BCE2A0.3000909@cisco.com> <3E40FD8E-3A38-4D2E-9270-D483B7509E3F@deployingradius.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 20:44:14 -0000 > does this wg have a chair? seems so. thank you, scott. randy From nobody Fri Feb 12 18:52:30 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648A41B2A99 for ; Fri, 12 Feb 2016 18:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 HABpCs4VlEFY for ; Fri, 12 Feb 2016 18:52:24 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0097.outbound.protection.outlook.com [65.55.169.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928B41B2A97 for ; Fri, 12 Feb 2016 18:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=direcpathcorp.onmicrosoft.com; s=selector1-direcpath-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t1q+80uM+3b/v2f0nCLpv0AJvUKkeiCzpFjY/pC/2T4=; b=As3yEfKFmtn1hit/pCLctWVgtLWXDL/s8ZmvcUdKSvdVcPR7bH51U68mXmqYZOlkXbZgDxPig0WXmMSV2yxYJZ5L3Q6/G6GnmRTieClv63/Ht8vCMOecLTResgmpiR0dJffB7ToIMpDPZaerxsEm8p82w7yx9f6tHmidwsfp/Kw= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=direcpath.com; Received: from [10.6.2.149] (24.98.60.52) by BY2PR01MB1717.prod.exchangelabs.com (10.163.26.143) with Microsoft SMTP Server (TLS) id 15.1.409.10; Sat, 13 Feb 2016 02:52:20 +0000 To: References: <56BDE83F.1030102@restena.lu> <56BDFE46.9000802@cisco.com> From: Robert Drake Message-ID: <56BE9A5A.9040309@direcpath.com> Date: Fri, 12 Feb 2016 21:52:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <56BDFE46.9000802@cisco.com> Content-Type: multipart/alternative; boundary="------------000505050000010405020404" X-Originating-IP: [24.98.60.52] X-ClientProxiedBy: BN3PR0601CA0012.namprd06.prod.outlook.com (25.162.30.22) To BY2PR01MB1717.prod.exchangelabs.com (25.163.26.143) X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1717; 2:YjUJZ4ItrF2FrAn6+iSPhOn4uJtbI6N7trmt5rGOrrxUXWfLl/2kGOU8Z4kS6sYYlVe2iNtMkDkj2gYP8wplDuaUBYECUpDvcqj7yYI2ft0BiFaWf/glo0UUfvx6YyFwGb3bgweZluzuCJUIFIARuQ==; 3:Le/Cjp6NRNFbyjC5qAUrSDLkJWm+Od5Vt/8e+yk8gZJ0O1G3B2FwEFOnZxq9mNosCNv/+8KkrVN53VgAWqVYyaCz+yPoeEbVI8HhweuDolxto3Fi1B1SG4xU2HsQgEx8; 25:E5zWaQM4WI9MirM5QZAtJu9gjLdDPWu6vZomYc1skAYVw94b0LfedWmbTnUYuKMIe0OZ2Jp5ji+eEiTwjHdF7LboL2Dmlx81htXkp0nBMHHFCJh1oyiE1JmyoHP4Oa3BQul6mlZAlEJDvXY2DrzZXBAjUVndZEbEjslSZLDjCC+I7ViIhmcpaZF1/d5O8DzApw48vNwJs6nP/nzNHxO0X3GaJERhmauUjH+/rQy3J5W+hew+Aswus9eusHwNnO7i3grygZbelDfLiL8JI1t5FzD9F9brnkX9dnWYD351Te0HEg8qepLuTm180QFS0Z+K X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR01MB1717; X-MS-Office365-Filtering-Correlation-Id: 02a76ea2-4c01-4b95-4320-08d33420b17b X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR01MB1717; BCL:0; PCL:0; RULEID:; SRVR:BY2PR01MB1717; X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1717; 4:yAwtIr2g4y70PDs2LMNzzipCJILLrM7u9+decEMBQpug5Yxy+N2nHMYqyEUSZyOARzyeatI8zOnfKk27xTvEjyaglOxprNEPI5+nXUuwENDmCcNBZi2FMilIXcowxwpoe7Lri/lPTfD+LL/8VjxFixQhDLcVcT4vtLHhiRdFgmvdXtG8a7WRgfb9C0afXPBnGyGNDBKzYBPA80uQY42FrbRp8zAzEhrX3czzsStvGDJZooyg3dEd9VD8chRmbDgQDVpDiShVJyLC9CSiL+ZFfOxjk8ncpiIpPjqUWEBC/jTIqT0xamHk3RCITYQHntBNBN1bKkNRrmae7Om7dn539Unqe6SbifvtWb3tHIs0y12pA2fVsHneOE3Z6enA/pn+RLIF97xHA8qdNwpctvAo4Q== X-Forefront-PRVS: 08512C5403 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(479174004)(377454003)(24454002)(19617315012)(83506001)(189998001)(65816999)(5008740100001)(36756003)(512944002)(110136002)(80316001)(19580405001)(19580395003)(5004730100002)(270700001)(42186005)(586003)(15975445007)(2351001)(40100003)(65806001)(87976001)(122386002)(92566002)(77096005)(450100001)(33656002)(66066001)(65956001)(87266999)(86362001)(3846002)(2906002)(76176999)(6116002)(50986999)(2950100001)(54356999)(84326002)(107886002)(4001350100001)(5001960100002)(1096002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR01MB1717; H:[10.6.2.149]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR01MB1717; 23:c6KngDFCi6uiCV8dV8VSMi9788pcs+fhKAQi0es3m?= =?us-ascii?Q?h8XKCaFw6yo6y6qvpvvRltuGtspxGBO+ZOYeGz5dQ50woteHkoo3Q+gEAmLl?= =?us-ascii?Q?nL9gnqw+ElkXtdMmAsPqKWZNLeHc05TvVHPdljsiuF7ZjzxLIOguEnnJR5vE?= =?us-ascii?Q?sbJu+2B84CKZqJGA1YahzG2gKblM5MWBgyERp4PP+OyClOMFGiC02dExsgjk?= =?us-ascii?Q?WW0CKZ7PR0wwCqe8GKf5DawAGQUbt+cPoRVwNtFQ4jFQxLfa7IgsPGNA6IkQ?= =?us-ascii?Q?cHCqslxtDV4nz6E7aA1rpvMqPtb9wHtDlXr91ENmCWicoeWdzTeqgWVkwnAH?= =?us-ascii?Q?4LWi2VKpKbizjupfPs3Zz4ydGRGra1qqKEkbBt8nO8euZh0O+B5CmTRN/KH+?= =?us-ascii?Q?G0wu7i47S+3lpsvt00ByfOjyDdzvOkP7D6imd1Z649LRfjMsD8A24FjBjTSK?= =?us-ascii?Q?FRMKmFa4+BD3BgZj6mvOqvYDUz1z91AQBuAIgePd1GpX/mI6o6c67r16N4QA?= =?us-ascii?Q?iExlsNDQiB9dbn/bJN6mfQ7uvKF3xq30WmdYwmE6VKwBIkS4XX4apDj1C6J3?= =?us-ascii?Q?Mvs3bScf5wgW98H5Ky7cPV4AwVOKr69pyIuYwlo5r+PtGmxjOMqS8xRDkCjZ?= =?us-ascii?Q?JPk6FUaaU81KRqjucKzsGquyq8Vo2BC9xRQLaEZUh3zV3fGeFZRm/qHRwbsF?= =?us-ascii?Q?yU7SgG3508o2gMc7QDmRJ2dvjx8uUfqsCSuU7G2RECqTedKhBdoFZZwd1m10?= =?us-ascii?Q?nzpb1MHP1fBJiXxBLnWOBiDyjkpFpQV7OBZTDpyrrYjMrNZBGG224eD1BtvK?= =?us-ascii?Q?QeiHKHW2midP6qXQxnL4Unzf+BxWAuzi8rsniC/gjat8XDjqPpWtJpDS1WCN?= =?us-ascii?Q?WVli5gw1Ftryo1TC1eTS14pqq6ziziRV9sWz+kNv1yYNA9vjV1ztlAZ0ZIEK?= =?us-ascii?Q?o7ITygL5ihYNX3yAYSlpcy4SWfHrLSDLaSwFCdAdSakZRp+3DH0NVtHiDDGA?= =?us-ascii?Q?qO+wfWztGaBFhIGWjftU7Yhv4j1+yTWIbQRatrzVFbSY52GDn4N8FqPYS/hh?= =?us-ascii?Q?SdW4dS13I/xPukpzcqYbh9RrNa4gIFCu5Do0BEIPojf38QoLstIVuxlnn0EG?= =?us-ascii?Q?FP928UTcntnTpL+Z4smhmQZ1391177VE5QlpQpHugriKfGIQCcmnQg4JhSD1?= =?us-ascii?Q?ZLbsM0fPnLUqOQMKCdu9XtQpEwN1D24u+zm?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1717; 5:YVDTDeovn5e9liEkLfiLg1zQazU1dA+uNe/5/dpwaCx3NCJcUQCxcGAc2pEkvN0SGQ0KrBcwOJwgtxeOeWM6MGLMvKKPy5kxgbvCkk2JToBJMzAonFTqirVJIV+1t1LAdUDoiqLCUetnC8QLpkRzcw==; 24:m+OxjHY1tcUJWvRAAdKG1IvR30KFOCT4UZoa4rRHyzCvQDmDF7ulu1s8z29NdcZWM+Hmq9M5AuYd+Co3yx03rnuCq5wKILEPyO1tzLC21nk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: direcpath.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2016 02:52:20.7958 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR01MB1717 Archived-At: Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 02:52:28 -0000 --------------000505050000010405020404 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 2/12/2016 10:46 AM, Eliot Lear wrote: > Hi Stefan, > > Unless it is absolutely determined that the current work can't doesn't > meet criteria for an IETF standard, I would be opposed to such an > exercise. For one thing, we all have other things to do. For another, > and as or more important, we would be denying the reality of the > situation. I would rather understand now what sort of changes are > being proposed in order for the current work to come up to snuff. > > Eliot > > Is there anything in this that is incorrect or incomplete? If not, then can it be resubmitted for informational status to define the protocol as it currently exists? https://tools.ietf.org/html/draft-grant-tacacs-02 --------------000505050000010405020404 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
On 2/12/2016 10:46 AM, Eliot Lear wrote:
Hi Stefan,

Unless it is absolutely determined that the current work can't doesn't meet criteria for an IETF standard, I would be opposed to such an exercise.  For one thing, we all have other things to do.  For another, and as or more important, we would be denying the reality of the situation.  I would rather understand now what sort of changes are being proposed in order for the current work to come up to snuff.

Eliot


Is there anything in this that is incorrect or incomplete?  If not, then can it be resubmitted for informational status to define the protocol as it currently exists?

https://tools.ietf.org/html/draft-grant-tacacs-02


--------------000505050000010405020404-- From nobody Sat Feb 13 04:43:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040A31B31D6 for ; Sat, 13 Feb 2016 04:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 Pwq_rLZKkFg3 for ; Sat, 13 Feb 2016 04:43:26 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816081B31D4 for ; Sat, 13 Feb 2016 04:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qpHW5x7/t6ABTIMgHIZbevh+uBimA68kIH7Pv11AplU=; b=C+fgU/Qd5ko7fK4Wa3fLQSJYJdXfUoVVtmIiYi9jQo/cqcRfP4P1PQGw+UaYb7+HnHGnk8+rMDEgi/Bk33sR+c7tLcFgZNGmxCFjRTb74VtDJEnvQhntGnvZpMQlU4+5UZqtDHec0qFxcMxq2Q5hBamisbI9BsslMiyUiA0vokg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.409.10; Sat, 13 Feb 2016 12:43:05 +0000 Message-ID: <02a101d1665b$9e16b380$4001a8c0@gateway.2wire.net> From: t.petch To: , Robert Drake References: <56BDE83F.1030102@restena.lu> <56BDFE46.9000802@cisco.com> <56BE9A5A.9040309@direcpath.com> Date: Sat, 13 Feb 2016 12:39:30 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB5PR01CA0054.eurprd01.prod.exchangelabs.com (25.163.24.22) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 2:T9t7ezSsK9u/Sj2NCfzgnliQUWjYGWeA1mC9EcLfQ/jwVJJS0HwQoPRr1PmBtVczGhsQ/grQxqSj1Ryf2uldsKyEfLmInOVl0xnvXAKfqvP9/DsbT2AIHVdiJ5oAcs5kj+aO8MdyPEyHALowxNhtNQ==; 3:zCuTAJnkEF6UH/AFojQm9YZiVgP9GJz+Sn3DTvh9jYa+PLp9libN8FpsAnKGuyORV4jwII9QLIXhmzgZ/saMpweGVoNPv0q6bbBXUDm68hKQMHbKbNJVmQ7/jcHFZv7I; 25:RJJOY7Ccoawy/yrRI8DY2DjNsmNL687aCObipfbGUmQzBRc7r+Nc2qlzdLyIKJ/3EkmlHR+ShbnXpnV106mYijq9DYBK3xjGLpsXgsLjE4JgPRppXzGaGFGuqCpMTOd9vZ5vSTnvhRRl84hFu5P0enHLax4xKdmtXiZTGKgZIVv0dEmkY+rjl2ON6megQXIXwOXBcw3HBevDX2FWIpwN49IJmLbFbl8SdABfQEXPUxke9Ed2snJaxYX0AFJgiN/tov45wkO7PNWJMn8GOh688Mz5adnlEisSoPbjNchoXpcFrBnjJ9rVWSW8LW8rSPcS X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-MS-Office365-Filtering-Correlation-Id: 34a8898e-266d-4e06-6bb9-08d3347337fc X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DBXPR07MB062; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB062; X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 4:hQD6KHytwRlsfH/JJdxKz4psY5kFt/CVWeVv9auGpkKmtKwmya488LJNXXKM5oC/5V0u0TU1OcFBAHDryxeq2NqyCCGsxObb7y8o+1P8g6NDSFMnblcNt2wZz7MuWGMruFOi+P8AS6icBdus8PMWoiDVjUh+bqDvETdji+GYvmozcraeKtsb/MPvc/rN4Fzgnzb+dA0dryZ4/CfUyj3+cErJWQDyu4wIL4xSnyM1nClEi3Ide/QBz7vqSPkSUyOy/y9p6E8bDRDzt1uioC1kWKyNm/iJaM1+OkWyp81wggppekfmhnMy4Kr+ns0r675SKM+gZwO+NowU/tuK8h0JrtX3VUCtlZtBavrR5sZ15G7vXanpuViVTMilvMEhbh+E X-Forefront-PRVS: 08512C5403 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(24454002)(479174004)(77096005)(5004730100002)(81816999)(76176999)(50986999)(81686999)(19580395003)(61296003)(19580405001)(92566002)(44736004)(1556002)(15975445007)(42186005)(23746002)(87976001)(50466002)(44716002)(6116002)(3846002)(586003)(40100003)(122386002)(14496001)(66066001)(47776003)(5008740100001)(86362001)(50226001)(62236002)(5001770100001)(1456003)(189998001)(116806002)(5001960100002)(107886002)(230700001)(84392002)(2906002)(33646002)(1096002)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DBXPR07MB062; 23:LAlV3UTH322BfdZ3kh+fI8AcAXb6rTOew1wWNZ?= =?Windows-1252?Q?dCY1iG8geGlbsPI/V01EWpcJ9DIdZug6OLDClO0Tmn5mnbZLC5dWWOCI?= =?Windows-1252?Q?HJ4VahrFXMemYINLQ1nYWhlJeCuAf9fRA/YS/lJGROFGR0RixKDmkIWr?= =?Windows-1252?Q?d83LwvwQkGlIV6RK9lWWhsAiUCsHh1pIVTfZtvoya0ZDWcuLl5JqI+Rl?= =?Windows-1252?Q?6/glm5gkgl9SA6yrMdskKp7qZN71lV17TvCWRn8Bp3bJS/16McQ4Cppe?= =?Windows-1252?Q?RQ+t4CO9QlAvkhTzm+m4JLfD+uaEEjHn7gw4m+zQWeobzqrbw55kZxPu?= =?Windows-1252?Q?4hiqFPxNaRkume/LzlcOeZZsReEr9YiVRbyEtrvQdPomtj/UxDf7Gdjl?= =?Windows-1252?Q?RFptBExTjSY8AwCrlYxerc21XtnZ9IjLgr6e6oRRfK+L/boEgZlVYZEv?= =?Windows-1252?Q?31ifYBTZNyl3oQrGuj7Qfk0ipc7BoBx4f3jnSSMvscOIpHin3hUcE3Lv?= =?Windows-1252?Q?dz3dkTDiT/oo5ZQTHB+EN68mPn7kkz4WsuUBMjqSTZ8koyZKtfbsVwoc?= =?Windows-1252?Q?m99CqpV9mINNV7BCwnZI7gr+x2hEJZSGJ49XTMzkiOSmbXm1lZgy3FZ2?= =?Windows-1252?Q?7rruiWvbnkeBQIX7QnR8yMVh+41mygVXMAvKXtx/5w4w5fLwZdyr6O/J?= =?Windows-1252?Q?ls30JgI/RXcB0DqLqVdBWj8gf4Q2RyCCwu6MwGF13Auiu9Ir40vGGX7/?= =?Windows-1252?Q?91tOHkWy8rAu34qEdScXwXyIesbg0/wjOLEH0faxPwSKufl/DtRXmyY3?= =?Windows-1252?Q?6LyfJosMhjoNnP5Y/U6gTUO6dZ7mClXsCCjGOmmO4KxAzSQlXZgviQRC?= =?Windows-1252?Q?8Kl+4ThMdM001dFJe63dkY3hn0bOWwGCA8JhMmRifoFfyvQQ35ZfZpRZ?= =?Windows-1252?Q?VbDgZZdLZuoEfZpa3tZDRM7Agb6/Q08sK8YCDgTH8+qzAR3Bo3e/o8rf?= =?Windows-1252?Q?+oFlnJkkcNKN9wZAqhgh1q/cNryLZd4kLlU+CjhJQSj/Z21FsI4vuvu9?= =?Windows-1252?Q?lTUQj9BKTXa+1pPWUNdGx6Rv+ZMmlfjOaqchn9G6QHI5nzpfGrW7HMvl?= =?Windows-1252?Q?lT+0bYKLhbB44ZPJ/qZ5MM0xOnqmBwu5zzoICJo7vt1MeTmqZ9TiuBNP?= =?Windows-1252?Q?i6qm1PcJVRfGobbJr5o9+wxAjWTaETDII0/leMJwVF/7/60rG2RcTx6I?= =?Windows-1252?Q?OFCOTuxq9cERTcStxtH8+viJlGF2lc2lxGeJ4FKdUhkPP+26H7lNj1Kp?= =?Windows-1252?Q?FXRL8ue8W25ivtZS8IhrzgCr/xs5Lv1gtJ3HJLTUDyms7CSOmoeycRtW?= =?Windows-1252?Q?ETIYYFp/zQ5y3aHp9AgbQXjPJG9FSu9g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 5:6xVMdWy0Ubs8NyVOZTnFhZ5TeCElN5sIW9vV57USttz+tvFjv6qaTYMcu9PK+MeMUqjD7DdmNbf7ESntug60/4DNmjE4GRtW0vndEnJh2wuoxDG8BvQ8teO48wSwMUPi72bAv4V2dPr/1SFa5roA6Q==; 24:7h9ELjVptNMnnSRVtvfc/OBIqzuaDIsGW0pj/7qRPNidWAjqLqVSec1kZlMTuhJVE+eKOCeRG8YK7puxZy6ZNVJ0/lSA14XtHoke9s7hgXw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2016 12:43:05.2984 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 Archived-At: Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 12:43:33 -0000 ---- Original Message ----- From: "Robert Drake" To: Sent: Saturday, February 13, 2016 2:52 AM > > On 2/12/2016 10:46 AM, Eliot Lear wrote: > > Hi Stefan, > > > > Unless it is absolutely determined that the current work can't doesn't > > meet criteria for an IETF standard, I would be opposed to such an > > exercise. For one thing, we all have other things to do. For another, > > and as or more important, we would be denying the reality of the > > situation. I would rather understand now what sort of changes are > > being proposed in order for the current work to come up to snuff. > > > > Eliot > > > Is there anything in this that is incorrect or incomplete? If not, then > can it be resubmitted for informational status to define the protocol as > it currently exists? > > https://tools.ietf.org/html/draft-grant-tacacs-02 No! Our procedures have moved on a lot since then and the I-D would need substantial editing. This is problematic. Nowadays - Note Well - anything you or I or anyone else says or writes can be used in an I-D without any breach of copyright. This I-D is 1997 - before my time - and I was looking yesterday to try and find out what rules the IETF was operating under then and could not find them. So, who owns the copyright in the text? Who has permission to edit and publish it? I do not know (and have seen this issue take a while to resolve in other circumstances). And then there is the question of IPR; reading RFC1492, which I think would be a Normative Reference in modern parlance, I would expect a manufacturer to be taking an interest in this and submitting an IPR claim. These are surmountable difficulties. The TLS WG decided that it wanted a specification of SSLv3 some 15 years after the event and we now have RFC6101 but it takes time and effort. Tom Petch From nobody Sat Feb 13 05:53:52 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2C21B32A2 for ; Sat, 13 Feb 2016 05:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.876 X-Spam-Level: *** X-Spam-Status: No, score=3.876 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, RDNS_NONE=1.274, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 7sZKI65vmy5j for ; Sat, 13 Feb 2016 05:53:35 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72AC31B3293 for ; Sat, 13 Feb 2016 05:53:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 85D2C15ACE1A; Sat, 13 Feb 2016 08:53:33 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHr48jC8pEdp; Sat, 13 Feb 2016 08:53:31 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 5447915ACDFD; Sat, 13 Feb 2016 08:53:31 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Scott O. Bradner" In-Reply-To: <02a101d1665b$9e16b380$4001a8c0@gateway.2wire.net> Date: Sat, 13 Feb 2016 08:53:31 -0500 Content-Transfer-Encoding: 7bit Message-Id: <430EA6BD-7BF8-4E02-9E7C-AE22960E8A28@sobco.com> References: <56BDE83F.1030102@restena.lu> <56BDFE46.9000802@cisco.com> <56BE9A5A.9040309@direcpath.com> <02a101d1665b$9e16b380$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 13:53:37 -0000 RFC 2026 was in force in 1997 - see section 10 Scott > On Feb 13, 2016, at 7:39 AM, t.petch wrote: > > ---- Original Message ----- > From: "Robert Drake" > To: > Sent: Saturday, February 13, 2016 2:52 AM >> >> On 2/12/2016 10:46 AM, Eliot Lear wrote: >>> Hi Stefan, >>> >>> Unless it is absolutely determined that the current work can't > doesn't >>> meet criteria for an IETF standard, I would be opposed to such an >>> exercise. For one thing, we all have other things to do. For > another, >>> and as or more important, we would be denying the reality of the >>> situation. I would rather understand now what sort of changes are >>> being proposed in order for the current work to come up to snuff. >>> >>> Eliot >>> >> Is there anything in this that is incorrect or incomplete? If not, > then >> can it be resubmitted for informational status to define the protocol > as >> it currently exists? >> >> https://tools.ietf.org/html/draft-grant-tacacs-02 > > No! Our procedures have moved on a lot since then and the I-D would need > substantial editing. This is problematic. Nowadays - Note Well - > anything you or I or anyone else says or writes can be used in an I-D > without any breach of copyright. This I-D is 1997 - before my time - > and I was looking yesterday to try and find out what rules the IETF was > operating under then and could not find them. So, who owns the > copyright in the text? Who has permission to edit and publish it? I do > not know (and have seen this issue take a while to resolve in other > circumstances). > > And then there is the question of IPR; reading RFC1492, which I think > would be a Normative Reference in modern parlance, I would expect a > manufacturer to be taking an interest in this and submitting an IPR > claim. > > These are surmountable difficulties. The TLS WG decided that it wanted > a specification of SSLv3 some 15 years after the event and we now have > RFC6101 but it takes time and effort. > > Tom Petch > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Sun Feb 14 03:31:02 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8081B3D52 for ; Sun, 14 Feb 2016 03:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=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 1zoQqIT-wbHy for ; Sun, 14 Feb 2016 03:30:54 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0133.outbound.protection.outlook.com [104.47.1.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388E81B3D33 for ; Sun, 14 Feb 2016 03:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lY7Qaso74y0kFbRyYwvevWxbK79srvE5FbQyvfCqOmk=; b=RxCJMHnf3CfZZKJRkG4hx4ojNPq0K5y+6ukgSoTtmuXiGq6ef8qd7Ki+gWNHuFva9Uv4YmFicdDevHZwEtg/inpiyNZKAhZk9kFbzYf4ruVfeOZ021flCJY7gNP1GGx/qZLJlODZhpBIyq2eKPKWeHmW/2RO+PUHPH5g4BoBTBg= Authentication-Results: sobco.com; dkim=none (message not signed) header.d=none;sobco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.396.15; Sun, 14 Feb 2016 11:30:49 +0000 Message-ID: <003f01d1671a$af55c720$4001a8c0@gateway.2wire.net> From: t.petch To: "Scott O. Bradner" References: <56BDE83F.1030102@restena.lu> <56BDFE46.9000802@cisco.com> <56BE9A5A.9040309@direcpath.com> <02a101d1665b$9e16b380$4001a8c0@gateway.2wire.net> <430EA6BD-7BF8-4E02-9E7C-AE22960E8A28@sobco.com> Date: Sun, 14 Feb 2016 11:27:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB3PR05CA0031.eurprd05.prod.outlook.com (25.160.41.159) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 2:/iSPfHvfowAMaHDnNBsL+ekS9a576aeO7adDDIzfZHRwB6HeuHLIo6LfyU35QJ61GyT94iYKmhKe8hPCOAj8o7XYntq0tGuKLvnd4N1yhT6xwxFfG+EzZkAGtrtYVaKY+zdwOp0oUQuk74d5/dqOTA==; 3:Hk9ASyc9Suqt8fTKGDE1pjxGivdoi0gxTi04XiAjR+IQGoQ2j80O42h5+LE9K760waFzUaOfeQM423bJkpoLu6y7O34n9nhURH2NcP/EikobkNTfNFbuELjrKcnJMwuu; 25:ik4sIUqFEji7lmhnd7OEmSHX8cRLWZwIOBLCd/2FL3gd48SyIef5DctzjXblvpXzs8QIBa62CfkCBp5jeWbeJ79gQX340KRE1akoWekLxP2fBWXizTM8U7/TEBZJ8+ZEPTd2JeBa8Ba7lPDsAbNedOb2cEcp4uO8nL2RnXsLuz9vqPoI6tPZIC5DZ0VIj9EFdgje0pbaGBELuCqpeZH7cRTPQ+CbnPWxWsx6rxYGyIk74TYdAQ4qnOyDAGj2da/alonb/Up5Fgses2aL0UH9sNXAWFYdFj6ZCDW1Z6BjNJUBibRHObk6sQBM+pfuuZ/d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-MS-Office365-Filtering-Correlation-Id: 14e29709-8c49-4e9f-949d-08d335324a64 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB051; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB051; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 4:AB58W32kpBb5ZNEE5haq3WZ8vjamn2Xu3OTbgHCZN/IWC3scDGT8gNSAfyM7WsYhxPXApTwaS3zy3YVHs70vrGSizVaMYPyy1RXuzuPJ/ThQyEhXSf9CAOUjXPYwU6V8XJg7hXQymeLehR7TqtnTys61updFZyKkBGW1pzu9kXHVl/kfZTakzxSLQnlwbPwKkBkEYWigTOsjtlh8iI9CJc4imLETVgasjGDVey5P3CdyxIX+FxzQWKFIjTy8DwLwqFXR5BLZh1V8e5KDiqzugm63lJwt/aVPKRRpmp8nJrweJBsYy+XVPSi6pytZmiEfdDud2znBfLiculuIY3e2lkoLxSpElj9rSSymsoKcNIRJ01499tfFEvW0HhahvKU1Iw2gELxXU7JeekjB5bu7Wy68MPUAfyuMLffhX/ERRkE= X-Forefront-PRVS: 0852EB6797 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(24454002)(479174004)(230700001)(122386002)(86362001)(87976001)(19580395003)(19580405001)(110136002)(14496001)(1556002)(5001960100002)(42186005)(93886004)(116806002)(5004730100002)(1096002)(61296003)(23756003)(77096005)(44736004)(76176999)(81816999)(50226001)(1456003)(47776003)(40100003)(81686999)(50986999)(84392002)(4326007)(3846002)(586003)(15975445007)(189998001)(50466002)(2906002)(6116002)(66066001)(44716002)(92566002)(33646002)(62236002)(5008740100001)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMSPR07MB051; 23:fzYEvGPySVVXjOM6sCXGkR2Rku7LWRWVNmCKwH5A?= =?iso-8859-1?Q?9kytZUx0VQq8tnpyPWzxKfhj11z2BK6dQfbDnAMOQxbSvx7SP6sAIiqSgK?= =?iso-8859-1?Q?qEYDvseJgXYxXnoCoLdSDCd4l/hmpW7LkVXZBGubdszti7WOTaNnfbRX9g?= =?iso-8859-1?Q?n0cVlGMqX8qgbpBsnIpeHjZ/hK9K8+W+FrS+/Tz4B+eOtPilIUf2iZX0C6?= =?iso-8859-1?Q?bIiaameVpBBV3qAf9H24Pfg/Wdg5EfGvV1JDh8DHgTC3GFQjVBVgTcmUxA?= =?iso-8859-1?Q?Yp5vO+OHQE0oa95sULUgxyO0Uzd+PF57NoYyG1fNw5S/cn1d9yPgtZOKjM?= =?iso-8859-1?Q?s4HMazyawFSv65MocQcM8I+Wb4XP2X3hy2eGRXE35wD1o0mc9m6pH0DiJc?= =?iso-8859-1?Q?7jcODcrMX5KsdUMONvqui1PT9M2vvYoTpu70AtOH8DepCurelwLlUAG4v3?= =?iso-8859-1?Q?K2fVyaMEgROzlcrIYenimjWpEtrC3x1vePqg6wfieIPvNlrCIuLew6f/qS?= =?iso-8859-1?Q?Za09F/6axjcaqRTyLc90MxmrnY1H/4rinOG6VzAbl5s/tUyZhMkyOEbsRB?= =?iso-8859-1?Q?HKKIXvq82Dy/iYB9BUduJx5e1/5e0lt8HFPSif7qfK8Shh5Ykp/JYcNxq3?= =?iso-8859-1?Q?pUh0z8MddjRXKbvNA+J5utCUjdmtNf5/U8OVMUJK4b50qpCphK0WQUQzWQ?= =?iso-8859-1?Q?OUBI8u82cCulVOlSQH9S/MyEVBwieTUI06lEZstYje0bxgIbE81lwM/Ssk?= =?iso-8859-1?Q?y2bXw5D5BaIrgtcJjjrs6nr/7jdayfUVqka49cxuccsBA1AmDb4dbpm40e?= =?iso-8859-1?Q?Wr9AuqI1G33O46u+wrdGlYTje1g/X0dPOTCE4/CvhQzCsrAP2Js9/DNWhd?= =?iso-8859-1?Q?Bqt19IAyK7Yw7c+CIU0yl5hY6Z00WkFzbxlQzprqtJ8W/xQuwUQgsR6Jct?= =?iso-8859-1?Q?r98N4ZUQakJVUuY/PlvvRhXAUqYT6bluQJB/F4N1N2ah8EAWlGkWI/dlct?= =?iso-8859-1?Q?ZvaqraYCBqCMq1MKP89DqjeLyRnHPlS7euBIyNSNEQZQWk+gPqGtaA9gSk?= =?iso-8859-1?Q?MdafSOMdP6kjoDUpoQYcxH2nnsDDqzSkWwnU3bRIYO+QpRV+FgMkt+utey?= =?iso-8859-1?Q?EDT0vy0ePxmWYE6Sf9eS4kjUJmQL6JhXd2kl5YdT2wPMFtZ9V7zFc71r3q?= =?iso-8859-1?Q?sAQGtqwXW0ROReQrCOKSnNk8M5CZLJ48FXMspmLQT5zO+GDb3p1bzupPsd?= =?iso-8859-1?Q?dXutMccazskIGFvOIf0hdiXSdiHVrHf+JY5xcGW1eQVxZS5G/rGiFx9swQ?= =?iso-8859-1?Q?CMAqn5JcCkR4RWSJWu8qYcFU271R6nEVd/eWGO2Cz6ug=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 5:Q1ZxLoK40VZwcV0qUcWtwr1R4+6ivdS0wp2jSbu3MZa8s0bGn6YsUVdhg1zpTDLof0D9w2Ac9o7dLl2B1Wp9NSwGeyQdRrZTu1RlaDLiLufYl4U+OFRXzt0yX2ZBuJCKfr8sPyg20rmhG9RMXmSxEA==; 24:PAMYp6Np2n8KhlkbEIyy4HtpBT3ajYozVJ4/UdM9rE9UDU7sDtfdyP+bLUJVjWOWKSfxSO3yTQu+UGLDgjbpYVZsE0lboLpF27pK8d903yg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2016 11:30:49.9150 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 11:31:00 -0000 ----- Original Message ----- From: "Scott O. Bradner" To: "t.petch" Sent: Saturday, February 13, 2016 1:53 PM > RFC 2026 was in force in 1997 - see section 10 Indeed, and RFC1602 was in force in October 1996 when -00 of this I-D was produced, but what I am missing is what it is that those two RFC are missing that caused us to produce RFC3667/RFC3668. To quote the latter two, " In the years since [RFC 2026] was published there have been a number of times when the exact intent of Section 10 has been the subject of vigorous debate within the IETF community. " So, do we have a sufficient grant of rights to take draft-grant-tacacs-02.txt and publish it with the necessary changes to bring it in line with current IETF practice or do we have to go back to the editors thereof, perhaps their affiliation, to get permission? With SSLv3 and RFC6101, that was not a problem; with this I-D, I do not know. Tom Petch > Scott > > > > > On Feb 13, 2016, at 7:39 AM, t.petch wrote: > > > > ---- Original Message ----- > > From: "Robert Drake" > > To: > > Sent: Saturday, February 13, 2016 2:52 AM > >> > >> On 2/12/2016 10:46 AM, Eliot Lear wrote: > >>> Hi Stefan, > >>> > >>> Unless it is absolutely determined that the current work can't > > doesn't > >>> meet criteria for an IETF standard, I would be opposed to such an > >>> exercise. For one thing, we all have other things to do. For > > another, > >>> and as or more important, we would be denying the reality of the > >>> situation. I would rather understand now what sort of changes are > >>> being proposed in order for the current work to come up to snuff. > >>> > >>> Eliot > >>> > >> Is there anything in this that is incorrect or incomplete? If not, > > then > >> can it be resubmitted for informational status to define the protocol > > as > >> it currently exists? > >> > >> https://tools.ietf.org/html/draft-grant-tacacs-02 > > > > No! Our procedures have moved on a lot since then and the I-D would need > > substantial editing. This is problematic. Nowadays - Note Well - > > anything you or I or anyone else says or writes can be used in an I-D > > without any breach of copyright. This I-D is 1997 - before my time - > > and I was looking yesterday to try and find out what rules the IETF was > > operating under then and could not find them. So, who owns the > > copyright in the text? Who has permission to edit and publish it? I do > > not know (and have seen this issue take a while to resolve in other > > circumstances). > > > > And then there is the question of IPR; reading RFC1492, which I think > > would be a Normative Reference in modern parlance, I would expect a > > manufacturer to be taking an interest in this and submitting an IPR > > claim. > > > > These are surmountable difficulties. The TLS WG decided that it wanted > > a specification of SSLv3 some 15 years after the event and we now have > > RFC6101 but it takes time and effort. > > > > Tom Petch > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Sun Feb 14 03:58:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445371A6F9A for ; Sun, 14 Feb 2016 03:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.495 X-Spam-Level: * X-Spam-Status: No, score=1.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 sp-6JgCOAs3E for ; Sun, 14 Feb 2016 03:58:38 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0EB1A6F6B for ; Sun, 14 Feb 2016 03:58:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 3CC8415C22BD; Sun, 14 Feb 2016 06:58:37 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd0lnG2SPghX; Sun, 14 Feb 2016 06:58:35 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id A8B6D15C22AE; Sun, 14 Feb 2016 06:58:35 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Scott O. Bradner" In-Reply-To: <003f01d1671a$af55c720$4001a8c0@gateway.2wire.net> Date: Sun, 14 Feb 2016 06:58:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56BDE83F.1030102@restena.lu> <56BDFE46.9000802@cisco.com> <56BE9A5A.9040309@direcpath.com> <02a101d1665b$9e16b380$4001a8c0@gateway.2wire.net> <430EA6BD-7BF8-4E02-9E7C-AE22960E8A28@sobco.com> <003f01d1671a$af55c720$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 11:58:40 -0000 RFC 2026 specifically permits the IETF to "prepare derivative works that = are based on or incorporate all or part of the contribution=E2=80=9D (Section = 10.3.1.1). The =E2=80=9C contribution=E2=80=9D in this case is the old ID. =20 The language in 2026 was based on language in RFC 1602 (section = 5.4.1.1). i.e., use of the old ID to make the new one is authorized by RFC 2026 RFC 3667 (and RFC 3668) was produced to clarify the specific details in = RFC 2026=20 section 10. The mandate given to the IPR working group that produced it=20= was to clarify but not to change the intent of RFC 2026. =20 Scott > On Feb 14, 2016, at 6:27 AM, t.petch wrote: >=20 > ----- Original Message ----- > From: "Scott O. Bradner" > To: "t.petch" > Sent: Saturday, February 13, 2016 1:53 PM >> RFC 2026 was in force in 1997 - see section 10 >=20 > Indeed, and RFC1602 was in force in October 1996 when -00 of this I-D > was produced, but what I am missing is what it is that those two RFC = are > missing that caused us to produce RFC3667/RFC3668. To quote the = latter > two, > " In the years since [RFC 2026] was > published there have been a number of times when the exact intent of > Section 10 has been the subject of vigorous debate within the IETF > community. " > So, do we have a sufficient grant of rights to take > draft-grant-tacacs-02.txt > and publish it with the necessary changes to bring it in line with > current IETF practice or do we have to go back to the editors thereof, > perhaps their affiliation, to get permission? With SSLv3 and RFC6101, > that was not a problem; with this I-D, I do not know. >=20 > Tom Petch >=20 >> Scott >>=20 >>=20 >>=20 >>> On Feb 13, 2016, at 7:39 AM, t.petch wrote: >>>=20 >>> ---- Original Message ----- >>> From: "Robert Drake" >>> To: >>> Sent: Saturday, February 13, 2016 2:52 AM >>>>=20 >>>> On 2/12/2016 10:46 AM, Eliot Lear wrote: >>>>> Hi Stefan, >>>>>=20 >>>>> Unless it is absolutely determined that the current work can't >>> doesn't >>>>> meet criteria for an IETF standard, I would be opposed to such an >>>>> exercise. For one thing, we all have other things to do. For >>> another, >>>>> and as or more important, we would be denying the reality of the >>>>> situation. I would rather understand now what sort of changes are >>>>> being proposed in order for the current work to come up to snuff. >>>>>=20 >>>>> Eliot >>>>>=20 >>>> Is there anything in this that is incorrect or incomplete? If not, >>> then >>>> can it be resubmitted for informational status to define the > protocol >>> as >>>> it currently exists? >>>>=20 >>>> https://tools.ietf.org/html/draft-grant-tacacs-02 >>>=20 >>> No! Our procedures have moved on a lot since then and the I-D would > need >>> substantial editing. This is problematic. Nowadays - Note Well - >>> anything you or I or anyone else says or writes can be used in an > I-D >>> without any breach of copyright. This I-D is 1997 - before my > time - >>> and I was looking yesterday to try and find out what rules the IETF > was >>> operating under then and could not find them. So, who owns the >>> copyright in the text? Who has permission to edit and publish it? > I do >>> not know (and have seen this issue take a while to resolve in other >>> circumstances). >>>=20 >>> And then there is the question of IPR; reading RFC1492, which I > think >>> would be a Normative Reference in modern parlance, I would expect a >>> manufacturer to be taking an interest in this and submitting an IPR >>> claim. >>>=20 >>> These are surmountable difficulties. The TLS WG decided that it > wanted >>> a specification of SSLv3 some 15 years after the event and we now > have >>> RFC6101 but it takes time and effort. >>>=20 >>> Tom Petch >>>=20 >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Sun Feb 14 12:18:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38231A03AB for ; Sun, 14 Feb 2016 12:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham 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 7VjyU6SrcM3n for ; Sun, 14 Feb 2016 12:18:01 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8807A1A03AA for ; Sun, 14 Feb 2016 12:18:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 3D292CF6; Sun, 14 Feb 2016 20:18:00 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz_DRtRSNZrX; Sun, 14 Feb 2016 20:18:00 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 7707AB63; Sun, 14 Feb 2016 20:17:59 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=us-ascii From: Alan DeKok In-Reply-To: <56BE2C93.7070406@gmail.com> Date: Sun, 14 Feb 2016 15:17:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6018547A-CAA3-4236-B966-8B2AC4C5A6AE@deployingradius.com> References: <93B875C8-FF5A-4CD3-BBAB-E028749C67FF@deployingradius.com> <56BCE1A7.6050807@gmail.com> <9B53AFCE-8792-4CB4-AC47-A2F0D986D759@deployingradius.com> <56BD1113.2010106@gmail.com> <56BE2C93.7070406@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 20:18:03 -0000 On Feb 12, 2016, at 2:03 PM, Brian E Carpenter = wrote: > No, that it's *used* by many operators. However, the real point about = putting it > on the standards track is that it would move change control of the = text to the IETF. TACACS+ the *existing* protocol is not under change control of the = IETF. That's my reason for suggesting publication of the protocol *as = it exists today* via an informational RFC. First, to document it. = Second, to make it clear that the protocol being documented was not = created under IETF change control. TACACS+ as it exists tomorrow is absolutely well within the scope of = the IETF. Any "future TACACS+" can be produced under IETF change = control, with whatever label the IETF wants. > That's a valid point to debate. Is there any win in that for the = community, as > opposed to leaving it entirely in the hands of "large companies"? I've tried to make my argument clear. I have *never* suggested = leaving the protocol entirely in the hands of large companies. > If this was only about rubber-stamping I would agree with you. I see the current document as conflating the two points I discussed = above.=20 * As such, it comes across as "rubber stamping" the historical TACACS+ = protocol as an IETF standard, because it's issuing a standards-track = document for "historical TACACS+ plus TLS". * the OPSAWG is defining a new (to the world and IETF) standard network = administration protocol as work so minor that it doesn't require a = charter update, Where more commonly we would have a WG devoted to = defining a critically important network administration protocol * It's an AAA protocol, but the AAA requirements shouldn't apply, = because it's not really an AAA protocol. * It's a network management protocol for "device administration" or = "device management", a use-case which is so vital that the phrases = aren't even mentioned in the document. * It's not a new protocol because it's been around for 18 years, but in = order to give the IETF change control, we have to add new bits and TLS = transport... which makes it a new protocol. The whole thing looks like special pleading to me. As such, I'm requesting a clear separation of topics, and a clear = statement of applicability. That the historical protocol be documented = separately from the future protocol. That documents clearly state it's = *not* a AAA protocol, and *should not* be used in situations where AAA = protocols are used today. That it's a network management protocol, and = it should be limited to that use-case. The thing which is amazing for me is that there is enormous push-back = to my request for consistently applying logic, the IETF process, and = IETF consensus. Alan DeKok. From nobody Mon Feb 15 01:19:17 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACB11B3048 for ; Mon, 15 Feb 2016 01:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=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 yg7-iyO301OS for ; Mon, 15 Feb 2016 01:19:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0684.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:684]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C36A1B304A for ; Mon, 15 Feb 2016 01:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=direcpathcorp.onmicrosoft.com; s=selector1-direcpath-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vfQlhJhlg8DzDE48/+Eb1OTxHVmae3KcpIUNF5cn6O0=; b=g8+yDP1NqA+g17wx1uJpe2JqjFCDXnkj9Gko/IKDOKEyJHo2rO5VzxX3qEL4VDPgGdK12xOiEeoLuGU9r7WgXaTOe1tkypTL7zJKqWjZcATAQzHOL20fGsgPxnI40Xpyl3d3O2+97Xg9bPHsCnwobVCqpchJaplNEdBndJPXzvU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=direcpath.com; Received: from [10.6.2.149] (24.98.60.52) by BY2PR01MB1719.prod.exchangelabs.com (10.163.26.145) with Microsoft SMTP Server (TLS) id 15.1.409.10; Mon, 15 Feb 2016 09:18:43 +0000 To: References: <56BDE83F.1030102@restena.lu> <56BDFE46.9000802@cisco.com> <56BE9A5A.9040309@direcpath.com> <02a101d1665b$9e16b380$4001a8c0@gateway.2wire.net> <430EA6BD-7BF8-4E02-9E7C-AE22960E8A28@sobco.com> <003f01d1671a$af55c720$4001a8c0@gateway.2wire.net> From: Robert Drake Message-ID: <3aab064c-2ea6-8238-f1db-76a56f35b769@direcpath.com> Date: Mon, 15 Feb 2016 04:18:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [24.98.60.52] X-ClientProxiedBy: DM2PR03CA0037.namprd03.prod.outlook.com (10.141.96.36) To BY2PR01MB1719.prod.exchangelabs.com (25.163.26.145) X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 2:VcSaVHQlJf6y8zl4SXO4ldJTMX5YCy+sfIg0a65c/IjNuhXWFO8fOa+xHtzYXHn+p7JZWP2INItf08Yor3rMm1kd3b3hj0sZHBE83S7cyHJ0SQKKiO7ntj6+6SXcSjdqbSCULJ03Rt1qhjDdlpxbGA==; 3:PKe382q7bypPPnhvPji5HYr9dTW8r7uzFIX1bJx7AQ8bPKOD8V2mgKXbEqA+cPd0v59RuGo0hsPZePgcgurVDGaKZ2VWMbSHdjDT8af2nDjyn0N2BQubdWUVT0Kq9vbF; 25:qpPx8gCthGl5QFyRKZ2Vec6vNvG2Zj3O3606+OQ4ebPKveeR9/1pu1QZ5ruELuxRl6lL4GtXPtcWkXOJC3OoPciR0hEMX2rwOfhXer8rYcrzYUUBC9MBh0B5eJeBG5ivfmqD0HBvBOD30QgtjKeFk/tDH+BE2yRpu0/GqahXJbFitaf0/CACeSw8EX4gjOZlR15b5R6WU6p9jKF+GiNXNHgx34SfnXNYiyDqs34Pqwn0aqgZDJBaiPSmed0kny2B0HMT3CIcVy2NZAfdyeE6RoTqs4KYn8pF5ZaBPEnbPWjgI2SmjSwgiwHKhF3VUdos X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR01MB1719; X-MS-Office365-Filtering-Correlation-Id: a2d15a6e-046a-4f2f-f766-08d335e9006e X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR01MB1719; BCL:0; PCL:0; RULEID:; SRVR:BY2PR01MB1719; X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 4:rwlq3okKnntCaVzcy1i1bfqByYQPCXcrGxtbdDOsBqK2C53bo5p7TQwuN+qDEMsEkuKLDvlJa2MMI3QOfpLs+iv2fGCYrdix8dEajzYOrs2M4it7BADtWQpJpLAYdoKBl2kUsqR2171XgvrAFqEJpwyX475RlzSg303DEwc6N7hFZqrjGVys6/vz7YFoKogLrehaRZWkZpfmTc2Gcuw+b9/+MbyNAzL+XyR9hadwoEvjYXFuDN94TVXrx6w6SWyZeVmqibui6lEN5+CXWKBImVv/PCKd+RsB+F2njoQRnnxG6CkNEQ5LFjz8hq6xpINwCm2k+5FW7TY/xIAPqvO51dRBRVLn2JfSYRh0W5wGFGN/KGW/SBYxzmTVn6BC9xIwXV6nKB3dzF7IQ8y9Idtf7w== X-Forefront-PRVS: 08534B37A7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(377454003)(61484003)(479174004)(13464003)(24454002)(50986999)(47776003)(2351001)(122386002)(77096005)(31696002)(92566002)(42186005)(450100001)(66066001)(23676002)(40100003)(36756003)(15975445007)(83506001)(31686004)(65956001)(54356999)(76176999)(87976001)(4001350100001)(86362001)(2870700001)(107886002)(110136002)(93886004)(189998001)(5001960100002)(19580395003)(19580405001)(2950100001)(65806001)(586003)(6116002)(1096002)(3846002)(5008740100001)(33646002)(2906002)(50466002)(5004730100002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR01MB1719; H:[10.6.2.149]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjAxTUIxNzE5OzIzOlFhRnVxRWpqMldjZzJXMGhOQ3AxaEgvMGJV?= =?utf-8?B?czhJU2h6QThRbk1WUCtvRjMvNlBGK1Zra0l6UGVacFI2emxDVEk2Z0grNHNv?= =?utf-8?B?cVY3Yy9QT0FQTngwS3VmR1pvZWhLQUhTWnlWMWFqUFFheEFyeUVHcjlPUE9G?= =?utf-8?B?TWd6S3B0NDBtRW1TM0s0Ti9sVWxoRm1vMGNQS1dMMGk5S2NrSUZuZmJ3aTNv?= =?utf-8?B?TW1NVzdiYm83dnE5SDNIUXplTytjMU02VGRkanloeWpJVTJEN2x3N3Y5SXhL?= =?utf-8?B?WHpjL2ttY05yRGx4RStRY1IyUlJVZDBjVHY1SnRnUGViZFkxOExwYVFqeG9U?= =?utf-8?B?L05TekpQTVZEbmRlK2FPMjlIcnlkYm9TSDVub2NoMWZqelhoZmJQWklWbTdv?= =?utf-8?B?SDU0S3ROSFp6VlZvV0YxVmw5SlNYaU11YWc4ZzBtcG11V05uRGlZYmwrcGFh?= =?utf-8?B?a29QVWVLNFJocFJBaitPVktUamlTR0doMHBRRUFRSlBxTSsydFMyWXpMa1Jm?= =?utf-8?B?UktsclB5TzBFSDRqNXBoLzhFeUdOQ29BbTQyQ0c0aWEzM1JLTGUzOUFPbm5v?= =?utf-8?B?ay9TaDZCWnJrQUJmY0xFbmg0ZFdvbk1CWE5tcG5LWWxMR3g2UzhiSzRTekZE?= =?utf-8?B?SGpUWDl6bXFwWmY4QlRlNmxmTEZyS24yT1RBYi81aGZmN0picmR4MVZhdmha?= =?utf-8?B?Q2FnMVZxSncreUZ5bThDa2VUK0pwclNIN2hvY2s4ZnNGaVdyR3IwbExZSEk1?= =?utf-8?B?UTNzbi9SanZBcmhMZ0pLWGdiUURZelNTMk5EQkcyTzhWSSsydEJGUHdxSyt5?= =?utf-8?B?dDc2UExpUjRQQXlqVlJoRHBOVlgyeU5wV1I0eWprKzFka0RkQ2Jrb0xtaHpO?= =?utf-8?B?b2JPUDlERkV3SUpOSTM3SGMyV25WL3h0TzhFeW1vNC9mdm91aWN2NFFINXhO?= =?utf-8?B?TG94Q0VjK1k4SXVIUVpaRkpJT0tFeGpvMGN3aVBvOW15ZkVQRUViS2x3UUQ4?= =?utf-8?B?aUl0cFlTVnBmV0ZEQis5d01jSVpiQm1BNTlSN2hZcHpubmNneXkxcXRKa3d5?= =?utf-8?B?bkg3NmdXZitld3hXcmdvRi9pSzN5SEhadTJBcjFnMjJuS1pZWDR5VjJ4K1Vp?= =?utf-8?B?VzhrU2lReHk0a2R6c0N3M1ZtcmRUZm12MTNvMEl5WXk3V3VRcDFnQmttRXZ1?= =?utf-8?B?ZFBXS05UZktOYmFDbkw5ZTRodXNSUHpNKzRWd3pjaFJBak4rVDZ1MHp1V0N3?= =?utf-8?B?MTliaHlhcFdkNHhVTzl4RTlCaWsxRFdNdGtkd25FUGNaWUMwUmtvU0VoWlZi?= =?utf-8?B?bEFMRWJpZ3NiUWtwVkZ6TnlZaWJvelovZzY4d0FSd2lhNWk0OG5iZWpnSW42?= =?utf-8?B?UzliK0xzZnQxREpjWTJ3SkM1cktCTHpkeGp1ZTRBU3JEN0RUWmlic1hWd2M2?= =?utf-8?B?cEQwV28rcklLbGsxKzZVUTJYS2cydUFuUFkzaFVBbW51Q243QXhkUzkzTTZ6?= =?utf-8?B?a1prQ0xkR2ZRU0tqMHZXcStkVEFWaDMrdVVDUVBjTm5FbW9jc1NWUkszalZG?= =?utf-8?B?enZFUm0rM1VEcUUwclVTMmFGYVZGUHU5Z0lZUWNNeFhaOHRYWVVWWlg0ZXAx?= =?utf-8?B?QmRpZXpBT0hrWTRwYS9rVDdPQ21rb01PZFAzemJnQlh2eTUxTmxYSFpHMFhT?= =?utf-8?Q?ImKuV2HKMb5cP8B2xQU4iMIucCSZyIy8g3H9GO+?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 5:koFoHZRDBwhSSjmUrMK06sQ3yhqbZhG8grvV7uRuD1ctOhGgniULed70v5KdNrjAY/ewteN60UWwqVYmdlOQnQfcQ5SEbCmfMxkIIYY0dQTBAMbuKusQvB1hxuun1nN4+TP9soyC+9+4VTDmg+9mFA==; 24:B18cumrz32VPaunI5rPnHIXHiJDt/r8K908fRNzilHSWKLqnRXHrzq/JDoPp7tlYdx8M+bLrhPrP86b7DYNdkki5rB1FuFKm8boaHhtqlNY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: direcpath.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2016 09:18:43.7639 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR01MB1719 Archived-At: Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 09:19:14 -0000 David Carrel and Lol Grant are both on linkedin. Lol Grant is listed as retired and may have absolutely no interest in trying to resolve copyright problems from 20 years ago, but maybe it would amuse both of them to get back involved. Or maybe not.. On 2/14/2016 6:58 AM, Scott O. Bradner wrote: > RFC 2026 specifically permits the IETF to "prepare derivative works that are based on or > incorporate all or part of the contribution†(Section 10.3.1.1). The “ contribution†in this case is the > old ID. > > The language in 2026 was based on language in RFC 1602 (section 5.4.1.1). > > i.e., use of the old ID to make the new one is authorized by RFC 2026 > > RFC 3667 (and RFC 3668) was produced to clarify the specific details in RFC 2026 > section 10. The mandate given to the IPR working group that produced it > was to clarify but not to change the intent of RFC 2026. > > > Scott > > >> On Feb 14, 2016, at 6:27 AM, t.petch wrote: >> >> ----- Original Message ----- >> From: "Scott O. Bradner" >> To: "t.petch" >> Sent: Saturday, February 13, 2016 1:53 PM >>> RFC 2026 was in force in 1997 - see section 10 >> Indeed, and RFC1602 was in force in October 1996 when -00 of this I-D >> was produced, but what I am missing is what it is that those two RFC are >> missing that caused us to produce RFC3667/RFC3668. To quote the latter >> two, >> " In the years since [RFC 2026] was >> published there have been a number of times when the exact intent of >> Section 10 has been the subject of vigorous debate within the IETF >> community. " >> So, do we have a sufficient grant of rights to take >> draft-grant-tacacs-02.txt >> and publish it with the necessary changes to bring it in line with >> current IETF practice or do we have to go back to the editors thereof, >> perhaps their affiliation, to get permission? With SSLv3 and RFC6101, >> that was not a problem; with this I-D, I do not know. >> >> Tom Petch >> >>> Scott >>> >>> >>> >>>> On Feb 13, 2016, at 7:39 AM, t.petch wrote: >>>> >>>> ---- Original Message ----- >>>> From: "Robert Drake" >>>> To: >>>> Sent: Saturday, February 13, 2016 2:52 AM >>>>> On 2/12/2016 10:46 AM, Eliot Lear wrote: >>>>>> Hi Stefan, >>>>>> >>>>>> Unless it is absolutely determined that the current work can't >>>> doesn't >>>>>> meet criteria for an IETF standard, I would be opposed to such an >>>>>> exercise. For one thing, we all have other things to do. For >>>> another, >>>>>> and as or more important, we would be denying the reality of the >>>>>> situation. I would rather understand now what sort of changes are >>>>>> being proposed in order for the current work to come up to snuff. >>>>>> >>>>>> Eliot >>>>>> >>>>> Is there anything in this that is incorrect or incomplete? If not, >>>> then >>>>> can it be resubmitted for informational status to define the >> protocol >>>> as >>>>> it currently exists? >>>>> >>>>> https://tools.ietf.org/html/draft-grant-tacacs-02 >>>> No! Our procedures have moved on a lot since then and the I-D would >> need >>>> substantial editing. This is problematic. Nowadays - Note Well - >>>> anything you or I or anyone else says or writes can be used in an >> I-D >>>> without any breach of copyright. This I-D is 1997 - before my >> time - >>>> and I was looking yesterday to try and find out what rules the IETF >> was >>>> operating under then and could not find them. So, who owns the >>>> copyright in the text? Who has permission to edit and publish it? >> I do >>>> not know (and have seen this issue take a while to resolve in other >>>> circumstances). >>>> >>>> And then there is the question of IPR; reading RFC1492, which I >> think >>>> would be a Normative Reference in modern parlance, I would expect a >>>> manufacturer to be taking an interest in this and submitting an IPR >>>> claim. >>>> >>>> These are surmountable difficulties. The TLS WG decided that it >> wanted >>>> a specification of SSLv3 some 15 years after the event and we now >> have >>>> RFC6101 but it takes time and effort. >>>> >>>> Tom Petch >>>> >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> OPSAWG@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Feb 15 02:07:12 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799AF1B30C7 for ; Mon, 15 Feb 2016 02:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 M5FOxK52xbfR for ; Mon, 15 Feb 2016 02:07:08 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ED71B30C6 for ; Mon, 15 Feb 2016 02:07:08 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 40CF8118ED1; Mon, 15 Feb 2016 10:07:08 +0000 (UTC) Date: Mon, 15 Feb 2016 10:07:08 +0000 From: heasley To: opsawg@ietf.org Message-ID: <20160215100708.GD80648@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 10:07:10 -0000 Seems that in the time bikeshedding, this could have already been in WGLC. Outstanding work! From nobody Mon Feb 15 07:10:09 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4661B3533 for ; Mon, 15 Feb 2016 07:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 nfL__m_ifDh8 for ; Mon, 15 Feb 2016 07:10:06 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBAC1B3532 for ; Mon, 15 Feb 2016 07:10:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D4AQCP6cFW/yYyC4deGQEBAQEPAQEBAYI+IStSc7oXAQ2BZyGFbAKBMjgUAQEBAQEBAX8LhEMBAQMSG0wSARUVVh8HAQQODRqHeAENoy6ZDgEBAQEBAQQBAQEBAQEBFQSGEog1MS2CfoEPBYVNkSwBhU6CbYJkhBGEQ4MahTuOPh4BAUKDY4hmAXsBAQE X-IPAS-Result: A2D4AQCP6cFW/yYyC4deGQEBAQEPAQEBAYI+IStSc7oXAQ2BZyGFbAKBMjgUAQEBAQEBAX8LhEMBAQMSG0wSARUVVh8HAQQODRqHeAENoy6ZDgEBAQEBAQQBAQEBAQEBFQSGEog1MS2CfoEPBYVNkSwBhU6CbYJkhBGEQ4MahTuOPh4BAUKDY4hmAXsBAQE X-IronPort-AV: E=Sophos;i="5.22,450,1449550800"; d="scan'208,217";a="160933871" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Feb 2016 10:10:04 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 15 Feb 2016 10:10:04 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Mon, 15 Feb 2016 16:09:51 +0100 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: automatic attachment of applications and services at the edge Thread-Index: AdFoAuqkDgFGUxitTRiPQzVc0ggEVA== Date: Mon, 15 Feb 2016 15:09:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF19470@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF19470AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "Unbehagen Jr, Paul E \(Paul\)" Subject: [OPSAWG] automatic attachment of applications and services at the edge X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 15:10:08 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF19470AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to draw the attention of the participants in the OPSAWG on an = individual submission that I am co-authoring. The problem we are trying to = solve is the optimization / minimizing of the amount of configuration that = an operator needs to do when new applications require the creation of paths= or tunnels in the core network. In order to avoid the reconfiguration of t= he core or heavy configuration at the edge the proposed method which we cal= l auto-attachment allows for the usage of a protocol running between the en= d stations and the first (edge) router that adds the information and charac= teristics of the new path according to the policies or mapping tables of th= e operators. A first implementation that we have running code for and is de= ployed is described in https://datatracker.ietf.org/doc/draft-unbehagen-lld= p-spb/ and uses the Link Layer Discovery Protocol (LLDP) with an IEEE 802.1= aq Shortest Path Bridging (SPB) network. Please have a look and let me know if there is interest and/or similar on-g= oing work. If there is enough interest I plan to request a short slot to di= scuss the idea at the OPSAWG meeting at IETF 95. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF19470AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I would like to draw the attention of the participan= ts in the OPSAWG on an individual submission that I am co-authoring. The pr= oblem we are trying to solve is the optimization / minimizing of the amount= of configuration that an operator needs to do when new applications require the creation of paths or tunnels= in the core network. In order to avoid the reconfiguration of the core or = heavy configuration at the edge the proposed method which we call auto-atta= chment allows for the usage of a protocol running between the end stations and the first (edge) router that= adds the information and characteristics of the new path according to the = policies or mapping tables of the operators. A first implementation that we= have running code for and is deployed is described in https://datatracker.ietf.org/doc/draft-unbehagen-lldp-spb/ and uses the= Link Layer Discovery Protocol (LLDP) with an IEEE 802.1aq Shortest Path Br= idging (SPB) network.

 

Please have a look and let me know if there is inter= est and/or similar on-going work. If there is enough interest I plan to req= uest a short slot to discuss the idea at the OPSAWG meeting at IETF 95.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF19470AZFFEXMB04globa_-- From nobody Mon Feb 15 07:35:44 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BE51B34C9 for ; Mon, 15 Feb 2016 07:35:42 -0800 (PST) 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] autolearn=ham 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 RzjGwCFGCkoT for ; Mon, 15 Feb 2016 07:35:41 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id D782A1B338A for ; Mon, 15 Feb 2016 07:35:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E2BCFD13; Mon, 15 Feb 2016 15:35:38 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM_izeexFPyp; Mon, 15 Feb 2016 15:35:38 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id B7AE3BA1; Mon, 15 Feb 2016 15:35:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <20160215100708.GD80648@shrubbery.net> Date: Mon, 15 Feb 2016 10:35:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <97B548DD-6589-4B13-9053-48C416390977@deployingradius.com> References: <20160215100708.GD80648@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 15:35:42 -0000 On Feb 15, 2016, at 5:07 AM, heasley wrote: >=20 > Seems that in the time bikeshedding, this could have already been in = WGLC. > Outstanding work! Following process and achieving consensus is not "bike shedding". It's = entirely inappropriate to describe it that way. Alan DeKok. From nobody Mon Feb 15 10:26:34 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75B41A8A96 for ; Mon, 15 Feb 2016 10:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 ufVo72g1Szyi for ; Mon, 15 Feb 2016 10:26:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2D11A8847 for ; Mon, 15 Feb 2016 10:26:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aVNqv-0001uv-Ku; Mon, 15 Feb 2016 18:26:29 +0000 Date: Tue, 16 Feb 2016 07:26:28 +1300 Message-ID: From: Randy Bush To: Alan DeKok In-Reply-To: <97B548DD-6589-4B13-9053-48C416390977@deployingradius.com> References: <20160215100708.GD80648@shrubbery.net> <97B548DD-6589-4B13-9053-48C416390977@deployingradius.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 18:26:33 -0000 >> Seems that in the time bikeshedding, this could have already been in >> WGLC. Outstanding work! > Following process and achieving consensus is not "bike shedding". > It's entirely inappropriate to describe it that way. i thought he was quite polite in not calling it something much stronger. how many operators do we need to scream in pain that this is something we do and need standardized in a simple and clear way does it take for the ietf purportedly ops area wg to actually listen. and folk wonder why ops walk away from the ietf in disgust? we know you like radius. oddly, we do to, but for a different purpose. tacacs+ needs to be simply, clearly, and formally documented. folk are willing to do the work. this wg is for that purpose. can we please move along? randy From nobody Mon Feb 15 10:36:53 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E71A21A6 for ; Mon, 15 Feb 2016 10:36:51 -0800 (PST) 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] autolearn=ham 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 c5Qipi2FkYPY for ; Mon, 15 Feb 2016 10:36:50 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DE2A41A0033 for ; Mon, 15 Feb 2016 10:36:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 4D8B8BA1; Mon, 15 Feb 2016 18:36:49 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m4Ti1H7JUFz; Mon, 15 Feb 2016 18:36:49 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id CE92B556; Mon, 15 Feb 2016 18:36:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Mon, 15 Feb 2016 13:36:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160215100708.GD80648@shrubbery.net> <97B548DD-6589-4B13-9053-48C416390977@deployingradius.com> To: Randy Bush X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 18:36:52 -0000 On Feb 15, 2016, at 1:26 PM, Randy Bush wrote: >=20 >>> Seems that in the time bikeshedding, this could have already been in >>> WGLC. Outstanding work! >> Following process and achieving consensus is not "bike shedding". >> It's entirely inappropriate to describe it that way. >=20 > i thought he was quite polite in not calling it something much = stronger. Feel free to share your feelings. > how many operators do we need to scream in pain that this is something > we do and need standardized in a simple and clear way does it take for > the ietf purportedly ops area wg to actually listen. and folk wonder > why ops walk away from the ietf in disgust? Which, of course, has nothing to do with me. Since IETF 93 in Prague, = I have consistently requested that TACACS+ be documented in an = informational RFC. > we know you like radius. oddly, we do to, but for a different = purpose. Which is a non sequitur. > tacacs+ needs to be simply, clearly, and formally documented. folk = are > willing to do the work. this wg is for that purpose. can we please > move along? I've agreed with all of that. So... we both agree that it should be documented. We both agree that = people should use TACACS+. I understand that there have been a lot of messages on the topic, but = my position isn't that complicated. Despite having a simple and = publicly stated position, I've seen enormous pushback (as here) with = comments that are, quite frankly, irrelevant to the position I hold. If the best counter-argument to me is a straw man, I have a nice torch = handy. It's called "reality". Alan DeKok. From nobody Mon Feb 15 10:42:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30631A9163 for ; Mon, 15 Feb 2016 10:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 mtNPUyyExkYA for ; Mon, 15 Feb 2016 10:42:36 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B211A914C for ; Mon, 15 Feb 2016 10:42:35 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id g127so121055795ywf.2 for ; Mon, 15 Feb 2016 10:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=/IsbcWRGtZrYYk+jTag8zd18Dk22KJvOWUJt/cpaGr0=; b=dg3yaEQUDjcGH94bmPkzha+ngt4PxzvgTGJqWfd9IvVh8JXqCjuL3OXUqduwB0JFlh SvPi/kEEiMhR+7C7QJCqKNUJFNIsCiPiq70iLSEpdhYJb3FSbGkB6nbz4JcdAl8nSOYb NT94cUS3/kPTFQuQ3K2KvZlbLqNgzP7wMTaWcIrZve87Ed4HDxjMABzITkZW3lZ/L4QS c9EEj3xuDsXKVAt6UvzVnYSEIoSmAqZRDqGCLKXucydIQxjagwQNb5TtdjZDOuCwfJ9O aJKjfoygpzE8/EPUW71k6lIEkCZ3Ucv93S/vOg1XHDOfoqKlcuuW+aeQoJ7wPSGX4pmf gHqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=/IsbcWRGtZrYYk+jTag8zd18Dk22KJvOWUJt/cpaGr0=; b=U9+QSqxITlQYOu88A6Ku0sagMdBe0AsaLyvrTzgnJp+mPXrK0wPMDVQDhOiL+df9mm gntOh6LM/6AKAx8oxyZFxfcjExVgJ4nHxE8Pri8++IXfbq53at+sQ5UwBUv9v0sHorEx 62iIDk+VH2m6wPPVDTrzeWmfn+NFdoA3qd3husptZb8pQqEXp0XTAzTj7HJ4YefdPJjN 7Rgz6qZTf9dtl3hkLMznqglfHBHrr0Wg4Xj7hmV4+qHUFYht6H3XGI9ojN6thQwdFuqv VSkTgpZyXR2NLla1V3KirnVN08mEfyF2xN+OTg67BW0jNRsl8cVCazbQm7rzoWbk66i1 7N2g== X-Gm-Message-State: AG10YOQ6u4r7Q4W44Z6v/dKsGHpnNkHX91j4FG4IMe0B1umJWjqYAomIQRMAQZal7ZZ4SPCpNMPWDRek0cINmhbg X-Received: by 10.13.210.67 with SMTP id u64mr9528060ywd.42.1455561755304; Mon, 15 Feb 2016 10:42:35 -0800 (PST) MIME-Version: 1.0 References: <20160215100708.GD80648@shrubbery.net> <97B548DD-6589-4B13-9053-48C416390977@deployingradius.com> In-Reply-To: From: Warren Kumari Date: Mon, 15 Feb 2016 18:42:25 +0000 Message-ID: To: Alan DeKok , Randy Bush Content-Type: multipart/alternative; boundary=001a114e7e305fd9c4052bd36154 Archived-At: Cc: opsawg Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 18:42:38 -0000 --001a114e7e305fd9c4052bd36154 Content-Type: text/plain; charset=UTF-8 Ok, let's all please take a step back, and calm down a little. We have a proposed path forward, but are waiting he hear back from our ADs (Benoit is on travel, and it is a vacation for many in the US) to get their input. We'll be the first to admit that we've done a less than stellar job here - there have been many reasons for this (including including travel, bringing on a new chair, Chinese New Year (and other vacations), etc), but we are trying to untangle ourselves - please hang in there for a bit longer... W On Mon, Feb 15, 2016 at 1:36 PM Alan DeKok wrote: > On Feb 15, 2016, at 1:26 PM, Randy Bush wrote: > > > >>> Seems that in the time bikeshedding, this could have already been in > >>> WGLC. Outstanding work! > >> Following process and achieving consensus is not "bike shedding". > >> It's entirely inappropriate to describe it that way. > > > > i thought he was quite polite in not calling it something much stronger. > > Feel free to share your feelings. > > > how many operators do we need to scream in pain that this is something > > we do and need standardized in a simple and clear way does it take for > > the ietf purportedly ops area wg to actually listen. and folk wonder > > why ops walk away from the ietf in disgust? > > Which, of course, has nothing to do with me. Since IETF 93 in Prague, I > have consistently requested that TACACS+ be documented in an informational > RFC. > > > we know you like radius. oddly, we do to, but for a different purpose. > > Which is a non sequitur. > > > tacacs+ needs to be simply, clearly, and formally documented. folk are > > willing to do the work. this wg is for that purpose. can we please > > move along? > > I've agreed with all of that. > > So... we both agree that it should be documented. We both agree that > people should use TACACS+. > > I understand that there have been a lot of messages on the topic, but my > position isn't that complicated. Despite having a simple and publicly > stated position, I've seen enormous pushback (as here) with comments that > are, quite frankly, irrelevant to the position I hold. > > If the best counter-argument to me is a straw man, I have a nice torch > handy. It's called "reality". > > Alan DeKok. > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a114e7e305fd9c4052bd36154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, let's all please take a step back, and calm down a= little.

We have a proposed path forward, but are waitin= g he hear back from our ADs (Benoit is on travel, and it is a vacation for = many in the US) to get their input.
We'll be the first to admit that we've done a less than stellar = job here - there have been many reasons for this (including=C2=A0including travel, bringing on= a new chair, Chinese New Year (and other vacations), etc), but we are tryi= ng to untangle ourselves - please hang in there for a bit longer...<= /div>

W=C2=A0
=


On Mon= , Feb 15, 2016 at 1:36 PM Alan DeKok <aland@deployingradius.com> wrote:
On Feb 15, 2016, at 1:26 PM, Randy Bush <randy@psg.com> wrote:
>
>>> Seems that in the time bikeshedding, this could have already b= een in
>>> WGLC.=C2=A0 Outstanding work!
>> Following process and achieving consensus is not "bike sheddi= ng".
>> It's entirely inappropriate to describe it that way.
>
> i thought he was quite polite in not calling it something much stronge= r.

=C2=A0 Feel free to share your feelings.

> how many operators do we need to scream in pain that this is something=
> we do and need standardized in a simple and clear way does it take for=
> the ietf purportedly ops area wg to actually listen.=C2=A0 and folk wo= nder
> why ops walk away from the ietf in disgust?

=C2=A0 Which, of course, has nothing to do with me.=C2=A0 Since IETF 93 in = Prague, I have consistently requested that TACACS+ be documented in an info= rmational RFC.

> we know you like radius.=C2=A0 oddly, we do to, but for a different pu= rpose.

=C2=A0 Which is a non sequitur.

> tacacs+ needs to be simply, clearly, and formally documented.=C2=A0 fo= lk are
> willing to do the work.=C2=A0 this wg is for that purpose.=C2=A0 can w= e please
> move along?

=C2=A0 I've agreed with all of that.

=C2=A0 So... we both agree that it should be documented.=C2=A0 We both agre= e that people should use TACACS+.

=C2=A0 I understand that there have been a lot of messages on the topic, bu= t my position isn't that complicated.=C2=A0 Despite having a simple and= publicly stated position, I've seen enormous pushback (as here) with c= omments that are, quite frankly, irrelevant to the position I hold.

=C2=A0 If the best counter-argument to me is a straw man, I have a nice tor= ch handy.=C2=A0 It's called "reality".

=C2=A0 Alan DeKok.

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
--001a114e7e305fd9c4052bd36154-- From nobody Mon Feb 15 10:46:49 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9B61A8AF3 for ; Mon, 15 Feb 2016 10:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 3GPc3WEGpSst for ; Mon, 15 Feb 2016 10:46:47 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C6C1A8AE4 for ; Mon, 15 Feb 2016 10:46:47 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u200so121303497ywf.0 for ; Mon, 15 Feb 2016 10:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=IJF0fzGFbOmSMVwON1UQq6E6JsFwN7xGljDLKXflZis=; b=ZLmlR5F2vWkidu3W22i89the7elmxqqz9hvX9ZMREYSfTmUbIKekiHMxBPFcNWAOv9 TMD93U6bfzUnxhziLim6ShGdVji1Cvfb4CweaPY+nCkK94vyhlLlfbZAcdwtsBx1HhwF Mw/4X7SFiM+nkbE28ZNu9uhcQf+BG1+gDXVScuuTs1C9zVffU6HyrUKiP0VaMziTxtnV qKrcppg7z7s3iKcsF9xNkk+d+1IboLKbmGwpVHU+bsrApwsxmWaQ9Twohfv0cYeloo4j IuGoWvKqoKjnIQ/fmaUDf0gLaa/2vXEluQKlOhZVJ6sPASt53Wvxchq64v2J765dsng8 WTjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=IJF0fzGFbOmSMVwON1UQq6E6JsFwN7xGljDLKXflZis=; b=DnAlSCqS+ilnn44i0F1bQLc6hqQa8MAk5VQDhqugZs58Sl+OnyPeKxp9t0N15xRgFD WOdKVN31geq6odFuh3KhI2KGwA8s7WgK0W1xcMGHHBhFoPgu/NySNRjavJWlTwu3EkfR G+a74YfAjfc17uezkfG7taKcNzZlor6Yo7r+oLq5fE6ivJ3GHJVbT0ildYn9LyUUK79o Q4l2UQTEShj2+rg92g2vuFXfftM4xtjDfkneZ+IEU4hxp7i52tV1aw7FS0DYXGenfAZ8 g2ORD3osPDmjRKvQuNLhIRESD1t67nho19/a7WifPc2PT+Hq2fpPgYTul/4mhd0DuvNi 1wHg== X-Gm-Message-State: AG10YOTi6yAVTG6IYndNIFssMJAYV39NZ5kgA4SSBjFPDVQs3dNNmwvL6GaV1PDP+AqSLmLexnUQFmccHC6xLlT/ X-Received: by 10.13.231.132 with SMTP id q126mr9628559ywe.203.1455562006635; Mon, 15 Feb 2016 10:46:46 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 15 Feb 2016 18:46:37 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c088c1e5ad9e6052bd37008 Archived-At: Subject: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 18:46:48 -0000 --94eb2c088c1e5ad9e6052bd37008 Content-Type: text/plain; charset=UTF-8 Dear WG, Thanks to everyone who has been participating. It is refreshing to see this much passion and involvement in OpsAWG! We wanted to give this a bit of time to settle down, and also to see where this ended up. We are going to do a series of steps to get as clear a view of the consensus of the WG about this document. This message is a explicit call for any known IPR. We will follow up with two other messages, each with a particular question - the reason for such formality is to try to untangle the many threads that erupted on the main list. Many of you have already expressed your opinion but can you please do so again in response to the forthcoming two messages so that the record is clear. We expect to determine the path forward in 2 weeks. Are you personally aware of any IPR that applies to draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. Scott, Tianran and Warren --94eb2c088c1e5ad9e6052bd37008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear WG,

Thanks to everyone = who has been participating. It is refreshing to see this much passion and i= nvolvement in OpsAWG! We wanted to give this a bit of time to settle down, = and also to see where this ended up.

We are going = to do a series of steps to get as clear a view of the consensus of the WG a= bout this document. =C2=A0 This message is a explicit call for any known IP= R.=C2=A0

We will follow up with two =C2=A0other me= ssages, each with a particular question - the reason for such formality is = to try to untangle the many threads that erupted on the main list.

Many of you have already expressed your opinion but can yo= u please do so again in response to the forthcoming two messages so that th= e record is clear.=C2=A0 We expect to determine the path forward in 2 weeks= .

Are you personally aware of any IPR that applies= to draft-ietf-opsawg-tacacs?=C2=A0 If so, has this IPR been disclosed in c= ompliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 53= 78 for more details.)

If you are a document author= or listed contributor on this document, please reply to this email regardl= ess of whether or not you are personally aware of any relevant IPR.

Scott, Tianran and Warren
--94eb2c088c1e5ad9e6052bd37008-- From nobody Mon Feb 15 12:15:06 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D11AD21C for ; Mon, 15 Feb 2016 12:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 vgdDvUDcthEs for ; Mon, 15 Feb 2016 12:15:04 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F731AD1FE for ; Mon, 15 Feb 2016 12:15:03 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id z7so64494636yka.3 for ; Mon, 15 Feb 2016 12:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=ys/XZR+F1uNUBucLQLY2HB8yuqwHDpFCiT39vycnjWE=; b=xIaUX/w0Xxu/WnRcIliCX+SX7L/SE5PbILWybahyZ+kkHLZbAgRHLhaWizyadkeID4 mh5gajmLEWCZLbqc8d3vQ42hVVp8LuUCZmOXw+k62AS4h1QPYvQPJh7+P3zgblLq1f+G 3Vcx+fWnd6/CV1cwD3PkQ7CZte6N3+iDGFGc5HVGIGkYbhofBZJLAEGMxsCylexnN6DK 5Wm4DuxcApdZIvGTdjo4UIJ6cd9KArxK+Fxe8WZOrApn+7ll3HGAm3pMWK/t5SeTpSuP T50PdyFirBSGlcZ62w4yPD9PZnMu7myOFVjCdthKPaTsJpbjEAqTvO3FGXCuIpjGHN0V ucxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=ys/XZR+F1uNUBucLQLY2HB8yuqwHDpFCiT39vycnjWE=; b=M0ev12v0ag3VQOymCGUPWhvdD5QOspJKD02V+Aaz3DhRoOFJgQ+L3AoHls4uUoWI6s /+M5o/M+o1hgkQ8lMj5x8woyNpAirGIYgvdZ0qNvt4L0SkVgbHjX1U9f4FJoKsCcK7Hp wBpmOMvoekxqm+qKL2zx1AJnye8tHOieuy1vijDXjgEkIhitDFE+6qW+67V7kQHTn8LL q9fc8qYXBNMGTRq6VMn43O8ZYOgM5G0AAdgeHr2cth4pHfnY0JTqZ+ldIjV8NufKegAL 15XgZnHybgl0A+cXxZB9ccVmnfFihK9qNwl/Ej0b/6Y3ac5BIa15CfBsKrAi3aGzepI9 fPHg== X-Gm-Message-State: AG10YOTVIZMXVhLoCcKMhXC1yJY4EvXfPqyr5lHR90HyPfX3PNuyQqu+8EpMd5RVC44ANuNQM2nAnWf5Q/pl3QOv X-Received: by 10.37.230.210 with SMTP id d201mr10109786ybh.134.1455567303010; Mon, 15 Feb 2016 12:15:03 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 15 Feb 2016 20:14:53 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0a8b540b29cc052bd4ac5b Archived-At: Subject: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 20:15:05 -0000 --94eb2c0a8b540b29cc052bd4ac5b Content-Type: text/plain; charset=UTF-8 Dear OpsAWG: This is the second of three messages [0] to determine what the OpsAWG should do with TACACS+ Should the ID, as presented, or as revised by the WG, be published as one or more RFCs? Scott, Tianran and Warren [0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00") --94eb2c0a8b540b29cc052bd4ac5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear OpsAWG:

This is the second of= three messages [0] to determine what the OpsAWG should do with TACACS+

Should the ID, as presented, or as revised by the WG,= be published as one or more RFCs?

Scott, Tianran = and Warren

[0]: The first one was the IP= R one ( "Untangling - Explicit call for IPR on draft-ietf-opsawg-tacac= s-00")
--94eb2c0a8b540b29cc052bd4ac5b-- From nobody Mon Feb 15 12:16:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579081ACE20 for ; Mon, 15 Feb 2016 12:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 Clet79oCBP5B for ; Mon, 15 Feb 2016 12:16:40 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C221A90DC for ; Mon, 15 Feb 2016 12:16:40 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id g127so122921256ywf.2 for ; Mon, 15 Feb 2016 12:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=Mkzk0KlIikWAdOQLX3BFANex2g6UJ4EC1Z5YnDwlva0=; b=fzYC0lz+iAoO+YRhRPHn08fji6Wj5ocmhotRFvk0dTi7Jnja8p37KD1su/46nyeqax iamqOVU0bHjJbKob6iEP8I7E3+jNf1DsOsY8lB5/TaqgDNat4oSWgMdI0UZlam2v31g+ 3PnhijDvBA3/N2RqJViEctraWpTQ6g1so/26zgBf1VV0mhs91sM56cnWpLtxDAhRGdOd ZKBmS6DJQ+6QhPdHS8wOS4bfmVCo32zKOWlRMCgTnVDIS5GysK4LXy/9H/zyNpCRoxfH FhNPszdqXx9DYZzLi0p8Ld8fq+TGGrnOiWPvBkr5VGZbiSssWIylek1E/S7sxbVyH92t MlQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Mkzk0KlIikWAdOQLX3BFANex2g6UJ4EC1Z5YnDwlva0=; b=Fo0vLu3n/DKNeEWA68d3e1K21bsasX36IUd5zU/ehp4o/oRKXMz8xO68Bj9w/d1Fkp 26l/sRy8v9wdI0dVz4iZUYja78cFogm3dgm8VF6jkd2Onwq7UmA26L3FBNb/eNrRJEg2 gj8DdjyIWLfq87q0etycZVYZ1wXG0mD1y23CgSW+fW1W35hjIedzhfokRLg3ZSVGXDyh gLgUtS2kIiM3KNyw7O8yprgtGjr5kcPi1QRaOA5skCSw44mVBNntdxvALN5UlLJ5ouV9 B2T1WQ4Z5iGVCVLiKbauNG3rLOrLnPqpZVC4AhuHTiZwyCJWiCPm2/3IpaCBuADpqb1m tYvg== X-Gm-Message-State: AG10YOSL72X7n0Qz2RIvmOlbpGwke9lPV4F7R2+USIEBRyBFP0smtRKldAx6C9cH4pyjvNKRuIVgZYIFfTsGCr2M X-Received: by 10.13.210.67 with SMTP id u64mr9759068ywd.42.1455567399868; Mon, 15 Feb 2016 12:16:39 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 15 Feb 2016 20:16:29 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a114e7e30d112c0052bd4b18e Archived-At: Subject: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 20:16:41 -0000 --001a114e7e30d112c0052bd4b18e Content-Type: text/plain; charset=UTF-8 This is the third of 3 messages to determine what the OpsAWG should do with TACACS+. If the answer to the previous question is yes, should the RFC describing the protocol itself (as opposed to any other document that might describe appropriate use) be published as a standards track RFC? Scott, Tianran and Warren --001a114e7e30d112c0052bd4b18e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is the third of 3 messages to determine what the= OpsAWG should do with TACACS+.

If the answer to t= he previous question is yes, should the RFC describing the protocol itself = (as opposed to any other document that might describe appropriate use) be p= ublished as a standards track RFC?

Scott, Tian= ran and Warren
--001a114e7e30d112c0052bd4b18e-- From nobody Mon Feb 15 12:37:11 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557421A8A08 for ; Mon, 15 Feb 2016 12:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 esHkQ85HbANT for ; Mon, 15 Feb 2016 12:37:09 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390611A8946 for ; Mon, 15 Feb 2016 12:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=516; q=dns/txt; s=iport; t=1455568629; x=1456778229; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ATN66GB7cybfLtYoJG3yGJx9aQoz/oGs96tzXWJqAcc=; b=iMSKT6WWr29/Z/Zn/VqaJRWqK/42fstxVaotPoZnZwd/Sd1fGKRXhB9G ltiQ5NRY5e1H+Os+IAEKO0rDUUAIOnCvA2z34l1RxHsF1ahgIgH1mcjvJ oE22L/1llhpAjiJJf/Vxi7svJJEZOfg516i26TiGBKDJvXuSXOymhw3b9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAgARNsJW/4sNJK1dgzq0O4UNghMBD?= =?us-ascii?q?YFnhg0CgTg4FAEBAQEBAQGBCoRCAQEEOEARCxgJFg8JAwIBAgFFBgEMCAEBiBa?= =?us-ascii?q?3IgEBAQEBAQEBAQEBAQEBAQEBGYYRhDWIbAEEjhuIXo1ViSKFUo4+HgEBQoQBH?= =?us-ascii?q?oh9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,452,1449532800"; d="scan'208";a="236928146" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2016 20:37:08 +0000 Received: from [10.82.246.55] (rtp-vpn2-1589.cisco.com [10.82.246.55]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1FKb7ZD013337; Mon, 15 Feb 2016 20:37:07 GMT To: Warren Kumari , "opsawg@ietf.org" References: From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <56C236F3.4030706@cisco.com> Date: Mon, 15 Feb 2016 15:37:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 20:37:10 -0000 On 2/15/16 15:14, Warren Kumari wrote: > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG > should do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as > one or more RFCs? I like the idea of documenting TACACS+ the way it is today as its own informational RFC. I also agree that extending it with the additional security measures is good, and separating any enhancements out into separate working items makes sense. Joe From nobody Mon Feb 15 12:39:50 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DED71ACEAF for ; Mon, 15 Feb 2016 12:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 E9eVN6usPL2Z for ; Mon, 15 Feb 2016 12:39:47 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DEE1ACE98 for ; Mon, 15 Feb 2016 12:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=633; q=dns/txt; s=iport; t=1455568787; x=1456778387; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=CR76ZSVF0F/m7nRuWZ/VxFNpodna8CR36ImyZzVukSs=; b=hYb11c0tUKenl1PBot1PKOD1BH7vp0Ec2Xh39xdFGWsz2YTqfRMrdQuC ujq0cqAXnuxkfH6HSxOy1an/ro9eJQHHjjBEXZii07759T5zSm6iGnZ5T ZBhGPyrro/e6yf45O1XSxbbPxaiow03kf78epDUeI4ednYCqWonG0AdXw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAgAgN8JW/5hdJa1dgzq0O4UNghMBD?= =?us-ascii?q?YFnhg0CgTg4FAEBAQEBAQGBCoRCAQEEOEARCxgJFg8JAwIBAgFFBgEMCAEBiBa?= =?us-ascii?q?3IwEBAQEBAQEBAQEBAQEBAQEBGYYRhDWIbAEEjhuIXo1ViSKFUo4+HgEBQoQBH?= =?us-ascii?q?oh9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,452,1449532800"; d="scan'208";a="236928665" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2016 20:39:46 +0000 Received: from [10.82.246.55] (rtp-vpn2-1589.cisco.com [10.82.246.55]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1FKdjWK000702; Mon, 15 Feb 2016 20:39:46 GMT To: Warren Kumari , "opsawg@ietf.org" References: From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <56C23791.4040600@cisco.com> Date: Mon, 15 Feb 2016 15:39:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 20:39:48 -0000 On 2/15/16 15:16, Warren Kumari wrote: > This is the third of 3 messages to determine what the OpsAWG should do > with TACACS+. > > If the answer to the previous question is yes, should the RFC describing > the protocol itself (as opposed to any other document that might > describe appropriate use) be published as a standards track RFC? I would rather see it be a standard, but I would be perfectly happy to see it published, in the current implementation, as an informational RFC (as stated in my previous answer). In either event, I feel this work should continue, especially the security enhancements. Joe From nobody Mon Feb 15 13:00:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4E1B2A79 for ; Mon, 15 Feb 2016 13:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3lCO0gE7dT7f for ; Mon, 15 Feb 2016 13:00:18 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3864F1B2A7C for ; Mon, 15 Feb 2016 13:00:15 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id g127so123740893ywf.2 for ; Mon, 15 Feb 2016 13:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-type; bh=7eiJjhV0iNlGKk3FEk5d+/sDbog+dtVCMVDDpy8714Y=; b=FVgrXFJ8DosJ0rIaPOMhffgfTIZoh4E6xP+Bxvy9tEj8gmU5EFup3c1S2ETcoBAZ+a /mQWIvY/3wGegWEUBPHN6ejnpXuAyM+XkP6d26v4T44kfkCH5qvfjW/9Q8M1DPZ0L9uQ Yq8rRWW27jb/C3zZScmRa2BBKSIJe0v7ZscWwmMfuQ6N3Hg598z+e6pmoQ7Cc2Xi7Hgo gbsth6UtpVL00ZDgfH4UpkJCUXU0jsqCcXsA/oeoYTnhK/cZYNETLa2L9ZfNvhwWV9RC UEa6z5uGnmq1aztZ8d8FAZ4RoGbpW6kBHsiLl8JU2V8VKIDtDpm2XpDRBFpKv5UoQ+kZ 6CbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type; bh=7eiJjhV0iNlGKk3FEk5d+/sDbog+dtVCMVDDpy8714Y=; b=NRWQRP1frnOtHQL1J5GZe85if+0oGLgD4vg6SI5laLNK5vONsjnmXLF0ONmB1YRUmE 0cRXKf8NrAZ7D1kdNlN0wqNyZinX22GT2cyIb8ZgdGjPyUCgiXNfG2Yzn+Np2ogsQPW7 HzKXYZoFMSU2WVp5iwEiDEBs6+un9jeuzevdAxRMH0P4NqyRgwdyFYtLeja9z/5uX87c Tk3hNWkohAIUqGniFDfv+/BVH5MbPxmd391z4PhBX6oJ6wL8L07GwAh/IBSNznDw/eyP T3B9Uml9I/jn6Bztd/H2RktYglv3aP0aCU6H9s5hNWa9VurKSlLUlt2r+V6nxTJp8FNY +/IQ== X-Gm-Message-State: AG10YOSsVHM5RfLrl4ML31feFUaj6SYip/05qqf+SU9sPE169xcT0+sbFHwEEoz5051L3Q== X-Received: by 10.13.240.194 with SMTP id z185mr10031119ywe.317.1455570014437; Mon, 15 Feb 2016 13:00:14 -0800 (PST) Received: from [192.168.0.170] (rrcs-97-76-236-4.se.biz.rr.com. [97.76.236.4]) by smtp.gmail.com with ESMTPSA id j198sm21931367ywg.16.2016.02.15.13.00.10 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 15 Feb 2016 13:00:13 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Mon, 15 Feb 2016 16:00:04 -0800 From: Edwin Mallette To: Warren Kumari , "opsawg@ietf.org" Message-ID: Thread-Topic: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3538396813_13535740" Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 21:00:20 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3538396813_13535740 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Yes. From: OPSAWG on behalf of Warren Kumari Date: Monday, February 15, 2016 at 12:14 PM To: "opsawg@ietf.org" Subject: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? Dear OpsAWG: This is the second of three messages [0] to determine what the OpsAWG should do with TACACS+ Should the ID, as presented, or as revised by the WG, be published as one or more RFCs? Scott, Tianran and Warren [0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00") _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --B_3538396813_13535740 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Yes.

From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Warren Kumari <= ;warren@kumari.net>
Date: Monday, February 15, 2016 at 12:14 PM
<= span style=3D"font-weight:bold">To: "= opsawg@ietf.org" <opsawg@ietf.org>
Subject: [OPSAWG] Detangling= - Q2: Publish TACACS+ as a RFC?

Dear= OpsAWG:

This is the second of three messages [0] to= determine what the OpsAWG should do with TACACS+

S= hould the ID, as presented, or as revised by the WG, be published as one or = more RFCs?

Scott, Tianran and Warren

[0]: The first one was the IPR one ( "Untangling - Expl= icit call for IPR on draft-ietf-opsawg-tacacs-00")
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org= /mailman/listinfo/opsawg --B_3538396813_13535740-- From nobody Mon Feb 15 13:00:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242171B2A8F for ; Mon, 15 Feb 2016 13:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham 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 mcME4tbt8UAE for ; Mon, 15 Feb 2016 13:00:38 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBD61B2A87 for ; Mon, 15 Feb 2016 13:00:38 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id r207so65312768ykd.2 for ; Mon, 15 Feb 2016 13:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-type; bh=cxloYUlEm2dyQtO+E0oGtiIdNDit6San1ebR+T9Hmk4=; b=HIdwWX+0JX5u8ayWMqvBcVW9S/wRGcvHNJyUedLkATUCD3Au7uMzR5bN1k1s4bnKqd FJbWSu4UPdQbjWrZoaZEN45YSdffZa7Hjd54CSh8jroWbI+A8C+nwHmoe5tWC8roPfPN ajzn+aagYaVvu5szc4HkMR4VHNja1ad2ctL1JVdhShZkYd4rA47R0TS9EEF6ie1z8QP6 QaYF8syBqvITtmL7cYcmdmBXKvayKE+HctuMquha3A2bAmJnYN4mArzkOKYN2G/g8wx4 TpiiMwNFdUw3xOIPG2nf12ceGub4ZqukIWFnbkuHZ45RopeMXB4vbRF+uoL4C55eOYY/ sMcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type; bh=cxloYUlEm2dyQtO+E0oGtiIdNDit6San1ebR+T9Hmk4=; b=ad/qVlaPIe+4Dm/MaPRqD34KDBbnG5YQ7AzTBM820K5VrXAfe6dT9Gk0cCgrBBEZPl ISoKqcMXFguYoEatN5zr9ncEdWv/pzoAqkXh+CQetmF5u+oA734OxieAGE1ItBAUq6k6 vbW+0M0o4oJkgLjqVoGnE9i5IXc67c2UHnb4FsD+Ouhlsnlrvp+hdKVTnjhsjfNNi9hq eHAXVw/Wtt1DjiTJQHAtyo5leewFdczG5QYv2ECJmnXSuUm9hqiUypLzD97prRoTmLrE 2JeaMN5TuHn4wq2Pir55Z5EzI3lKpRUqIitGeLuP1vAmRKlZN1zw5SURHJfhxjjMGvyn uwvA== X-Gm-Message-State: AG10YOQa9WyZ6CYllNlva3OyitJPyJRdmEtzrbSwnLd31flLvavgzTgSu6YdARfCJOg+dw== X-Received: by 10.37.231.10 with SMTP id e10mr9824022ybh.140.1455570037930; Mon, 15 Feb 2016 13:00:37 -0800 (PST) Received: from [192.168.0.170] (rrcs-97-76-236-4.se.biz.rr.com. [97.76.236.4]) by smtp.gmail.com with ESMTPSA id p189sm21956775ywc.9.2016.02.15.13.00.35 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 15 Feb 2016 13:00:37 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Mon, 15 Feb 2016 16:00:29 -0800 From: Edwin Mallette To: Warren Kumari , "opsawg@ietf.org" Message-ID: Thread-Topic: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3538396837_13549720" Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 21:00:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3538396837_13549720 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Yes. From: OPSAWG on behalf of Warren Kumari Date: Monday, February 15, 2016 at 12:16 PM To: "opsawg@ietf.org" Subject: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? This is the third of 3 messages to determine what the OpsAWG should do with TACACS+. If the answer to the previous question is yes, should the RFC describing the protocol itself (as opposed to any other document that might describe appropriate use) be published as a standards track RFC? Scott, Tianran and Warren _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --B_3538396837_13549720 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Yes.

From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Warren Kumari <= ;warren@kumari.net>
Date: Monday, February 15, 2016 at 12:16 PM
<= span style=3D"font-weight:bold">To: "= opsawg@ietf.org" <opsawg@ietf.org>
Subject: [OPSAWG] Detangling= - Q3: Publish TACACS+ as a standards track RFC?

This is the third of 3 messages to determine what the OpsAW= G should do with TACACS+.

If the answer to the prev= ious question is yes, should the RFC describing the protocol itself (as oppo= sed to any other document that might describe appropriate use) be published = as a standards track RFC?

Scott, Tianran and Wa= rren
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org= /mailman/listinfo/opsawg --B_3538396837_13549720-- From nobody Mon Feb 15 13:02:38 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2293C1B2A95 for ; Mon, 15 Feb 2016 13:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 L3VNlRObWkT3 for ; Mon, 15 Feb 2016 13:02:35 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9499C1B2A97 for ; Mon, 15 Feb 2016 13:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2612; q=dns/txt; s=iport; t=1455570154; x=1456779754; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=B2/rti0gpSOGupQ4WF2M0z1A48lLTlaWTxC8sU+5t0A=; b=Rsw72U+uFX1Iq5CyXPqol6OTyfayU7OYGSbjAzrKijdTJdNy4I1s4q8g 8LJQL1H74Yc84qgInriu+MM32s57H0LPrX6UnJN/HleA6vEJmHkficBt1 8fDlXH14vnKOYFhNUlpQCHqKgkrxr9uPvRfopb8/YHDozS5849slVof9X I=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgCbPMJW/xbLJq1evQKCEw6BZ4YNA?= =?us-ascii?q?oFwFAEBAQEBAQGBCoQ4CgEBBCNVEQsDARQJFgsCAgkDAgECAUUGAQwIAQGIFqh?= =?us-ascii?q?GjmYBAQEBAQEBAwEBAQEBAQEBEAiKRocygToBBJZ5gwGBZIhwiSKFUo4+HgFDg?= =?us-ascii?q?2Q7iH0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,452,1449532800"; d="asc'?scan'208,217";a="632675450" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2016 21:02:32 +0000 Received: from [10.61.80.74] (ams3-vpn-dhcp4171.cisco.com [10.61.80.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1FL2WnJ004625; Mon, 15 Feb 2016 21:02:32 GMT To: Warren Kumari , "opsawg@ietf.org" References: From: Eliot Lear Message-ID: <56C23CE7.6080107@cisco.com> Date: Mon, 15 Feb 2016 22:02:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f4kTUU1nCVElfAMiw60AKJ0vtDomdgHp8" Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 21:02:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f4kTUU1nCVElfAMiw60AKJ0vtDomdgHp8 Content-Type: multipart/alternative; boundary="------------020002030100030106020305" This is a multi-part message in MIME format. --------------020002030100030106020305 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/15/16 9:14 PM, Warren Kumari wrote: > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG > should do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as > one or more RFCs? Yes, for reasons previously stated. Eliot --------------020002030100030106020305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 2/15/16 9:14 PM, Warren Kumari wrote:
Dear OpsAWG:

This is the second of three messages [0] to determine what the OpsAWG should do with TACACS+

Should the ID, as presented, or as revised by the WG, be published as one or more RFCs?

Yes, for reasons previously stated.

Eliot

--------------020002030100030106020305-- --f4kTUU1nCVElfAMiw60AKJ0vtDomdgHp8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWwjzoAAoJEIe2a0bZ0nozHFMH/3QnnK+HfM0hUwKih3m3QpBw tZUl0Z4h9aQnCar7luJ+ctBQgHLixH0J3hymyfRg4LkGH+KTpuGEyuuuXrg1ewm4 QPu45w6cQ/Tq2jUuJsJ9dS1SKf4bmADPLGRzp9WndZjF1irykohKvmDYrsPDi9Zn 3Q8v9YETaTqqE4/lhFP+TnxOw2tA0YjVKbn578TzPsp2wyMm65dxPv8u9iSmXVLs Ovan1xWPrB80ZvbH5bQrXjIP/wx2VMam91Q+SVTbGWqXA8zp4X8Y1kNmeZC53mst sKtPlNU4dXQo7uQ9Ua0LWhD+uWfUArTzHGeu//eP7/IgYN/nW4+5K9M1f03O6QY= =J22U -----END PGP SIGNATURE----- --f4kTUU1nCVElfAMiw60AKJ0vtDomdgHp8-- From nobody Mon Feb 15 14:34:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F2A1A1A4C for ; Mon, 15 Feb 2016 14:34:03 -0800 (PST) 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] autolearn=ham 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 eBPkUFnZ4LMC for ; Mon, 15 Feb 2016 14:34:01 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CE0921A1A3D for ; Mon, 15 Feb 2016 14:34:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E7328D13; Mon, 15 Feb 2016 22:33:59 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e_ObL6mkrdf; Mon, 15 Feb 2016 22:33:59 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 63EB8BD8; Mon, 15 Feb 2016 22:33:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Mon, 15 Feb 2016 17:33:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4E9C5B7E-D3B6-4119-ACAA-601CBC0C3492@deployingradius.com> References: To: "Bradner, Scott" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 22:34:03 -0000 Some corrections. On Feb 12, 2016, at 11:46 AM, Bradner, Scott wrote: > The topics of the appeal and other messages from Mr. DeKok included: > 1/ The adoption of the TACACS+ Internet Draft as a working group item. My appeal concerned the *process* of adoption as a WG item. > 2/ The appropriateness of publishing the TACACS+ Internet Draft as > a RFC through the IETF track. My comments at the time of the appeal show that I support publishing = historical TACACS+ protocol as an informational RFC, via the OPSAWG > 3/ The appropriateness of publishing the TACACS+ Internet Draft as > a standards track RFC. My comments at the time of the appeal show that I support publishing = the *changed* (i.e. future) TACACS+ as a standards track RFC. I do not support publishing the historical TACACS+ protocol as a = standards track RFC. > 20 July 2015: The ops area session was held. The TACACS+ slides used > during the session are at:=20 > https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf >=20 > Minutes of the session are quite sparse. They note that the = presentation > occurred and that Alan DeKok objected to the proposal. I don't see copy of the minutes on the WG mailing list archives. They = aren't on the WG page at: https://datatracker.ietf.org/wg/opsawg/meetings/ Alan DeKok. From nobody Mon Feb 15 14:37:56 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0061A0406 for ; Mon, 15 Feb 2016 14:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham 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 yxJ_lLH7VoPY for ; Mon, 15 Feb 2016 14:37:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1FE1A03ED for ; Mon, 15 Feb 2016 14:37:52 -0800 (PST) Received: from DM2PR07MB397.namprd07.prod.outlook.com (10.141.104.15) by DM2PR07MB400.namprd07.prod.outlook.com (10.141.104.17) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 15 Feb 2016 22:37:35 +0000 Received: from DM2PR07MB397.namprd07.prod.outlook.com ([169.254.11.31]) by DM2PR07MB397.namprd07.prod.outlook.com ([169.254.11.31]) with mapi id 15.01.0409.017; Mon, 15 Feb 2016 22:37:35 +0000 From: "Bradner, Scott" To: Alan DeKok Thread-Topic: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic Thread-Index: AQHRZbTdsu3rDjDDYkeKTAvH1Vz5zA== Date: Mon, 15 Feb 2016 22:37:34 +0000 Message-ID: <779E4D5E-0F84-4B0B-B3EF-1A5A50106817@harvard.edu> References: <4E9C5B7E-D3B6-4119-ACAA-601CBC0C3492@deployingradius.com> In-Reply-To: <4E9C5B7E-D3B6-4119-ACAA-601CBC0C3492@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=harvard.edu; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.166.5.69] x-microsoft-exchange-diagnostics: 1; DM2PR07MB400; 5:W6K2B4afhUOb9D4terKP0xM+4D+BaIq6R7MYpMjUGm7iAwhayRLkeBNBKTbAvofxGTuAksv2Ld9lJd2NwkdCI2UJWypFdxyn9wQ0DP3CyHH3vT1zWCVPVA0FhvMt/qtMdZUHlM5VjRrBHQU55amucQ==; 24:J/tGI/c9EpxbpQ4C314XAj3E7y6llpwNTLB/3YxFHYAJRguaGVSiHh5zjF3NbEcAUZt+vMvqU1qhoH+98x/a56uOAr9a1Su4b62tOX3eGCM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR07MB400; x-ms-office365-filtering-correlation-id: d2bf132e-d913-479e-9474-08d33658998d x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35762410373642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM2PR07MB400; BCL:0; PCL:0; RULEID:; SRVR:DM2PR07MB400; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(2950100001)(92566002)(4326007)(2900100001)(1220700001)(11100500001)(40100003)(5001960100002)(66066001)(88552002)(586003)(1096002)(5008740100001)(6116002)(110136002)(87936001)(3280700002)(102836003)(189998001)(3846002)(3660700001)(36756003)(83716003)(19580405001)(5002640100001)(10400500002)(5004730100002)(19580395003)(86362001)(54356999)(76176999)(50986999)(230783001)(561944003)(33656002)(2906002)(122556002)(99286002)(106116001)(90282001)(82746002)(75432002)(89122001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR07MB400; H:DM2PR07MB397.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <59ED708E27AB6C4FBC373DC31F8B08D8@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2016 22:37:34.9026 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR07MB400 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 22:37:55 -0000 the minutes (such as they are) are included in the proceedings https://www.ietf.org/proceedings/93/minutes/minutes-93-opsarea Scott > On Feb 15, 2016, at 5:33 PM, Alan DeKok wrote= : >=20 > Some corrections. >=20 > On Feb 12, 2016, at 11:46 AM, Bradner, Scott wrote: >> The topics of the appeal and other messages from Mr. DeKok included: >> 1/ The adoption of the TACACS+ Internet Draft as a working group item. >=20 > My appeal concerned the *process* of adoption as a WG item. >=20 >> 2/ The appropriateness of publishing the TACACS+ Internet Draft as >> a RFC through the IETF track. >=20 > My comments at the time of the appeal show that I support publishing his= torical TACACS+ protocol as an informational RFC, via the OPSAWG >=20 >> 3/ The appropriateness of publishing the TACACS+ Internet Draft as >> a standards track RFC. >=20 > My comments at the time of the appeal show that I support publishing th= e *changed* (i.e. future) TACACS+ as a standards track RFC. >=20 > I do not support publishing the historical TACACS+ protocol as a standar= ds track RFC. >=20 >> 20 July 2015: The ops area session was held. The TACACS+ slides used >> during the session are at:=20 >> https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf >>=20 >> Minutes of the session are quite sparse. They note that the presentatio= n >> occurred and that Alan DeKok objected to the proposal. >=20 > I don't see copy of the minutes on the WG mailing list archives. They a= ren't on the WG page at: >=20 > https://datatracker.ietf.org/wg/opsawg/meetings/ >=20 > Alan DeKok. >=20 From nobody Mon Feb 15 15:07:18 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1AB1A1B49 for ; Mon, 15 Feb 2016 15:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 Ol75x5txWCug for ; Mon, 15 Feb 2016 15:07:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2A11A1B2D for ; Mon, 15 Feb 2016 15:07:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aVSEa-000327-S9; Mon, 15 Feb 2016 23:07:13 +0000 Date: Tue, 16 Feb 2016 12:07:11 +1300 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:07:16 -0000 > Should the ID, as presented, or as revised by the WG, be published as one > or more RFCs? tacacs+ as we know and use it today should be ps today future work good and should be encouraged. randy From nobody Mon Feb 15 15:08:14 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA981A1BAC for ; Mon, 15 Feb 2016 15:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 Sn9hEEA539yG for ; Mon, 15 Feb 2016 15:08:12 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402631A1B9A for ; Mon, 15 Feb 2016 15:08:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aVSFX-00032m-5a; Mon, 15 Feb 2016 23:08:11 +0000 Date: Tue, 16 Feb 2016 12:08:09 +1300 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:08:13 -0000 > If the answer to the previous question is yes, should the RFC > describing the protocol itself (as opposed to any other document that > might describe appropriate use) be published as a standards track RFC? it is a deployed and widely used protocol. this question is silly. of course it should be standards track. randy From nobody Mon Feb 15 15:16:40 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B76C1A6EE0 for ; Mon, 15 Feb 2016 15:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 TPrWtNo4ivB5 for ; Mon, 15 Feb 2016 15:16:34 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0078.outbound.protection.outlook.com [65.55.169.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C68D1A010C for ; Mon, 15 Feb 2016 15:16:34 -0800 (PST) Received: from DM2PR07MB397.namprd07.prod.outlook.com (10.141.104.15) by DM2PR07MB399.namprd07.prod.outlook.com (10.141.104.27) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 15 Feb 2016 23:16:32 +0000 Received: from DM2PR07MB397.namprd07.prod.outlook.com ([169.254.11.31]) by DM2PR07MB397.namprd07.prod.outlook.com ([169.254.11.31]) with mapi id 15.01.0409.017; Mon, 15 Feb 2016 23:16:32 +0000 From: "Bradner, Scott" To: Alan DeKok Thread-Topic: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic Thread-Index: AQHRZbTdsu3rDjDDYkeKTAvH1Vz5zA== Date: Mon, 15 Feb 2016 23:16:32 +0000 Message-ID: References: <4E9C5B7E-D3B6-4119-ACAA-601CBC0C3492@deployingradius.com> In-Reply-To: <4E9C5B7E-D3B6-4119-ACAA-601CBC0C3492@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=harvard.edu; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:184:4601:8bf0:5d2:be6c:85b5:6b31] x-microsoft-exchange-diagnostics: 1; DM2PR07MB399; 5:Xlhnmr4IUNmMKea+Kpgjx1ubNcjagnvumfLfx5rlioO6DSzkKBQmtlmZsNpLYMuk69cQNvuLoaIl8VaSnytqDiL1/PuqnAqcul/QlhP9UiIDxLHM/YdSZWWBInEQ/h/uDyxShqMmOVgQLPy+KIYtUA==; 24:T0DSEemy0jxhlWOHsr1J6dVwUvm2FGgZpGXSGTGFvFfIEtwXsD7epLBd574RbT9r4fNTfSuHePR3o+j8i9cbfH5dg5HGPAnS7+NjIXbwDm0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR07MB399; x-ms-office365-filtering-correlation-id: 98efce51-6689-4450-88b0-08d3365e0ab1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35762410373642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM2PR07MB399; BCL:0; PCL:0; RULEID:; SRVR:DM2PR07MB399; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(122556002)(102836003)(586003)(6116002)(87936001)(5008740100001)(1220700001)(1096002)(11100500001)(36756003)(89122001)(3660700001)(106116001)(33656002)(99286002)(40100003)(3280700002)(75432002)(88552002)(5004730100002)(2900100001)(5002640100001)(2950100001)(189998001)(82746002)(92566002)(50986999)(54356999)(76176999)(19580405001)(19580395003)(561944003)(4326007)(10400500002)(230783001)(83716003)(5001960100002)(110136002)(90282001)(86362001)(2906002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR07MB399; H:DM2PR07MB397.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2016 23:16:32.2044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR07MB399 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:16:38 -0000 ps - the session was in the ops area meeting, which is why the minutes are = not on the opsawg list Scott > On Feb 15, 2016, at 5:33 PM, Alan DeKok wrote= : >=20 > Some corrections. >=20 > On Feb 12, 2016, at 11:46 AM, Bradner, Scott wrote: >> The topics of the appeal and other messages from Mr. DeKok included: >> 1/ The adoption of the TACACS+ Internet Draft as a working group item. >=20 > My appeal concerned the *process* of adoption as a WG item. >=20 >> 2/ The appropriateness of publishing the TACACS+ Internet Draft as >> a RFC through the IETF track. >=20 > My comments at the time of the appeal show that I support publishing his= torical TACACS+ protocol as an informational RFC, via the OPSAWG >=20 >> 3/ The appropriateness of publishing the TACACS+ Internet Draft as >> a standards track RFC. >=20 > My comments at the time of the appeal show that I support publishing th= e *changed* (i.e. future) TACACS+ as a standards track RFC. >=20 > I do not support publishing the historical TACACS+ protocol as a standar= ds track RFC. >=20 >> 20 July 2015: The ops area session was held. The TACACS+ slides used >> during the session are at:=20 >> https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf >>=20 >> Minutes of the session are quite sparse. They note that the presentatio= n >> occurred and that Alan DeKok objected to the proposal. >=20 > I don't see copy of the minutes on the WG mailing list archives. They a= ren't on the WG page at: >=20 > https://datatracker.ietf.org/wg/opsawg/meetings/ >=20 > Alan DeKok. >=20 From nobody Mon Feb 15 16:37:38 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1701A89A5 for ; Mon, 15 Feb 2016 16:37:35 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 a44RzoPlAdBe for ; Mon, 15 Feb 2016 16:37:28 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0695.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::695]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2D21A8892 for ; Mon, 15 Feb 2016 16:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=direcpathcorp.onmicrosoft.com; s=selector1-direcpath-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j1vJFMuEsm1nB5he5DabPYYCrkePUE4RPUza8gNqsWw=; b=MYuchH/ygbTIV2hv//yVT0+XmTUiJZ22JGH+cZUOCivbWz5fWCVVrGuhl9KwOFQ7mLYsntYCEAHUtevXLynPusnnSC8gB0MINOweEx6m4x5dPidz+IHWoYncGCWDnOa/vrmAvm55tI62g4pMsGcfjSm/hHa2nVq4ZDFcl8BDcRY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=direcpath.com; Received: from [10.6.2.149] (24.98.60.52) by BY2PR01MB1719.prod.exchangelabs.com (10.163.26.145) with Microsoft SMTP Server (TLS) id 15.1.409.10; Tue, 16 Feb 2016 00:37:11 +0000 To: References: From: Robert Drake Message-ID: <64d27e00-62eb-2343-204e-6ddfc1313618@direcpath.com> Date: Mon, 15 Feb 2016 19:37:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D6AE1E666FD9B61332189544" X-Originating-IP: [24.98.60.52] X-ClientProxiedBy: BN1PR02CA0046.namprd02.prod.outlook.com (10.141.56.46) To BY2PR01MB1719.prod.exchangelabs.com (25.163.26.145) X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 2:Cs/lr2toIRAhU41cIV6UYhdHwKjuV6iYkUPVPCDZA/s/FzrHeRYNamlepQx/77pnZTd6eLA95o+oRZixLmCW6DkUTp5Vx90hG4LGIDl36jIwQ+KwYmh8FWcexmZ6/wSAWKr8mORqLK40dnbhP2oaYw==; 3:BU4ZqAiqNH6vsO6VFvQ4KP+1WXQ3wQrmUHnsNgGgEQxX/lf8oPCWymIYMzYYAxlUjTnFefuss9x7um+w09nlQSgR9CDpPEGNq4DNe26c4Dq5pHhXBejD2+etyqdwHH/K; 25:lnoknzAJbOFrPr1pSYEdhRavh9Rhs+UG9EgXZOOt7s4Z36tjD7ivChizjhQAW5PdWRGm3RYbrjlFFealHKXswkrUWKQ7ZODCZKxaMBawvqe7SP87VyW9lhZDDN05sgeJVu4DQpPmbYYi9xt5/Z8YJpCk3fz0ivd34xyjW4e1BZvxqD5kqztdMYZgPWH47dblY1PX05nMgcKPzWuOtzKOIBC/7nytLh7ZMekMdQtiOfUjzAKv70O9SNT22T8g75Ecx1Pgf9vi30GM6VPK8+KGCbDNADT54wvAXIHPcS4hXWL6R+i4dm4w4uYbeaCrYWoX; 4:HcLEJiMn3jfimex0Aa9KtcflujrCpquD4rYiC85Wz7HhX7PEt1vV4CbmO0TZdDdMjvS3trbWfYlboo4x35W/v4woxbe5daYEs5QMXGyIcSd5s8iz962wvYmfmNTSHRpGmGhsPaOqS/+KhcNi0RSsLF02hs3N3b8Tz+z+JKEkn736xNtOA+7RtyJ/DpbXuhciP7Eyw5Wjf8opdxnaj9buv+AT0U3pnpdilmVhTVxNdIZUWuIGhNbsDtp3/7STs0UWvTOLABH39lm+9441crNdAntBw/R+lnaKiV2JIbaQmCHlxJ+yWacvKMZlrW9hyfdYj058MscKQL8WbIpv6nxQYtNfVnvSKh+YajNd0SVbphU= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR01MB1719; X-MS-Office365-Filtering-Correlation-Id: e0fdf8ac-6e07-4add-e543-08d336694eeb X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR01MB1719; BCL:0; PCL:0; RULEID:; SRVR:BY2PR01MB1719; X-Forefront-PRVS: 0854128AF0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(377454003)(479174004)(24454002)(2351001)(50986999)(16236675004)(84326002)(122386002)(77096005)(19617315012)(92566002)(42186005)(66066001)(450100001)(15975445007)(36756003)(40100003)(65956001)(83506001)(31686004)(76176999)(54356999)(110136002)(86362001)(87976001)(107886002)(189998001)(5001960100002)(4001350100001)(3846002)(19580405001)(19580395003)(6116002)(65806001)(1096002)(5008740100001)(2906002)(33646002)(2950100001)(270700001)(586003)(512944002)(65826006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR01MB1719; H:[10.6.2.149]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR01MB1719; 23:QEEhf7vUOL9StgyzGdEva0U7quMLZlfSe0diPQBfh?= =?us-ascii?Q?27z3HFrdzyr35a+Om2BvN0gSvVCk2Xufcj93Le6992Qw4gxmco2gLvm1+3gw?= =?us-ascii?Q?qFHcWDEBgeTL0AAnCJ1qziKdLw94oponxcNtn2+u4jjKkSUH6XjHzov+izEK?= =?us-ascii?Q?5p+0kCoga6K6gVIKU8qUWAKNHwLNirwVXa4Y7Y3VF8XwB4hOWWfkXrbCjydc?= =?us-ascii?Q?nL6AhPkavm6WExgtDmYS0Re4BRTzpFdmzNesD2BklKOIsJ+IieefBDtY8oVK?= =?us-ascii?Q?JV2eqks44LB4QOkyi8lb7OH0YMqC8tlM5Vayk3v09tLLP5hFOcx7LCZDKCpW?= =?us-ascii?Q?uQzlKWs8S0/IASkyx6eAJiQEegW66+DDnOUcw86T1jJ3wgGN+aLDFHRXuxbY?= =?us-ascii?Q?tn6lsK5dPB/CcO/mXRzhbz8IC2d460JaEO+KDRDpL0iYKf8RhURPEc4HnUtQ?= =?us-ascii?Q?W8ZmmwtYpzyJUB/a8enbUUlww9oxyn6aXKZ8NqRdQtRWrxLK1rsWBavtLmc0?= =?us-ascii?Q?Ap3i/mqkIjF2F1SBn5E7KEHO56wy2Xx8S3HmsG69J5z5yua0HkNAaP6bugpw?= =?us-ascii?Q?isrqxFa4TzSWm6a6JmPu0xx0OZh0QDVKwy3NGIX7DEtS0l+u3JRNxVG9sCdU?= =?us-ascii?Q?RQJSYQtwIXpg3UmYsGduMsW192sipQEXeBdMAeVgWWi9WQw6oZotNOChOuTJ?= =?us-ascii?Q?dxAoPua/gN5cSPsaRetm7W9nq0mK6bIak4cP4s7tN2/naHmd3n85uNJRmuQQ?= =?us-ascii?Q?/j9pj87VamIq6PsSjNr49T97d1GWRlujg/VOy4jwv/lnIv62/ECJm8g07Uix?= =?us-ascii?Q?2wuq5tpk4BBc91gVSqnjYFmSYRjV/HivU60WRDVs7IP2skMqe+zUdHxIutJw?= =?us-ascii?Q?inE49JdKPcWwIEi5efu8ksF4na1dEaqOb6OfvbntTLARKs+0RlF64ixhuUHe?= =?us-ascii?Q?ML13tDXj+yOOgyTlYUD16R/Pf7VvmgmBbGco50piyjMVjFxC2k1/u6OxtkN8?= =?us-ascii?Q?Pbesihu7GkrviJPxOKJod1rHabsWz5ebsOCWX1jeLOyM32S21EXXtlylOkCW?= =?us-ascii?Q?gK+gHjVOoyPlpypuPq9oE2jRFZcgviC1iSGEs8NVKxG2BQ+hKj0x33wmFu+n?= =?us-ascii?Q?4Wh4zJiM9UURjFFRdT6fOQOBQpJKm2P30QyTFca4M7GIgJkMNW8F+DT4wlZ9?= =?us-ascii?Q?IBZjlohsEdIvoI8gOgO8M4hq5VnhB3KLV8S?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 5:Y6Jnb+7BHw+P2ArmD8LEsT8qWRJVg4ZJ4+x7+JB3ReZ4ry9Mr6Z3V0QORhrwxgvXkYQJW7fmn9qYOknGrPafs6goSIsJOKSDAFDkSfNxRnheb7tXfVhZvd+14d4fU9UEwM3ZASZhVynVUllXph5UqQ==; 24:eWlF55lBQMnyDYjjwNnMLCQKpevfLKyr5phTBfXdI4AVZ6lRr9x0PHyOXL7/tMOitseeX0mHQQ1pcBkVHmEZQbqCzKCLd+sGKMdsyKf31kA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: direcpath.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2016 00:37:11.0107 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR01MB1719 Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 00:37:35 -0000 --------------D6AE1E666FD9B61332189544 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 2/15/2016 3:14 PM, Warren Kumari wrote: > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG > should do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as > one or more RFCs? > Yes > Scott, Tianran and Warren > > [0]: The first one was the IPR one ( "Untangling - Explicit call for > IPR on draft-ietf-opsawg-tacacs-00") > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------D6AE1E666FD9B61332189544 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit



On 2/15/2016 3:14 PM, Warren Kumari wrote:
Dear OpsAWG:

This is the second of three messages [0] to determine what the OpsAWG should do with TACACS+

Should the ID, as presented, or as revised by the WG, be published as one or more RFCs?

Yes

Scott, Tianran and Warren

[0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00")


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------D6AE1E666FD9B61332189544-- From nobody Mon Feb 15 20:18:31 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9101B336E for ; Mon, 15 Feb 2016 20:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 Jl0FI2yL6sdQ for ; Mon, 15 Feb 2016 20:18:28 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFB61B3326 for ; Mon, 15 Feb 2016 20:18:27 -0800 (PST) Received: from mb-2.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1G4IIwT031400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2016 04:18:20 GMT (envelope-from joelja@bogus.com) To: "Bradner, Scott" , Alan DeKok References: <4E9C5B7E-D3B6-4119-ACAA-601CBC0C3492@deployingradius.com> From: joel jaeggli Message-ID: Date: Mon, 15 Feb 2016 20:18:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GpNGD3Sc4dJQ1SEqGNEHnbegu3mB3JK3B" Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] appeal on adoption of draft-ietf-opsawg-tacacs-00.txt as an opsawg topic X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 04:18:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GpNGD3Sc4dJQ1SEqGNEHnbegu3mB3JK3B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/15/16 3:16 PM, Bradner, Scott wrote: > ps - the session was in the ops area meeting, which is why the minutes = are not on the opsawg list Joint meetings have the property of occupying one slot. that may be a tooling problem but satisfies the proceedings reporting in it's current form. > Scott >=20 >> On Feb 15, 2016, at 5:33 PM, Alan DeKok wr= ote: >> >> Some corrections. >> >> On Feb 12, 2016, at 11:46 AM, Bradner, Scott wrote: >>> The topics of the appeal and other messages from Mr. DeKok included: >>> 1/ The adoption of the TACACS+ Internet Draft as a working group item= =2E >> >> My appeal concerned the *process* of adoption as a WG item. >> >>> 2/ The appropriateness of publishing the TACACS+ Internet Draft as >>> a RFC through the IETF track. >> >> My comments at the time of the appeal show that I support publishing = historical TACACS+ protocol as an informational RFC, via the OPSAWG >> >>> 3/ The appropriateness of publishing the TACACS+ Internet Draft as >>> a standards track RFC. >> >> My comments at the time of the appeal show that I support publishing= the *changed* (i.e. future) TACACS+ as a standards track RFC. >> >> I do not support publishing the historical TACACS+ protocol as a stan= dards track RFC. >> >>> 20 July 2015: The ops area session was held. The TACACS+ slides used >>> during the session are at:=20 >>> https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf >>> >>> Minutes of the session are quite sparse. They note that the presenta= tion >>> occurred and that Alan DeKok objected to the proposal. >> >> I don't see copy of the minutes on the WG mailing list archives. The= y aren't on the WG page at: >> >> https://datatracker.ietf.org/wg/opsawg/meetings/ >> >> Alan DeKok. >> >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --GpNGD3Sc4dJQ1SEqGNEHnbegu3mB3JK3B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbCowUACgkQ8AA1q7Z/VrLbQQCaA2RFZq+rBQHa09wrd9y+D9TY vFAAmwbu4LAyf9zOSgaYkMh420Is9W8g =MAqk -----END PGP SIGNATURE----- --GpNGD3Sc4dJQ1SEqGNEHnbegu3mB3JK3B-- From nobody Mon Feb 15 21:04:37 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C871B351D for ; Mon, 15 Feb 2016 21:04:35 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 BZyzQkBXU5Fp for ; Mon, 15 Feb 2016 21:04:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0646.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:646]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7271B34E0 for ; Mon, 15 Feb 2016 21:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=direcpathcorp.onmicrosoft.com; s=selector1-direcpath-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bfKGKhsviw9ZwOmCbMh0BwuApK7tR1Mpsyk2+Q2onWg=; b=Mbj1Y3K9L70QVCQYt2PZ0MO1HjcRVQazNd7aB/k8NZLtanPTu2kUCoNnWCK2Ds1DJ1E0sTmhxCDKqEQgbaanOmyBhwWIUY9MiMs8bHb6I3pUGm19N2uwnuEWsgxjYKjga+Y/PQxBjSBHlYTG/C1Q9qa+xmM2sg0FfHAk/vqyXNI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=direcpath.com; Received: from [10.6.2.149] (24.98.60.52) by BY2PR01MB1719.prod.exchangelabs.com (10.163.26.145) with Microsoft SMTP Server (TLS) id 15.1.409.10; Tue, 16 Feb 2016 05:04:06 +0000 To: References: From: Robert Drake Message-ID: <94e82782-bea8-01ca-f4eb-a2d822bc3713@direcpath.com> Date: Tue, 16 Feb 2016 00:04:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EDC4C2C1E6C18D441D1B4805" X-Originating-IP: [24.98.60.52] X-ClientProxiedBy: BN1PR12CA0032.namprd12.prod.outlook.com (25.160.77.42) To BY2PR01MB1719.prod.exchangelabs.com (25.163.26.145) X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 2:X5xxYWmdL78JL5AmYOKiQD/buhE4+B5GGcmcb4Mg3ikt9lOc1AJG2R8Cf4ob7xk4PVSo6QzA6TYMGrBdjuU4kNwe8Wt5lS2Z44b2RvoITujewqEHTvJlcZ8t7DVW3MxiIp8jJ+g6fZHrE5ZVdO+Oxg==; 3:H+e0wXd18ZHnt6D+Sbf2v41gaBNYVX3TB8hURHdB4glV/tg8ZYwO9MzXZuUnq4venVFrbjRWcipMayqK7CLsjBybX/T1YfdizUS94209nd9vYeA/FyCnVwADxdUnocyf; 25:tXOjoNESwyUgxYzZXvPqjaXuIkXhqoGjSzdSsZ/EVJnbvLuY4oFbguygJhfzGNyihRcgpK/C3wmCJcYzVMpn5wAU51W8L6bVIjVkc/xOGSjb9ZnoRu7efSbOUZpAQFhXazu+vWl9dErvHAVuI9q9bSECWqOjBE9YJiDDVkBPgqJrC9qRJFXAz261YP2gN4KUVKaF1LWPKyeqp974yCytJiUnuuJhjHNPfO+ibPXG1+h3T1hcMD4/5k8qCfAMXMLOAmTDZ+kwC//cVDlPeKuuNIyl5Ol1dnNPr6vIcNVziZKMuhV2Zm4P3YEotKbwD+lU; 4:K5dKjT8C67ZS/FcN1DoUbeL8fxx5H7myW+G7VvkzjqMo2m+QWuSxgRvzKJb5UDLIyyIvtOU5P7BVjf8+c7TDTyQW7jqynt3dx+IvGxqwdT4xKPCZB21WTCV3FXXjz2DTcoRpbLXbUjUBpwGR4kME2r3GeMJd76lOVblGCx7pWoEmnDCx98oS5G5Vu37gxXlH1XMBrFmn0wc1tif3TBAyRvowbjEWMEjUzI7WVD7t6/QqQuUVx/095qp3gy/ict2b44kHdmcL9ZitcFFZsa9HPu+ofJ6d0VPbx1Xzw/z5hykKR8fcGLW+WA4NNpxORIAd1nwaXdZ2lRD3AIBvus/ndRjp0lFVBuObNkVkbzpCJrA= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR01MB1719; X-MS-Office365-Filtering-Correlation-Id: b2aa079c-0ad5-40d0-f61a-08d3368e991f X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR01MB1719; BCL:0; PCL:0; RULEID:; SRVR:BY2PR01MB1719; X-Forefront-PRVS: 0854128AF0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(24454002)(377454003)(479174004)(4001350100001)(5001960100002)(189998001)(110136002)(107886002)(86362001)(87976001)(33646002)(586003)(2906002)(5008740100001)(5004730100002)(512944002)(270700001)(2950100001)(19580405001)(3846002)(19580395003)(1096002)(6116002)(122386002)(84326002)(77096005)(2351001)(50986999)(16236675004)(65956001)(83506001)(40100003)(15975445007)(36756003)(76176999)(54356999)(31686004)(42186005)(31696002)(92566002)(19617315012)(66066001)(450100001)(65826006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR01MB1719; H:[10.6.2.149]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR01MB1719; 23:p6fXslOzryfGpK0LXMsg1/BIWm7GJwDVZQF5M9w9W?= =?us-ascii?Q?XceAmlE2B3l0AR+fNi68w5lw20DReUSb0XTsYqti05WKmbwypBgHuG0HBVdx?= =?us-ascii?Q?MOywHL90mjIDHE3aM+UVsFyFXhPJGKHXlacccXU3rFbKEKKfSlA0f+y3WyGX?= =?us-ascii?Q?fzn3+n3tAzBiqLxE52H5foIn6v96A/MhgrluE1Tg8Aru9owMENql4OpR4Ajz?= =?us-ascii?Q?0HuCNu1sz2rR0TGXfIXWP/q7uQrmvWbj9JA7Xri6o10x5pnwkc/yD8m7BJDX?= =?us-ascii?Q?PIWY4ODu6ranAw3N8jJXHv39m50Avhv0opFfj4C3H5vgce1JKHiagBRDjKoH?= =?us-ascii?Q?KHiCC/xH8l6f6XbKuqXW4BG4Ck3W3rvOyVMgGYCHaA8czyDkF153A+LeFHZT?= =?us-ascii?Q?mIz32HNyaF44WtqXfy1WLjdpf1uHlvKHdL6a2pAkwjcsQNpP3fCsIrw5h953?= =?us-ascii?Q?TmyYMBPChgjPvptvx78r074bikf1vg894MGiXDvb8MTT1l0sNeUJ07BPMh9y?= =?us-ascii?Q?B/15i5D/enG6RuwsTspD7ccOydkVHvNMGB9oQBlatwkcB7OZGM6AbB+rs1wH?= =?us-ascii?Q?YkNkj7YY0iv7zpe7/RM6/yu5yye/DfgssIWTWGw5Xj5KfuNUdzgpfdivBw2t?= =?us-ascii?Q?NSH9wgYPWBTrVgVRL9f3/nimETiFlLK7kwhlWx/jiCD86oLv603ApI0OZmqU?= =?us-ascii?Q?HmKuG2ABxutEmnaHkbuiAd92B6xn9xSpnmTpnDD7nJwQIdmXR9/9DJce4Gq4?= =?us-ascii?Q?sB+F4dd9iJUJcm56aOqARJrPy6r8vJNnoJI7t3aHrxzmZ/8mIK3fhLQH3dUd?= =?us-ascii?Q?ZAbFs9jq+75Pjd/BfZIEBtM5OdjV9gBq8tjC1EO7maFgXxEPyitb9W/hj6St?= =?us-ascii?Q?nStu+BMgup0r7zQlvMnflLx6OeHZLJ7/3Rnm46nqQoLKWo1FPqJXRLMXv8uY?= =?us-ascii?Q?/OQQdYNQM2lEnBChspRJWxOLdEZfoChV+a09OQ/xS//PhRGl0Iv59cSftzSc?= =?us-ascii?Q?SngWCh63dxcKyK8YtjTMGvojT/8uSeC366ZxAur4M3/lyTptMhHCf0e7u7OP?= =?us-ascii?Q?cxE5nS78xbHq3lHY3mXDLJRNLDqM8jwhG4vaFSOokIBupVDoy4+VR+eJRG4o?= =?us-ascii?Q?Bce8Zjy3Slr3nyfItkfaNuMBl8EMYPAqtzc9DfKRXtwej3I9KuomqTGxOU+e?= =?us-ascii?Q?MMwW5YjQMtAsCLlOzowd6p4HgOHzp0uBRNl2bdi1HX7vQAJ+CliBQ/QwA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 5:z/pLkxVOYQnSi/TuzMjGGyqZSBpfnkOefX7CQPpHhOsXmFtvGeLF+SO0mzhIV4fRSRGFBvtJ2kQOlKHy75XBOh94Ub3MjVn6aG6BiNd+pkAdIrmI+oiyWnjbekveI5Hx+uSHz7EfnZMza8BcLQrJQA==; 24:qFMVV+Tvx2eKkN7DjQNclH86KCBBrWzBrwT3SHMdf7ZZxOeDsxybPB82X5+lhVBj4z2FeurFNiShrOaJx4WmAV3qOBAy3Ej/LNbjHHKCh/0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: direcpath.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2016 05:04:06.8980 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR01MB1719 Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 05:04:35 -0000 --------------EDC4C2C1E6C18D441D1B4805 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 2/15/2016 3:16 PM, Warren Kumari wrote: > This is the third of 3 messages to determine what the OpsAWG should do > with TACACS+. > > If the answer to the previous question is yes, should the RFC > describing the protocol itself (as opposed to any other document that > might describe appropriate use) be published as a standards track RFC? Yes > > Scott, Tianran and Warren > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------EDC4C2C1E6C18D441D1B4805 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit


On 2/15/2016 3:16 PM, Warren Kumari wrote:
This is the third of 3 messages to determine what the OpsAWG should do with TACACS+.

If the answer to the previous question is yes, should the RFC describing the protocol itself (as opposed to any other document that might describe appropriate use) be published as a standards track RFC?
Yes



Scott, Tianran and Warren


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------EDC4C2C1E6C18D441D1B4805-- From nobody Mon Feb 15 22:05:03 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A131A1AFF for ; Mon, 15 Feb 2016 22:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 50hrqvzPQAOx for ; Mon, 15 Feb 2016 22:05:01 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106311A1AFC for ; Mon, 15 Feb 2016 22:05:01 -0800 (PST) Received: from mb-2.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1G64dDC031914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2016 06:04:40 GMT (envelope-from joelja@bogus.com) To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA6BF19470@AZ-FFEXMB04.global.avaya.com> From: joel jaeggli Message-ID: <7adf2207-ae09-f7a2-fa72-88ec3f79ead8@bogus.com> Date: Mon, 15 Feb 2016 22:04:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF19470@AZ-FFEXMB04.global.avaya.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h7EkBsqr6RonpqsufaEnxUuTmvoktMTBf" Archived-At: Cc: "Unbehagen Jr, Paul E \(Paul\)" Subject: Re: [OPSAWG] automatic attachment of applications and services at the edge X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 06:05:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h7EkBsqr6RonpqsufaEnxUuTmvoktMTBf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Am I correct in understanding that the goal is to not have to implment spb on the client device? so this takes the place of an isis implementation that would do the signaling per 802.1aq. On 2/15/16 7:09 AM, Romascanu, Dan (Dan) wrote: > Hi, >=20 > =20 >=20 > I would like to draw the attention of the participants in the OPSAWG on= > an individual submission that I am co-authoring. The problem we are > trying to solve is the optimization / minimizing of the amount of > configuration that an operator needs to do when new applications requir= e > the creation of paths or tunnels in the core network. In order to avoid= > the reconfiguration of the core or heavy configuration at the edge the > proposed method which we call auto-attachment allows for the usage of a= > protocol running between the end stations and the first (edge) router > that adds the information and characteristics of the new path according= > to the policies or mapping tables of the operators. A first > implementation that we have running code for and is deployed is > described in https://datatracker.ietf.org/doc/draft-unbehagen-lldp-spb/= > and uses the Link Layer Discovery Protocol (LLDP) with an IEEE 802.1aq > Shortest Path Bridging (SPB) network. >=20 > =20 >=20 > Please have a look and let me know if there is interest and/or similar > on-going work. If there is enough interest I plan to request a short > slot to discuss the idea at the OPSAWG meeting at IETF 95. >=20 > =20 >=20 > Thanks and Regards, >=20 > =20 >=20 > Dan >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --h7EkBsqr6RonpqsufaEnxUuTmvoktMTBf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbCu/IACgkQ8AA1q7Z/VrLPrgCdHxzqLA18DE4YlldQWruvua2C 06cAn1frwagXnIMUS7JaFSlgt9yndOpq =2vuz -----END PGP SIGNATURE----- --h7EkBsqr6RonpqsufaEnxUuTmvoktMTBf-- From nobody Mon Feb 15 22:11:24 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109E61A1A6A for ; Mon, 15 Feb 2016 22:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Z9WtxAT1A_a8 for ; Mon, 15 Feb 2016 22:11:21 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96041A013F for ; Mon, 15 Feb 2016 22:11:20 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id e127so99384134pfe.3 for ; Mon, 15 Feb 2016 22:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=ggGr9ObAaBX1ZZs9MbtdzG21gWE9qt0SvMZ+vWqSlNI=; b=TeE35mqqpc/dSuOHuHa/Q+D/N03R7jrrl3fMq/nfi4dSdZZd7a2sUs/vHwSqVBbsvq TfG262RbWKVs/yt/sXnv3MMB5jDMAeYHach9BY3fI2vaVHSnSD7l4CAx7H76EwhM/Mq5 ZluN18kHz+7xPQo2w6m6QWx5kP2Yv2IMOcPmxtFbA8dU3PNXDn0yJ2+mZk9bRWl2qONz WDdnrCNamU4vtgsS9MMn88yt0ZCTirjQ/MdW5nG42fs2bMzegl6osuyccIuhcvvhtmlq 4OUuREET/PJuCW0GlJ0Z1zX80lPS2TJn57P82IDMpZeyCaMf+JAtFNWw3OVrSCQJly5w 2s2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ggGr9ObAaBX1ZZs9MbtdzG21gWE9qt0SvMZ+vWqSlNI=; b=Ztsu+vqVUNsujw+fiWi/8oS5gGwJtRzPQfgdys18LCT3bGtTkAzmUhJ2WgiZgeu0un BAb90j38oURL8pzEZ/tAC6OZP1tFqjEDdRMEPH+umpluAgV7LK2ymFpZlYMkDpTaesqf S7XL0J8pqUfXotj2gJsb5kNLuXo0YvRrGPhVV/tcGU4StyBQiFrw6VzcHq8MAs7K3oLi bMza0wFKbn6SORzHz/ywDGDOuNhx0j7KYs2EYTBxC9dq4snnveApxydjJhYt5jNyeqED ciMr2Mv4+eei1nlsgel413mSWtpLTbZnr4zA1zYcYOfmnHTff6RgiNtPOeRX9xMuQ8OV 4UrQ== X-Gm-Message-State: AG10YORefGdcWXmIpBYPEcN3NdQvHf0izQxyJi1ePPypJRC5AzVGkKxtW9OuukvzShxEfw== X-Received: by 10.98.70.211 with SMTP id o80mr28503716pfi.124.1455603080594; Mon, 15 Feb 2016 22:11:20 -0800 (PST) Received: from Melindas-MacBook-Pro.local (63-140-97-159-radius.dynamic.acsalaska.net. [63.140.97.159]) by smtp.googlemail.com with ESMTPSA id h66sm42590693pfd.91.2016.02.15.22.11.17 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Feb 2016 22:11:19 -0800 (PST) To: opsawg@ietf.org References: <94e82782-bea8-01ca-f4eb-a2d822bc3713@direcpath.com> From: Melinda Shore Message-ID: <56C2BC71.1020601@gmail.com> Date: Mon, 15 Feb 2016 21:06:41 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <94e82782-bea8-01ca-f4eb-a2d822bc3713@direcpath.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 06:11:22 -0000 I'm a little concerned that what's taking place has the appearance of voting, and I hope that the minority viewpoint will be weighed on its merit. That said, I think it's very clearly the case that TACACS+ ought to be published (indeed, probably needs to be published) given its ubiquity and our interest in interoperability. I don't much care how (mostly because I'm unconvinced that anybody not involved with the IETF cares very much about the distinctions we make), but I do think that being careful about process helps protect the working group and the broader organization against appeals and such, which are a time and energy sink. But the bottom line is: I think it needs to be published as an RFC. Melinda From nobody Mon Feb 15 22:18:24 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD81A6F64 for ; Mon, 15 Feb 2016 22:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 jU33TTkiUG9U for ; Mon, 15 Feb 2016 22:18:22 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6811A6F32 for ; Mon, 15 Feb 2016 22:18:22 -0800 (PST) Received: from mb-2.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1G6IHwb031996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2016 06:18:17 GMT (envelope-from joelja@bogus.com) To: Alan DeKok , heasley References: <20160215100708.GD80648@shrubbery.net> <97B548DD-6589-4B13-9053-48C416390977@deployingradius.com> From: joel jaeggli Message-ID: <8de38fb4-0ae6-56cc-10e4-54998c71a3bc@bogus.com> Date: Mon, 15 Feb 2016 22:18:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <97B548DD-6589-4B13-9053-48C416390977@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4I7lpIwfAao6gRiCXAveA8KG1HlO3akS" Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+, a suggestion X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 06:18:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p4I7lpIwfAao6gRiCXAveA8KG1HlO3akS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We have strayed away from the work at hand, and I don't see this line of discussion getting more appropriate. thanks joel On 2/15/16 7:35 AM, Alan DeKok wrote: > On Feb 15, 2016, at 5:07 AM, heasley wrote: >> >> Seems that in the time bikeshedding, this could have already been in W= GLC. >> Outstanding work! >=20 > Following process and achieving consensus is not "bike shedding". It'= s entirely inappropriate to describe it that way. >=20 > Alan DeKok. >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --p4I7lpIwfAao6gRiCXAveA8KG1HlO3akS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbCvyQACgkQ8AA1q7Z/VrIfdQCfXmymPQ1ESk4j+5FcbGvZzljV KakAnj2w4+ZJ3UpMfk3DlUR5YSv4ADkU =4UoS -----END PGP SIGNATURE----- --p4I7lpIwfAao6gRiCXAveA8KG1HlO3akS-- From nobody Mon Feb 15 22:25:26 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCD61A8754 for ; Mon, 15 Feb 2016 22:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 oNHYHutetpfp for ; Mon, 15 Feb 2016 22:25:22 -0800 (PST) Received: from zm-out-01.forthnet.gr (zm-out-01.forthnet.gr [194.219.0.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7981A8752 for ; Mon, 15 Feb 2016 22:25:22 -0800 (PST) Received: from zm-in-01.cloud.forthnet.prv (zm-in-01.cloud.forthnet.prv [10.24.31.15]) by zm-out-01.forthnet.gr (Postfix) with ESMTP id D4AF9120F8B; Tue, 16 Feb 2016 08:25:20 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id BFFBD1201CB; Tue, 16 Feb 2016 08:25:20 +0200 (EET) X-DSPAM-Result: Innocent Authentication-Results: zm-in-01.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id HNwIlLBMKKd9; Tue, 16 Feb 2016 08:25:20 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id 1C65C1202BE; Tue, 16 Feb 2016 08:25:20 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-01.cloud.forthnet.prv 1C65C1202BE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1455603920; bh=dCWkLt+7VeDV+RgESsPgVAC46B07zdKJouojJmviTLU=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=q1yhSWUj8SjKWfBSCBcoAQWKGH6W/EFcyVzljKmQW8Ttb1I5ScwOi5/31/DBmoO+Z bzvx9pgU/lHhXy67L8IMtoIT6+4bzKsNmfmskb5aFoUfLri3zQ0avZ5H/wtUi+4jng a1+2BRblYZgums+rCmRjCGb8+m5GeTxuRVMM0490= X-Virus-Scanned: amavisd-new at zm-in-01.cloud.forthnet.prv Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id BqoPl2f2QQKH; Tue, 16 Feb 2016 08:25:20 +0200 (EET) Received: from [IPv6:2a02:2149:8742:9300:e0e2:8647:be0c:14ad] (ip-2a02-2149-8742-9300-e0e2-8647-be0c-14ad.ip6.forthnet.gr [IPv6:2a02:2149:8742:9300:e0e2:8647:be0c:14ad]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTPA id DF7521201CB; Tue, 16 Feb 2016 08:25:19 +0200 (EET) Message-ID: <56C2C0CB.5030208@forthnet.gr> Date: Tue, 16 Feb 2016 08:25:15 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 MIME-Version: 1.0 To: Warren Kumari , "opsawg@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 06:25:25 -0000 Yes! -- Tassos Warren Kumari wrote on 15/2/16 22:14: > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG should do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as one or more RFCs? > > Scott, Tianran and Warren > > [0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00") > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Feb 15 22:25:54 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D7F1A3B9C for ; Mon, 15 Feb 2016 22:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 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_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 izQupOn7edgJ for ; Mon, 15 Feb 2016 22:25:51 -0800 (PST) Received: from zm-out-01.forthnet.gr (zm-out-01.forthnet.gr [194.219.0.13]) by ietfa.amsl.com (Postfix) with ESMTP id BF6761A8758 for ; Mon, 15 Feb 2016 22:25:50 -0800 (PST) Received: from zm-in-01.cloud.forthnet.prv (zm-in-01.cloud.forthnet.prv [10.24.31.15]) by zm-out-01.forthnet.gr (Postfix) with ESMTP id 088B1120F8B; Tue, 16 Feb 2016 08:25:50 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id 03EB51202BE; Tue, 16 Feb 2016 08:25:50 +0200 (EET) X-DSPAM-Result: Innocent Authentication-Results: zm-in-01.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id WJz92oqUi6A7; Tue, 16 Feb 2016 08:25:49 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id 639601201CB; Tue, 16 Feb 2016 08:25:49 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-01.cloud.forthnet.prv 639601201CB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1455603949; bh=x6qcRBg1Qe21aXp+XkZOlm52NNT+I3hEZwzt24qqAlo=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=CmI3lWLbZ2rJom2csrgq4U4XIF5rITOWDPdic55THGmq+fAMRupaDHKY1ZcrsCst1 TyBgUR9GsshKS4FdqKnG/poZNgWWbowP55tI5Qi5PlFDLVpVcoweHjhvi0Hzlf8ScT 24mLj/yMXx6sSpgSSdxn3juEoHqrVBZHbqMwEG8g= X-Virus-Scanned: amavisd-new at zm-in-01.cloud.forthnet.prv Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id T-LkAU1i2wva; Tue, 16 Feb 2016 08:25:49 +0200 (EET) Received: from [IPv6:2a02:2149:8742:9300:e0e2:8647:be0c:14ad] (ip-2a02-2149-8742-9300-e0e2-8647-be0c-14ad.ip6.forthnet.gr [IPv6:2a02:2149:8742:9300:e0e2:8647:be0c:14ad]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTPA id 382F311FE72; Tue, 16 Feb 2016 08:25:49 +0200 (EET) Message-ID: <56C2C0E9.3020708@forthnet.gr> Date: Tue, 16 Feb 2016 08:25:45 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 MIME-Version: 1.0 To: Warren Kumari , "opsawg@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 06:25:52 -0000 Yes -- Tassos Warren Kumari wrote on 15/2/16 22:16: > This is the third of 3 messages to determine what the OpsAWG should do with TACACS+. > > If the answer to the previous question is yes, should the RFC describing the protocol itself (as opposed to any other document that might describe appropriate use) be published as a standards track RFC? > > Scott, Tianran and Warren > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Feb 16 02:43:12 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACF81B2CEB for ; Tue, 16 Feb 2016 02:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 hmvcawOBtYOb for ; Tue, 16 Feb 2016 02:43:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693761ACF60 for ; Tue, 16 Feb 2016 02:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3656; q=dns/txt; s=iport; t=1455619387; x=1456828987; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=zeLsxDaonIDMKJ0s9v9rTbpRU/ZQXA8mXoHjkSinPos=; b=GWn9xQ9+8Biy7lRyRbrhkygnl8meNhhmwbdllUdepQBjo5zYiQEKOBNs IHobLKRWS9i4E6dxX2aO4Jw6PbxkqiEn9/MC+a761n9hRcXAPYp5Qb1MI y0Lq9phqNwMyTrmv64Cwivz17081JwvnIr9eH0SV2NRPD05le3MM59VD9 E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgAW/MJW/xbLJq1evQqCEw6BZ4YNA?= =?us-ascii?q?oFyFAEBAQEBAQGBCoRCAQEEI1URCQIEARMJFgsCAgkDAgECAUUGAQwIAQGIFox?= =?us-ascii?q?cnROPAgEBAQEBAQEDAQEBAQEBAQEQCIpGhzKBOgEEln+DBYFkiHCJIYVSjkAeA?= =?us-ascii?q?UODZDuJCgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,455,1449532800"; d="asc'?scan'208,217";a="649357244" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2016 10:43:05 +0000 Received: from [10.61.67.192] (ams3-vpn-dhcp960.cisco.com [10.61.67.192]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1GAh5it001568; Tue, 16 Feb 2016 10:43:05 GMT To: Warren Kumari , "opsawg@ietf.org" References: From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <56C2FD38.5080902@cisco.com> Date: Tue, 16 Feb 2016 11:43:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hvsoBLneElx39Ebx4afMbgxvTtcrfQdcj" Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 10:43:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hvsoBLneElx39Ebx4afMbgxvTtcrfQdcj Content-Type: multipart/alternative; boundary="------------000802010807030201060509" This is a multi-part message in MIME format. --------------000802010807030201060509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chairs, On 2/15/16 9:16 PM, Warren Kumari wrote: > This is the third of 3 messages to determine what the OpsAWG should do > with TACACS+. > > If the answer to the previous question is yes, should the RFC > describing the protocol itself (as opposed to any other document that > might describe appropriate use) be published as a standards track RFC? > I believe the answer to this question should at least initially be =E2=80=9Cyes=E2=80=9D. If the WG comes to determine that the result is s= o disparate that an informational document describing what is currently deployed is also required, we can do that later. My logic is quite simple: there may not be energy for two documents, and the changes may be simple enough to effect in common implementations that a second document may not be necessary. Eliot --------------000802010807030201060509 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chairs,

On 2/15/16 9:16 PM, Warren Kumari wrote:
This is the third of 3 messages to determine what the OpsAWG should do with TACACS+.

If the answer to the previous question is yes, should the RFC describing the protocol itself (as opposed to any other document that might describe appropriate use) be published as a standards track RFC?

I believe the answer to this question should at least initially be =E2=80=9Cyes=E2=80=9D.=C2=A0 If the WG comes to determine that the re= sult is so disparate that an informational document describing what is currently deployed is also required, we can do that later.=C2=A0 My logic is quite simpl= e: there may not be energy for two documents, and the changes may be simple enough to effect in common implementations that a second document may not be necessary.

Eliot

--------------000802010807030201060509-- --hvsoBLneElx39Ebx4afMbgxvTtcrfQdcj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWwv05AAoJEIe2a0bZ0noz7tIH/iUo/5EUld2+RIEJcN4enCPG vBuJTWVUiEPgq6S49pCGvJKSVLfkuFV9CVJe64ecb1MVCv3c2fC+nYkaN3dwgh4o x4SFMUgV/rwgn9e56F5v2380fFx5drY5vY+1D8L1w3PcmB0Q3nHXSl6mQG8ebHS/ rDZN96PDO2whjiOOnOL8mbxvY3CwzqAcqKtBk81E5jJHiNr0xIThSrrHenEYbUG/ 7dL4Mdv2taOH8BH/vIEK5j4kh1N6QW8efJAehWToKn1TIvJuba6lirbMX8vb8wnd X+1yCHzvytt8Vzv8wK1d1pNYUypIIZisZrXZa4FtlbxzTQirlUsiGYfnvQufa+g= =wgtp -----END PGP SIGNATURE----- --hvsoBLneElx39Ebx4afMbgxvTtcrfQdcj-- From nobody Tue Feb 16 03:32:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639A61A86F0 for ; Tue, 16 Feb 2016 03:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 yrUjjn9SzYgw for ; Tue, 16 Feb 2016 03:32:15 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D591A92EB for ; Tue, 16 Feb 2016 03:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tXDxtb2uJOJl031GcYn5OTDn5z9atdQnLc9E2TMPEjw=; b=fOjk2btYCYtf+c64rfzTOZfuMDGqdZ+z75WjbDDOZzUsPPbsT1IO6gdMEzsLT5nPE87CuHWa1D/cQVoo/jv9BMZdEksme68xnOj56JXyQpw+4AFi2F6LOyMELAHRILURtsZqsIzpUNAQXLC0DSVXsvGg9VYPWmuK5bcCwBT0f/k= Authentication-Results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.151.172.136) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 16 Feb 2016 11:31:53 +0000 Message-ID: <020b01d168ad$288830e0$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari , References: Date: Tue, 16 Feb 2016 11:28:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.151.172.136] X-ClientProxiedBy: AM3PR02CA0050.eurprd02.prod.outlook.com (10.242.240.50) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB057; 2:Tl1uYkbwbn0NQeVJpsMRjHS3CXfI67lKloI4T7lJYumuT8sruIbwWME4O/3OaCjGRsS1prjtSRxrq3kqIS2Og3VAT+iunDCpiePU1wsOQquBWX9x6zZATTOxzuTqlNRD6ODtG7d0mj0rV4GUrOLXZg==; 3:hcodrGHK4mDUKPzrJnlAOWGXLyns/6wEFZP/qMkDfVsxaEuioGKS5fTCeozhFTL/iEdXXH7V70kOHO4HIHKz6GXaSNJ2iWE7Yhs4imGHpBrRlzfSppGSadjz2olPPg36; 25:2tPBspHsLuMBl+ak7uGE+0FcMUy6v6Ym/mybjyUbmOX6WFiS/VtT7zxJTBFg1tXqucknNH0B/tzgFprUT78Y1N6lMJ7XWUhLWuEit91iMDLGMoIhHelPRJtNrCp/6Mv2717TTmHlxYdq90vYVoKAODhg+UUThy2EulbUjbi1666u/QcGBC9zozVfW7C9Y06KnQPvCWcAaezyM3cAQ01wd6JzeCQmB6vcOw4FipBhr8goxfM2WAfAxGjN0ihx+wTPpFQNV2Te5zJ8MVlo2bJIBqjlD2sSUnLxm7TyzZJ4x5YVMfhI5wIqnm4T5Zg75F3h X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-MS-Office365-Filtering-Correlation-Id: 4088f892-17e7-46aa-bf58-08d336c4c4da X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB3PR07MB057; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB057; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB057; 4:6w8nZHxeEnhpQ45G93Y9YKj63LB5YuUOQP3WcpHv8VlQt2sc6ZsUZ3YP/JyZDJblsggS65igzbDsKDQH3unXItDs87TYNKhSk1tg1P0bL0iBe9u5OFJ+LL7LYZqhCEQqReqzcn4z4cRLoGUdXUQLCVCnjHuQEZmZMQV90NMZL6c+By/WYK0rf1ZEKqKfZwy4x6Xd504wadV9+h5t7k8wBRR6oEIbXyD4dRDBJni5qZ/t5PH7X1fqrfeFflHPoPrelLhdDIWajFPXXx5Ik38dnsM9PAGuyXKhMGjVaF6XSqx9pfKoXBxYcaIMHujWWUtPUpmQEmiOP1Bd9U9b97pZq7Fgw0ZclHxQr25fKmJyNLt1UKToneNhrS7mvWcqBzSE X-Forefront-PRVS: 0854128AF0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(13464003)(51444003)(2906002)(87976001)(1556002)(66066001)(50226001)(23676002)(14496001)(5001770100001)(47776003)(40100003)(189998001)(5008740100001)(230700001)(86362001)(5001960100002)(1096002)(77096005)(44716002)(62236002)(15975445007)(61296003)(5820100001)(5004730100002)(81686999)(50986999)(76176999)(42186005)(19580405001)(6116002)(107886002)(92566002)(3846002)(19580395003)(81816999)(50466002)(586003)(122386002)(33646002)(74416001)(7726001)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNTc7MjM6ZUtuUm5KZ1MrcVdocCtod0t5cjJvY0dYN0pM?= =?utf-8?B?MnRGVCtMdzZGOGNvYVdXNzMvR2JyWlBlQ1BNTXFhbFhlSXc5TUVkTlpldllr?= =?utf-8?B?NzFmVU9OeDNXTXJpYUpRdUZJcHZkYWNxNDQ4MWFkS3pYWjlHaWdEQkkyVFN2?= =?utf-8?B?elhLRVk1OHNOUHJkNC9SQUJSRHhUakMzZzJZczlQV0xKdkdSRGZhRGlVbjl5?= =?utf-8?B?amZyMkNkd3FhQ3N0MjNtR3RJdzAvNmVxWE1QUVFacTRoZktXMUViR3RQTjdx?= =?utf-8?B?Y3F3M3NBNzRiSStOUzBaL09FSnlCMkUra3ROVjhXZEpWdFg0WHVqZmdubWpE?= =?utf-8?B?Rnpvb1N5clRpZ1FUVkZtUTJXNEhBVkYvZ1RCN1lqeGtxUGdBcE54Y2F1aFFL?= =?utf-8?B?N0hJRkdDYzN2SnlCUDFwdnRvZFN2a0R6MkhZRXdqcWVHTUoyNThZeSthWnJY?= =?utf-8?B?amhtK1B0ZGIyVkZWNExEUEh0bEMwdWh1dExZelZkQzNudUd4THFXSW4wRm93?= =?utf-8?B?bXN1SmFWWnFvMW1RTFpYVFdWeE80NDluc2xnbjJDejVkaVd4TlNxUjk3dHBn?= =?utf-8?B?M0tQbndlZ1ZoRE82cXhuY2FXLzZ1RUxXUzVKMUJEWE05OEtDK2VWcmFLcW9j?= =?utf-8?B?cHJ0eE1KQm5FUzZJKzQwdUE5eEhHVUREbnM2RllvS01lYkxIcFk5bXFzQk5L?= =?utf-8?B?Z21LZVZDZVllWWVPU01neG9wN2pRREpqRHFoNWh0M1V2ZDZxOHFpaUlpK2x6?= =?utf-8?B?cFVWdVdrYmJsL2RyVmhKd2ZLaTZNMk1ZTjRKd3JoblUyTHVtdzZncURsZUdG?= =?utf-8?B?Y0FXWkdQSjVFMFc5L0tnb2FUbis4aEMyZ21COEJXcXdvR0FrOXdrRTIwT2c1?= =?utf-8?B?UzI1WldTTWxIdzBBMjMwVk54ZmZ1Vm9KaHFMS1BWY1FJWE50emVaTTBuVlo0?= =?utf-8?B?bTJoTnJzSFd3VU1MTkFYREZ3WjBnTy9oQ3ZnRHFYMjRVVnNpenorMVI2MGg4?= =?utf-8?B?WGxJMW9JZStYQWRHR1dTaXNKZ0xXNjRvc293Y29xKzNQTGphQzl1dlhPNDNv?= =?utf-8?B?YTRobGIzSmZtWFluR2lpU29pdk9zQnpQaW1VRkYvVnhxSXRndjRvUnFTdHFS?= =?utf-8?B?TFdqczQwK0xIUndPSkZjNjQybGxDSlRXeFVieUFZSGlPZTYwcmZCN0dLSGVh?= =?utf-8?B?cHVzeDcrdjFzclNqZ0FwSjdKQ3BhMU5RK1hrRUgyU1FYbWJaOVBDK3NnUWll?= =?utf-8?B?UXoyRi93MkpwUWdHUEpXQkVoWUlmbWd1SDBwcmFORWt5NU1QRnBMbVE0dDQy?= =?utf-8?B?Z1lzdVNDVENlbkt4dGdBZEp4K1R2NFVROHAza0w2SmEwVncwaDlOMnNPaE1i?= =?utf-8?B?ZEFIZHJBUjI1TG5lem1LdEdZSXorY1JUaEdNSSsxVjNqL24zaGROMDZaYXlM?= =?utf-8?B?ZVMvcVdLQjl1azl5WmFLa0dRRHU5UXBkanhVeGtzbU1abmNFdHRRTG4wcUF0?= =?utf-8?B?K2lBN0VhRTdMYTRERjdHRllGWGx2QlNtQzBhQkFyU3BiQzYvWHBEQW92eUNy?= =?utf-8?B?blNWNTJMM3drNDJoRm94MXd4NlpvS1pUY25xTmdYczRWWUNqVlVucDR2Y3dm?= =?utf-8?Q?V3QrbiHgx7U5tG180Uw?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB057; 5:CayQ7od015bTMb7Kvtg0uTuEoCtLEbLTFEhs3jaIUH8lg5zsnVWgcneDAsJLlYV5ifM6wX9sDiVl87bomGehuUd1Ub5zJkv0ftBap3qlSIWiotmfY7snKOmV5/1Q2Fp7u8UiT/Jb+H7DflwreWIUKA==; 24:Suy6i3mmymX14L3KJEgVlxs59DVoeAHcqIvIdspsJ6C1mx3+0hNciCqIhx+5nCCFVKgj4gk5/Sfe5q6HgQzzBTpcakF/f9SnB6sIvcj+Gd4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2016 11:31:53.1191 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB057 Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 11:32:21 -0000 --- Original Message ----- From: "Warren Kumari" To: Sent: Monday, February 15, 2016 8:14 PM > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG > should do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as one > or more RFCs? No, it should not. A similar situation arose with syslog, a widely used, well-understood protocol without a standard definition. In this case, the aim was for the IETF to add security so first, it had to define the protocol, which it did with RFC3164. The I-D adding security seemed to progress well until it ran into strong objections at IETF meetings which led to substantial changes, essentially saying that RFC3164 got it wrong, that it may describe one flavour of syslog but that it did not describe what was in widespread use. In due course, RFC5424 appeared and is an excellent RFC. But ... some time later, the question arose, on an IETF list, did it describe what was happening in the Internet, and the feeling was that it did not. When the time came to model syslog in YANG, the authors of the I-D looked at five implementations and then chose the obsoleted, Informational RFC3164 as the best description of the protocol! So is the IETF's Standards track specification of syslog of any benefit to the Internet? The problem is that for all the following of the correct procedures by the syslog WG, documenting consensus, gaining participation and so on, the end result is flaky. With hindsight, I think that the syslog WG did not have a wide enough participation to represent all the different flavours of the protocol and that if it had have, then it might have been clear that a single, Standards track specification was impossible. You may have pairwise compatability between the products of six different manufacturers with TACACS+ but that just may mean that each manufacturer has learnt that, in the market place, they have to cope with five other flavours of the protocol to sell a product and that a single specification does not exist. (Famously, there have been cases of Microsoft getting a specification wrong and smaller manufacturers then building faults into their products in order to interoperate - such is the commercial world). So, I believe that the IETF should not get involved with TACACS+; for all the enthusiasm displayed on the list, we do not have sufficiently wide skills. I do not doubt the wishes of those on the list to have a Standards track specification but that does not mean that it is possible to produce such a specification that reflects what is happening on the Internet. (It would, of course, be different if, as has happened in other cases, a trade body came to the IETF and asked for their work to come under the change control of the IETF but I see no evidence that such a body exists; or, if a manufacturer, say Xxx, wants to submit an ISE I-D on "Xxx's implementation of TACACS+", then I would fine with that). Tom Petch p.s. You do not say which I-D - I assume draft-ietf-opsawg-tacacs-00 and not draft-grant-tacacs-02.txt - but from my perspective, that makes no difference. > Scott, Tianran and Warren > > [0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on > draft-ietf-opsawg-tacacs-00") > ------------------------------------------------------------------------ -------- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Tue Feb 16 04:47:32 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C211B2D67 for ; Tue, 16 Feb 2016 04:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 cTXKDefZmYAk for ; Tue, 16 Feb 2016 04:47:30 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095351B2FED for ; Tue, 16 Feb 2016 04:47:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D0AQDAGcNW/xUHmMZeGQEBAQEPAQEBAYJfK1JtBroiAQ2BXgkXCoUiSgKBNTgUAQEBAQEBAYEKhEEBAQEBAwEBAQ8oNAsMBAIBCA0EBAEBAQoUCQcnCxQJCAEBBAENBQgTB4d4AQ2fT5lGAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGEoQ0hAExgyuBDwWFTpExAYVSgm2CZIQRhEODGYU7jkAeAQFCg2Nqh2ABewEBAQ X-IPAS-Result: A2D0AQDAGcNW/xUHmMZeGQEBAQEPAQEBAYJfK1JtBroiAQ2BXgkXCoUiSgKBNTgUAQEBAQEBAYEKhEEBAQEBAwEBAQ8oNAsMBAIBCA0EBAEBAQoUCQcnCxQJCAEBBAENBQgTB4d4AQ2fT5lGAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGEoQ0hAExgyuBDwWFTpExAYVSgm2CZIQRhEODGYU7jkAeAQFCg2Nqh2ABewEBAQ X-IronPort-AV: E=Sophos;i="5.22,455,1449550800"; d="scan'208";a="142831308" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Feb 2016 07:47:26 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 16 Feb 2016 07:47:26 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Tue, 16 Feb 2016 07:47:19 -0500 From: "Romascanu, Dan (Dan)" To: joel jaeggli , "opsawg@ietf.org" Thread-Topic: [OPSAWG] automatic attachment of applications and services at the edge Thread-Index: AdFoAuqkDgFGUxitTRiPQzVc0ggEVAAdJtqAABALD6A= Date: Tue, 16 Feb 2016 12:47:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF1A0E6@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BF19470@AZ-FFEXMB04.global.avaya.com> <7adf2207-ae09-f7a2-fa72-88ec3f79ead8@bogus.com> In-Reply-To: <7adf2207-ae09-f7a2-fa72-88ec3f79ead8@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Unbehagen Jr, Paul E \(Paul\)" Subject: Re: [OPSAWG] automatic attachment of applications and services at the edge X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 12:47:32 -0000 Hi Joel, This is correct. Legacy devices or devices constrained in resources (think = IoT) would have a problem to implement ISIS and the full signaling stack. T= he proposed solution requires them only to support LLDP or some other one-h= op auto-attach protocol.=20 Regards, Dan > -----Original Message----- > From: joel jaeggli [mailto:joelja@bogus.com] > Sent: Tuesday, February 16, 2016 8:05 AM > To: Romascanu, Dan (Dan); opsawg@ietf.org > Cc: Unbehagen Jr, Paul E (Paul) > Subject: Re: [OPSAWG] automatic attachment of applications and services a= t > the edge >=20 > Am I correct in understanding that the goal is to not have to implment sp= b on > the client device? so this takes the place of an isis implementation that= would > do the signaling per 802.1aq. >=20 > On 2/15/16 7:09 AM, Romascanu, Dan (Dan) wrote: > > Hi, > > > > > > > > I would like to draw the attention of the participants in the OPSAWG > > on an individual submission that I am co-authoring. The problem we are > > trying to solve is the optimization / minimizing of the amount of > > configuration that an operator needs to do when new applications > > require the creation of paths or tunnels in the core network. In order > > to avoid the reconfiguration of the core or heavy configuration at the > > edge the proposed method which we call auto-attachment allows for the > > usage of a protocol running between the end stations and the first > > (edge) router that adds the information and characteristics of the new > > path according to the policies or mapping tables of the operators. A > > first implementation that we have running code for and is deployed is > > described in > > https://datatracker.ietf.org/doc/draft-unbehagen-lldp-spb/ > > and uses the Link Layer Discovery Protocol (LLDP) with an IEEE 802.1aq > > Shortest Path Bridging (SPB) network. > > > > > > > > Please have a look and let me know if there is interest and/or similar > > on-going work. If there is enough interest I plan to request a short > > slot to discuss the idea at the OPSAWG meeting at IETF 95. > > > > > > > > Thanks and Regards, > > > > > > > > Dan > > > > > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > >=20 From nobody Tue Feb 16 07:33:29 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA851B2D5E for ; Tue, 16 Feb 2016 07:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=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 oUD7DioLTNOG for ; Tue, 16 Feb 2016 07:33:21 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 792551B2C85 for ; Tue, 16 Feb 2016 07:33:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id B338DCF8; Tue, 16 Feb 2016 15:33:20 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfTtGYEQrOEx; Tue, 16 Feb 2016 15:33:20 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id BB31C9E2; Tue, 16 Feb 2016 15:33:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Tue, 16 Feb 2016 10:33:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 15:33:24 -0000 On Feb 15, 2016, at 3:14 PM, Warren Kumari wrote: >=20 > Dear OpsAWG: >=20 > This is the second of three messages [0] to determine what the OpsAWG = should do with TACACS+ >=20 > Should the ID, as presented, or as revised by the WG, be published as = one or more RFCs? I'll say a guarded yes. I have previously explained my preferences for how this work should go = forward. I won't repeat them here. I'll also echo t.petch's concerns. There has been no discussion about TACACS+ implementations. i.e. does = the draft accurately document the protocol as it exists today? We don't = know. It would be good to get feedback from implementors as to whether or = not the document is correct on it's technical content. I see that = information as critical to have. Alan DeKok. From nobody Tue Feb 16 07:43:06 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978C91A8A9C for ; Tue, 16 Feb 2016 07:43:05 -0800 (PST) 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] autolearn=ham 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 Fd6QCxlzlszP for ; Tue, 16 Feb 2016 07:43:04 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DC0B91ACF08 for ; Tue, 16 Feb 2016 07:43:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 4CFE5A61; Tue, 16 Feb 2016 15:43:03 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJvuE6hLd4CX; Tue, 16 Feb 2016 15:43:03 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id B3E899E2; Tue, 16 Feb 2016 15:43:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Tue, 16 Feb 2016 10:43:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <646B4C50-7D93-4FB1-BC3F-87885F39715D@deployingradius.com> References: To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 15:43:05 -0000 On Feb 15, 2016, at 3:16 PM, Warren Kumari wrote: >=20 > This is the third of 3 messages to determine what the OpsAWG should do = with TACACS+. >=20 > If the answer to the previous question is yes, should the RFC = describing the protocol itself (as opposed to any other document that = might describe appropriate use) be published as a standards track RFC? I would say "No". I'll repeat my reasoning here. I support publishing "historical TACACS+" as an informational RFC. = That makes it clear the protocol was developed outside of the IETF, and = not under IETF change control. Despite external people not = differentiating between "informational" and "standards track", the IETF = process does make that differentiation. If we are to follow the = process, we should follow the process. I believe any discussion of TACACS+ MUST remove all discussion of it = as an "AAA protocol". If it's an AAA protocol, then the requirements = for AAA protocols should apply. If (as many proponents claim), it's not = an AAA protocol, then the requirements for AAA protocols shouldn't = apply. But the document then MUST NOT describe itself as an AAA = protocol. I support publishing the "future TACACS+" as a standards track RFC. = But I think this work should be done outside of OPSAWG. New management protocols are not a "small, highly focused projects = that don't merit a WG of their own". They require special adoption = processes due to the enormous costs they impose on the industry. If, on the other hand, OPSAWG published a standards track document = titled "TLS transport profile for legacy network management protocols", = that would fall within the charter. But defining a new (to the IETF and the world) network management = protocol is entirely outside of the scope of OPSAWG. Or, if (as many people say) the protocol isn't new, then OPSAWG won't = be making any changes to TACACS+. It can't both be under IETF change = control, and at the same time, 100% historical TACACS+ and nothing more. Alan DeKok. From nobody Tue Feb 16 10:53:19 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7721ACE3B for ; Tue, 16 Feb 2016 10:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 mSaMl5hxV9_g for ; Tue, 16 Feb 2016 10:53:16 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D07D1ACE36 for ; Tue, 16 Feb 2016 10:53:16 -0800 (PST) Received: by mail-pa0-x229.google.com with SMTP id fl4so95907624pad.0 for ; Tue, 16 Feb 2016 10:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=6H+LRD+1y+Lc7GCqODznAlAPkYD6FpzUUeqwfsh3ad0=; b=jVlr8tb9n/R792DYfnmMT3Y0yjt6Kj5MQtuIGuK2owiZzq31YpjN+7faqHDMWek9dD jICCbuVrPWmy3KTPdbpmRN+6hZ1/Db5g6BYKeCGo2yedRAqi8h614BxJtUn87lGcAPve Vm6E7kGXdgfDa+1myGWJD1eisJ+E0UyDgezmHxd/UuQwAAXR1xK4JMcU56fAw4AF8va0 qpsjMcqVPvyZsU926KHCoMFpgzbHIeZFJyf9Ph09AiOj+fpOMD+qrdzVBn0PFRDyZt5a 3jsmwDe3Lifr65qW9RnHHOngkXCGSdOCgZmb5vnYsDpUhoF/SB5NMuE3P5/g0PjZ8ycc ULUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=6H+LRD+1y+Lc7GCqODznAlAPkYD6FpzUUeqwfsh3ad0=; b=dDe+kxrwnYZO1gXYqOBW/nr77QJcuAbQ1bPLdWJiR7s4sVcWTG+7uEFlbDMpi9iOuL CSpd2u528NtxKZGRTF4ycP37ms6g5dn0FUUxyGXXPJLzvyZLVXbi1Wcjgo07acxaUizF 4MIPL9PJA3/dVEq4tC5aE4IOimHurE9FwvVfJ7iV5QSM8D46sEor2YbMO081b67tWU04 OJeMLF2DzoSQAa9ALrnsiyw8KqQaFFhzSIVqrihXOvCLKSS+rFzNnpsK5DOTAnmEEwad +da5zmV9e5xBi3MkQKaGt7g0xrza53PdPYIvbuhkG/+4KdPlGyYpteHdG25GL0kOOsBN roQQ== X-Gm-Message-State: AG10YORs79k9tFLLLKn6HBI2IdIb3qmjEEFgl53IFUN2lwrIaDEUf8hLewQfPgO1aFBkyg== X-Received: by 10.66.251.162 with SMTP id zl2mr33475530pac.116.1455648795897; Tue, 16 Feb 2016 10:53:15 -0800 (PST) Received: from ?IPv6:2406:e007:666a:1:28cc:dc4c:9703:6781? ([2406:e007:666a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l24sm35709840pfb.73.2016.02.16.10.53.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 10:53:14 -0800 (PST) To: Warren Kumari , "opsawg@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56C3701D.1000803@gmail.com> Date: Wed, 17 Feb 2016 07:53:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 18:53:18 -0000 On 16/02/2016 09:14, Warren Kumari wrote: > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG > should do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as one > or more RFCs? I find it impossible to answer this in a binary fashion, unfortunately. Yes, it is useful to the community to publish an accurate description of the currently deployed protocol. If that is what the current draft is, go for it, if and only if it does not carry any restriction on derivative works. No, it is not useful to publish a description of the currently deployed protocol mixed with proposed extensions. If that is what the current draft is, split it. Brian > > Scott, Tianran and Warren > > [0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on > draft-ietf-opsawg-tacacs-00") > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Tue Feb 16 10:57:20 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52AF1A90E9 for ; Tue, 16 Feb 2016 10:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 4LdDnSjbuN7V for ; Tue, 16 Feb 2016 10:57:18 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF851A9025 for ; Tue, 16 Feb 2016 10:57:18 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id fy10so68340964pac.1 for ; Tue, 16 Feb 2016 10:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=36AjD/KAx+yW3ONdTzzIamC1QgFA5un5aziBVCNM2mg=; b=d+U2QNVPsYSSCWzuESOKiLPlgpU+wFsHWJV08vrBqqkv1EtIdH+2rjsSnIpPwm8f1j VZbWQOLJ6AXWOuDJwgM9Ox5SUm/tAPd56W2xL4D69AJHCIwJ+3uAPdoSyZGhIEbGfMrH uzTK6rOsofMoOxgL2bkYtxQBgW93r3wA+CqKuXYZ7l117Cy0aRe0MKNLRo0lKTe8wU9p 6cgtWxaZaBl7DuuzYeL+w0uhy87+/PVQp+8wI2ZbDGw+7P8F3wO7AtXCZTzT6+rBQy0T qkvNe8fE8wApgT54OELSpFZqz+/FluP1raLEXzc1uMnUSGbuc3wZCeoVJAcQye4aeCZN irlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=36AjD/KAx+yW3ONdTzzIamC1QgFA5un5aziBVCNM2mg=; b=KUqoglLANJa7W9ZgnaDVeMW1QU6RyaNJHfpVviEe/qECucfbfqhRfiEEU44nz/IGD7 VUeeS70BWBUsSgaiAquCTE+upynWW4I40BCcrbgtBseoRPwkHumSpnLRhv9SxRIAzUh+ 23FhvY6HWcKeFb30wr9XFZB8KhyNI5AmgvBfyEj/4yezdpyQXKrzKsTMVVCsQu10dUsV k8zc16vdvIOBSgKvatp6jsj/ELSS+rEf74NOpU3zZYoETG68IkNv4gG78H0GXn5pPUO/ cTIMP9KcJD3KvY1d9FcldHguCZr1GpAw6kEIeJyaoKXYAnoQGRP2fTOF7H03+IATxFcX aoUQ== X-Gm-Message-State: AG10YOSMZ79BrXtufDeh6OgPL2+4UqDfvAdvlHfjXNZRuWEODzoMI6zguHxnhiCDG/uugw== X-Received: by 10.66.55.6 with SMTP id n6mr33498611pap.35.1455649037832; Tue, 16 Feb 2016 10:57:17 -0800 (PST) Received: from ?IPv6:2406:e007:666a:1:28cc:dc4c:9703:6781? ([2406:e007:666a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 9sm47422813pfc.69.2016.02.16.10.57.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 10:57:16 -0800 (PST) To: Warren Kumari , "opsawg@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56C3710F.7010301@gmail.com> Date: Wed, 17 Feb 2016 07:57:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 18:57:19 -0000 On 16/02/2016 09:16, Warren Kumari wrote: > This is the third of 3 messages to determine what the OpsAWG should do with > TACACS+. > > If the answer to the previous question is yes, should the RFC describing > the protocol itself (as opposed to any other document that might describe > appropriate use) be published as a standards track RFC? If it is only an accurate description of the currently deployed protocol, I couldn't care less whether it's Proposed Standard or Informational, as long as the IETF can make derivative works. If there are proposed extensions or changes, that should be standards track. Brian > > Scott, Tianran and Warren > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Tue Feb 16 12:14:14 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB45D1B36BC for ; Tue, 16 Feb 2016 12:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 agiV_CpbDGXm for ; Tue, 16 Feb 2016 12:14:11 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BC41B36B9 for ; Tue, 16 Feb 2016 12:14:11 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id u200so149148363ywf.0 for ; Tue, 16 Feb 2016 12:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J3v80biHkVndZ1LHzAVqlfT2FPERhDMf0tOvQRIDasU=; b=hWTEgUSBSfCzYwUsr1Nq3G9ZyZ3t+QCqAA/l9hONNBZx4FiqugY0otEejkQjerf/4l SkFt5gqWxk/wCH8y3a3kB89cgfybvVslEBlgPLuzLfEx8LFqoUqd54NJ1zFzJWcZK5Ts QWslOwGRCaU/9nrQJxvgSvyyR6ZFzsdebzrCN9RKR4EndzHrNasUfxfxJJm7dICeBO+z dfzKnQ7TmsrXAiZ1+ewWONc9MEAKcZWKusREx/KTE64n8lv4yNUj1iCgoEQe5m6yGhWT cT4aK4RKlk3dGHowfQtrJgtUNqaxCMH5tu6GEXmuN56bgx/5dc4wxFGFYDVxnE1jWUMi xfAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J3v80biHkVndZ1LHzAVqlfT2FPERhDMf0tOvQRIDasU=; b=Ebxobcbbo3cUpwAeOmL1XimKj6gNDPQw5Vt0FHzGAJSdh42sxckJbmDVLPQaxkmk4/ oRCyPIFkiWEvXhW5SwDc8z2RdCkeZiYY9R5LyGtBxjq27i26s/b2GKR1mKMYaJo/AcuC 0tKfcXpffiPq+ABtc8ilDBXJR4M8gKL42OAK7+ldx5WWgogbq7N2t4vi6rAE7z+rLWfD D9OCsF41si5NxYvgPgYgx4e9Hce2IgiFZPggmUpfRT6SpI93CmE8AIuszTWO24dclAlp jikxyHNkQZCCd/6v2MkY+Vc78tpx9fghnFet6WkmbW8sSpkCwRN4dZNdneb0khfKdw/r vM6g== X-Gm-Message-State: AG10YOROC85zO9KV8n+m5Fo0j3z0Ha6KugUv39pPktwlzz50Zq5dZaCrvPJtwkTHzg2prqIuVo2llTOLhZEZtg== MIME-Version: 1.0 X-Received: by 10.13.200.65 with SMTP id k62mr13182556ywd.145.1455653650545; Tue, 16 Feb 2016 12:14:10 -0800 (PST) Received: by 10.13.209.198 with HTTP; Tue, 16 Feb 2016 12:14:10 -0800 (PST) In-Reply-To: <56C3701D.1000803@gmail.com> References: <56C3701D.1000803@gmail.com> Date: Tue, 16 Feb 2016 15:14:10 -0500 Message-ID: From: Christopher Morrow To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 20:14:12 -0000 On Tue, Feb 16, 2016 at 1:53 PM, Brian E Carpenter wrote: > Yes, it is useful to the community to publish an accurate description > of the currently deployed protocol. If that is what the current draft > is, go for it, if and only if it does not carry any restriction on > derivative works. I think the derivatives work issue here is based on potential IPR claims restricting use of TACACS+ beyond the currently documented (in draft) protocol... if that's the case then we're sunk :( (as operators who need current functionality and want better security properties going forward) If we're not sunk by the IPR torpedo, I would like to see the current work finished as an RFC, yes. From nobody Tue Feb 16 12:15:00 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A170B1B36CA for ; Tue, 16 Feb 2016 12:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 sMxn2_pGaLZb for ; Tue, 16 Feb 2016 12:14:57 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8238E1B36C5 for ; Tue, 16 Feb 2016 12:14:57 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id e63so54184768ywc.3 for ; Tue, 16 Feb 2016 12:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gG162Gy+P7eIYO73DTcu3hpCt05ow2NSy/IWDazWgtY=; b=ludjHRFC/ZoRiBf0b2C+RtYv+cHNCoBQI/dw55NqvSnE5em3WMFA20HoX8GR7P8Et6 zddKH7GtQIzBPJ5gCoHbMvHeyGPB0iBiUp8Bv88MfAaxETt0b2bs4nqQK29Q4HydSWkW xcIFfAGSBwBtfaJOGTI6FbEw6h4adJoaJULwmkNQeoNTiWgnScdREfv6uduFrz0eYTEx uvAiscInaeXY5CjTb1zubCm+nBtk7o5mdVL9u1GzdDjO0g17kFZgNa18mYfWrXJ3BEJV ThcEptvsUodYOwTTDFdcxIX8t4HIqI/3CEAiX060QecF/PonpXEmitgM29uEgOc67jwa heRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gG162Gy+P7eIYO73DTcu3hpCt05ow2NSy/IWDazWgtY=; b=LxD036YjCm0/gmgLzBidhc7NIciPC+4ij6C2mmqMZjFww9BXOotGmF5o3AS9+CUJWT Tem/SEMaWIRJswfOI3Vsaco4D/eztorWHez9Jje87Qg0Xw0UKA74DpHTzMS8cBL3Ntyy hE8eAaw8zFVF9In6xohk0na+2x/EuNgCaUuPVMbYeRjd07XD4Xu5zNdb1Dd6+LsrIdSG RC+uOTWscpmSR67Qs4NQCJ1/aQfSgaypAfsPhdH7/3NNGgDp+PPSyZxDwOJS/M0qGMKK Dr9sfw2sH/NHrrs3kiXcOlXfzcCbjF8xx8kSOhJe5unTMccCmvXEpZ/Cjnk/+UhcEQE7 I0+A== X-Gm-Message-State: AG10YOQHBXMhtNS/wcAXVKv0O3dL0X+5/np90xPOkt1maVabtVEhl7KcNWNEtHytiwlJIkFGDXWBSutMj7reqw== MIME-Version: 1.0 X-Received: by 10.13.205.198 with SMTP id p189mr14883196ywd.180.1455653696925; Tue, 16 Feb 2016 12:14:56 -0800 (PST) Received: by 10.13.209.198 with HTTP; Tue, 16 Feb 2016 12:14:56 -0800 (PST) In-Reply-To: <56C3710F.7010301@gmail.com> References: <56C3710F.7010301@gmail.com> Date: Tue, 16 Feb 2016 15:14:56 -0500 Message-ID: From: Christopher Morrow To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 20:14:58 -0000 On Tue, Feb 16, 2016 at 1:57 PM, Brian E Carpenter wrote: > If it is only an accurate description of the currently deployed protocol, > I couldn't care less whether it's Proposed Standard or Informational, as > long as the IETF can make derivative works. It seems to me that 'proposed standard' is ok here, provided we outrun the IPR torpedo. From nobody Tue Feb 16 12:29:11 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B844B1B36CB for ; Tue, 16 Feb 2016 12:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 mzT11dVmlgI8 for ; Tue, 16 Feb 2016 12:29:08 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726591B36BD for ; Tue, 16 Feb 2016 12:29:08 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id h129so149654897ywb.1 for ; Tue, 16 Feb 2016 12:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=UV6HWEXKtMczsKc+Lz50GQoSFd61gYmMRscf3AFTo54=; b=svVKZ2O1WQwmdfy00/XoGGzoHoSBTyPCJpK7m4kKf4PLOn3F66mitqecmZ6Dggmt8z TynI4lU31rk3z0M43n2upk5Q30NA2CnCYRRAuZGozwr3HICFpVPTY+tglCghl4Nu1HPP EBg+cXz/v1hZsYR5ClEaiJImi696+34eMvLSoGxvr3nFIo9ZzxGCqnQqYi8pSj3SYlFq cHJk2llUz+VTtCt2SyTmZPHA8DqL+43XdxvaDcYAT5lvApxOWmesaz66njvZW2Dy72Ie GnhzAbf/UfT93kzlzx5JRiaF+OwtyrX0DZVtRABu+pIbuXdo+/W912+cZedFLz7lCs5u lN6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=UV6HWEXKtMczsKc+Lz50GQoSFd61gYmMRscf3AFTo54=; b=PddOxpPlMsYAhwTvj8GQd7PkYR/hHRUE6ACity3W2xigGFcPlxQSa+qo3WMm2qHy0i 4LEElo3IcrXID+9ID5fXAy64eJTELB6EzTzPgpaMzXevYnctC1yG8nsGZmYt0ibRlXL5 F5dOdscG3To7zsGnOGqD5GfybOd4zqhMOEw5/zrjauL0m3NJ7L/9yuFw0gM0cVrl4RdT BEV8DOiZIyInkk1IvhciIcBEaa32JSSo7G3rlM9rYWTTUszM5GdymUT28D+wRVwlCTet zcBXq9FTAKuTrLOmyA/X2pVF9y7RZcPc8u40lU/4fPY2T5Fg1/+6FhsjxeBekhE8gE1F t8tg== X-Gm-Message-State: AG10YOQECKKb2X+E4mAlBs+81zGeXGTDzlvQD6uKzcQqu7fbTwcBhNLkHF35cdkM7ym5ComyOofO8MMxNLQwGRfb X-Received: by 10.13.231.132 with SMTP id q126mr13017970ywe.203.1455654547721; Tue, 16 Feb 2016 12:29:07 -0800 (PST) MIME-Version: 1.0 References: <56C3710F.7010301@gmail.com> In-Reply-To: <56C3710F.7010301@gmail.com> From: Warren Kumari Date: Tue, 16 Feb 2016 20:28:58 +0000 Message-ID: To: Brian E Carpenter , "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c088c1e3bbbca052be8fcea Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 20:29:09 -0000 --94eb2c088c1e3bbbca052be8fcea Content-Type: text/plain; charset=UTF-8 On Tue, Feb 16, 2016 at 1:57 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 16/02/2016 09:16, Warren Kumari wrote: > > This is the third of 3 messages to determine what the OpsAWG should do > with > > TACACS+. > > > > If the answer to the previous question is yes, should the RFC describing > > the protocol itself (as opposed to any other document that might describe > > appropriate use) be published as a standards track RFC? > > If it is only an accurate description of the currently deployed protocol, > I couldn't care less whether it's Proposed Standard or Informational, as > long as the IETF can make derivative works. > > If there are proposed extensions or changes, that should be standards > track. > One thing to keep in mind is that, if the document describing the currently deployed protocol is informational, we may have a tricky time making the extensions be standards track; it would (presumably) require a downref. W > > Brian > > > > > Scott, Tianran and Warren > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > --94eb2c088c1e3bbbca052be8fcea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue= , Feb 16, 2016 at 1:57 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 16/02/2016 09:16, Warren Kumari wrote:
> This is the third of 3 messages to determine what the OpsAWG should do= with
> TACACS+.
>
> If the answer to the previous question is yes, should the RFC describi= ng
> the protocol itself (as opposed to any other document that might descr= ibe
> appropriate use) be published as a standards track RFC?

If it is only an accurate description of the currently deployed protocol, I couldn't care less whether it's Proposed Standard or Informationa= l, as
long as the IETF can make derivative works.

If there are proposed extensions or changes, that should be standards track= .

One thing to keep in mind is that, if= the document describing the currently deployed protocol is informational, = we may have a tricky time making the extensions be standards track; it woul= d (presumably) require a downref.=C2=A0
=C2=A0
W
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0Brian

>
> Scott, Tianran and Warren
>
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg >
--94eb2c088c1e3bbbca052be8fcea-- From nobody Tue Feb 16 12:48:28 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DE01B2DE1 for ; Tue, 16 Feb 2016 12:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 UzrwgK6ESx8m for ; Tue, 16 Feb 2016 12:48:21 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92E81B2C10 for ; Tue, 16 Feb 2016 12:48:21 -0800 (PST) Received: by mail-yk0-x22b.google.com with SMTP id u9so78695455ykd.1 for ; Tue, 16 Feb 2016 12:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=uShl1MCjgUVilWnqZpwsBQgqOqfivcltVMlv7q0Zkvw=; b=M5lPKZRTDqq8327lF8j+pdAC5LDx6SNunC5zV+oLhEQzt0V7Ye4lPHfSxfr1T221LM hdG9UJBDueI6HGl74v635+huxVsOxY6TpQKR9ori8fa7HIcb7B3+2YsZENoIS27pIU7w EzjAA/Yr4Aus1nhQc4npIGaa/m5oiD+2sWgFqElUUtZGwWq+TeinO+bEhOAFc2kOjFka k2oJyYmf07H+bMHJbfR9KcVvPhcxCbLcMFYHSGlGqC6iHLMHD/Z47u7sVYKxyLiKxU0I WJva9oEp781xztFc0+CywCJFBDYZojyTh+Do2OULe7h0gVRfNlQpF6wKZ32ubg1aFhdG Fvyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=uShl1MCjgUVilWnqZpwsBQgqOqfivcltVMlv7q0Zkvw=; b=MfsyP2eO2402VlK0IaqYukSh54rTdnRzjRv0hLkE5kQ5HEOtcXZh2Z4DcvodwAEHn1 OLKg3l1CHHrGzz6bOoosJ5Mk3dU8mKcUR48G/rUSAvfTB8H0a4Mcn23tfjdj6yyJPbP0 kAnUF08TW16z0jlTq6tE3MUIdZi/7MaNEcQOGjnJzG0n1kMH7GwYH02v4idNXdt72niG OSARN3jt4PeMW3pj+9mGoZr8vYSVERb3tVUSEMKCFxG58ozNSV8kXwQ7xjZeyIh5zur6 HNH+Jagu59J8R9LWab2H7Wrln8eh8UP8icTDDsUyqC2gmmWGFVj2FDmoxqeQw4lYhgIG B26w== X-Gm-Message-State: AG10YOQdnAt7Y34uSjxtY0ewUKavtQp0khkiWM5pUX7xY0QwNPimfbmJmzwGOkMXIgHzjHGkJZGHWZzFMci7zDA+ X-Received: by 10.37.97.210 with SMTP id v201mr14339194ybb.77.1455655700999; Tue, 16 Feb 2016 12:48:20 -0800 (PST) MIME-Version: 1.0 References: <56C3701D.1000803@gmail.com> In-Reply-To: From: Warren Kumari Date: Tue, 16 Feb 2016 20:48:11 +0000 Message-ID: To: Christopher Morrow , Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1142ed04f98cd1052be940e3 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 20:48:23 -0000 --001a1142ed04f98cd1052be940e3 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 16, 2016 at 3:14 PM Christopher Morrow < christopher.morrow@gmail.com> wrote: > On Tue, Feb 16, 2016 at 1:53 PM, Brian E Carpenter > wrote: > > > Yes, it is useful to the community to publish an accurate description > > of the currently deployed protocol. If that is what the current draft > > is, go for it, if and only if it does not carry any restriction on > > derivative works. > > I think the derivatives work issue here is based on potential IPR > claims restricting use of TACACS+ beyond the currently documented (in > draft) protocol.. > We are still waiting to hear back from that authors on the explicit IPR check ( https://mailarchive.ietf.org/arch/msg/opsawg/uJUQ4HfSohtJVV3SrR9Qcdnpn5k) , but I should point out that the (boilerplate) starts out with: "This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79." Due to the network issues in Prague I was not present at the OpsAREA / OpsAWG meeting, but at 2:30 in the meeting audio recording Joel brought up the Note Well, so presumably the authors are aware -- but we'll wait to hear back on the explicit ACK. if that's the case then we're sunk :( (as operators who need current > functionality and want better security properties going forward) > If we're not sunk by the IPR torpedo, I would like to see the current > work finished as an RFC, yes. --001a1142ed04f98cd1052be940e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue= , Feb 16, 2016 at 3:14 PM Christopher Morrow <christopher.morrow@gmail.com> wrote:
=
On Tue, Feb 16, 2016 at 1:53 PM, Brian E Car= penter
<brian.= e.carpenter@gmail.com> wrote:

> Yes, it is useful to the community to publish an accurate description<= br> > of the currently deployed protocol. If that is what the current draft<= br> > is, go for it, if and only if it does not carry any restriction on
> derivative works.

I think the derivatives work issue here is based on potential IPR
claims restricting use of TACACS+ beyond the currently documented (in
draft) protocol..

We are still waiting = to hear back from that authors on the explicit IPR check (https:/= /mailarchive.ietf.org/arch/msg/opsawg/uJUQ4HfSohtJVV3SrR9Qcdnpn5k) , bu= t I should point out that the (boilerplate) starts out with:
&quo= t;This Internet-Draft is submitted in full conformance with the provisions = of BCP 78 and BCP 79."

Due to the network iss= ues in Prague I was not present at the OpsAREA / OpsAWG meeting, but at 2:3= 0 in the meeting audio recording Joel brought up the Note Well, so presumab= ly the authors are aware -- but we'll wait to hear back on the explicit= ACK.

if that's the case then we're sunk :( (as operators who need curren= t
functionality and want better security properties going forward)=C2=A0

If we're not sunk by the IPR torpedo, I would like to see the current work finished as an RFC, yes.
--001a1142ed04f98cd1052be940e3-- From nobody Tue Feb 16 14:31:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC091A8A48 for ; Tue, 16 Feb 2016 14:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 qYxWtq0MMlfL for ; Tue, 16 Feb 2016 14:31:02 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D441A89C5 for ; Tue, 16 Feb 2016 14:31:02 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id z13so79761162ykd.0 for ; Tue, 16 Feb 2016 14:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=zOMwgxLpIheSwgEGYfyh63yYEGZUdbos6ie3XDq7k9o=; b=Cpf+R4ABN9mM2i7Y+8kFqDWQ2D5VsovCG6bzxo/VqUYlyZEE44OKYN+mkZvzq8EE8g 2KyjXBbkl+VtuewUd8C2g8muLVaS+IN4qstcSi0bk9kvHY1YapZRbIJXd/7Ox3OGTnC8 DTB65KMt2oJiR3TFpERQ7QTvThk8Ff9053FHK7IvWSF4NZUnSwdajWhBmVx2+Y/VdpC0 qdMc95pYbfuA97TYR9g/KJ2q0J1EK8Ui2k5SsD6LGnUZh9GH3NW1SZpq8SYWkjAIYG8O npRS2EriD+ofw4QPzSnKJatyJT0Y0a9FaV8a1mJURxawXeacFp0QXUxuHu3QhCEyvwee A8OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=zOMwgxLpIheSwgEGYfyh63yYEGZUdbos6ie3XDq7k9o=; b=HIFzHfIvbjHRd6/k8/3FB9CHbOqpMCbgWwykzu2YJeDN0BJcKk2n11UNI6NLIgJ6E9 hScMRQCmBekA2XnjwUXYoGCfDvaGIkSE9YzJlQFAAOkEebcPuytpCstsJgo1TYSYwiwP TqfxeGLYsyNVOALuN6kRU0qT+BtSxYHy835F4scID4Ob0ePCDAIPW2ZqFnHnRdvjmbI2 CObaHaIJfj+r5hjF0M2wcrTP2XdyhpB54kb5gFMkAkDZN2qP+0Bibx8sxmF75G+VpwzM hOYJxLT6stOGKQtaC4RiPoJkkGEgYjy08j1bhL50eDaA02SPwBS5iuzDFZenAu+jdZA8 H+lw== X-Gm-Message-State: AG10YOQ8ENP47I+wnS5keVGpj7pXlV3Lgasalf+SitdB3VD1faiw7oKxgs/l0CZoEF/HTzjcp5VpBMifgqMg5zyS X-Received: by 10.37.230.210 with SMTP id d201mr13638607ybh.134.1455661861559; Tue, 16 Feb 2016 14:31:01 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Tue, 16 Feb 2016 22:30:51 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0a8b542c0dc5052beab093 Archived-At: Subject: [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 22:31:03 -0000 --94eb2c0a8b542c0dc5052beab093 Content-Type: text/plain; charset=UTF-8 Dear OpsAWG, While we have lots of energy / interest, we'd appreciate some additional review of draft-ietf-opsawg-capwap-alt-tunnel ( https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ). This document has an interesting history - it completed WGLC in 2014-08-27 and was submitted to be published as an RFC on 2014-09-08. We then got draft-you-opsawg-capwap-separation-for-mp, which had some some significant similarities. We asked the ADs to hold alt-tunnel while we discussed what to do, and then finally asked the ADs / IESG to return it to the WG so that these two documents could be merged into one ( https://www.ietf.org/mail-archive/web/opsawg/current/msg04071.html ). This document has already passed one WGLC (module the minor merging), and we are waiting on the authors to address some comments (e.g: https://www.ietf.org/mail-archive/web/opsawg/current/msg04161.html ) and update the email addresses - once that happens we will do another WGLC -- but, while we are waiting, we'd appreciate any other review and feedback. W --94eb2c0a8b542c0dc5052beab093 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear OpsAWG,

While we have lots of ener= gy / interest, we'd appreciate some additional review of=C2=A0draft-iet= f-opsawg-capwap-alt-tunnel (https://datatracker.ietf.org/doc/draft-i= etf-opsawg-capwap-alt-tunnel/=C2=A0).

This doc= ument has an interesting history - it completed WGLC in=C2=A02014-08-27 and= was submitted to be published as an RFC on=C2=A02014-09-08.

=
We then got=C2=A0draft-you-opsawg-capwap-separa= tion-for-mp, which had some some significant similarities. We asked the ADs= to hold alt-tunnel while we=C2=A0discussed=C2=A0what to do, and then final= ly asked the ADs / IESG to return it to the WG so that these two documents = could be merged into one (=C2=A0https://www.ietf.org/mail-archive/web/o= psawg/current/msg04071.html=C2=A0).

T= his document has already passed one WGLC (module the minor merging), and we= are waiting on the authors to address some comments (e.g:=C2=A0https://www.ietf.org/mail-archive/web/opsawg/c= urrent/msg04161.html=C2=A0) and upda= te the email addresses - once that happens we will do=C2=A0another=C2=A0WGL= C -- but, while we are waiting, we'd=C2=A0appreciate=C2=A0any other rev= iew and feedback.

<= /span>
W
--94eb2c0a8b542c0dc5052beab093-- From nobody Tue Feb 16 14:55:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEFD1AC444 for ; Tue, 16 Feb 2016 14:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 eVrPkE2AbB6V for ; Tue, 16 Feb 2016 14:55:40 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A501B1AC41D for ; Tue, 16 Feb 2016 14:55:39 -0800 (PST) Received: from mb-2.local ([8.18.217.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1GMtamR037669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2016 22:55:37 GMT (envelope-from joelja@bogus.com) To: Warren Kumari , Brian E Carpenter , "opsawg@ietf.org" References: <56C3710F.7010301@gmail.com> From: joel jaeggli Message-ID: Date: Tue, 16 Feb 2016 14:55:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6FSlFDL0oN50QBkkUV4S96nsnqu7toEFe" Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 22:55:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6FSlFDL0oN50QBkkUV4S96nsnqu7toEFe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/16/16 12:28 PM, Warren Kumari wrote: >=20 >=20 > On Tue, Feb 16, 2016 at 1:57 PM Brian E Carpenter > > wrot= e: >=20 > On 16/02/2016 09:16, Warren Kumari wrote: > > This is the third of 3 messages to determine what the OpsAWG > should do with > > TACACS+. > > > > If the answer to the previous question is yes, should the RFC > describing > > the protocol itself (as opposed to any other document that might > describe > > appropriate use) be published as a standards track RFC? >=20 > If it is only an accurate description of the currently deployed > protocol, > I couldn't care less whether it's Proposed Standard or Informationa= l, as > long as the IETF can make derivative works. >=20 > If there are proposed extensions or changes, that should be > standards track. >=20 >=20 > One thing to keep in mind is that, if the document describing the > currently deployed protocol is informational, we may have a tricky time= > making the extensions be standards track; it would (presumably) require= > a downref.=20 it would; it is not logically a huge problem, merely wierd. I doubt very much that a push for better securing of an existing mature protocol is the likely source of controversy there. > W >=20 >=20 > Brian >=20 > > > > Scott, Tianran and Warren > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --6FSlFDL0oN50QBkkUV4S96nsnqu7toEFe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbDqOgACgkQ8AA1q7Z/VrKrzQCeLqWOG9LZ53fTWKjm7Wf7EXKi c/cAn3ImQI1JC0kKZbIW/ZFBcCg/tfjI =ljVu -----END PGP SIGNATURE----- --6FSlFDL0oN50QBkkUV4S96nsnqu7toEFe-- From nobody Tue Feb 16 15:09:01 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2151ACD1D for ; Tue, 16 Feb 2016 15:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 MCzgV4rSDfzO for ; Tue, 16 Feb 2016 15:08:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CE71ACD2C for ; Tue, 16 Feb 2016 15:08:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aVojp-0008Mk-Oh; Tue, 16 Feb 2016 23:08:58 +0000 Date: Wed, 17 Feb 2016 12:08:56 +1300 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: References: <56C3710F.7010301@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:09:00 -0000 >> One thing to keep in mind is that, if the document describing the >> currently deployed protocol is informational, we may have a tricky time >> making the extensions be standards track; it would (presumably) require >> a downref. > > it would; it is not logically a huge problem, merely wierd. > > I doubt very much that a push for better securing of an existing mature > protocol is the likely source of controversy there. what is amusing is that some folk seem to be contemplating that the rfc of an old and widely distributed and used protocol should not be standard. randy From nobody Tue Feb 16 15:14:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D92E1ACE69 for ; Tue, 16 Feb 2016 15:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 AstMtbxtgTmw for ; Tue, 16 Feb 2016 15:14:45 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82631ACE65 for ; Tue, 16 Feb 2016 15:14:44 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id u200so152956025ywf.0 for ; Tue, 16 Feb 2016 15:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=queuefull.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hUxWYf9gxA/uN25SuWA9e9M850ioi6zmcUcNcBrtgYQ=; b=IEtCVTna2wsEDKECHX07Xcay5YYH/M5Mh9CfQsjrT0uQla0zFnCP+tg+r/XO7sRYUx f9lmsyJ3Mnvb4pxe86H+CWzt4LkiQVjWnKlnVhpaTRM41ihm9+7VrJGeZaicrb0dKKbz UHfEEKBNH4DN+R4pc6c2wocmDrolmw2y5geG4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hUxWYf9gxA/uN25SuWA9e9M850ioi6zmcUcNcBrtgYQ=; b=d9tjwmUUfxLp0+Fsnw/n8QY6+ZqKqG7REwaA7QQG4xYv5+XWHx7TxaqXKpnmDLRncd lkInQtVTE78A/m5/4jYgy+xRK0YWGjj5k3Gb2K87cXromHkO530ABjUP+95ht643TPgd zJlGecw8WEPCLtYvUyk1x32Zpg/uPWhw3BAx2wxF8vLKVWTEpl0EDnMKTI6IUSNNy4AE v8ALTv5wapA4jhZXz8YGlJkcWc3KINleEOvK0J+fw1VBiUPHe9CpZSSBCo88Ad4gbdez dVkg98Vv6KeimwKbGMEVSR8ZU+izxtXPzSFwTJTMDNk3Witp3HgZ7wqoYyPbbPYyqOnd GPNQ== X-Gm-Message-State: AG10YOT9Dp3G0iFZUd/C4C21hWPu85G7zJCrB0Ts/NXY8XwoVstkvLlwyeAjcImfIRZnDiB0RKWypxrEZL8PmA== MIME-Version: 1.0 X-Received: by 10.129.154.68 with SMTP id r65mr13605768ywg.151.1455664484127; Tue, 16 Feb 2016 15:14:44 -0800 (PST) Received: by 10.129.136.133 with HTTP; Tue, 16 Feb 2016 15:14:44 -0800 (PST) In-Reply-To: References: <56C3710F.7010301@gmail.com> Date: Tue, 16 Feb 2016 18:14:44 -0500 Message-ID: From: Benson Schliesser To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c0bb2fa7d503d052beb4ccd Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:14:46 -0000 --94eb2c0bb2fa7d503d052beb4ccd Content-Type: text/plain; charset=UTF-8 +1 to Randy's observation. It's almost as if we value our own opinions more than we value running code... -Benson On Tuesday, February 16, 2016, Randy Bush wrote: > >> One thing to keep in mind is that, if the document describing the > >> currently deployed protocol is informational, we may have a tricky time > >> making the extensions be standards track; it would (presumably) require > >> a downref. > > > > it would; it is not logically a huge problem, merely wierd. > > > > I doubt very much that a push for better securing of an existing mature > > protocol is the likely source of controversy there. > > what is amusing is that some folk seem to be contemplating that the > rfc of an old and widely distributed and used protocol should not be > standard. > > randy > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --94eb2c0bb2fa7d503d052beb4ccd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to Randy's observation.=C2=A0

It's almost as = if we value our own opinions more than we value running code..= .

-Benson


On Tuesday, February 1= 6, 2016, Randy Bush <randy@psg.com&= gt; wrote:
>> One thing to keep in = mind is that, if the document describing the
>> currently deployed protocol is informational, we may have a tricky= time
>> making the extensions be standards track; it would (presumably) re= quire
>> a downref.
>
> it would; it is not logically a huge problem, merely wierd.
>
> I doubt very much that a push for better securing of an existing matur= e
> protocol is the likely source of controversy there.

what is amusing is that some folk seem to be contemplating that the
rfc of an old and widely distributed and used protocol should not be
standard.

randy

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg
--94eb2c0bb2fa7d503d052beb4ccd-- From nobody Tue Feb 16 15:22:46 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9911A90E1 for ; Tue, 16 Feb 2016 15:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 pgri_viSDmo0 for ; Tue, 16 Feb 2016 15:22:43 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E521A90A3 for ; Tue, 16 Feb 2016 15:22:43 -0800 (PST) Received: from mb-2.local ([8.18.217.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1GNMgag037827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2016 23:22:42 GMT (envelope-from joelja@bogus.com) To: Randy Bush References: <56C3710F.7010301@gmail.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <87dbb116-d6f5-e591-7742-4088973a1342@bogus.com> Date: Tue, 16 Feb 2016 15:22:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TPls1KUJFVvrlrwO0koN4mlfJtAqMiGKr" Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:22:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TPls1KUJFVvrlrwO0koN4mlfJtAqMiGKr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/16/16 3:08 PM, Randy Bush wrote: >>> One thing to keep in mind is that, if the document describing the >>> currently deployed protocol is informational, we may have a tricky ti= me >>> making the extensions be standards track; it would (presumably) requi= re >>> a downref.=20 >> >> it would; it is not logically a huge problem, merely wierd. >> >> I doubt very much that a push for better securing of an existing matur= e >> protocol is the likely source of controversy there. >=20 > what is amusing is that some folk seem to be contemplating that the > rfc of an old and widely distributed and used protocol should not be > standard. Occasionally I wonder if "this problem" is the hill I'm going to choose to die on... Then I remember I'm at the IETF, and self-restraint suggests otherwise. > randy >=20 --TPls1KUJFVvrlrwO0koN4mlfJtAqMiGKr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbDr0IACgkQ8AA1q7Z/VrIbuACdFKRcMXyG9MxbFMWzQYMOvV2T 8f8An0xovVP9zrsy02AM1kCF7UCtSWkW =isXV -----END PGP SIGNATURE----- --TPls1KUJFVvrlrwO0koN4mlfJtAqMiGKr-- From nobody Tue Feb 16 15:24:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F511ACE9E for ; Tue, 16 Feb 2016 15:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 oQX0uR0S4C1L for ; Tue, 16 Feb 2016 15:24:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A8A1ACE9C for ; Tue, 16 Feb 2016 15:24:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aVoyi-0008Qt-8o; Tue, 16 Feb 2016 23:24:20 +0000 Date: Wed, 17 Feb 2016 12:24:18 +1300 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <87dbb116-d6f5-e591-7742-4088973a1342@bogus.com> References: <56C3710F.7010301@gmail.com> <87dbb116-d6f5-e591-7742-4088973a1342@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:24:22 -0000 > Occasionally I wonder if "this problem" is the hill I'm going to > choose to die on... sorry you have decided to die. you'll be missed randy From nobody Tue Feb 16 15:28:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745111AC3AB for ; Tue, 16 Feb 2016 15:28:39 -0800 (PST) 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] autolearn=ham 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 vcz-4ekvTTP5 for ; Tue, 16 Feb 2016 15:28:37 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 36F051ABD3C for ; Tue, 16 Feb 2016 15:28:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 729DB13B1; Tue, 16 Feb 2016 23:28:36 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEKzbR56RL6s; Tue, 16 Feb 2016 23:28:36 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 035798D4; Tue, 16 Feb 2016 23:28:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Tue, 16 Feb 2016 18:28:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <608CB8C2-BC74-43ED-A055-6F30E70EC623@deployingradius.com> References: <56C3710F.7010301@gmail.com> To: Benson Schliesser X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:28:39 -0000 On Feb 16, 2016, at 6:14 PM, Benson Schliesser = wrote: >=20 > +1 to Randy's observation.=20 >=20 > It's almost as if we value our own opinions more than we value running = code... I suggest posting links to the mailing list archives where someone = suggests that the document be published as *only* an informational RFC. = Failing that, publicly withdrawing this claim. The only record of someone wanting *only* an informational RFC was me = at the mic in Prague. Discussions since then have convinced me to = change my mind. Which I've stated publicly, for anyone who cares to = read my messages. The discussions in the last month have been around publishing (a) just = a standards track RFC, or (b) a standards track RFC and an informational = RFC. I'm still surprised at the level of vitriol, contradictory logic, and = just plain false statements being made here. I find such "arguments" = entirely unconvincing. Alan DeKok. From nobody Tue Feb 16 15:31:38 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174491A00CF for ; Tue, 16 Feb 2016 15:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 go5kDtWWl097 for ; Tue, 16 Feb 2016 15:31:34 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481A61A015F for ; Tue, 16 Feb 2016 15:31:34 -0800 (PST) Received: from mb-2.local ([8.18.217.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1GNVUxn037917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2016 23:31:33 GMT (envelope-from joelja@bogus.com) To: Randy Bush References: <56C3710F.7010301@gmail.com> <87dbb116-d6f5-e591-7742-4088973a1342@bogus.com> From: joel jaeggli Message-ID: <7fef9742-a5e7-d336-e0a9-fd7028513ba6@bogus.com> Date: Tue, 16 Feb 2016 15:31:29 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SQoFkKOfAc4jwbKVTUaS7hRHsLkSq26EG" Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:31:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SQoFkKOfAc4jwbKVTUaS7hRHsLkSq26EG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/16/16 3:24 PM, Randy Bush wrote: >> Occasionally I wonder if "this problem" is the hill I'm going to >> choose to die on... >=20 > sorry you have decided to die. you'll be missed HW=C6T, WE GAR-DEna in geardagum, =FEeodcyninga =FErym gefrunon, hu =F0a =E6=FEelingas ellen fremedon! oft Scyld Scefing scea=FEena =FEreatum, monegum m=E6g=FEum meodosetla ofteah, egsode eorlas, sy=F0=F0an=E6rest wear=F0 feasceaft funden; he =FE=E6s frofre gebad, weox under wolcnum weor=F0myndum =FEah, o=F0 =FE=E6t him =E6ghwylc ymbsittendra ofer hronrade hyran scolde, gomban gyldan; =FE=E6t w=E6s god cyning! > randy >=20 --SQoFkKOfAc4jwbKVTUaS7hRHsLkSq26EG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbDsVIACgkQ8AA1q7Z/VrKfIQCfaMDQoTXMRZBlZzs1oGDsQSjo YY8An0gOpwHoNB0/p4yuvZ7OgvSl5krB =ex1y -----END PGP SIGNATURE----- --SQoFkKOfAc4jwbKVTUaS7hRHsLkSq26EG-- From nobody Tue Feb 16 15:48:50 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D818A1AD06F for ; Tue, 16 Feb 2016 15:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 OmJpkOfrIxa0 for ; Tue, 16 Feb 2016 15:48:47 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D3FDF1AD068 for ; Tue, 16 Feb 2016 15:48:46 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1GNmIq8029073; Tue, 16 Feb 2016 18:48:18 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Benson Schliesser , Randy Bush Thread-Topic: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? Thread-Index: AdFpFJKIIbwG4s0/HESMr+rISMs8fQ== Date: Tue, 16 Feb 2016 23:48:45 +0000 Message-ID: <20160216234853.18296912.98092.51830@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0688313111==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-16_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602160387 Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:48:50 -0000 --===============0688313111== Content-Type: multipart/alternative; boundary="===============0062135848==" MIME-Version: 1.0 --===============0062135848== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 UGxlYXNlIGVubGlnaHRlbiBtZSAtIHdoYXQgZGlkIElFVEYgaGF2ZSB0byBkbyB3aXRoIHRoZSBU QUNBQ1MgcnVubmluZyBjb2RlPyBEaWQgYW55Ym9keSBhbW9uZyB0aG9zZSB3aG8gd2FudCBpdCBv biB0aGUgc3RhbmRhcmRzIHRyYWNrIGV2ZW4gc2VlIHRoZSBzb3VyY2VzIG9mIHRoYXQgY29kZSAo YW5kIGNvdWxkIHBvaW50IG1lIGF0IGFuIGF2YWlsYWJsZSByZWZlcmVuY2UgaW1wbGVtZW50YXRp b24pPwoKTm9ybWFsbHkgYSBwcm90b2NvbCBjb21wbGV0ZWQgb3V0c2lkZSBvZiBJRVRGIGlzIGRl c2NyaWJlZCBpbiBhbiBJbmZvcm1hdGlvbmFsIFJGQyBpZiBpdCdzIHBvcHVsYXIgZW5vdWdoIHRv IGp1c3RpZnkgdGhhdC4gVEFDQUNTIGlzIGRlcGxveWVkIHdpZGVseSBlbm91Z2gsIG5vIGFyZ3Vt ZW50IHRoZXJlIC0gYnV0IHdoeSBzaG91bGQgYSBwcm90b2NvbCB0aGF0IG1hbmFnZWQgdG8gZ2V0 IGJvcm4sIGRlcGxveWVkLCBhbmQgd2lkZS1zcHJlYWQgZm9yIG1vcmUgdGhhbiB0d28gZGVjYWRl cywgc3VkZGVubHkgbmVlZCBhbiBJRVRGIHN0YW5kYXJkcy10cmFjayBSRkMgdG8gZGVmaW5lIGl0 PyBXaHkgaXNuJ3QgSW5mb3JtYXRpb25hbCBnb29kIGVub3VnaD8KCkkndmUgbm8gc3Rha2UgaW4g dGhpcyBmaWdodCwgYW5kIGRvbid0IHJlYWxseSBjYXJlIC0ganVzdCB3YW50IHRvIGhlYXIgdGhl IHJlYXNvbnMuCgpTZW50wqBmcm9twqBtecKgQmxhY2tCZXJyecKgMTDCoHNtYXJ0cGhvbmXCoG9u wqB0aGUgVmVyaXpvbsKgV2lyZWxlc3PCoDRHwqBMVEXCoG5ldHdvcmsuCkZyb206IEJlbnNvbiBT Y2hsaWVzc2VyClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE2IDE4OjE0ClRvOiBSYW5k eSBCdXNoCkNjOiBvcHNhd2cKU3ViamVjdDogUmU6IFtPUFNBV0ddIERldGFuZ2xpbmcgLSBRMzog UHVibGlzaCBUQUNBQ1MrIGFzIGEgc3RhbmRhcmRzIHRyYWNrIFJGQz8KCisxIHRvIFJhbmR5J3Mg b2JzZXJ2YXRpb24uwqAKCkl0J3MgYWxtb3N0IGFzIGlmIHdlIHZhbHVlIG91ciBvd24gb3Bpbmlv bnMgbW9yZSB0aGFuIHdlIHZhbHVlIHJ1bm5pbmcgY29kZS4uLgoKLUJlbnNvbgoKCk9uIFR1ZXNk YXksIEZlYnJ1YXJ5IDE2LCAyMDE2LCBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPiB3cm90ZToK Pj4gT25lIHRoaW5nIHRvIGtlZXAgaW4gbWluZCBpcyB0aGF0LCBpZiB0aGUgZG9jdW1lbnQgZGVz Y3JpYmluZyB0aGUKPj4gY3VycmVudGx5IGRlcGxveWVkIHByb3RvY29sIGlzIGluZm9ybWF0aW9u YWwsIHdlIG1heSBoYXZlIGEgdHJpY2t5IHRpbWUKPj4gbWFraW5nIHRoZSBleHRlbnNpb25zIGJl IHN0YW5kYXJkcyB0cmFjazsgaXQgd291bGQgKHByZXN1bWFibHkpIHJlcXVpcmUKPj4gYSBkb3du cmVmLgo+Cj4gaXQgd291bGQ7IGl0IGlzIG5vdCBsb2dpY2FsbHkgYSBodWdlIHByb2JsZW0sIG1l cmVseSB3aWVyZC4KPgo+IEkgZG91YnQgdmVyeSBtdWNoIHRoYXQgYSBwdXNoIGZvciBiZXR0ZXIg c2VjdXJpbmcgb2YgYW4gZXhpc3RpbmcgbWF0dXJlCj4gcHJvdG9jb2wgaXMgdGhlIGxpa2VseSBz b3VyY2Ugb2YgY29udHJvdmVyc3kgdGhlcmUuCgp3aGF0IGlzIGFtdXNpbmcgaXMgdGhhdCBzb21l IGZvbGsgc2VlbSB0byBiZSBjb250ZW1wbGF0aW5nIHRoYXQgdGhlCnJmYyBvZiBhbiBvbGQgYW5k IHdpZGVseSBkaXN0cmlidXRlZCBhbmQgdXNlZCBwcm90b2NvbCBzaG91bGQgbm90IGJlCnN0YW5k YXJkLgoKcmFuZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCk9QU0FXRyBtYWlsaW5nIGxpc3QKT1BTQVdHQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnCgo= --===============0062135848== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
Please enlighten me - what did IETF have to do with the TACACS = running code? Did anybody among those who want it on the standards track ev= en see the sources of that code (and could point me at an available referen= ce implementation)?

Normally a protocol completed ou= tside of IETF is described in an Informational RFC if it's popular enough t= o justify that. TACACS is deployed widely  enough, no argument there -= but why should a protocol that managed to get born, deployed, and wide-spr= ead for more than two decades, suddenly need an IETF standards-track RFC to= define it? Why isn't Informational good enough?

I've= no stake in this fight, and don't really care - just want to hear the reas= ons.
=

= = =
Sent from my Blac= kBerry 10 smartphone on the Verizon Wireless&= nbsp;4G LTE network.
= = =
From: Benson Schliesser
=
Sent: Tuesday, February 16, 2016 18:14
To: Ran= dy Bush
Cc: opsawg
Subject: Re: [OPSAWG] = Detangling - Q3: Publish TACACS+ as a standards track RFC?

+1 to Randy's observation. 

It's almost as if we value our own opinions more than we = value running code...

-Benson


On Tuesday, February 16, 2016, Randy Bush <randy@psg.com> wrote:
>> One thing to keep in mind is that, if the document describing the<= br> >> currently deployed protocol is informational, we may have a tricky= time
>> making the extensions be standards track; it would (presumably) re= quire
>> a downref.
>
> it would; it is not logically a huge problem, merely wierd.
>
> I doubt very much that a push for better securing of an existing matur= e
> protocol is the likely source of controversy there.

what is amusing is that some folk seem to be contemplating that the
rfc of an old and widely distributed and used protocol should not be
standard.

randy

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--===============0062135848==-- --===============0688313111== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDIxNjIzNDg1MlowLwYJKoZIhvcNAQkEMSIEINddjXXAQViY 5+Y54soL6TlQKWu66qV52We4Vhuihz8AMAsGCSqGSIb3DQEBCwSCAQA8TfAWlxWXC53ZjBW729Nc OdOr4euF1BAx3qjCJjLnkqUtz2tYgS1fsLo/8Yu/t8ENjC1aPGiifjo3d2o0rUo8NgdY712W9OZ8 58o09tajyqBfvi5AW/mPWZ13q/J9BfO3Jqt2RCVad13h0yPQKiou5HyXAvwbW4d6HuzAb7Z1CI7z OGu6Mc8VIUjFiie67mPV1aAYQVfqQqKOIWKXUKbnCNBlyn8aPPiVE/IytXehNCcwrvQI1WDApvme jgVDU2LqqXbqUjlEPwydi/lFXejPC7EV62d/6luRdcITp8LS2roCGFesAK7PY3C9VBy3vDGG+BXz s6GzRqGNuAaTJWSfAAAAAAAA --===============0688313111==-- From nobody Tue Feb 16 16:07:40 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA2D1B29EF for ; Tue, 16 Feb 2016 16:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_SINGLE_URI=0.001, BODY_SINGLE_WORD=1.983, RP_MATCHES_RCVD=-0.006] autolearn=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 87ukeJwM-yNe for ; Tue, 16 Feb 2016 16:07:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369461B29F0 for ; Tue, 16 Feb 2016 16:07:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aVpea-00005c-EL; Wed, 17 Feb 2016 00:07:36 +0000 Date: Wed, 17 Feb 2016 13:07:35 +1300 Message-ID: From: Randy Bush To: "Blumenthal, Uri - 0553 - MITLL" In-Reply-To: <20160216234853.18296912.98092.51830@ll.mit.edu> References: <20160216234853.18296912.98092.51830@ll.mit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 00:07:39 -0000 http://shrubbery.net/tac_plus/ From nobody Tue Feb 16 16:14:25 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530E31B2A8F for ; Tue, 16 Feb 2016 16:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 jDH7DCD1NNG5 for ; Tue, 16 Feb 2016 16:14:21 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9ED1B2A8E for ; Tue, 16 Feb 2016 16:14:21 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id x1so293631lbj.3 for ; Tue, 16 Feb 2016 16:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7hjny+pCZiehf823ukoALKqw16b0xRqrik2cnSzsvNs=; b=JSvpwBtlhZ2Xq7fhjiQkeFbHRvBF9rCx4g8RvwpP0zu643fFz0YDiTIL36gsyUJfFW j5QDio4DPhXQdbxxJTVD5sppU4THiS281R9oo6S7DXtxPEgz+4CaSrrwnQ7oWlk8dVmy GoQFBHgse5hvcmAfmdvjPwvEK+zbr+wAdJ0aUeIs9bY/xtw31RhviXbaTkH46cSFWxyY f2VKl44df9+9bj1/1k38YJBjanPGpY2isTBJaOt4HYrhZRMViDTVeYWldjUJWw13kRM/ mZCvKdavUyPBcuIFaii+j6tZnBJsPP237vJ3agS1BOhuRSjso/ZGiIzI02D4SJmzuhq+ vfCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7hjny+pCZiehf823ukoALKqw16b0xRqrik2cnSzsvNs=; b=VXZruQb2fT7U3mKdx812aJJArmLr6kELpmSDStnnhlSc48cZuZda1W3KH8iKWQfUzr WMbZcw7HbZcIuSKzHvSmE7R2nduOijcDexKL1mQpaa/HYnjL5uBnudWvmXJRdc4bm/vT +oizt3eVsXBkodjmrfIZZOW2esxtoCt8VDGizC59WpQbBUGZWsQa/rOSH99R0pYlJaRr ua7a9s35hk1inrXOxgdoc8r6jKBV8kMaT7iv90eKwSjlvri9zH4JcMSSmFl8KEXZs1D6 1N4PUNU0MoEkOg+5+A00tTNyjvYHH4bGEd3TvtxzHjFXDxK1o2zbT7SKprac6TMfZSFs 3TEA== X-Gm-Message-State: AG10YOSOUZATj784WX+SHBaoX9fSpQ8d5QX/ANdBDN+DVWlzKqjGo/qoww2xsiIHeYga6WMLoLnl0pDerOYzAQ== MIME-Version: 1.0 X-Received: by 10.112.131.37 with SMTP id oj5mr9133316lbb.94.1455668059557; Tue, 16 Feb 2016 16:14:19 -0800 (PST) Received: by 10.112.110.68 with HTTP; Tue, 16 Feb 2016 16:14:19 -0800 (PST) In-Reply-To: References: <56C3710F.7010301@gmail.com> Date: Tue, 16 Feb 2016 16:14:19 -0800 Message-ID: From: Andy Bierman To: Randy Bush Content-Type: multipart/alternative; boundary=047d7b343ba299e8f0052bec2155 Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 00:14:23 -0000 --047d7b343ba299e8f0052bec2155 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 16, 2016 at 3:08 PM, Randy Bush wrote: > >> One thing to keep in mind is that, if the document describing the > >> currently deployed protocol is informational, we may have a tricky time > >> making the extensions be standards track; it would (presumably) require > >> a downref. > > > > it would; it is not logically a huge problem, merely wierd. > > > > I doubt very much that a push for better securing of an existing mature > > protocol is the likely source of controversy there. > > what is amusing is that some folk seem to be contemplating that the > rfc of an old and widely distributed and used protocol should not be > standard. > > I think some of us are confused by the use of the term "standard". This sometimes refers to a process that is driven by requirements, and open to multiple competing solution proposals which address the requirements. Usually the solution is not decided in advance. Is that the process you have in mind? Doesn't sound like it at all. Who decides that the draft represents the One True definition of TACACS+? Is that open to debate, decided by WG consensus? I am not questioning the value of publishing an RFC, but a standards track RFC requires a proper process. > randy > Andy > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --047d7b343ba299e8f0052bec2155 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 16, 2016 at 3:08 PM, Randy Bush <randy@psg.com> = wrote:
>> One thing to keep in mind= is that, if the document describing the
>> currently deployed protocol is informational, we may have a tricky= time
>> making the extensions be standards track; it would (presumably) re= quire
>> a downref.
>
> it would; it is not logically a huge problem, merely wierd.
>
> I doubt very much that a push for better securing of an existing matur= e
> protocol is the likely source of controversy there.

what is amusing is that some folk seem to be contemplating that the
rfc of an old and widely distributed and used protocol should not be
standard.


I think some of us are confused by the= use of the term "standard".
This sometimes refers to a= process that is driven by requirements, and
open to multiple com= peting solution proposals which address the requirements.
Usually= the solution is not decided in advance.

Is that t= he process you have in mind? Doesn't sound like it at all.
Wh= o decides that the draft represents the One True definition of TACACS+?
Is that open to debate, decided by WG consensus?

I am not questioning the value of publishing an RFC, but a standards = track RFC
requires a proper process.=C2=A0


=C2=A0
randy


Andy
=C2= =A0

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--047d7b343ba299e8f0052bec2155-- From nobody Tue Feb 16 16:16:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C561A8994 for ; Tue, 16 Feb 2016 16:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 0ASkoD7jQLLO for ; Tue, 16 Feb 2016 16:16:44 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28D01A8872 for ; Tue, 16 Feb 2016 16:16:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 02A4B1602C08; Tue, 16 Feb 2016 19:16:43 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKVnIai2tTZ4; Tue, 16 Feb 2016 19:16:41 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id E3D811602BF7; Tue, 16 Feb 2016 19:16:41 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Scott O. Bradner" In-Reply-To: Date: Tue, 16 Feb 2016 19:16:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3DFCC6F8-5B55-49ED-AE15-617B893A2743@sobco.com> References: <56C3710F.7010301@gmail.com> To: Andy Bierman X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 00:16:45 -0000 > On Feb 16, 2016, at 7:14 PM, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Feb 16, 2016 at 3:08 PM, Randy Bush wrote: > >> One thing to keep in mind is that, if the document describing the > >> currently deployed protocol is informational, we may have a tricky = time > >> making the extensions be standards track; it would (presumably) = require > >> a downref. > > > > it would; it is not logically a huge problem, merely wierd. > > > > I doubt very much that a push for better securing of an existing = mature > > protocol is the likely source of controversy there. >=20 > what is amusing is that some folk seem to be contemplating that the > rfc of an old and widely distributed and used protocol should not be > standard. >=20 >=20 > I think some of us are confused by the use of the term "standard". > This sometimes refers to a process that is driven by requirements, and > open to multiple competing solution proposals which address the = requirements. > Usually the solution is not decided in advance. >=20 > Is that the process you have in mind? Doesn't sound like it at all. > Who decides that the draft represents the One True definition of = TACACS+? > Is that open to debate, decided by WG consensus? decided by WG consensus Scott >=20 > I am not questioning the value of publishing an RFC, but a standards = track RFC > requires a proper process.=20 >=20 >=20 > =20 > randy >=20 >=20 > Andy > =20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Feb 16 16:21:44 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C165A1A1EFF for ; Tue, 16 Feb 2016 16:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 kXaBKZRUm1Kd for ; Tue, 16 Feb 2016 16:21:42 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC5F1A00CE for ; Tue, 16 Feb 2016 16:21:41 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id x1so362658lbj.3 for ; Tue, 16 Feb 2016 16:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=31MUhg8TzvAOqQngX1Ydy20UhlnROpCmLZP8xvFcZMY=; b=MoQKW6GKCWd+mYPHumAHrQva2AxtzesccrI40NmY1IR5hlkESNq9TqhFJhuOioxPPD ao3u8xZMbUWqq6CGXRNk0ukzU08Ya0ESX1eBlGLsl/UhVWBeNCMRVOpagHnFdn/YkDnG IdEep4S675vvPhpytK//+jT9wc1d/RwgJgRLuoMEzv4Ov6DnzbyNAI75DEqUwuUIRkDJ 2RgfWXEMKSi5LvxbRCT6XvXIoSvArLfW1skZH8YJ1z8k7MFgoS/vXp/UBdQphLBIeZpo 3noS1kQAWkq9JFwvLhinadDbytQNuXxIqfl05IJ0U2RjL0lsSLlG2hfW2K3WMDvxrucW pPSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=31MUhg8TzvAOqQngX1Ydy20UhlnROpCmLZP8xvFcZMY=; b=lyD/xDOWxlj4PLq71SwLlaG1Ld0D0KUC79eEp20iIq9Tu/BIhNJhdSXmU5h1zem5if ZDglg7T0VEfNHpP7U9TbqkzglpMIMKOgVa+kydn2GvSEWHyoez9ev39gd+Gu4Krb81Hc Jx0TWiaxCzeEhFF7a0Rim0y9jbWmNcn9B58LTLh51x7/bIlgjJyaAPrDcfxO0UatDrBI /qIh4+tHnwas+hQzFMfCQSXqK+bp1/KE3Kx2anjuKVVj9qkv9H+XWVPzXwlifEm9HCJo A0t++WQurAFpE7jTQpGsv/LPQo94uSbx9jFZPVhIw7gRoplDkuL22XO53J4xgd0ipPno N5rw== X-Gm-Message-State: AG10YOQUe0MtyuE/mJnP2tguZYfAsxqb9AJsgYPKG+PtIiQf1iq0/ca0CmB/ySlsac3srkQftnZ4NONQzWwj+A== MIME-Version: 1.0 X-Received: by 10.112.131.37 with SMTP id oj5mr9141505lbb.94.1455668499929; Tue, 16 Feb 2016 16:21:39 -0800 (PST) Received: by 10.112.110.68 with HTTP; Tue, 16 Feb 2016 16:21:39 -0800 (PST) In-Reply-To: <3DFCC6F8-5B55-49ED-AE15-617B893A2743@sobco.com> References: <56C3710F.7010301@gmail.com> <3DFCC6F8-5B55-49ED-AE15-617B893A2743@sobco.com> Date: Tue, 16 Feb 2016 16:21:39 -0800 Message-ID: From: Andy Bierman To: "Scott O. Bradner" Content-Type: multipart/alternative; boundary=047d7b343ba2d9696c052bec3bae Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 00:21:43 -0000 --047d7b343ba2d9696c052bec3bae Content-Type: text/plain; charset=UTF-8 On Tue, Feb 16, 2016 at 4:16 PM, Scott O. Bradner wrote: > > > On Feb 16, 2016, at 7:14 PM, Andy Bierman wrote: > > > > > > > > On Tue, Feb 16, 2016 at 3:08 PM, Randy Bush wrote: > > >> One thing to keep in mind is that, if the document describing the > > >> currently deployed protocol is informational, we may have a tricky > time > > >> making the extensions be standards track; it would (presumably) > require > > >> a downref. > > > > > > it would; it is not logically a huge problem, merely wierd. > > > > > > I doubt very much that a push for better securing of an existing mature > > > protocol is the likely source of controversy there. > > > > what is amusing is that some folk seem to be contemplating that the > > rfc of an old and widely distributed and used protocol should not be > > standard. > > > > > > I think some of us are confused by the use of the term "standard". > > This sometimes refers to a process that is driven by requirements, and > > open to multiple competing solution proposals which address the > requirements. > > Usually the solution is not decided in advance. > > > > Is that the process you have in mind? Doesn't sound like it at all. > > Who decides that the draft represents the One True definition of TACACS+? > > Is that open to debate, decided by WG consensus? > > > decided by WG consensus > sounds like standards track is OK then > Scott > Andy > > > > I am not questioning the value of publishing an RFC, but a standards > track RFC > > requires a proper process. > > > > > > > > randy > > > > > > Andy > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > --047d7b343ba2d9696c052bec3bae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 16, 2016 at 4:16 PM, Scott O. Bradner <= ;sob@sobco.com> wrote:

> On Feb 16, 2016, at 7:14 PM, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Feb 16, 2016 at 3:08 PM, Randy Bush <randy@psg.com> wrote:
> >> One thing to keep in mind is that, if the document describing= the
> >> currently deployed protocol is informational, we may have a t= ricky time
> >> making the extensions be standards track; it would (presumabl= y) require
> >> a downref.
> >
> > it would; it is not logically a huge problem, merely wierd.
> >
> > I doubt very much that a push for better securing of an existing = mature
> > protocol is the likely source of controversy there.
>
> what is amusing is that some folk seem to be contemplating that the > rfc of an old and widely distributed and used protocol should not be > standard.
>
>
> I think some of us are confused by the use of the term "standard&= quot;.
> This sometimes refers to a process that is driven by requirements, and=
> open to multiple competing solution proposals which address the requir= ements.
> Usually the solution is not decided in advance.
>
> Is that the process you have in mind? Doesn't sound like it at all= .
> Who decides that the draft represents the One True definition of TACAC= S+?
> Is that open to debate, decided by WG consensus?


decided by WG consensus

sounds like sta= ndards track is OK then



Scott

Andy
=C2=A0
>
> I am not questioning the value of publishing an RFC, but a standards t= rack RFC
> requires a proper process.
>
>
>
> randy
>
>
> Andy
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg >
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

--047d7b343ba2d9696c052bec3bae-- From nobody Tue Feb 16 22:08:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5C31B2F81 for ; Tue, 16 Feb 2016 22:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 l2yDlrZIcFjl for ; Tue, 16 Feb 2016 22:08:01 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8811B2EEE for ; Tue, 16 Feb 2016 22:08:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4253; q=dns/txt; s=iport; t=1455689281; x=1456898881; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k+fiC3A8uv0XknqnDlOHOtc6MKjAGD/rllEmP7FnKHQ=; b=PjtFLWi8R0hkcbnugpFEWAZmlAfNg1EAI2il1uhOsT0Z0MwLSwrNbEyx Ew8o0EbQWtyrvpCL67Qh/g7d+yrmKWpqsmI6ucEGPeS1Qkni0DDC26ndj AONRbh+e+eRxGWdD3hmkbaqrzWQKbcZpv2ATr8EKSKT77icgnzmgOG1qU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgANDsRW/40NJK1egzpSbQa6MwENg?= =?us-ascii?q?WcXDIUgSgKBOzgUAQEBAQEBAX8LhEEBAQEEAQEBGh0UHQMFBhACAQgRAwECDRI?= =?us-ascii?q?QJwoBHQgCBA4FHQSHZAMSDrZTDYRbAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSJU?= =?us-ascii?q?H2EBRACASOENAWHVY8uAYVSiAaBXIRDiFSORgEeAQFCg2Nqh2V8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,458,1449532800"; d="scan'208";a="74082779" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Feb 2016 06:07:58 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u1H67wH3017010 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 06:07:58 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 00:07:57 -0600 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.1104.009; Wed, 17 Feb 2016 00:07:57 -0600 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: OPSAWG Digest, Vol 105, Issue 119 Thread-Index: AQHRaCE/ZN5rAbxFm0agIlc+ut4Y+J8wOCGA Date: Wed, 17 Feb 2016 06:07:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.195.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 119 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 06:08:03 -0000 Hi Warren, I am one of the contributing authors in this document. I sincerely apologise for submitting a document which seemed to evoke passion in OpsAWG ;-) As you can tell from my email address, I work for Cisco, which provided some input in taking the original TACACS and evolving it to TACACS+ in 1990s. I have double checked with IPR expert (a lawyer) in Cisco and he sees no IPR issues, and with our IETF experts who know of no IPR which impact TACACS+ in our pursuit of getting TACACS+ ratified as a standard, if that is what OpsAWG elects to do. I can work offline to make sure that we get the proper wording, but to the absolute best of my knowledge, Cisco has no IPR that applies to the document. Just to say, this process came about from engineers who are very interested in TACACS+ and its adoption and deployment, one of whom (me) works for Cisco. We want to address the crypto issue it has, and clean up the document, try to remove ambiguities, and deprecate some really insecure features. But also want to remove the perception that TACACS+ is a proprietary Cisco protocol. We thought that working with IETF to standardise the protocol may help all that, and get some interesting technical criticism. Many thanks and Best Regards, Doug, (Collaborating with: Thorsten, Andrej). On 15/02/2016 18:46, "OPSAWG on behalf of opsawg-request@ietf.org" wrote: >Send OPSAWG mailing list submissions to > opsawg@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsawg >or, via email, send a message with subject or body 'help' to > opsawg-request@ietf.org > >You can reach the person managing the list at > opsawg-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OPSAWG digest..." > > >Today's Topics: > > 1. Untangling - Explicit call for IPR on > draft-ietf-opsawg-tacacs-00 (Warren Kumari) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 15 Feb 2016 18:46:37 +0000 >From: Warren Kumari >To: "opsawg@ietf.org" >Subject: [OPSAWG] Untangling - Explicit call for IPR on > draft-ietf-opsawg-tacacs-00 >Message-ID: > >Content-Type: text/plain; charset=3D"utf-8" > >Dear WG, > >Thanks to everyone who has been participating. It is refreshing to see >this >much passion and involvement in OpsAWG! We wanted to give this a bit of >time to settle down, and also to see where this ended up. > >We are going to do a series of steps to get as clear a view of the >consensus of the WG about this document. This message is a explicit call >for any known IPR. > >We will follow up with two other messages, each with a particular >question >- the reason for such formality is to try to untangle the many threads >that >erupted on the main list. > >Many of you have already expressed your opinion but can you please do so >again in response to the forthcoming two messages so that the record is >clear. We expect to determine the path forward in 2 weeks. > >Are you personally aware of any IPR that applies to >draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in >compliance >with IETF IPR rules? >(See RFCs 3979, 4879, 3669, and 5378 for more details.) > >If you are a document author or listed contributor on this document, >please >reply to this email regardless of whether or not you are personally aware >of any relevant IPR. > >Scott, Tianran and Warren >-------------- next part -------------- >An HTML attachment was scrubbed... >URL:=20 >0802/attachment.html> > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 105, Issue 119 >**************************************** From nobody Wed Feb 17 02:37:17 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99561A8966 for ; Wed, 17 Feb 2016 02:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 Ksqpa6rfKOps for ; Wed, 17 Feb 2016 02:37:12 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50341A1B87 for ; Wed, 17 Feb 2016 02:37:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D9AQDlTMRW/yYyC4deGQEBAQEPAQEBAYI+IStSbQaFN7JpghMBDYFnIIUjSgIcgSQ4FAEBAQEBAQGBCoRBAQEBAQMSEQpMEAIBCA0EBAEBCxkEAwICAjAUCQgCBAENBQgah3gBDaExikmPFQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhOEOoQFEAIBHRYXCYJKK4EPBZcDAYVSiWKHXIU7hXGIVh4BAUKBTGOBNGoBAQGHYgF7AQEB X-IPAS-Result: A2D9AQDlTMRW/yYyC4deGQEBAQEPAQEBAYI+IStSbQaFN7JpghMBDYFnIIUjSgIcgSQ4FAEBAQEBAQGBCoRBAQEBAQMSEQpMEAIBCA0EBAEBCxkEAwICAjAUCQgCBAENBQgah3gBDaExikmPFQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhOEOoQFEAIBHRYXCYJKK4EPBZcDAYVSiWKHXIU7hXGIVh4BAUKBTGOBNGoBAQGHYgF7AQEB X-IronPort-AV: E=Sophos;i="5.22,459,1449550800"; d="scan'208,217";a="161273246" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Feb 2016 05:36:52 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 17 Feb 2016 05:36:53 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Wed, 17 Feb 2016 11:36:50 +0100 From: "Romascanu, Dan (Dan)" To: Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel Thread-Index: AQHRaQnNTs6nVq4LrUm0hx+GCukWsJ8wClVg Date: Wed, 17 Feb 2016 10:36:50 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF1B1D5@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF1B1D5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: Dorothy Stanley Subject: Re: [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 10:37:15 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF1B1D5AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGUgcHJldmlvdXMgdmVyc2lvbnMgb2YgdGhpcyBkb2N1 bWVudC4gSSBkbyBub3QgZmluZCBzaWduaWZpY2FudCBjaGFuZ2VzIGluIHRoZSBjb250ZW50IHNp bmNlLiBJIGJlbGlldmUgdGhhdCBpdOKAmXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KDQpBRkFJ SyB0aGUgZG9jdW1lbnQgd2FzIGFsc28gcmV2aWV3ZWQgYnkgSUVFRSA4MDIuMTEuIEkgYW0gY29w eWluZyB0aGUgRG9yb3RoeSBTdGFubGV5IHdobyBpcyB0aGUgbGlhaXNvbiBtYW5hZ2VyLCBhcyBJ IGRvIG5vdCBrbm93IGlmIHNoZSBpcyBzdWJzY3JpYmVkIHRvIHRoZSBXRyBtYWlsIGxpc3QuDQoN ClJlZ2FyZHMsDQoNCkRhbg0KDQoNCg0KRnJvbTogT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXYXJyZW4gS3VtYXJpDQpTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDE3LCAyMDE2IDEyOjMxIEFNDQpUbzogb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0 OiBbT1BTQVdHXSBSZXZpZXcgb2YgIkFsdGVybmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlvbiBmb3Ig RGF0YSBGcmFtZXMgaW4gQ0FQV0FQIiAtIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVu bmVsDQoNCkRlYXIgT3BzQVdHLA0KDQpXaGlsZSB3ZSBoYXZlIGxvdHMgb2YgZW5lcmd5IC8gaW50 ZXJlc3QsIHdlJ2QgYXBwcmVjaWF0ZSBzb21lIGFkZGl0aW9uYWwgcmV2aWV3IG9mIGRyYWZ0LWll dGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVubmVsIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0LXR1bm5lbC88aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9y Z19kb2NfZHJhZnQtMkRpZXRmLTJEb3BzYXdnLTJEY2Fwd2FwLTJEYWx0LTJEdHVubmVsXyZkPUJR TUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFm dWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09WVNUVFR6WmpEakRfZnhSRGJaVFdnVzZ0QnJ3T2Fkb01XN01Q NFJSRkZkUSZzPVp1d1AyVFp5UmVKWG1IOHRIdHQ4QmcwU0RHdm1YMl91bjhUdG1KVTVzUUkmZT0+ ICkuDQoNClRoaXMgZG9jdW1lbnQgaGFzIGFuIGludGVyZXN0aW5nIGhpc3RvcnkgLSBpdCBjb21w bGV0ZWQgV0dMQyBpbiAyMDE0LTA4LTI3IGFuZCB3YXMgc3VibWl0dGVkIHRvIGJlIHB1Ymxpc2hl ZCBhcyBhbiBSRkMgb24gMjAxNC0wOS0wOC4NCg0KV2UgdGhlbiBnb3QgZHJhZnQteW91LW9wc2F3 Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAsIHdoaWNoIGhhZCBzb21lIHNvbWUgc2lnbmlmaWNh bnQgc2ltaWxhcml0aWVzLiBXZSBhc2tlZCB0aGUgQURzIHRvIGhvbGQgYWx0LXR1bm5lbCB3aGls ZSB3ZSBkaXNjdXNzZWQgd2hhdCB0byBkbywgYW5kIHRoZW4gZmluYWxseSBhc2tlZCB0aGUgQURz IC8gSUVTRyB0byByZXR1cm4gaXQgdG8gdGhlIFdHIHNvIHRoYXQgdGhlc2UgdHdvIGRvY3VtZW50 cyBjb3VsZCBiZSBtZXJnZWQgaW50byBvbmUgKCBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL29wc2F3Zy9jdXJyZW50L21zZzA0MDcxLmh0bWw8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFy Y2hpdmVfd2ViX29wc2F3Z19jdXJyZW50X21zZzA0MDcxLmh0bWwmZD1CUU1GYVEmYz1CRnBXUXc4 YnN1S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhw QnNGQSZtPVlTVFRUelpqRGpEX2Z4UkRiWlRXZ1c2dEJyd09hZG9NVzdNUDRSUkZGZFEmcz01OW9j TWtKRFpXXzB0UFV5OVFjY3lqSWM4MVlqcWU1UmhqZ3JDWDBhRzhNJmU9PiApLg0KDQpUaGlzIGRv Y3VtZW50IGhhcyBhbHJlYWR5IHBhc3NlZCBvbmUgV0dMQyAobW9kdWxlIHRoZSBtaW5vciBtZXJn aW5nKSwgYW5kIHdlIGFyZSB3YWl0aW5nIG9uIHRoZSBhdXRob3JzIHRvIGFkZHJlc3Mgc29tZSBj b21tZW50cyAoZS5nOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29wc2F3 Zy9jdXJyZW50L21zZzA0MTYxLmh0bWw8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVfd2ViX29wc2F3 Z19jdXJyZW50X21zZzA0MTYxLmh0bWwmZD1CUU1GYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRR JnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNGQSZtPVlTVFRUelpq RGpEX2Z4UkRiWlRXZ1c2dEJyd09hZG9NVzdNUDRSUkZGZFEmcz1ZMjRVSHY0djU0eGc3cmdXS0hp dmY4eGJlT1JXQllkM3NqZzZTSmcxdDJ3JmU9PiApIGFuZCB1cGRhdGUgdGhlIGVtYWlsIGFkZHJl c3NlcyAtIG9uY2UgdGhhdCBoYXBwZW5zIHdlIHdpbGwgZG8gYW5vdGhlciBXR0xDIC0tIGJ1dCwg d2hpbGUgd2UgYXJlIHdhaXRpbmcsIHdlJ2QgYXBwcmVjaWF0ZSBhbnkgb3RoZXIgcmV2aWV3IGFu ZCBmZWVkYmFjay4NCg0KVw0K --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF1B1D5AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBoYXZlIHJldmlld2VkIHRoZSBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGlzIGRvY3Vt ZW50LiBJIGRvIG5vdCBmaW5kIHNpZ25pZmljYW50IGNoYW5nZXMgaW4gdGhlIGNvbnRlbnQgc2lu Y2UuIEkgYmVsaWV2ZSB0aGF0IGl04oCZcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFGQUlLIHRoZSBkb2N1bWVudCB3YXMgYWxzbyByZXZpZXdlZCBieSBJRUVFIDgwMi4xMS4g SSBhbSBjb3B5aW5nIHRoZSBEb3JvdGh5IFN0YW5sZXkgd2hvIGlzIHRoZSBsaWFpc29uIG1hbmFn ZXIsIGFzIEkgZG8gbm90IGtub3cgaWYgc2hlIGlzIHN1YnNjcmliZWQgdG8gdGhlDQogV0cgbWFp bCBsaXN0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldhcnJlbiBLdW1hcmk8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBGZWJydWFyeSAxNywgMjAxNiAxMjozMSBBTTxicj4NCjxiPlRvOjwvYj4gb3Bz YXdnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPUFNBV0ddIFJldmlldyBvZiAmcXVv dDtBbHRlcm5hdGUgVHVubmVsIEVuY2Fwc3VsYXRpb24gZm9yIERhdGEgRnJhbWVzIGluIENBUFdB UCZxdW90OyAtIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVubmVsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgT3BzQVdHLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgd2UgaGF2 ZSBsb3RzIG9mIGVuZXJneSAvIGludGVyZXN0LCB3ZSdkIGFwcHJlY2lhdGUgc29tZSBhZGRpdGlv bmFsIHJldmlldyBvZiZuYnNwO2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVubmVsICg8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRvcHNhd2ctMkRjYXB3 YXAtMkRhbHQtMkR0dW5uZWxfJmFtcDtkPUJRTUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpI NjRRJmFtcDtyPUk0ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmYW1w O209WVNUVFR6WmpEakRfZnhSRGJaVFdnVzZ0QnJ3T2Fkb01XN01QNFJSRkZkUSZhbXA7cz1adXdQ MlRaeVJlSlhtSDh0SHR0OEJnMFNER3ZtWDJfdW44VHRtSlU1c1FJJmFtcDtlPSI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5u ZWwvPC9hPiZuYnNwOykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgZG9jdW1lbnQgaGFzIGFuIGludGVyZXN0aW5nIGhpc3RvcnkgLSBp dCBjb21wbGV0ZWQgV0dMQyBpbiZuYnNwOzIwMTQtMDgtMjcgYW5kIHdhcyBzdWJtaXR0ZWQgdG8g YmUgcHVibGlzaGVkIGFzIGFuIFJGQyBvbiZuYnNwOzIwMTQtMDktMDguPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHRoZW4gZ290Jm5ic3A7 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLTwv c3Bhbj5zZXBhcmF0aW9uLWZvci1tcCwgd2hpY2ggaGFkIHNvbWUgc29tZSBzaWduaWZpY2FudCBz aW1pbGFyaXRpZXMuIFdlIGFza2VkIHRoZSBBRHMgdG8gaG9sZCBhbHQtdHVubmVsIHdoaWxlIHdl Jm5ic3A7ZGlzY3Vzc2VkJm5ic3A7d2hhdCB0byBkbywgYW5kIHRoZW4gZmluYWxseSBhc2tlZCB0 aGUgQURzDQogLyBJRVNHIHRvIHJldHVybiBpdCB0byB0aGUgV0cgc28gdGhhdCB0aGVzZSB0d28g ZG9jdW1lbnRzIGNvdWxkIGJlIG1lcmdlZCBpbnRvIG9uZSAoJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbC0yRGFyY2hpdmVfd2ViX29wc2F3Z19jdXJyZW50X21zZzA0MDcxLmh0bWwmYW1wO2Q9 QlFNRmFRJmFtcDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9STRkekd4UjMxT2NOWENK ZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNGQSZhbXA7bT1ZU1RUVHpaakRqRF9meFJEYlpUV2dX NnRCcndPYWRvTVc3TVA0UlJGRmRRJmFtcDtzPTU5b2NNa0pEWldfMHRQVXk5UWNjeWpJYzgxWWpx ZTVSaGpnckNYMGFHOE0mYW1wO2U9Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL29wc2F3Zy9jdXJyZW50L21zZzA0MDcxLmh0bWw8L2E+Jm5ic3A7KS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVudCBo YXMgYWxyZWFkeSBwYXNzZWQgb25lIFdHTEMgKG1vZHVsZSB0aGUgbWlub3IgbWVyZ2luZyksIGFu ZCB3ZSBhcmUgd2FpdGluZyBvbiB0aGUgYXV0aG9ycyB0byBhZGRyZXNzIHNvbWUgY29tbWVudHMg KGUuZzombmJzcDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfb3BzYXdnX2N1 cnJlbnRfbXNnMDQxNjEuaHRtbCZhbXA7ZD1CUU1GYVEmYW1wO2M9QkZwV1F3OGJzdUtwbDFTZ2la SDY0USZhbXA7cj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJmFt cDttPVlTVFRUelpqRGpEX2Z4UkRiWlRXZ1c2dEJyd09hZG9NVzdNUDRSUkZGZFEmYW1wO3M9WTI0 VUh2NHY1NHhnN3JnV0tIaXZmOHhiZU9SV0JZZDNzamc2U0pnMXQydyZhbXA7ZT0iPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb3BzYXdnL2N1cnJlbnQvbXNnMDQxNjEuaHRt bDwvYT4mbmJzcDspDQogYW5kIHVwZGF0ZSB0aGUgZW1haWwgYWRkcmVzc2VzIC0gb25jZSB0aGF0 IGhhcHBlbnMgd2Ugd2lsbCBkbyZuYnNwO2Fub3RoZXImbmJzcDtXR0xDIC0tIGJ1dCwgd2hpbGUg d2UgYXJlIHdhaXRpbmcsIHdlJ2QmbmJzcDthcHByZWNpYXRlJm5ic3A7YW55IG90aGVyIHJldmll dyBhbmQgZmVlZGJhY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF1B1D5AZFFEXMB04globa_-- From nobody Wed Feb 17 03:05:38 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848401B38BE for ; Wed, 17 Feb 2016 03:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 jfetoPBKm7Nk for ; Wed, 17 Feb 2016 03:05:34 -0800 (PST) Received: from mail.tpip.net (mail.tpip.net [92.43.49.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA3B1B38C1 for ; Wed, 17 Feb 2016 03:05:33 -0800 (PST) Received: from office.tpip.net (office.tpip.net [92.43.51.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tpip.net (Postfix) with ESMTPS id 7B3634F404; Wed, 17 Feb 2016 11:05:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by office.tpip.net (Postfix) with ESMTP id 216A3A3066; Wed, 17 Feb 2016 12:06:25 +0100 (CET) Received: from office.tpip.net ([127.0.0.1]) by localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id alfi8sljfC56; Wed, 17 Feb 2016 12:06:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by office.tpip.net (Postfix) with ESMTP id 992CDA306D; Wed, 17 Feb 2016 12:06:24 +0100 (CET) X-Virus-Scanned: amavisd-new at tpip.net Received: from office.tpip.net ([127.0.0.1]) by localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aFcmriLMH5-e; Wed, 17 Feb 2016 12:06:24 +0100 (CET) Received: from [192.168.13.53] (unknown [192.168.13.53]) by office.tpip.net (Postfix) with ESMTPSA id 3AEBBA3066; Wed, 17 Feb 2016 12:06:24 +0100 (CET) To: "Romascanu, Dan (Dan)" , Warren Kumari , "opsawg@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA6BF1B1D5@AZ-FFEXMB04.global.avaya.com> From: Andreas Schultz Message-ID: <56C453F9.8080406@tpip.net> Date: Wed, 17 Feb 2016 12:05:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF1B1D5@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Dorothy Stanley Subject: Re: [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 11:05:36 -0000 Hi, On 02/17/2016 11:36 AM, Romascanu, Dan (Dan) wrote: > Hi, > > I have reviewed the previous versions of this document. I do not find s= ignificant changes in the content since. I believe that it=92s ready > for publication. The comments in https://www.ietf.org/mail-archive/web/opsawg/current/msg0= 4161.html have not yet been addressed. Having written those comment, I obviously feel that there should be some = changes made before publication. Regards Andreas > AFAIK the document was also reviewed by IEEE 802.11. I am copying the D= orothy Stanley who is the liaison manager, as I do not know if she is > subscribed to the WG mail list. > > Regards, > > Dan > > *From:*OPSAWG [mailto:opsawg-bounces@ietf.org] *On Behalf Of *Warren Ku= mari > *Sent:* Wednesday, February 17, 2016 12:31 AM > *To:* opsawg@ietf.org > *Subject:* [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data = Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel > > Dear OpsAWG, > > While we have lots of energy / interest, we'd appreciate some additiona= l review of draft-ietf-opsawg-capwap-alt-tunnel > (https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ > ). > > This document has an interesting history - it completed WGLC in 2014-08= -27 and was submitted to be published as an RFC on 2014-09-08. > > We then got draft-you-opsawg-capwap-separation-for-mp, which had some s= ome significant similarities. We asked the ADs to hold alt-tunnel > while we discussed what to do, and then finally asked the ADs / IESG to= return it to the WG so that these two documents could be merged into > one ( https://www.ietf.org/mail-archive/web/opsawg/current/msg04071.htm= l > ). > > This document has already passed one WGLC (module the minor merging), a= nd we are waiting on the authors to address some comments (e.g: > https://www.ietf.org/mail-archive/web/opsawg/current/msg04161.html > ) > and update the email addresses - once that happens we will do another W= GLC -- but, while we are waiting, we'd appreciate any other review > and feedback. > > W > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Thu Feb 18 01:57:59 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9072C1B31BA for ; Thu, 18 Feb 2016 01:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, WEIRD_PORT=0.001] autolearn=ham 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 fhResuH_za01 for ; Thu, 18 Feb 2016 01:57:55 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDED11B3459 for ; Thu, 18 Feb 2016 01:57:53 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1E92E43AE1 for ; Thu, 18 Feb 2016 10:57:52 +0100 (CET) To: opsawg@ietf.org References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56C5959F.7050906@restena.lu> Date: Thu, 18 Feb 2016 10:57:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3o2gTUPXbJ3STQUNOQdEihBC9H9uSgBRn" Archived-At: Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 09:57:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3o2gTUPXbJ3STQUNOQdEihBC9H9uSgBRn Content-Type: multipart/mixed; boundary="------------050606050308080005000209" This is a multi-part message in MIME format. --------------050606050308080005000209 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > This is the second of three messages [0] to determine what the OpsAWG > should do with TACACS+ >=20 > Should the ID, as presented, or as revised by the WG, be published as > one or more RFCs? Yes, in multiple RFCs. The RFC describing the current state has to be Informational; if that's not happening, my answer converts retroactively into a No. Greetings, Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------050606050308080005000209 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------050606050308080005000209-- --3o2gTUPXbJ3STQUNOQdEihBC9H9uSgBRn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWxZWgAAoJEMDeajWKOdxmD3IP/3CF2ouNjngsGfv2wSiF2lvU xqy9BKQPWf+AahH4j23Cg+4u8X1uv0BOm8fVDKv51q7y1sz/nR3i1D0rEe5HfiE9 zLsAe2NS9hKgYmRwFryre2mcs4qXM3SEGvV1YlKzwHjQewj3GBtrPI9bBB9DOt6O yH0xJihrXFsL7e1zClJKXJb5BUk41yuOF/9seVm45j1Zku24HjhMoZ+UEkRLmJlj /pBjoMWcgF0nFwq/cF6u8c9yNQH2qw9xuv9K1G1Yz5DhBTQjrebOtvdGL7qJpVIO b8XnysiqgRoWdxIU7gduiR2gH4AguFjaLlh9Yo22EE7HcoaUNSRxuffJmcfePbIg pZYeWGhGq85pM9qXcRtze4QzSEJ6xMuExkHkV43Re1P/9FU2udSM/cYbr3GGMaDr Zmfb2kdfj08ZtO1A0J6NSAw3jjKFDm6HscVng04q3msWPMB60IcjpciQu5jShBwa P0f4mgPoVQcNjh2XwH7S5daevfXtBi44CMb2tG+rKLul21QUqRBQXKtlWF+J0Xnj DmNAMxZsqYQ9hHwpib9gt6dJ4bWfdIm5O8lE04GvKcfH7oLB3wxSyHROrCCUIWXH 0xVrYLGoUZwzIJIfd6txVwyl9fQ0kPk6DI3yenhPl6jWmrlQq5JffRMeDMTnPW4S qh171/jeHvZ0e5iOlTkm =wPkS -----END PGP SIGNATURE----- --3o2gTUPXbJ3STQUNOQdEihBC9H9uSgBRn-- From nobody Thu Feb 18 02:00:28 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46FD1B3BAC for ; Thu, 18 Feb 2016 02:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, WEIRD_PORT=0.001] autolearn=ham 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 ncEFCAJqszSx for ; Thu, 18 Feb 2016 02:00:26 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498D11B3B3F for ; Thu, 18 Feb 2016 02:00:26 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id AA60243AE3 for ; Thu, 18 Feb 2016 11:00:24 +0100 (CET) To: opsawg@ietf.org References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56C59638.8080607@restena.lu> Date: Thu, 18 Feb 2016 11:00:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="P1bMMJJed8GwTpekR7LFJxVahMajemrL9" Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 10:00:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P1bMMJJed8GwTpekR7LFJxVahMajemrL9 Content-Type: multipart/mixed; boundary="------------070709040604010405060200" This is a multi-part message in MIME format. --------------070709040604010405060200 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > This is the third of 3 messages to determine what the OpsAWG should do > with TACACS+. >=20 > If the answer to the previous question is yes, should the RFC describin= g > the protocol itself (as opposed to any other document that might > describe appropriate use) be published as a standards track RFC? That's a trick question; "the protocol itself" definition is what is under debate right now. Is "the protocol itself" TACACS+ as deployed today? Or is it TACACS+ with additions? If the former: No, it should be Informational. If the latter: My answer to Question 2 is now a No. Greetings, Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------070709040604010405060200 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------070709040604010405060200-- --P1bMMJJed8GwTpekR7LFJxVahMajemrL9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWxZY4AAoJEMDeajWKOdxmo6IQAM2lD+H8ZdTqMLxOUvqBq1X6 1ZrgEKb+mPmR3vIGBjVMcE4GVLyxW8QLc4WWUKoIPkhOPIRn9ygQZSMQHF4aV5VN Bb4Gey8eSpYRwn/FVgoWuD3RS/sfcTY0I9xgyfDu+ou8/081QOvLyxxeeS/zK+XY VIgYuc9itS65L+dd5D7+JaYzf/dRUIttKeafiLhyeZVKTn8PkDetLc33TRgiwyfu bp/pRfglPtyeEpDRXCCK/BMvhkEpIY2oLgnPD76WuLPl9rLO7FPWGsE90XRFm7u4 1AOJbujRcl9+RZlkZxt2CbFIILWvKGCMQy4kXEJ80Qv6QU72WQqjmV7uFWW2kh0X HlCyxX8Ln99Vbi9eKXF7sjCAljXHfN+gXH0cOJN2Jwv4Ga9BO3aazY5MS2NXMJZj KeBsJ5BDcl4vP6FSzxNND9ifzF6Z1w8m6gUAMcIuzRI5/XJ7ZS/cZfnnmMiV2fOv 51SiMfirmZK27D8lr37T6be4R3lFjPWr3VS3A5FMI00b2YN5NZ2CJ6n8poVb1aU8 xTl0tjYgPnrRt7AwEoGcYRsq7IbDGCPob46cpHWTTiV6O0wTFlnZ38S3T7JQoSha Hf8n2Q8+Cb+brxQDvvwphTSCBFux9w7O5uPL37webghBbNqZ7Ssd8ai7VeFMZD6e NazEt1H9Y/fLrmSkLT49 =iiiH -----END PGP SIGNATURE----- --P1bMMJJed8GwTpekR7LFJxVahMajemrL9-- From nobody Thu Feb 18 07:17:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AF41A8AC0 for ; Thu, 18 Feb 2016 07:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 7HTTGxWQklvF for ; Thu, 18 Feb 2016 07:17:36 -0800 (PST) Received: from magic.dirtside.com (magic.dirtside.com [70.184.240.83]) by ietfa.amsl.com (Postfix) with ESMTP id 34B1F1A8BBD for ; Thu, 18 Feb 2016 07:17:35 -0800 (PST) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id u1IFHSg0031822 for ; Thu, 18 Feb 2016 10:17:28 -0500 X-Really-To: Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 14F8EEBDB5 for ; Thu, 18 Feb 2016 10:17:28 -0500 (EST) Received: by mail-io0-f174.google.com with SMTP id z135so76779142iof.0 for ; Thu, 18 Feb 2016 07:17:28 -0800 (PST) X-Gm-Message-State: AG10YOThX1a1HyM/YR+J4yrK5cPF/7WdCcy99mmJrpT2mE0gqzsX4Mxqepr3ksWWepmFaJ5VYmHktsoozg3W9w== X-Received: by 10.107.164.15 with SMTP id n15mr8631034ioe.148.1455808647556; Thu, 18 Feb 2016 07:17:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.216.42 with HTTP; Thu, 18 Feb 2016 07:17:08 -0800 (PST) In-Reply-To: References: From: William Herrin Date: Thu, 18 Feb 2016 10:17:08 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Warren Kumari Content-Type: text/plain; charset=UTF-8 X-Spam-Checker: magic.dirtside.com Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:17:41 -0000 On Mon, Feb 15, 2016 at 3:14 PM, Warren Kumari wrote: > Should the ID, as presented, or as revised by the WG, be published as one or > more RFCs? Greetings, I would not object to an informational RFC documenting a widely used protocol regardless of whether the IETF controls the standardization of that protocol. I have two caveats: 1. Whoever controls standardization of the protocol must not object to the RFC. 2. If a vendor or other third party controls standardization of a protocol and does not elect to cede standardization of the protocol to the IETF then the IETF must not develop, revise or improve the protocol in any way. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: From nobody Thu Feb 18 07:19:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700AC1AD34F for ; Thu, 18 Feb 2016 07:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dfpb1DRi272J for ; Thu, 18 Feb 2016 07:19:03 -0800 (PST) Received: from magic.dirtside.com (magic.dirtside.com [70.184.240.83]) by ietfa.amsl.com (Postfix) with ESMTP id F07501AD37B for ; Thu, 18 Feb 2016 07:19:02 -0800 (PST) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id u1IFIuHK031903 for ; Thu, 18 Feb 2016 10:18:57 -0500 X-Really-To: Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id BA3F5EBD58 for ; Thu, 18 Feb 2016 10:18:56 -0500 (EST) Received: by mail-ig0-f177.google.com with SMTP id y8so16017208igp.0 for ; Thu, 18 Feb 2016 07:18:56 -0800 (PST) X-Gm-Message-State: AG10YOT7EPS8lVWS7ZrqZNuB+CIaL+jXA3tOfCcLkiaBrEUif4hngdP4lP1PNBkQtyHrJqQ+ooZhOo617Nj9LQ== X-Received: by 10.50.147.34 with SMTP id th2mr3672431igb.27.1455808736393; Thu, 18 Feb 2016 07:18:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.216.42 with HTTP; Thu, 18 Feb 2016 07:18:36 -0800 (PST) In-Reply-To: References: From: William Herrin Date: Thu, 18 Feb 2016 10:18:36 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Warren Kumari Content-Type: text/plain; charset=UTF-8 X-Spam-Checker: magic.dirtside.com Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:19:04 -0000 On Mon, Feb 15, 2016 at 3:16 PM, Warren Kumari wrote: > If the answer to the previous question is yes, should the RFC describing the > protocol itself (as opposed to any other document that might describe > appropriate use) be published as a standards track RFC? Greetings, In my opinion, IETF standards track RFCs should be reserved for protocols for which further development is expected to occur primarily within the IETF framework. As I understand the situation (feel free to correct me if I'm wrong), TACACS+ is a vendor maintained standard, specifically Cisco. Regardless of publication, Cisco intends to retain control of the standard and its future development. If my understanding is correct, TACACS+ should not be presented as an IETF standards track RFC. I would remind folks that it's perfectly OK for a network protocol to be a standard without it being an _IETF_ standard. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: From nobody Thu Feb 18 07:28:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388C01ACEB1 for ; Thu, 18 Feb 2016 07:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 qrLnkYe5REN2 for ; Thu, 18 Feb 2016 07:28:38 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A01E1A9143 for ; Thu, 18 Feb 2016 07:28:38 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:705e:14d0:a2e8:d784]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1IFSTmI050313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Feb 2016 15:28:29 GMT (envelope-from joelja@bogus.com) To: William Herrin , Warren Kumari References: From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> Date: Thu, 18 Feb 2016 07:28:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nKfATD1jd6bSe11jWwoR02VeXWn6pDvH4" Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:28:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nKfATD1jd6bSe11jWwoR02VeXWn6pDvH4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/18/16 7:18 AM, William Herrin wrote: > On Mon, Feb 15, 2016 at 3:16 PM, Warren Kumari wrot= e: >> If the answer to the previous question is yes, should the RFC describi= ng the >> protocol itself (as opposed to any other document that might describe >> appropriate use) be published as a standards track RFC? >=20 > Greetings, >=20 > In my opinion, IETF standards track RFCs should be reserved for > protocols for which further development is expected to occur primarily > within the IETF framework. As I understand the situation (feel free to > correct me if I'm wrong), TACACS+ is a vendor maintained standard, > specifically Cisco. Regardless of publication, Cisco intends to retain > control of the standard and its future development. Assuming the document is split into to pieces here part of goal as I understand it is address the issue of adding ssl to the existing specification in an inter-operable fashion. > If my understanding is correct, TACACS+ should not be presented as an > IETF standards track RFC. > > I would remind folks that it's perfectly OK for a network protocol to > be a standard without it being an _IETF_ standard. >=20 > Regards, > Bill Herrin >=20 --nKfATD1jd6bSe11jWwoR02VeXWn6pDvH4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbF4x0ACgkQ8AA1q7Z/VrK0gwCZAWwFkJnN6TDZUSLN9StPkPjZ gxwAni9xIrPgim/sq0K6ew6jB3G214hG =a1F7 -----END PGP SIGNATURE----- --nKfATD1jd6bSe11jWwoR02VeXWn6pDvH4-- From nobody Thu Feb 18 12:05:10 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8BA1B2CD1 for ; Thu, 18 Feb 2016 12:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pLsapRYqv_nr for ; Thu, 18 Feb 2016 12:05:01 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0EC11B3471 for ; Thu, 18 Feb 2016 12:02:49 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id bc4so35160815lbc.2 for ; Thu, 18 Feb 2016 12:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DNr3SRYlx1dksgH8zVlQjwdim4qA73Kk3VCunXY/kWM=; b=Ea4zBzMuyLvhBgEP8qWEEuBtIlHmNiv7gj14MaG0av6LgIxLrECkn0/kZOnBt6mLSB 0FFP1N8dyyn6d8dJKvfIky+8XBuWTGBGl4TeVWe4QWOd08XPqba3s6ien/OYAjo4hVSx V8gJ6/cCybUBSXRcY3iesiFJvEgtDU2snd6bYseFX1AxaqNXWVecLKZY2rL3hcyVBYcK WmsXn6uNZdAQErUrX+6/yYBCWDLJreWpgrpUHgQ3TDVpK9sVtVYh6b/QgE6WUbZ2gewE KGH21fvqkYQD50mtHf5ZbQVOqJE66C2AG0vnKbmlt8pDXeMgiacaxuP7rBcuQQXXClvO 5R+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DNr3SRYlx1dksgH8zVlQjwdim4qA73Kk3VCunXY/kWM=; b=KyBm3j3mTS6EC+JJ9K5YArdizPbQfmxOeo6jAo27s0fXooQ+Uelqu2+EL05KMnUdXv 1tbzBBe6hjirsY3ohpoiRMI4kvun8s2ojdumUyRwCV6mUwydnLNMpKWUdmPboIsbeBGT kzn8mplb8OCZEIxTonlbW5eBRz5FiAqJImezZVI2QluetvRklNRtcXNd7WBc2RMaT1w+ 7ZySL/CHY9cON+ohLofkvMBcg/3LhTGbutk6KuvDPxRoJKh2gFjowIk6K4ZeEJBfHPO5 yThfPrSWZlgto5yEwShVzGYWMqYkgw22wOcJsriwFIllYH7klzMgcxTIpbK+LPziP8Dn dong== X-Gm-Message-State: AG10YOTMPYKFw3oygYlwwt8ifmIcEtdf/Gs7gYNESFkOFBoWjfjmJwOcd3ZeEFGBLJ30wOdiSc2EGgRfptWhSA== MIME-Version: 1.0 X-Received: by 10.112.131.37 with SMTP id oj5mr3296294lbb.94.1455825767821; Thu, 18 Feb 2016 12:02:47 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 18 Feb 2016 12:02:47 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2016 12:02:47 -0800 Message-ID: From: Andy Bierman To: William Herrin Content-Type: multipart/alternative; boundary=047d7b343ba2bf0ce1052c10d98e Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 20:05:07 -0000 --047d7b343ba2bf0ce1052c10d98e Content-Type: text/plain; charset=UTF-8 On Thu, Feb 18, 2016 at 7:18 AM, William Herrin wrote: > On Mon, Feb 15, 2016 at 3:16 PM, Warren Kumari wrote: > > If the answer to the previous question is yes, should the RFC describing > the > > protocol itself (as opposed to any other document that might describe > > appropriate use) be published as a standards track RFC? > > Greetings, > > In my opinion, IETF standards track RFCs should be reserved for > protocols for which further development is expected to occur primarily > within the IETF framework. As I understand the situation (feel free to > correct me if I'm wrong), TACACS+ is a vendor maintained standard, > specifically Cisco. Regardless of publication, Cisco intends to retain > control of the standard and its future development. > > I think in order for WG consensus to determine decisions wrt/ this document, it would no longer be a Cisco protocol. Cisco would have to give all change control authority to the IETF. Maybe an expert on IETF process (like Scott) can clarify. Andy If my understanding is correct, TACACS+ should not be presented as an > IETF standards track RFC. > > I would remind folks that it's perfectly OK for a network protocol to > be a standard without it being an _IETF_ standard. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin@dirtside.com bill@herrin.us > Owner, Dirtside Systems ......... Web: > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --047d7b343ba2bf0ce1052c10d98e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 18, 2016 at 7:18 AM, William Herrin <<= a href=3D"mailto:bill@herrin.us" target=3D"_blank">bill@herrin.us> wrote:
On Mon, Feb 15, 2016 at 3:16= PM, Warren Kumari <warren@kumari.n= et> wrote:
> If the answer to the previous question is yes, should the RFC describi= ng the
> protocol itself (as opposed to any other document that might describe<= br> > appropriate use) be published as a standards track RFC?

Greetings,

In my opinion, IETF standards track RFCs should be reserved for
protocols for which further development is expected to occur primarily
within the IETF framework. As I understand the situation (feel free to
correct me if I'm wrong), TACACS+ is a vendor maintained standard,
specifically Cisco. Regardless of publication, Cisco intends to retain
control of the standard and its future development.



I think in order for WG= consensus to determine decisions wrt/ this document,
it would no= longer be a Cisco protocol.=C2=A0 Cisco would have to give all change cont= rol
authority to the IETF.=C2=A0 Maybe an expert on IETF process = (like Scott) can clarify.


Andy


If my understanding is correct, TACACS+ should not be presented as an
IETF standards track RFC.

I would remind folks that it's perfectly OK for a network protocol to be a standard without it being an _IETF_ standard.

Regards,
Bill Herrin

--
William Herrin ................ herr= in@dirtside.com=C2=A0 bill@herrin.us<= /a>
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/><= br>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--047d7b343ba2bf0ce1052c10d98e-- From nobody Thu Feb 18 12:08:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A73E1B2C46 for ; Thu, 18 Feb 2016 12:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6aLFDZ8dko_e for ; Thu, 18 Feb 2016 12:08:03 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B481AD0D6 for ; Thu, 18 Feb 2016 12:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1459; q=dns/txt; s=iport; t=1455826083; x=1457035683; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=h+6WIoOTP/h3fEkIIS7bIfz+OjxgSESBY66pw7w3By8=; b=eswoFvkErGYV0PR8i8hlTxaWLfqZu3yTqbutDeyA8WbJxLI+X2dFsaee VTObi6gRVtR/wp3Gc6Nl8VN4AXhX8U7PF5b0mTydf1W/hKm5I/jy8H190 JH6v3rhjYhaV3c4MZ8/dO7aPZKQPIjBUx1ITl5qtt5QnhpahDXR886uu+ 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfBwCrI8ZW/xbLJq1et32FD4QIhg0Cg?= =?us-ascii?q?jQBAQEBAQFlJ4RCAQEEI0gNARALGAkWCwICCQMCAQIBRQYBDAgBAYgWrQqPEAE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEPCIpNhzWBOgEEjSmJXIMFgWSDWIUZiSGFUo5HY?= =?us-ascii?q?oNkO4lNAQEB?= X-IronPort-AV: E=Sophos;i="5.22,467,1449532800"; d="asc'?scan'208";a="635589158" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2016 20:08:01 +0000 Received: from [10.61.99.158] (dhcp-10-61-99-158.cisco.com [10.61.99.158]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1IK800V000563; Thu, 18 Feb 2016 20:08:00 GMT To: Andy Bierman , William Herrin References: From: Eliot Lear Message-ID: <56C624A1.6090604@cisco.com> Date: Thu, 18 Feb 2016 21:08:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iinWIxec4uJoLdVfUjonwxkPtg1xe7JTC" Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 20:08:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iinWIxec4uJoLdVfUjonwxkPtg1xe7JTC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/18/16 9:02 PM, Andy Bierman wrote: > > I think in order for WG consensus to determine decisions wrt/ this > document, > it would no longer be a Cisco protocol. Cisco would have to give all > change control > authority to the IETF. Maybe an expert on IETF process (like Scott) > can clarify. > That is the deal, no matter the vendor, when something becomes an IETF standard. And this is why I say, let's see where we land before having to cough up two documents, when one might do just fine. Eliot --iinWIxec4uJoLdVfUjonwxkPtg1xe7JTC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWxiSiAAoJEIe2a0bZ0nozCqMIAMy8rpgHWeoIBNaSmQi+zwvi XumNJnDD6Jh3giCrmQa3QXKoHQNDI/MFJTN2vERdosdDQ3Tdt8Qvb0PeWhcOcQqs 0eMRyIxsw5KSD/1q01WxzVQD5faSxSnfucmsuQXfsKwQhy7inrOp5ExIBYa/EeXZ mbSRm0BB6M6eUhXjFHqtqbDrA+1Mna78J0WsjUwG/xDaQJpFNQF0nGS8CGEHe4t/ OzP1hUKRBiENn10NZECRRpekG/0o5pxib1WprZIRiNMP8uTpsAatO6OglCCA1lFW awFfnAeqQEjzcP/6TbHVJX6K89hayDMQt6hBqZuqT7iD42DMyjJgr22237jFvpM= =NZpB -----END PGP SIGNATURE----- --iinWIxec4uJoLdVfUjonwxkPtg1xe7JTC-- From nobody Thu Feb 18 12:17:10 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77F41ACDFD for ; Thu, 18 Feb 2016 12:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 ZTsW7AdxPjsH for ; Thu, 18 Feb 2016 12:17:03 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E622F1A8ACA for ; Thu, 18 Feb 2016 12:17:02 -0800 (PST) Received: from [21.63.27.137] ([172.56.39.30]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1IKGg1V052058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2016 20:16:45 GMT (envelope-from joelja@bogus.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (13D15) In-Reply-To: <56C624A1.6090604@cisco.com> Date: Thu, 18 Feb 2016 12:16:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4F839D13-EC16-4EDF-9B90-7F4B050AD5AE@bogus.com> References: <56C624A1.6090604@cisco.com> To: Eliot Lear Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 20:17:08 -0000 Sent from my iPhone > On Feb 18, 2016, at 12:08, Eliot Lear wrote: >=20 >=20 >=20 >> On 2/18/16 9:02 PM, Andy Bierman wrote: >>=20 >> I think in order for WG consensus to determine decisions wrt/ this >> document, >> it would no longer be a Cisco protocol. Cisco would have to give all >> change control >> authority to the IETF. Maybe an expert on IETF process (like Scott) >> can clarify. >=20 > That is the deal, no matter the vendor, when something becomes an IETF > standard. And this is why I say, let's see where we land before having > to cough up two documents, when one might do just fine. When we say something is adopted by the working group indeed the working gro= up now has change control. Thier is bit of give and take required to bring w= ork here. >=20 > Eliot >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Feb 18 13:18:12 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699981A0405 for ; Thu, 18 Feb 2016 13:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 qfkxB9CvkO-6 for ; Thu, 18 Feb 2016 13:18:04 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C356C1A90E6 for ; Thu, 18 Feb 2016 13:17:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id D60731632E42; Thu, 18 Feb 2016 16:17:54 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvYvVYlVFK14; Thu, 18 Feb 2016 16:17:53 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id EAA8F1632E2C; Thu, 18 Feb 2016 16:17:53 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Scott O. Bradner" In-Reply-To: Date: Thu, 18 Feb 2016 16:17:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <829E6B90-4B31-41A4-A6F5-09F74CDDA4F4@sobco.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 21:18:10 -0000 as requested: the IETF requires the ability to make directive works and the submission = of of the ID=20 for publication did that=20 the IETF does not require (but likes to have ) =E2=80=9Cchange = control=E2=80=9D on the underlying technology where the originating company agrees to not further develop a branch of = the technology=20 and call it by the same name - we have only officially gotten that in a = very few cases (e.g. NFS - see RFC 1790) The IETF did not even get change control in = the case of MPLS (a.k.a Tag Switching) but did go right ahead and develop MPLS so in almost all cases the IETF proceeds with the assurance by the = authors of an ID that they have the right to contribute the text to the IETF=20 note that any patent issues are completely separate from the copyright = and =E2=80=9Cchange control=E2=80=9D Scott > On Feb 18, 2016, at 3:02 PM, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Feb 18, 2016 at 7:18 AM, William Herrin = wrote: > On Mon, Feb 15, 2016 at 3:16 PM, Warren Kumari = wrote: > > If the answer to the previous question is yes, should the RFC = describing the > > protocol itself (as opposed to any other document that might = describe > > appropriate use) be published as a standards track RFC? >=20 > Greetings, >=20 > In my opinion, IETF standards track RFCs should be reserved for > protocols for which further development is expected to occur primarily > within the IETF framework. As I understand the situation (feel free to > correct me if I'm wrong), TACACS+ is a vendor maintained standard, > specifically Cisco. Regardless of publication, Cisco intends to retain > control of the standard and its future development. >=20 >=20 >=20 > I think in order for WG consensus to determine decisions wrt/ this = document, > it would no longer be a Cisco protocol. Cisco would have to give all = change control > authority to the IETF. Maybe an expert on IETF process (like Scott) = can clarify. >=20 >=20 > Andy >=20 >=20 > If my understanding is correct, TACACS+ should not be presented as an > IETF standards track RFC. >=20 > I would remind folks that it's perfectly OK for a network protocol to > be a standard without it being an _IETF_ standard. >=20 > Regards, > Bill Herrin >=20 > -- > William Herrin ................ herrin@dirtside.com bill@herrin.us > Owner, Dirtside Systems ......... Web: >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Feb 18 13:35:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4B61B3297 for ; Thu, 18 Feb 2016 13:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 w4bCMxbrsryJ for ; Thu, 18 Feb 2016 13:35:45 -0800 (PST) Received: from magic.dirtside.com (magic.dirtside.com [70.184.240.83]) by ietfa.amsl.com (Postfix) with ESMTP id DE4D21A09CF for ; Thu, 18 Feb 2016 13:25:50 -0800 (PST) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id u1ILPdwK009433 for ; Thu, 18 Feb 2016 16:25:40 -0500 X-Really-To: Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id A9FCFEBD82 for ; Thu, 18 Feb 2016 16:25:39 -0500 (EST) Received: by mail-ig0-f173.google.com with SMTP id 5so22759785igt.0 for ; Thu, 18 Feb 2016 13:25:39 -0800 (PST) X-Gm-Message-State: AG10YOQqwFkX3VoX5zqviKTXuiTJChJkTvrXnjkCtbsBa9vO4eyQJ6CotZySz31XYvosbV3JFWR69Nje0RU0eA== X-Received: by 10.50.160.7 with SMTP id xg7mr5253659igb.64.1455830739246; Thu, 18 Feb 2016 13:25:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.216.42 with HTTP; Thu, 18 Feb 2016 13:25:19 -0800 (PST) In-Reply-To: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> From: William Herrin Date: Thu, 18 Feb 2016 16:25:19 -0500 X-Gmail-Original-Message-ID: Message-ID: To: joel jaeggli Content-Type: text/plain; charset=UTF-8 X-Spam-Checker: magic.dirtside.com Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 21:35:47 -0000 On Thu, Feb 18, 2016 at 10:28 AM, joel jaeggli wrote: > On 2/18/16 7:18 AM, William Herrin wrote: >> In my opinion, IETF standards track RFCs should be reserved for >> protocols for which further development is expected to occur primarily >> within the IETF framework. As I understand the situation (feel free to >> correct me if I'm wrong), TACACS+ is a vendor maintained standard, >> specifically Cisco. Regardless of publication, Cisco intends to retain >> control of the standard and its future development. > > Assuming the document is split into to pieces here part of goal as I > understand it is address the issue of adding ssl to the existing > specification in an inter-operable fashion. Hi Joel, Is Cisco prepared to cede further change control of the core TACACS+ standard to the IETF process? I have no objection to the IETF absorbing, standardizing and improving the TACACS+ protocol if that is the vendor's desire. I would not want to see multiple standards bodies in control of different little bits of the TACACS+ standard. I think that would sow needless confusion among the folks trying to work with it. I respectfully observe that should Cisco wish to retain control of the core TACACS+ standard, nothing prevents them from adopting a consensus recommendation for security improvements into the standard without any need for IETF publication. In such situations, IETF publication offers little more than bragging rights. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: From nobody Thu Feb 18 15:56:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29891ACD5F for ; Thu, 18 Feb 2016 15:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ac4lLnVia_Fs for ; Thu, 18 Feb 2016 15:56:19 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899271ACD5A for ; Thu, 18 Feb 2016 15:56:19 -0800 (PST) Received: by mail-pa0-x233.google.com with SMTP id fy10so39383971pac.1 for ; Thu, 18 Feb 2016 15:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=GX5FK0FhttiRI465Z9WdDr5oJjPqyeVhWTdJOpCBDIo=; b=XhEYHyBCyaNjOLxhrm9Dl0JJxsgI773jR7lM6JWXCLdgFlDU9ZA5pCgiKHdS1moL0b EZsO4f2fi4n+/XqKt5bxuA70oC94hdD/GshT7v35IGDK+OHJ5s9ohr4eveL/HGYXbpvd nOIf4mj3Isl41ysdxIQO5M8VLZrXo2mU8LvR+txGWTDT6BDH88FftW0xI391JyNvUR+8 ffTLB4h6VHfA23qn/80DdVgo1FMMwuSCA7UKRQD+c9PrdFVW8ivE1otgMW6ijNG20SA+ VxXSQjNBIJzM20VJy9SBm9IugOBUslT+NjZqM4GqYl5BUosGHMOd4AzdX+ZbhJns399T ZZzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=GX5FK0FhttiRI465Z9WdDr5oJjPqyeVhWTdJOpCBDIo=; b=GhXZW28Ob6qkdL50X3H34IQ1bCfLNqEokNDSxb5kuCjlTuS+d7+EJWxUMgZuzm9toD +kLD8uDwdG+fp2k6N8tK6MXyJ2BGVDAny42wTWeboOEyRssLg6EbUPK2skUUsDNCPs8N rugEmbc3GTFmVExwHhoiwILpr6+4Xj09sl82FsCTYPjSBrm0kiDOuyhQh5i6/nF/HIIP 6gSTtkrESqXENF/QY+gx8JLX6tuGL192b061nbziQwV7VcPDDkNiaER6zPaTmW7uVW0+ KyxtV+Dt2EWq6A34vGc40oPe2gM7SjgrdnW6HdclSph2urpUEDudWQRBWsTtGlsHA/qT V4SA== X-Gm-Message-State: AG10YOTk1SR23DrlGlHMzYZ1cyjT9GwAEJAbJq3oLKVEwm7SnA2cwvBaO8V4iUdJ/I+smA== X-Received: by 10.66.228.201 with SMTP id sk9mr14075689pac.1.1455839779185; Thu, 18 Feb 2016 15:56:19 -0800 (PST) Received: from ?IPv6:2406:e007:7581:1:28cc:dc4c:9703:6781? ([2406:e007:7581:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 79sm12920651pfr.22.2016.02.18.15.56.16 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 15:56:17 -0800 (PST) To: opsawg@ietf.org References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56C65A2A.1050304@gmail.com> Date: Fri, 19 Feb 2016 12:56:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 23:56:21 -0000 On 19/02/2016 10:25, William Herrin wrote: > On Thu, Feb 18, 2016 at 10:28 AM, joel jaeggli wrote: >> On 2/18/16 7:18 AM, William Herrin wrote: >>> In my opinion, IETF standards track RFCs should be reserved for >>> protocols for which further development is expected to occur primarily >>> within the IETF framework. As I understand the situation (feel free to >>> correct me if I'm wrong), TACACS+ is a vendor maintained standard, >>> specifically Cisco. Regardless of publication, Cisco intends to retain >>> control of the standard and its future development. >> >> Assuming the document is split into to pieces here part of goal as I >> understand it is address the issue of adding ssl to the existing >> specification in an inter-operable fashion. > > Hi Joel, > > Is Cisco prepared to cede further change control of the core TACACS+ > standard to the IETF process? The IETF deals with individual contributors, not companies. As Scott noted, the authors have already given change control to the IETF by submitting a draft with the appropriate boilerplate. Of course, what any company chooses to actually implement is their own business. Brian From nobody Thu Feb 18 16:52:30 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520E1A6FB5 for ; Thu, 18 Feb 2016 16:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 iGp3piWVfuTE for ; Thu, 18 Feb 2016 16:52:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194651A6FB2 for ; Thu, 18 Feb 2016 16:52:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aWZJ4-00033i-1d; Fri, 19 Feb 2016 00:52:26 +0000 Date: Fri, 19 Feb 2016 13:52:22 +1300 Message-ID: From: Randy Bush To: Andy Bierman In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 00:52:29 -0000 > I think in order for WG consensus to determine decisions wrt/ this > document, it would no longer be a Cisco protocol. Cisco would have to > give all change control authority to the IETF. andy, you have been around for a while. where did you get the idea it was otherwise in the case of this document? this is just another ietf document. it happens to document a protocol used by many operators on many vendors' equipment. where does all this ipr, proprietary, ... paranoia come from? [ that was a rhetorical question; no need to answer ] randy From nobody Thu Feb 18 16:56:40 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E9F1A6F63 for ; Thu, 18 Feb 2016 16:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FoxFrZia2w6E for ; Thu, 18 Feb 2016 16:56:38 -0800 (PST) Received: from magic.dirtside.com (magic.dirtside.com [70.184.240.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4B18C1A6F58 for ; Thu, 18 Feb 2016 16:56:38 -0800 (PST) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id u1J0uWOa014592 for ; Thu, 18 Feb 2016 19:56:32 -0500 X-Really-To: Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 215FBEBD82 for ; Thu, 18 Feb 2016 19:56:32 -0500 (EST) Received: by mail-io0-f176.google.com with SMTP id z135so93797684iof.0 for ; Thu, 18 Feb 2016 16:56:32 -0800 (PST) X-Gm-Message-State: AG10YORC7z16RdNUrePYMuXoZ61QT5wJ2Q3Vjuj07rlGelQXBJbwibSXcq71tKiZnuaWCCNKWSEhxprvXIxgwA== X-Received: by 10.107.15.201 with SMTP id 70mr11298737iop.125.1455843391695; Thu, 18 Feb 2016 16:56:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.216.42 with HTTP; Thu, 18 Feb 2016 16:56:12 -0800 (PST) In-Reply-To: <56C65A2A.1050304@gmail.com> References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> <56C65A2A.1050304@gmail.com> From: William Herrin Date: Thu, 18 Feb 2016 19:56:12 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 X-Spam-Checker: magic.dirtside.com Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 00:56:40 -0000 On Thu, Feb 18, 2016 at 6:56 PM, Brian E Carpenter wrote: > On 19/02/2016 10:25, William Herrin wrote: >> Is Cisco prepared to cede further change control of the core TACACS+ >> standard to the IETF process? > > The IETF deals with individual contributors, not companies. As Scott noted, > the authors have already given change control to the IETF by submitting a > draft with the appropriate boilerplate. > > Of course, what any company chooses to actually implement is their own > business. With due respect Brian, you're talking past the issue. If Cisco, the company, intends to back away from maintaining the core TACACS+ standard in favor of the IETF's process then I see no problem with bringing the protocol into the IETF process. If not, then only sorrow will come from the IETF creating a _competing standard with the same name_. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: From nobody Thu Feb 18 17:09:46 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8EA1A037A for ; Thu, 18 Feb 2016 17:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 ky1_kyTR03In for ; Thu, 18 Feb 2016 17:09:43 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6F11A0334 for ; Thu, 18 Feb 2016 17:09:43 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id l143so44271445lfe.2 for ; Thu, 18 Feb 2016 17:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bthSf/E0WrTviLPtn9/K8+n8Ku9HN6y/cEsVSIYMk/I=; b=kIiivP0oVnvNE2zvVo45gC4eU8JnMyAIdokk5SBMorYwp0Vop6sjUnbZgkLMrpPqHm hJzCwghctSID6RBB1T75K4sVYvq/7BVT73OA+EbThIqnVXALJD/k2Astlkoii2MER/QJ 57sEDx+iVAUpQsVtYkQbxK4DsECCtKQqgelV42Fddve3qUEUWkLCr0igu/7mX1fh1Iid r1lwvP0FSCrA5RjezYAqIvlwzuK7v83RwMzQ7QjBDiXLlwEbtD/a61Nv4x/ZuWbmK1Dd jpnYURwPVgiztPlgUa1aO16DWPCwKDnJt+mWaNuKYQx+IUgp97DM7u56D0+dOlyelCPK Nh2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bthSf/E0WrTviLPtn9/K8+n8Ku9HN6y/cEsVSIYMk/I=; b=Cl1pNaIrbHpbJHjaIkY6IQcbzkx0F8xwFZCi1RN6nG+/MnArLRgvgW69Wf+bo+GUpy dy1J5QuWg96zeknBHde+qBwo+tsD+7PE4xicfCGMBRWzkH6/mm0AFfgK8GobuXqKqOEG VNYPVuOqI6jwT+nlLoXbvkvOJPGZdX7gyIPZXVvTzWyMtC7Q6L5DrUqbQIqo8Yr4XfOi LT117tMAKzLubWZxfCeC2Y6q/G/kSf8THn7H153gvDzy7rhBRFRHMCWbfIXKUCA3+Gdv ngJfVanvnvsT1Vcf9geJvyLpR4CItM85EyIq+nXjPva2/vF1Lv6vpgJl0pZuCYUNoq8U P5dQ== X-Gm-Message-State: AG10YOQjSidz+foMLUqaENIfjSmlWXPqkLxTmjGorsJWVfvj4qI7PfHyopH7ITFfw8r5hKS9ykfoDf08XkBVCQ== MIME-Version: 1.0 X-Received: by 10.25.16.214 with SMTP id 83mr4399477lfq.13.1455844181447; Thu, 18 Feb 2016 17:09:41 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 18 Feb 2016 17:09:41 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2016 17:09:41 -0800 Message-ID: From: Andy Bierman To: Randy Bush Content-Type: multipart/alternative; boundary=001a113fc38448a9e0052c1523f4 Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 01:09:44 -0000 --001a113fc38448a9e0052c1523f4 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 18, 2016 at 4:52 PM, Randy Bush wrote: > > I think in order for WG consensus to determine decisions wrt/ this > > document, it would no longer be a Cisco protocol. Cisco would have to > > give all change control authority to the IETF. > > andy, you have been around for a while. where did you get the idea it > was otherwise in the case of this document? > > It is not that clear from the discussions where "documenting a proprietary protocol" ends and "WG makes whatever changes and additions they want" begins. It is not clear how much backward compatibility with existing implementations is expected. If the WG was starting with a set of requirements, and was open to multiple solution proposals, this would look more like a standards effort to me. Working backwards from running code seems like more of an Informational RFC task. > this is just another ietf document. it happens to document a protocol > used by many operators on many vendors' equipment. where does all this > ipr, proprietary, ... paranoia come from? [ that was a rhetorical > question; no need to answer ] > > randy > Andy --001a113fc38448a9e0052c1523f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 18, 2016 at 4:52 PM, Randy Bush <randy@psg.com> = wrote:
> I think in order for WG conse= nsus to determine decisions wrt/ this
> document, it would no longer be a Cisco protocol.=C2=A0 Cisco would ha= ve to
> give all change control authority to the IETF.

andy, you have been around for a while.=C2=A0 where did you get the idea it=
was otherwise in the case of this document?


It is not that clear from the discussi= ons where "documenting a proprietary protocol" ends
and= "WG makes whatever changes and additions they want" begins.
It is not clear how much backward compatibility with existing impleme= ntations is expected.

If the WG was starting with = a set of requirements, and was open to multiple
solution proposal= s, this would look more like a standards effort to me.
Working ba= ckwards from running code seems like more of an Informational RFC task.


=C2=A0
this is just another ietf document.=C2=A0 it happens to document a protocol=
used by many operators on many vendors' equipment.=C2=A0 where does all= this
ipr, proprietary, ... paranoia come from?=C2=A0 [ that was a rhetorical
question; no need to answer ]

randy

Andy
=C2= =A0

--001a113fc38448a9e0052c1523f4-- From nobody Thu Feb 18 19:04:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53AA1A8AD6 for ; Thu, 18 Feb 2016 19:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 O67WlVS6Pl7W for ; Thu, 18 Feb 2016 19:04:46 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703301A8AB8 for ; Thu, 18 Feb 2016 19:04:46 -0800 (PST) Received: by mail-pa0-x22f.google.com with SMTP id fl4so42152850pad.0 for ; Thu, 18 Feb 2016 19:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8sc92yWCuG4231fAcqtZQWvDMMPXhZXC+ybM5x9n9Pg=; b=YuxLCrZndMRfSbGHjjBR6wQlqXBproDjF7Hq88Cb1NKGyG2mPklzEwNALIbUYylmhP mb9TryTFcjkGa37wrhLfUe6zkEitS3p0wqJCO0LBClsnl3FrelBWn+UQ+xytfWWdI8Si 2PsNEma1LIaUfVJp8JwbHC+mS+KQ7d2aIcUCk8qszPatZodAwcRUGZJ7qVBcmNGKXjjs MxulxSN9gCxxH93TIe7b0REEEawuQ3fv0oc5vKHCIPouVBg4RMx4eJsuw1Q+zBgYOIer 3f6ovh8jJ2uJ/ocDNV7YkCDG9qmt1tuePuwxuGKXMQ84BS/2SZSKBNWIVHjszRsAJxXw jiog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8sc92yWCuG4231fAcqtZQWvDMMPXhZXC+ybM5x9n9Pg=; b=Rq+Iwp/hhlbKqyq6IwRJxeFrVIR9lGHRmwPGGzLl6HGMNaFS0x52scDdUCGX14O2tP rWY5Qydg/Dx8gIoDKkPcQkUs9roQI2EhReGzegjClbzFz7y4kcsE0JmBbNiISm6Oy2y8 mYttX6a+DrDnxd8VrRgkQX1N8ZO1LFntD9Tn+d9YoWk+9gk8fSCl/kNu6XzADXvESkOL HHwyCUCXvUvp9ZNz9yFp8LeSYIu92WYppz1pOVDBy/JVoiye9HTwj24b9ZuaS1nRp36O XJl4JhEphBKc/iFExMlIuTgS8u7/zeAaydkxr/PXe8kTv87l+JK/RB12EN+AEHsV1SyY R6YA== X-Gm-Message-State: AG10YOSo5sYA6Inv/br1ycbXApbeajlm0pRcERxXXi/tNkOtHvt1GQ8pE0KAhZNXOzHfIQ== X-Received: by 10.66.62.161 with SMTP id z1mr15127026par.108.1455851086136; Thu, 18 Feb 2016 19:04:46 -0800 (PST) Received: from ?IPv6:2406:e007:7581:1:28cc:dc4c:9703:6781? ([2406:e007:7581:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q8sm13391069pfa.70.2016.02.18.19.04.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 19:04:44 -0800 (PST) To: William Herrin References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> <56C65A2A.1050304@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56C68655.7070509@gmail.com> Date: Fri, 19 Feb 2016 16:04:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 03:04:47 -0000 On 19/02/2016 13:56, William Herrin wrote: > On Thu, Feb 18, 2016 at 6:56 PM, Brian E Carpenter > wrote: >> On 19/02/2016 10:25, William Herrin wrote: >>> Is Cisco prepared to cede further change control of the core TACACS+ >>> standard to the IETF process? >> >> The IETF deals with individual contributors, not companies. As Scott noted, >> the authors have already given change control to the IETF by submitting a >> draft with the appropriate boilerplate. >> >> Of course, what any company chooses to actually implement is their own >> business. > > With due respect Brian, you're talking past the issue. If Cisco, the > company, intends to back away from maintaining the core TACACS+ > standard in favor of the IETF's process then I see no problem with > bringing the protocol into the IETF process. If not, then only sorrow > will come from the IETF creating a _competing standard with the same > name_. Yes, logically, those statements are true. But we have no way to know what a company's true intentions are or to know whether they will stick to those intentions, whatever some employees might say. So I don't think these hypotheticals about possible futures affect the decision to be taken now, which is, for once, genuinely about rough consensus and running code. otoh not many companies would want to knowingly market a product that has the same name as an IETF standard but does not conform to that standard. OK, the bikeshed now has enough different colour samples on it that we should stop. Brian From nobody Thu Feb 18 20:51:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395C81A86FB for ; Thu, 18 Feb 2016 20:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 TakXRs9vgq2x for ; Thu, 18 Feb 2016 20:51:45 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792B41A86E4 for ; Thu, 18 Feb 2016 20:51:45 -0800 (PST) Received: from mb-2.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1J4piuF054918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Feb 2016 04:51:44 GMT (envelope-from joelja@bogus.com) To: Andy Bierman , Randy Bush References: From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <846ccbee-3db2-1669-9f7a-d8515c1119c8@bogus.com> Date: Thu, 18 Feb 2016 20:51:36 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0SQ6OhIgfw0UwU4Dt6vpM1b38sjrK6dk5" Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 04:51:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0SQ6OhIgfw0UwU4Dt6vpM1b38sjrK6dk5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/18/16 5:09 PM, Andy Bierman wrote: >=20 >=20 > On Thu, Feb 18, 2016 at 4:52 PM, Randy Bush > wrote: >=20 > > I think in order for WG consensus to determine decisions wrt/ thi= s > > document, it would no longer be a Cisco protocol. Cisco would ha= ve to > > give all change control authority to the IETF. >=20 > andy, you have been around for a while. where did you get the idea= it > was otherwise in the case of this document? >=20 >=20 > It is not that clear from the discussions where "documenting a > proprietary protocol" ends > and "WG makes whatever changes and additions they want" begins. > It is not clear how much backward compatibility with existing > implementations is expected. >=20 > If the WG was starting with a set of requirements, and was open to mult= iple > solution proposals, this would look more like a standards effort to me.= I'm not sure that imposing a particular model on standards work as a whole rather than in specific is appropriate. Sometimes we draw explicitly on sources that are already or largely fully formed on arrival, sometimes we do not; sometimes we do waterfalls, in particular if we need to converge, and some times we don't. We need to be fairly careful to avoid a generalization that doesn't apply to some or a large part of our efforts. On the Ops side of things we tend to be working with and abundance of pre-existing work. > Working backwards from running code seems like more of an Informational= > RFC task. >=20 > =20 >=20 > this is just another ietf document. it happens to document a proto= col > used by many operators on many vendors' equipment. where does all = this > ipr, proprietary, ... paranoia come from? [ that was a rhetorical > question; no need to answer ] >=20 > randy >=20 >=20 > Andy > =20 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --0SQ6OhIgfw0UwU4Dt6vpM1b38sjrK6dk5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbGn1oACgkQ8AA1q7Z/VrKPOgCfRcM+446mcirjzgnhahH5kHZv 4DIAn26TTdaZQ97HcKZVAxKM4pRiY5tu =UduH -----END PGP SIGNATURE----- --0SQ6OhIgfw0UwU4Dt6vpM1b38sjrK6dk5-- From nobody Fri Feb 19 08:48:24 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384291B325A for ; Fri, 19 Feb 2016 08:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 ildAZXDjQsaC for ; Fri, 19 Feb 2016 08:48:13 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0111.outbound.protection.outlook.com [104.47.2.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18991B3259 for ; Fri, 19 Feb 2016 08:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xK16OOhAehjtjoukhKgqaYpn3QxWuXSprGJv0Idzy/o=; b=UJ36j2OeCqb+id+8Tyeb6zenshMhKWfnJh3Qg1YgxVUG+7yJP5XI7difJPxpLZISKK4/z7MXYJjzKkvhogMzCRh/hfFGYeGtuIq1Q5E7EX+n/Odo7x/9UNYw0zD0ZvJLpSJsfKyzV4Hhdf/uN4+gUb21JnCH2ETDZ2q3bupfk7Q= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.171.3.105) by AM4PR07MB1620.eurprd07.prod.outlook.com (10.166.132.150) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 16:48:09 +0000 Message-ID: <017b01d16b34$d3c92020$4001a8c0@gateway.2wire.net> From: t.petch To: , Brian E Carpenter References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> <56C65A2A.1050304@gmail.com> Date: Fri, 19 Feb 2016 16:39:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.171.3.105] X-ClientProxiedBy: AM2PR09CA0072.eurprd09.prod.outlook.com (25.160.228.168) To AM4PR07MB1620.eurprd07.prod.outlook.com (25.166.132.150) X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 2:UA5H8Euf1q1+YaWK/F29rueJx+/0NNbaA8PmiADF0oHew2994t1QnIvjm1JqGGs/taBbn6XkcAnkTdOM9sOTe/nR+hS2B9JuUcAOm5lSoxcO8N/URi9WTKTMw5M/vTi+7tFG1mTdTqKu6jTiGbHiZw==; 3:l2VKDrDtut9Q1wMqRFtUIX2EzWKaKUB47e+xfjTssobYbn9nUe1x3GzwJMJ+Zs23L7TFfBM3oVoms2wVHiP9qCitE/tNxsS4OUtt1Dl/4nJzgXt9oZgLLxTAkohSU7/a; 25:jlTECNojNxOqS9KccMR3pw7P5WNxKU9kh8ZjjGsnVDgYdAzzpYhb/mufhjjEXzQ1nMF54T952lIMcWyOmkFDY1niYoJO40wWqzOQxUXIc+Toaxz+X2iMDnrB9KTEmESjo0CUDhcRR3b1P93iE3UuglSWfPUCTv5RWmZvKFvnMkdR87k9Q5c73Owhzpk0vHJjcf1Gd8ZTF26q1QKn+hTFwiNm8Se7ze8B6oOa90Jsh7RIp0DPpglzs2HtzgpcyS1jQh5If8Cz32P7K3GWxP5la7rjyXrqEzhm0rxGRYZwvFZcNg9jMF0dCvrjBKxrNiLB X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1620; X-MS-Office365-Filtering-Correlation-Id: 9d899fd3-a02a-4876-0005-08d3394c72e6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM4PR07MB1620; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1620; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 4:LM1lcHnhCEAFmWtoHiWHdhA9WGEYHdeIzrLIsBHM/0Q+y3dnC/eY1Qonm2gYxy72QCvx1bhRJ48IKmSJaN+ceEmBI2JEtmvcLGiU5i8QfS8qld2W9AMEthsnpQOIWZ1MHG6IiZ6hcQSvbuACPrsMq43zgCKIsK6gbWWtNCZPNwKPreaQXcZTQ6dbuXZZFRV1uwjgksrPOik7AASSyUuIXragSlKwUzeX/uICasNOXTAjwW9RkmSVT02QsnaW7jrSJ0ow6DWvbYVSXk+n0Y3dmHQKSbYeO/8JMJHweS8rjfyhcHmAUa/dHTDAlYVXapSKSpBuYkUjMaTsLSstXREEEXdw+MaOsCVue5CoIQpFXaaZ1bZ5ZfDofYM6fB5y3qsF X-Forefront-PRVS: 08572BD77F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(479174004)(24454002)(13464003)(52044002)(377454003)(66066001)(14496001)(107886002)(93886004)(92566002)(44716002)(62236002)(3846002)(586003)(81816999)(2906002)(50986999)(40100003)(6116002)(76176999)(84392002)(81686999)(1456003)(122386002)(33646002)(1096002)(77096005)(47776003)(86362001)(50226001)(19580405001)(50466002)(5008740100001)(5001770100001)(189998001)(42186005)(116806002)(23756003)(5004730100002)(19580395003)(5001960100002)(87976001)(230700001)(61296003)(1556002)(44736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1620; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM4PR07MB1620; 23:V0PIBOWYDq6rv3kWrsRz9/OcWd0spZYZ6X+8Eyf?= =?iso-8859-1?Q?zEgYr70zHd6Filk2zHM04OSZQWEfRCJWrVVH5SxJczxleGC5PZyN9O2BQ1?= =?iso-8859-1?Q?IFkPGegY2Y+t3VsHy0gc+mrpa8Hd0hTDrrlOtHTB45sP2eZVwa6hbY3uK7?= =?iso-8859-1?Q?rZqqEt048zH8QwZlAVrsPAP5yswK02N5oEY+GjTomcU+nhilL5viD9qs6N?= =?iso-8859-1?Q?pRRYVUwz3xhNsIBZtYvK3tq7dmavOl0pwVK73Zsg5k23HOg+Xm5RrLg+oP?= =?iso-8859-1?Q?yCo7/MLIuOfiv2FEk5ARTDIEwuSHqdHJ5urc01F2UbvZr7K+R99gOAzmX8?= =?iso-8859-1?Q?jaC0JEI5GpcukkuQzmS3Ch6wSMMWdIoBrplUzvpqY/mxW1k3r1eM1P6Mm8?= =?iso-8859-1?Q?rRdstD32xsddT+y33Vgo1/Us5Lfi+H4yXuwcYI2yARmxveaiFG6pGVZ4Yt?= =?iso-8859-1?Q?152aaWnQkWADLxesBBscEDHoONebVeVJKT/8Wc1QBDMpYmLlYhKxAwnG/o?= =?iso-8859-1?Q?3jLpMIfWaUMVvAE68YUScqEBbap3pTj/3kKmZnR8dkcS/ZGNS80q3rWhga?= =?iso-8859-1?Q?4yPr1elcRyyaKzJpgaaOY0Wny4x8viQ0OkWtg1dFIqn8QPHRI/H9NI6I/Y?= =?iso-8859-1?Q?1B3BOV+EJfzLUy3Vz0lYyje3cK8SgMv80SkY9ryPKa/MOUB6CQY4DhJzLZ?= =?iso-8859-1?Q?Y/SvEWhcTcI6jZ+fcxrZjv3uki2ataohu2xANJZhPVAii4IaGO5QqXjyJL?= =?iso-8859-1?Q?Ge4kbEzyiejwlugOsSkrIVTLfEG/UJf61TsmD3EVuUnQ+o+XQD/NiruDdJ?= =?iso-8859-1?Q?3AaTKVZ3ZQfXFwOe9gNhruo9StjAMYRV3j+Cfyg9O9yQEfyr706fZxxNMB?= =?iso-8859-1?Q?aBKqoa1Ra6NWSZrVxzFMFHnpEDV9rWpUKMJgh0UEtZTVDd9/5Q/qeTZ1Xc?= =?iso-8859-1?Q?I+2uXtENfByBbWXm3WPs1Gz11g2qSGeUtVeyVBPomSxgurLqve5Ou0bI7O?= =?iso-8859-1?Q?lnhAS10BOicOIRhVg3HVv+D6zhn92gZXY1UsHzqYgVrDs7DFLyBaePh/T8?= =?iso-8859-1?Q?c9mt2UG9nY0IISMJ3enaX21SMFqZIndnx0mzOufinIG0nXmY7J3yP2dEeK?= =?iso-8859-1?Q?6si6+5qMFQ04X7xa2aP+ZQPGdLMOXxQ5Zx1K6zP0xJW7Wg8Wp4Bk50e9/r?= =?iso-8859-1?Q?t+B2ZB6lzufIsKh+2Vr/aQ3lNs8rfcnDvF3hxHI8UyzPRRZS6o3h8qXkZZ?= =?iso-8859-1?Q?ehlpTvKhWWHqHPqXCSM9OhjoKD/Pjyjl1HkbDfNWhBCmjkqyd4oeewxd4l?= =?iso-8859-1?Q?dRt1bkY9gcxb9qs98gwPPuUSENJaqYL79P8088X00GYig=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 5:dAIoP5S1FQRWeK9/qfC8w4ncRdMbS2UcuZ1aNELRPWyxpJslSCCJOHWJzfvsxKbDUQC4OqVjld5Sku3gorMRW3GMJVKgdzOm2N4tiYaFCC8eJfDF9iX7EnfMcJXsg2IwfddilEdt1sfZnkAqdE85xw==; 24:Fo1iq4ZTXosixOsZaCXluKF77ZkcRyy4ZloR2LqJh4eXjuXobJojpFGFXph6B/xHkwTBuwRESnjS7MZza/LhlRnjbK3wXrZOuGhC8Gcx3Mc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2016 16:48:09.5157 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1620 Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 16:48:21 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: Sent: Thursday, February 18, 2016 11:56 PM > On 19/02/2016 10:25, William Herrin wrote: > > On Thu, Feb 18, 2016 at 10:28 AM, joel jaeggli wrote: > >> On 2/18/16 7:18 AM, William Herrin wrote: > >>> In my opinion, IETF standards track RFCs should be reserved for > >>> protocols for which further development is expected to occur primarily > >>> within the IETF framework. As I understand the situation (feel free to > >>> correct me if I'm wrong), TACACS+ is a vendor maintained standard, > >>> specifically Cisco. Regardless of publication, Cisco intends to retain > >>> control of the standard and its future development. > >> > >> Assuming the document is split into to pieces here part of goal as I > >> understand it is address the issue of adding ssl to the existing > >> specification in an inter-operable fashion. > > > > Hi Joel, > > > > Is Cisco prepared to cede further change control of the core TACACS+ > > standard to the IETF process? > > The IETF deals with individual contributors, not companies. As Scott noted, > the authors have already given change control to the IETF by submitting a > draft with the appropriate boilerplate. And what I have seen more than once is a large, American company, which shares an e-mail domain with IETF participants who have actively worked on an I-D, submit an IPR claim late in the day. When asked, the participants have explained that American law is such that companies aim to keep participants in the dark about possible IPR claims. So the participants have honestly and accurately answered all the questions about IPR and yet the company (with the same e-mail domain) has put in a late claim. So until it is, or is just about to be, an RFC, I don't know whether or not a technology will be encumbered by an IPR claim and I know of nothing that the participants can say to allay my concerns (the company's lawyers might be able to:-). Tom Petch > Of course, what any company chooses to actually implement is their own > business. > > Brian > > From nobody Fri Feb 19 09:00:36 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4660E1B32B1 for ; Fri, 19 Feb 2016 09:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 elU9Qz1dfRSE for ; Fri, 19 Feb 2016 09:00:33 -0800 (PST) Received: from magic.dirtside.com (magic.dirtside.com [70.184.240.83]) by ietfa.amsl.com (Postfix) with ESMTP id 746871B329B for ; Fri, 19 Feb 2016 09:00:33 -0800 (PST) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id u1JH0RGi000812 for ; Fri, 19 Feb 2016 12:00:28 -0500 X-Really-To: Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 8F52BEBD58 for ; Fri, 19 Feb 2016 12:00:27 -0500 (EST) Received: by mail-io0-f181.google.com with SMTP id 9so115806825iom.1 for ; Fri, 19 Feb 2016 09:00:27 -0800 (PST) X-Gm-Message-State: AG10YOT8Qs6jCJDsUlS5KjDAnd8I29laqcJvxlrOnvKfq1ytAdFFWPHyDxBGLU/UccDR0ma85SfGELyiWG1RTQ== X-Received: by 10.107.15.201 with SMTP id 70mr14699748iop.125.1455901227078; Fri, 19 Feb 2016 09:00:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.216.42 with HTTP; Fri, 19 Feb 2016 09:00:07 -0800 (PST) In-Reply-To: <56C68655.7070509@gmail.com> References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> <56C65A2A.1050304@gmail.com> <56C68655.7070509@gmail.com> From: William Herrin Date: Fri, 19 Feb 2016 12:00:07 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 X-Spam-Checker: magic.dirtside.com Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 17:00:35 -0000 On Thu, Feb 18, 2016 at 10:04 PM, Brian E Carpenter wrote: > We have no way to > know what a company's true intentions are or to know whether they > will stick to those intentions, whatever some employees might say. Hi Brian, Respectfully, every company is capable of communicating its official intentions and designating employees authorized to do so. Whether they're likely to renege later is, I agree, an issue we can't reasonably consider. > So I don't think these hypotheticals about possible futures affect > the decision to be taken now, which is, for once, genuinely about > rough consensus and running code. Creating a derivative work of a vendor's product while keeping the vendor's product name without the vendor's express consent? That's solely and genuinely about rough consensus and running code? Seriously? Gain the vendor's formal consent to take over the standard. Derive a new work from the vendor's standard under a different, readily distinguished name. Produce an informational RFC documenting the vendor's standard without change. Depending on your goals, you have at least three satisfactory paths forward. Why insist on an objectionable path instead? Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: From nobody Fri Feb 19 09:40:37 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745941B333E for ; Fri, 19 Feb 2016 09:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 yp5Ad1KhqGGM for ; Fri, 19 Feb 2016 09:40:35 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB561B3342 for ; Fri, 19 Feb 2016 09:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4219; q=dns/txt; s=iport; t=1455903634; x=1457113234; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=pdxy4ZR5K83f9AVLeeo173ry8pz99MHuzXruK33VAmI=; b=M6xgz/pYCKOZx8cChkzimmAQjA7ZJw9Gxgl753gilc0hJMQceWKOKqIp 3UZ+vtm0vik5ssiCnkgAxKwjzj7VbBVCNSN6EZBoXTNDv4k6PWNcMTb7d 9Q140ICGEX7NMM4R0j4z1ai09o9Cl7CBa7oC8VdIVyhs/ow3qoEsgRB26 g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBADPUsdW/xbLJq1evSuECYYNAoIiA?= =?us-ascii?q?QEBAQEBZSeEQgEBBCNVARALBBQJFgsCAgkDAgECAUUGAQwIAQGIFqxvjwsBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQENCIpNhzWBOgWXB4MIgWSIcokhhVKOSGKCAxmBS?= =?us-ascii?q?TuIagEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,471,1449532800"; d="asc'?scan'208,217";a="625575674" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2016 17:40:32 +0000 Received: from [10.61.162.143] ([10.61.162.143]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1JHeWcn000674; Fri, 19 Feb 2016 17:40:32 GMT To: Andy Bierman , Randy Bush References: From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <56C7538F.4000209@cisco.com> Date: Fri, 19 Feb 2016 18:40:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XhL3kG6eDkG6D2sjBXgC8W7NxE1uMj3BW" Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 17:40:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XhL3kG6eDkG6D2sjBXgC8W7NxE1uMj3BW Content-Type: multipart/alternative; boundary="------------030806060904010602080404" This is a multi-part message in MIME format. --------------030806060904010602080404 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andy, On 2/19/16 2:09 AM, Andy Bierman wrote: > > It is not that clear from the discussions where "documenting a > proprietary protocol" ends > and "WG makes whatever changes and additions they want" begins. > It is not clear how much backward compatibility with existing > implementations is expected. > I understand your concern.=20 My suggestion is that working group consensus (not any particular individual's or company's point of view) determine what is in a proposed standard. Operational experience with what is running is going to dictate what many people believe should and should not be in in that doc. Whether there is an informational document won't change this.=20 That's a good thing. If someone said we should rewrite TACACS+ to use=20 EBCDIC encoding, for instance, I'm pretty sure you'd see a lot of people complain. If the WG diverges substantially from what is running code, then two documents seem called for. But I don't see that we've crossed that bridge yet. Eliot --------------030806060904010602080404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andy,

On 2/19/16 2:09 AM, Andy Bierman wrote= :

It is not that clear from the discussions where "documenting a proprietary protocol" ends
and "WG makes whatever changes and additions they want" begins.
It is not clear how much backward compatibility with existing implementations is expected.


I understand your concern.=C2=A0

My suggestion is that working group consensus (not any particular individual's or company's point of view) determine what is in a proposed standard.=C2=A0 Operational experience with what is running = is going to dictate what many people believe should and should not be in in that doc.=C2=A0 Whether there is an informational document won'= t change this.=C2=A0 That's a good thing.=C2=A0 If someone said we shou= ld rewrite TACACS+ to use=C2=A0 EBCDIC encoding, for instance, I'm prett= y sure you'd see a lot of people complain.=C2=A0 If the WG diverges substantially from what is running code, then two documents seem called for.=C2=A0 But I don't see that we've crossed that bridge yet.=

Eliot

--------------030806060904010602080404-- --XhL3kG6eDkG6D2sjBXgC8W7NxE1uMj3BW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWx1OPAAoJEIe2a0bZ0nozayIIALjEhSe49g8GzMBXH3IObNho TGDBD0f+CRBdEHUyE4ADatDSrwyzmvuV8c6EUB5uRP2VukgyC1i6cZZjBIPIuZtq kj2pMNQP/29dTmi3ZE3pv6qurwnSE5lYp5pUIIeJg6M3SsEIjRkguwoxHRmtzZ68 XyHoJ/uFQ8eL388N75HT85E+/1VOuVVt9sbkxz4YcnFABv17/dqwmhxiTvxR6MxR EFw0sAKvaFMua9+NzGWzrrZNyJDETRdXIKpS2JMkAJcVfL2EKMhInPUfQXMcggo3 y8+0j69R5ij2s2N0ieF8+Ij8HF+0nAE2KTgRq33qKYejzaj+o1w/VtCrBQul24U= =ckHs -----END PGP SIGNATURE----- --XhL3kG6eDkG6D2sjBXgC8W7NxE1uMj3BW-- From nobody Fri Feb 19 16:04:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0E1B36F5 for ; Fri, 19 Feb 2016 16:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 LKqoX5qu0sDr for ; Fri, 19 Feb 2016 16:04:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5826E1B36F0 for ; Fri, 19 Feb 2016 16:04:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIW86152; Sat, 20 Feb 2016 00:03:57 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 20 Feb 2016 00:03:55 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Fri, 19 Feb 2016 16:03:43 -0800 From: Linda Dunbar To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] automatic attachment of applications and services at the edge Thread-Index: AQHRa3IpGrgpOP/ObE6KFitvqhYhoQ== Date: Sat, 20 Feb 2016 00:03:43 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DEDB7A@dfweml701-chm> References: <9904FB1B0159DA42B0B887B7FA8119CA6BF19470@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657DEB962@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA6BF1959A@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF1DCAB@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF1DCAB@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.190] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DEDB7Adfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56C7AD6E.0080, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9da4adff03c04911a222333218b15db8 Archived-At: Subject: Re: [OPSAWG] automatic attachment of applications and services at the edge X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 00:04:04 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DEDB7Adfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, Thank you very much for bringing attention to this draft. What being proposed by the draft is almost like ES-IS protocol, isn't it? I think it is quite useful. Thanks, Linda Dunbar From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (= Dan) Sent: Monday, February 15, 2016 9:10 AM To: opsawg@ietf.org Cc: Unbehagen Jr, Paul E (Paul) Subject: [OPSAWG] automatic attachment of applications and services at the = edge Hi, I would like to draw the attention of the participants in the OPSAWG on an = individual submission that I am co-authoring. The problem we are trying to = solve is the optimization / minimizing of the amount of configuration that = an operator needs to do when new applications require the creation of paths= or tunnels in the core network. In order to avoid the reconfiguration of t= he core or heavy configuration at the edge the proposed method which we cal= l auto-attachment allows for the usage of a protocol running between the en= d stations and the first (edge) router that adds the information and charac= teristics of the new path according to the policies or mapping tables of th= e operators. A first implementation that we have running code for and is de= ployed is described in https://datatracker.ietf.org/doc/draft-unbehagen-lld= p-spb/ and uses the Link Layer Discovery Protocol (LLDP) with an IEEE 802.1= aq Shortest Path Bridging (SPB) network. Please have a look and let me know if there is interest and/or similar on-g= oing work. If there is enough interest I plan to request a short slot to di= scuss the idea at the OPSAWG meeting at IETF 95. Thanks and Regards, Dan --_000_4A95BA014132FF49AE685FAB4B9F17F657DEDB7Adfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan,

 

Thank you very much fo= r bringing attention to this draft.

What being proposed by= the draft is almost like ES-IS protocol, isn’t it?

 

I think it is quite us= eful.

 

Thanks, Linda Dunbar

 

 

 

 

From: OPSAWG [= mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, February 15, 2016 9:10 AM
To: opsawg@ietf.org
Cc: Unbehagen Jr, Paul E (Paul)
Subject: [OPSAWG] automatic attachment of applications and services = at the edge

 

Hi,

 

I would like to draw the attention of the participan= ts in the OPSAWG on an individual submission that I am co-authoring. The pr= oblem we are trying to solve is the optimization / minimizing of the amount= of configuration that an operator needs to do when new applications require the creation of paths or tunnels= in the core network. In order to avoid the reconfiguration of the core or = heavy configuration at the edge the proposed method which we call auto-atta= chment allows for the usage of a protocol running between the end stations and the first (edge) router that= adds the information and characteristics of the new path according to the = policies or mapping tables of the operators. A first implementation that we= have running code for and is deployed is described in https://datatracker.ietf.org/doc/draft-unbehagen-lldp-spb/ and uses the= Link Layer Discovery Protocol (LLDP) with an IEEE 802.1aq Shortest Path Br= idging (SPB) network.

 

Please have a look and let me know if there is inter= est and/or similar on-going work. If there is enough interest I plan to req= uest a short slot to discuss the idea at the OPSAWG meeting at IETF 95.

 

Thanks and Regards,

 

Dan

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657DEDB7Adfweml701chm_-- From nobody Sun Feb 21 13:55:16 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596B61B2D00 for ; Sun, 21 Feb 2016 13:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 GT_x4761FN1v for ; Sun, 21 Feb 2016 13:55:13 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE661B2CDF for ; Sun, 21 Feb 2016 13:55:13 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id r207so55228105ykd.2 for ; Sun, 21 Feb 2016 13:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=AWeWLPw7aXbYMw8H0gwSfzCSz9N6kTX3TB4psUHrXV0=; b=roVqXeDvcs3wnfuCVKSWSNOtvU0ydpMsPFlDy6X3dNjrxD0YRmsN3at9vjCXsbwnW2 mrZ0xoNPONImaNf9Dcq0TRu19YGPEadS3hVHSc8vc9c6HI9SgLCrluh9Ie05WM83kIG6 zSQtdpM786mZWj+kp6ht+9VGJf9yTLVux5GmFwz9RDR0eUtwCNKE7Ul6Gz40qWyga98Q vKVF7DmXLz/QVj464Ujn9/1AMcE5XYSNMHPCmYvM4tARcVBlSuO8RQc6TwK2L+40E+cg EyxSBcpbmr+I76nQxK3JyEaPTQlMedAnh7183airJbtYWYhkmR7GgmiG6c+3b7r1c7aY AR5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=AWeWLPw7aXbYMw8H0gwSfzCSz9N6kTX3TB4psUHrXV0=; b=euT1N+cohaesusnaV+5UFwWoOt5QeQfn44vjy2LhAfXZ+TCIpsUdR1hxuf4Yz5eecc hsBlYkwO8RH0EwMEUdgBSrmE45EoZO5MzzkBiBvX5JoCDyAmEWcVu5Aol9nzqfgSYtaA kLvYuJpvN5dVFC1UpCHlroqzhDQYdLsUXkLCWohkW5HZ/TacZsOvDO3I5lOICcwe3sJ5 YTfArdteAbcUo8gHb7DzF4nh7uSHGM7UYEQzOs4weOU7Ccre6LJenQ3wDZpQTjPzaXL0 W3wtzRwneUsQ2h7kd2MMNvMjkVQGtmgDNrtgmXDnjk5J7hsHbR6K1q2+rYilgeGa6rGR +9BQ== X-Gm-Message-State: AG10YOQkF39/alwnYN4NlJKEx237fHdaabSOi2CcJ0sqrdfqvwLvUGRIrsSiFMwV8EeYdlHsck7aaRCqWPJsU4ou X-Received: by 10.37.94.215 with SMTP id s206mr5948581ybb.119.1456091713052; Sun, 21 Feb 2016 13:55:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Sun, 21 Feb 2016 21:55:03 +0000 Message-ID: To: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs.authors@ietf.org Content-Type: multipart/alternative; boundary=001a11423a72516ba5052c4ec5ac Archived-At: Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 21:55:15 -0000 --001a11423a72516ba5052c4ec5ac Content-Type: text/plain; charset=UTF-8 Dear WG (and specifically draft-ietf-opsawg-tacacs authors), So far we have received an IPR acknowledgment from Douglas ( https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) , but are still missing it from the rest of the authors: Thorsten Dahm, Andrej Ota, David Carrel, Lol Grant. Please reply to this email regardless of whether or not you are personally aware of any relevant IPR... (I have just noticed that David and Lol do not have email addresses listed. Thorsten said that he spoke with them (recording from Prague) - please add their email addresses - they will need to ack the IPR, and also the AUTH48 if / when it happens...) W On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari wrote: > Dear WG, > > Thanks to everyone who has been participating. It is refreshing to see > this much passion and involvement in OpsAWG! We wanted to give this a bit > of time to settle down, and also to see where this ended up. > > We are going to do a series of steps to get as clear a view of the > consensus of the WG about this document. This message is a explicit call > for any known IPR. > > We will follow up with two other messages, each with a particular > question - the reason for such formality is to try to untangle the many > threads that erupted on the main list. > > Many of you have already expressed your opinion but can you please do so > again in response to the forthcoming two messages so that the record is > clear. We expect to determine the path forward in 2 weeks. > > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance > with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are personally > aware of any relevant IPR. > > Scott, Tianran and Warren > --001a11423a72516ba5052c4ec5ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear WG (and specifically draft-ietf-opsawg-tacacs authors= ),

So far we have received an IPR acknowledgment from Do= uglas (https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbA= rBKM42iNRiMxq8) , but are still missing it from the rest of the authors= :=C2=A0Thorsten Dahm,=C2=A0Andrej Ota,=C2=A0David Carrel,=C2=A0Lol Grant.

Please reply to this email regardless of wheth= er or not you are personally aware of any relevant IPR...
<= br>
(I have just noticed that David and=C2=A0Lol do not have emai= l addresses listed.=C2=A0Thorsten said that= he spoke with them (recording from Prague) - please add their email addres= ses - they will need to ack the IPR, and also the AUTH48 if / when it happe= ns...)

W


On Tue, Feb 16, 2016 at 7:46 AM Warre= n Kumari <warren@kumari.net>= wrote:
Dear = WG,

Thanks to everyone who has been participating.= It is refreshing to see this much passion and involvement in OpsAWG! We wa= nted to give this a bit of time to settle down, and also to see where this = ended up.

We are going to do a series of steps to = get as clear a view of the consensus of the WG about this document. =C2=A0 = This message is a explicit call for any known IPR.=C2=A0

We will follow up with two =C2=A0other messages, each with a particu= lar question - the reason for such formality is to try to untangle the many= threads that erupted on the main list.

Many of yo= u have already expressed your opinion but can you please do so again in res= ponse to the forthcoming two messages so that the record is clear.=C2=A0 We= expect to determine the path forward in 2 weeks.

= Are you personally aware of any IPR that applies to draft-ietf-opsawg-tacac= s?=C2=A0 If so, has this IPR been disclosed in compliance with IETF IPR rul= es?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)
=

If you are a document author or listed contributor on t= his document, please reply to this email regardless of whether or not you a= re personally aware of any relevant IPR.

Scott, Ti= anran and Warren
--001a11423a72516ba5052c4ec5ac-- From nobody Mon Feb 22 06:19:35 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCA71B2EFB for ; Mon, 22 Feb 2016 06:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 rZXtspOryS5F for ; Mon, 22 Feb 2016 06:19:31 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1160B1B2ECE for ; Mon, 22 Feb 2016 06:19:30 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AYAgAvGMtW/xUHmMZeGQEBAQEPAQEBAYI+IStSbQaFN7MDghMBDYFmIIVtAoE8OBQBAQEBAQEBZCeEQQEBAQEDEhtcAgEIDQQBAwEBCx0HMhQDBggCBAESCBqHeAENnnWZIAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGE4Q5hAQxLQmCdYEPBYVPjSSEFAGFVoJugmSEEUqDeYMZhTuOSR4BAUKBTIIYagEBhzEBfAEBAQ X-IPAS-Result: A2AYAgAvGMtW/xUHmMZeGQEBAQEPAQEBAYI+IStSbQaFN7MDghMBDYFmIIVtAoE8OBQBAQEBAQEBZCeEQQEBAQEDEhtcAgEIDQQBAwEBCx0HMhQDBggCBAESCBqHeAENnnWZIAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGE4Q5hAQxLQmCdYEPBYVPjSSEFAGFVoJugmSEEUqDeYMZhTuOSR4BAUKBTIIYagEBhzEBfAEBAQ X-IronPort-AV: E=Sophos;i="5.22,484,1449550800"; d="scan'208,217";a="168507725" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Feb 2016 09:19:29 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 22 Feb 2016 09:19:28 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 22 Feb 2016 15:19:27 +0100 From: "Romascanu, Dan (Dan)" To: Linda Dunbar , "opsawg@ietf.org" Thread-Topic: [OPSAWG] automatic attachment of applications and services at the edge Thread-Index: AQHRa3Iu/4iUfe55M0+oKbBfuK/nap84ICPA Date: Mon, 22 Feb 2016 14:19:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF23998@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BF19470@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657DEB962@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA6BF1959A@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF1DCAB@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657DEDB7A@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DEDB7A@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF23998AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] automatic attachment of applications and services at the edge X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 14:19:34 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF23998AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Thanks for your interest and comment. From a topology and architecture poin= t of view the idea is indeed similar to ES-IS. The difference is in the con= tent of the information that is being exchanged between the end-station and= the edge router. Regards, Dan From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Saturday, February 20, 2016 2:04 AM To: Romascanu, Dan (Dan); opsawg@ietf.org Subject: RE: [OPSAWG] automatic attachment of applications and services at = the edge Dan, Thank you very much for bringing attention to this draft. What being proposed by the draft is almost like ES-IS protocol, isn't it? I think it is quite useful. Thanks, Linda Dunbar From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (= Dan) Sent: Monday, February 15, 2016 9:10 AM To: opsawg@ietf.org Cc: Unbehagen Jr, Paul E (Paul) Subject: [OPSAWG] automatic attachment of applications and services at the = edge Hi, I would like to draw the attention of the participants in the OPSAWG on an = individual submission that I am co-authoring. The problem we are trying to = solve is the optimization / minimizing of the amount of configuration that = an operator needs to do when new applications require the creation of paths= or tunnels in the core network. In order to avoid the reconfiguration of t= he core or heavy configuration at the edge the proposed method which we cal= l auto-attachment allows for the usage of a protocol running between the en= d stations and the first (edge) router that adds the information and charac= teristics of the new path according to the policies or mapping tables of th= e operators. A first implementation that we have running code for and is de= ployed is described in https://datatracker.ietf.org/doc/draft-unbehagen-lld= p-spb/ and uses the Link Layer Discovery Protocol (LLDP) with an IEEE 802.1= aq Shortest Path Bridging (SPB) network. Please have a look and let me know if there is interest and/or similar on-g= oing work. If there is enough interest I plan to request a short slot to di= scuss the idea at the OPSAWG meeting at IETF 95. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF23998AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Thanks for your intere= st and comment. From a topology and architecture point of view the idea is = indeed similar to ES-IS. The difference is in the content of the informatio= n that is being exchanged between the end-station and the edge router.

 

Regards,

 

Dan<= /p>

 

 

From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
Sent: Saturday, February 20, 2016 2:04 AM
To: Romascanu, Dan (Dan); opsawg@ietf.org
Subject: RE: [OPSAWG] automatic attachment of applications and servi= ces at the edge

 

Dan,

 

Thank you very much fo= r bringing attention to this draft.

What being proposed by= the draft is almost like ES-IS protocol, isn’t it?

 

I think it is quite us= eful.

 

Thanks, Linda Dunbar

 

 

 

 

From: OPSAWG [= mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, February 15, 2016 9:10 AM
To: opsawg@ietf.org
Cc: Unbehagen Jr, Paul E (Paul)
Subject: [OPSAWG] automatic attachment of applications and services = at the edge

 

Hi,

 

I would like to draw the attention of the participan= ts in the OPSAWG on an individual submission that I am co-authoring. The pr= oblem we are trying to solve is the optimization / minimizing of the amount= of configuration that an operator needs to do when new applications require the creation of paths or tunnels= in the core network. In order to avoid the reconfiguration of the core or = heavy configuration at the edge the proposed method which we call auto-atta= chment allows for the usage of a protocol running between the end stations and the first (edge) router that= adds the information and characteristics of the new path according to the = policies or mapping tables of the operators. A first implementation that we= have running code for and is deployed is described in https://datatracker.ietf.org/doc/draft-unbehagen-lldp-spb/ and uses the= Link Layer Discovery Protocol (LLDP) with an IEEE 802.1aq Shortest Path Br= idging (SPB) network.

 

Please have a look and let me know if there is inter= est and/or similar on-going work. If there is enough interest I plan to req= uest a short slot to discuss the idea at the OPSAWG meeting at IETF 95.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF23998AZFFEXMB04globa_-- From nobody Mon Feb 22 06:39:06 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6591B3371 for ; Mon, 22 Feb 2016 06:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.085 X-Spam-Level: X-Spam-Status: No, score=0.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RP_MATCHES_RCVD=-0.006, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 I7NRFCY78PvA for ; Mon, 22 Feb 2016 06:39:02 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD7E1B3367 for ; Mon, 22 Feb 2016 06:39:02 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1MEc5aE033277; Mon, 22 Feb 2016 09:38:05 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: "Romascanu, Dan (Dan)" , Linda Dunbar , "opsawg@ietf.org" Thread-Topic: [OPSAWG] automatic attachment of applications and services at the edge Thread-Index: AdFtfrYvDgFGUxitTRiPQzVc0ggEVA== Date: Mon, 22 Feb 2016 14:38:36 +0000 Message-ID: <20160222143844.18296912.70526.52991@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1510946238==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-22_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602220177 Archived-At: Subject: Re: [OPSAWG] automatic attachment of applications and services at the edge X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 14:39:04 -0000 --===============1510946238== Content-Type: multipart/alternative; boundary="===============0137209985==" MIME-Version: 1.0 --===============0137209985== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhlbiB3b3VsZCBpdCBiZSBwcmFjdGljYWwgdG8gaGF2ZSBvbmUgcHJvdG9jb2wgdGhhdCBtYW5h Z2VkIGNhcnJpZXMgYm90aCBraW5kcyBvZiBkYXRhPwoKU2VudMKgZnJvbcKgbXnCoEJsYWNrQmVy cnnCoDEwwqBzbWFydHBob25lwqBvbsKgdGhlIFZlcml6b27CoFdpcmVsZXNzwqA0R8KgTFRFwqBu ZXR3b3JrLgpGcm9tOiBSb21hc2NhbnUsIERhbiAoRGFuKQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5 IDIyLCAyMDE2IDA5OjE5ClRvOiBMaW5kYSBEdW5iYXI7IG9wc2F3Z0BpZXRmLm9yZwpTdWJqZWN0 OiBSZTogW09QU0FXR10gYXV0b21hdGljIGF0dGFjaG1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBz ZXJ2aWNlcyBhdCB0aGUJZWRnZQoKSGkgTGluZGEsCsKgClRoYW5rcyBmb3IgeW91ciBpbnRlcmVz dCBhbmQgY29tbWVudC4gRnJvbSBhIHRvcG9sb2d5IGFuZCBhcmNoaXRlY3R1cmUgcG9pbnQgb2Yg dmlldyB0aGUgaWRlYSBpcyBpbmRlZWQgc2ltaWxhciB0byBFUy1JUy4gVGhlIGRpZmZlcmVuY2Ug aXMgaW4gdGhlIGNvbnRlbnQgb2YgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXMgYmVpbmcgZXhjaGFu Z2VkIGJldHdlZW4gdGhlIGVuZC1zdGF0aW9uIGFuZCB0aGUgZWRnZSByb3V0ZXIuCsKgClJlZ2Fy ZHMsCsKgCkRhbgrCoArCoApGcm9tOiBMaW5kYSBEdW5iYXIgW21haWx0bzpsaW5kYS5kdW5iYXJA aHVhd2VpLmNvbV0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDIwLCAyMDE2IDI6MDQgQU0KVG86 IFJvbWFzY2FudSwgRGFuIChEYW4pOyBvcHNhd2dAaWV0Zi5vcmcKU3ViamVjdDogUkU6IFtPUFNB V0ddIGF1dG9tYXRpYyBhdHRhY2htZW50IG9mIGFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMgYXQg dGhlIGVkZ2UKwqAKRGFuLArCoApUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBicmluZ2luZyBhdHRl bnRpb24gdG8gdGhpcyBkcmFmdC4KV2hhdCBiZWluZyBwcm9wb3NlZCBieSB0aGUgZHJhZnQgaXMg YWxtb3N0IGxpa2UgRVMtSVMgcHJvdG9jb2wsIGlzbuKAmXQgaXQ/CsKgCkkgdGhpbmsgaXQgaXMg cXVpdGUgdXNlZnVsLgrCoApUaGFua3MsIExpbmRhIER1bmJhcgrCoArCoArCoArCoApGcm9tOiBP UFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFz Y2FudSwgRGFuIChEYW4pClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTUsIDIwMTYgOToxMCBBTQpU bzogb3BzYXdnQGlldGYub3JnCkNjOiBVbmJlaGFnZW4gSnIsIFBhdWwgRSAoUGF1bCkKU3ViamVj dDogW09QU0FXR10gYXV0b21hdGljIGF0dGFjaG1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBzZXJ2 aWNlcyBhdCB0aGUgZWRnZQrCoApIaSwKwqAKSSB3b3VsZCBsaWtlIHRvIGRyYXcgdGhlIGF0dGVu dGlvbiBvZiB0aGUgcGFydGljaXBhbnRzIGluIHRoZSBPUFNBV0cgb24gYW4gaW5kaXZpZHVhbCBz dWJtaXNzaW9uIHRoYXQgSSBhbSBjby1hdXRob3JpbmcuIFRoZSBwcm9ibGVtIHdlIGFyZSB0cnlp bmcgdG8gc29sdmUgaXMgdGhlIG9wdGltaXphdGlvbiAvIG1pbmltaXppbmcgb2YgdGhlIGFtb3Vu dCBvZiBjb25maWd1cmF0aW9uIHRoYXQgYW4gb3BlcmF0b3IgbmVlZHMgdG8gZG8gd2hlbiBuZXcg YXBwbGljYXRpb25zIHJlcXVpcmUgdGhlIGNyZWF0aW9uIG9mIHBhdGhzIG9yIHR1bm5lbHMgaW4g dGhlIGNvcmUgbmV0d29yay4gSW4gb3JkZXIgdG8gYXZvaWQgdGhlIHJlY29uZmlndXJhdGlvbiBv ZiB0aGUgY29yZSBvciBoZWF2eSBjb25maWd1cmF0aW9uIGF0IHRoZSBlZGdlIHRoZSBwcm9wb3Nl ZCBtZXRob2Qgd2hpY2ggd2UgY2FsbCBhdXRvLWF0dGFjaG1lbnQgYWxsb3dzIGZvciB0aGUgdXNh Z2Ugb2YgYSBwcm90b2NvbCBydW5uaW5nIGJldHdlZW4gdGhlIGVuZCBzdGF0aW9ucyBhbmQgdGhl IGZpcnN0IChlZGdlKSByb3V0ZXIgdGhhdCBhZGRzIHRoZSBpbmZvcm1hdGlvbiBhbmQgY2hhcmFj dGVyaXN0aWNzIG9mIHRoZSBuZXcgcGF0aCBhY2NvcmRpbmcgdG8gdGhlIHBvbGljaWVzIG9yIG1h cHBpbmcgdGFibGVzIG9mIHRoZSBvcGVyYXRvcnMuIEEgZmlyc3QgaW1wbGVtZW50YXRpb24gdGhh dCB3ZSBoYXZlIHJ1bm5pbmcgY29kZSBmb3IgYW5kIGlzIGRlcGxveWVkIGlzIGRlc2NyaWJlZCBp biBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC11bmJlaGFnZW4tbGxkcC1z cGIvIGFuZCB1c2VzIHRoZSBMaW5rIExheWVyIERpc2NvdmVyeSBQcm90b2NvbCAoTExEUCkgd2l0 aCBhbiBJRUVFIDgwMi4xYXEgU2hvcnRlc3QgUGF0aCBCcmlkZ2luZyAoU1BCKSBuZXR3b3JrLgrC oApQbGVhc2UgaGF2ZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93IGlmIHRoZXJlIGlzIGludGVyZXN0 IGFuZC9vciBzaW1pbGFyIG9uLWdvaW5nIHdvcmsuIElmIHRoZXJlIGlzIGVub3VnaCBpbnRlcmVz dCBJIHBsYW4gdG8gcmVxdWVzdCBhIHNob3J0IHNsb3QgdG8gZGlzY3VzcyB0aGUgaWRlYSBhdCB0 aGUgT1BTQVdHIG1lZXRpbmcgYXQgSUVURiA5NS4KwqAKVGhhbmtzIGFuZCBSZWdhcmRzLArCoApE YW4KwqAKCg== --===============0137209985== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable = =
Then would it be practical to ha= ve one protocol that managed carries both kinds of data?
= =

= = =
Sent from my Bl= ackBerry 10 smartphone on the Verizon Wireles= s 4G LTE network.
= = <= tr>
From: Romascanu, Dan (Dan)<= /div>
Sent: Monday, February 22, 2016 09:19
To: Linda Dunbar; opsawg@ietf.org
Subject: Re: [OPSAWG] autom= atic attachment of applications and services at the edge

Hi Linda,

 

Thanks for your intere= st and comment. From a topology and architecture point of view the idea is = indeed similar to ES-IS. The difference is in the content of the informatio= n that is being exchanged between the end-station and the edge router.

 

Regards,

 

Dan

 

 

From: Linda = Dunbar [mailto:linda.dunbar@huawei.com]
Sent: Saturday, February 20, 2016 2:04 AM
To: Romascanu, Dan (Dan); opsawg@ietf.org
Subject: RE: [OPSAWG] automatic attachment of applications and servi= ces at the edge

 

Dan,

 

Thank you very much fo= r bringing attention to this draft.

What being proposed by= the draft is almost like ES-IS protocol, isn=E2=80=99t it?

 

I think it is quite us= eful.

 

Thanks, Linda Dunbar

 

 

 

 

From: OPSAWG= [mailto:opsawg-bounces@ietf.org= ] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, February 15, 2016 9:10 AM
To: opsawg@ietf.org
Cc: Unbehagen Jr, Paul E (Paul)
Subject: [OPSAWG] automatic attachment of applications and services = at the edge

 

Hi,

 

I would like to draw the attention of the participan= ts in the OPSAWG on an individual submission that I am co-authoring. The pr= oblem we are trying to solve is the optimization / minimizing of the amount= of configuration that an operator needs to do when new applications require the creation of paths or tunnels= in the core network. In order to avoid the reconfiguration of the core or = heavy configuration at the edge the proposed method which we call auto-atta= chment allows for the usage of a protocol running between the end stations and the first (edge) router that= adds the information and characteristics of the new path according to the = policies or mapping tables of the operators. A first implementation that we= have running code for and is deployed is described in https://datatracker.ietf.org/doc/draft-unbehagen-lldp-spb/ and uses the= Link Layer Discovery Protocol (LLDP) with an IEEE 802.1aq Shortest Path Br= idging (SPB) network.

 

Please have a look and let me know if there is inter= est and/or similar on-going work. If there is enough interest I plan to req= uest a short slot to discuss the idea at the OPSAWG meeting at IETF 95.

 

Thanks and Regards,

 

Dan

 


--===============0137209985==-- --===============1510946238== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDIyMjE0Mzg0M1owLwYJKoZIhvcNAQkEMSIEII1Kw+BO0dFe 9kx6hNZWblwdr8S+nuiz7IlfcfhtumnmMAsGCSqGSIb3DQEBCwSCAQBpilp3bCDRnw1pVUnWIPMG jzUdhOZImr0UOig2dGUSWxNfYRcGid+YjZnZElQbVa+IGJf7Ngedz1q2NweKgqoz6sSOdVq8SJtl REHLJQMJD/ImuogC68liCAGHX8qaudOyx6nZMl3Nyp+US8NkNrD8KvMUswNAsitBp+qUgUmUBgAo lgsgTIl2eWt2s8U2e+cLgWk/gCYBTlWyxL9KffgrlvUEVfLSOpVZRX1MKKKH+7toLq1LFyDb8ym2 ygvANQmyduhNoADrJgKSj//CgZHwksV8V7dyOslNn/czXOKOTMsuatDnuzuKA+N9aEyrV39aWWqt LguFnV9qUHwDpztjAAAAAAAA --===============1510946238==-- From nobody Mon Feb 22 07:02:46 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F941B3484 for ; Mon, 22 Feb 2016 07:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=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 Tqi5Hf0iSPA1 for ; Mon, 22 Feb 2016 07:02:41 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0611.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:611]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFA11B2D7C for ; Mon, 22 Feb 2016 07:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=direcpathcorp.onmicrosoft.com; s=selector1-direcpath-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+jtwQ3HmebnL+1Xn9hCopTYEFURyX+eRXLMTGsP8DQo=; b=Nsd7R0bleozFuNAp0iBoQaT+cu7RVpHFAKw93A7i/qMOpalOAGMfYEKFYGeEtF2AndVR23Cv8gI/FFbPVEPhBv0kHpkSggsCKchF/AXXPozeTsuDFMz03FasSQj7/QReCyprWnqktkAwQF0nJCU1kKjl+d9Zbd132B6YudsW38U= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=direcpath.com; Received: from [10.6.2.149] (24.98.60.52) by BY2PR01MB1719.prod.exchangelabs.com (10.163.26.145) with Microsoft SMTP Server (TLS) id 15.1.415.9; Mon, 22 Feb 2016 15:02:19 +0000 To: References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> <56C65A2A.1050304@gmail.com> <017b01d16b34$d3c92020$4001a8c0@gateway.2wire.net> From: Robert Drake Message-ID: Date: Mon, 22 Feb 2016 10:02:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <017b01d16b34$d3c92020$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [24.98.60.52] X-ClientProxiedBy: SN1PR16CA0055.namprd16.prod.outlook.com (25.163.13.23) To BY2PR01MB1719.prod.exchangelabs.com (25.163.26.145) X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 2:9G3uKTAQtOMVtqAxYGqVqEYqF4vsc2kVPoSkg3EUzlxzLvgraGDxgXGOQIiFOqnJfys3pWC9ibbkhkwE0WRCRv+8NnP/kpsughOw9RRtAyXDY3SPhDh5F1Hw412xhETcPeAkVlL0oIOasq/QZRzKMA==; 3:tpA57s+5AtIY8MbvhXgT8RxO44CMuIQYrg7VUpcJxFzpTFh0K3gMpFFRYA294I2jMOhMTcFxzUNheox47LFxVCcz4HGM43dtwL4QkoA0FgnszpsP+aUVG7/L1k2i52n2; 25:44lOPelae0tryXnqxKjOpzenFJCDW4CW5AAov++SfIeHJwrhziP8ljnT/UP5MfQ/camoJoLLRqvDaz2yzyB+8BfnViR/NYI+73V44Reb5xpWCiUNgbGvc9vDY3uOpN1uFdtmOzLHZPwqv7Y69luo3Bg9kckSmQ0d2NpmdDnQZFce0N20AsYBSrRG652igIBlSkuEkt7Z9IY2zQm9Y1EEegwsMo61TDcKROeJIEdOY1b1noOgIWRNfIMnHroEtETA8KasTksmUOXiKHsMWXnmT1D6KlL9MYRC9K+lQXGtcv8tCCCsjwNopxTMlVZT+mf0z6HaVlvYNSQG1X+jjHMpjgsUqidVfsxpmUCCf3WLgbA= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR01MB1719; X-MS-Office365-Filtering-Correlation-Id: 3dfc5e43-40cb-4c58-0e16-08d33b992949 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY2PR01MB1719; BCL:0; PCL:0; RULEID:; SRVR:BY2PR01MB1719; X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 4:Nxxb/nwlOueSSvmXH8YaVkVlrBr2m3J472HHf4pFJR1jImm3rLHZEcRGKlJQfTVCtJa7p9qzPK+AvAFiIzxHUq5439zKayh0DakZwzfQ/Yt9bTt4GEk5L2bsbsU5gN8APtvGjSsv1suLThUD63FbIB17jLj4aPrqGmi61CJYdi6xitbTLEqhasTwJ+wrYPbQpr/7TUTtnWWftcL+npCBCxfWVFvAyQc/54jI/t+fA85URpJ958yBEpVmww/YMlX0Gis0K776AcIw2y7oJVfOjzP7MN0+5jAgQqoPGDsIxOg/K6tDDNtfqDv9KLPdn85yM0DQ7u3hnhWIpkW8Fo8ihyrCfnvmFzjCHyk4/awG48M= X-Forefront-PRVS: 0860FE717F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(24454002)(479174004)(377454003)(87976001)(42186005)(3846002)(50986999)(76176999)(54356999)(23746002)(107886002)(110136002)(5001960100002)(189998001)(93886004)(36756003)(31686004)(586003)(66066001)(5004730100002)(2906002)(5008740100001)(65806001)(47776003)(230700001)(1096002)(65956001)(6116002)(33646002)(50466002)(83506001)(92566002)(2351001)(64126003)(31696002)(2950100001)(86362001)(40100003)(122386002)(77096005)(4001350100001)(450100001)(65826006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR01MB1719; H:[10.6.2.149]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR01MB1719; 23:Ssn7SopXtU+S4OXrKAC1/e12hzmQ4hAjtK6am?= =?Windows-1252?Q?paq610ZyBM48NqYiP7fz/UCPT21g3nHIxFPa5mSBywwXV44nE6PnHGVs?= =?Windows-1252?Q?DwF89gBduWzEHjN8ed1Mv5k209KSxwAnKI0Yl4MY5dXNjXGS/j5k90ve?= =?Windows-1252?Q?rTCySCIS4Vv2qjwVnLJWVhw3JG+d7Tw/WeQlwGg6ZdkbxSkV3KYFLeeN?= =?Windows-1252?Q?tG/YOAiVZdlJaKnJn3ZSdxTuOCPV3/miecNTDQ9d/QAYDnxmgDGvErpF?= =?Windows-1252?Q?TKTp5AMgq64ys0dFgyR1rEhmPmaGWhs5nvIop0KsrKvk+vTecyCAgV71?= =?Windows-1252?Q?dmwkGAicrxqvv4ZtPPZ8Flntqe6HPa1XAu9AlqNKhkLrxO23lnMrTvSb?= =?Windows-1252?Q?pAd3ITXIeY8yZTn39TNleGpN52uHSOfivEvo+sBHP8NWZ+DF991yhWbn?= =?Windows-1252?Q?kNo2Re/87AzmZPoeO/mjivWGhgPlVW8zTfZofb1X3JXp4i6tcNYL2Oit?= =?Windows-1252?Q?6q5rIOxLkAN0v+pZ5iRn3Geq7vr7IhurTlD8MGB8sb9BGkQOAbe9+Mv6?= =?Windows-1252?Q?6r1wPT1YtZkBz3zGYXjqq6P+e4LoLGI1TqyNDtztQPnpo9C55zOBmw+p?= =?Windows-1252?Q?kFO/XQ6f8Cjt0Jx7NhVnNVrK94z+rN8FYFUConexS28I8JLaRnXU3+aS?= =?Windows-1252?Q?j+69y12BKM9FYxiMmbvCFzFJInK0iJIjM0u/IgzYC0cRdRu6JoFga3Yi?= =?Windows-1252?Q?lGDTmhmwy5NXErPtoEgGclW+ukOUkIXUWDo0ozazsBo86k+ZcgcTKFD6?= =?Windows-1252?Q?w6dipxpBmV0Pye5WYG/rLwhi3mESt293icD5KNiNnuIkTJCZhGQ/Jdc3?= =?Windows-1252?Q?QIN7uZjEWgEqOCGCKqRaliWVmucYJbK0DOwPZ6VNQfxHH9Knk5SxqjCc?= =?Windows-1252?Q?Fnv8P5y9KJeEiF2skoK0+xURhNcd3wjtdmw3S61G8YBkiJlIAadnwQUo?= =?Windows-1252?Q?RRS9ZMDoNWFBh+vhC/NHRQrxQUadB7lCMwI+zKikXAQK408BAvErwX5T?= =?Windows-1252?Q?zjym29jmhD3dCEgmHBykZPWpNAw6kTBYVLwQdK90JqfWQGYrCi9cWvaS?= =?Windows-1252?Q?iUwvMEUC8/vb1O2KL2Y7Jm8X5KhWwpaZ9PiRCmm45vf3PoIBWRxbjlJT?= =?Windows-1252?Q?KRiCdCTgF7QCt1jfZDzpkl0WmOikT5QAMUkwyRxMII5b9Z6vRp0n80c2?= =?Windows-1252?Q?N3kFTEOKUa/NxJiF1/7fD1+O9wA6sKXJpuBAWyubmRXfy4dQNA/Fwnos?= =?Windows-1252?Q?Chh?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1719; 5:vQJEQcywplwaMdlUTr7hDF5f6g7kfIl+Qc+kl33/Dd7Max9ox8/8gKuwEjL3HKx3TwkqvoFxJ3HVkFRSpasJ8gtgnzsvvYgFtQsZ6EcR6iz/AF44Kvsbr7t/jeVPcEcaNid8vOwYV+456Ocl2JC7EQ==; 24:LfnH3MVsTmjr6smXL5TTzNG9NALLCNjm89Qs0u3iWNcJPoMMeHmD9MN/4GgBnTWFn9+lpdsLkG3F7ALZGyQj/RrYRneQCBJb1LqYnSSOOXU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: direcpath.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2016 15:02:19.6029 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR01MB1719 Archived-At: Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 15:02:44 -0000 On 2/19/2016 11:39 AM, t.petch wrote: > So until it is, or is just about to be, an RFC, I don't know whether or > not a technology will be encumbered by an IPR claim and I know of > nothing that the participants can say to allay my concerns (the > company's lawyers might be able to:-). That seems like something you need to worry about no matter what the protocol is or where it originally came from. If a company wants to torpedo the standards process then they've always got lawyers. It doesn't matter how silly their claim is, they can tie it up in lawsuits for years. The only thing we have to fight back is the threat to walk away from them as a customer if they don't use a standard for this. Honestly, I've got enough troubles trying to get vendors to adopt tacacs+ without someone adding proprietary extensions. If they want to try it I can see us staying on the existing tacacs+ for another 20 years. The flip side to this is, if the IETF drags out this fight for too long, I could see major vendors making their own efforts to secure the protocol prior to anyone making a standard (possibly because a large customer demands the protocol be secured for whatever reason). If that happens, we might be stuck with TACACS+TLS from one vendor that doesn't interoperate with TACACS+blowfish from another (hopefully all with the ability to fallback to the defacto standard if needed.. or perhaps we just run 3 separate servers with different extensions to support multiple vendors..) Maybe not. It's been 20 years. It's possible it's just too obscure to worry about, but we won't know until it happens. > Tom Petch Robert From nobody Mon Feb 22 07:05:46 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC6B1B3477 for ; Mon, 22 Feb 2016 07:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 9j6J2LftkWlU for ; Mon, 22 Feb 2016 07:05:41 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F081B2D7C for ; Mon, 22 Feb 2016 07:05:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A0AgBEI8tW/yYyC4deDgsBAQEBDwEBAQGCPiErUm0GuDqCEwENgV8HFwEIhW0CHIEgOBQBAQEBAQEBZCeEQQEBAQEDEhEKOiICAQgNBAEDAQELHQMCAgIwFAMGCAEBBAESCBqHeQENnyeKSY5bAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYThDmEBDEWFwmCEjgTGIEPBYVPjSSEFAGFVoJugmSEEUqDeYMZhTuOSR4BAUKBTIFdO2oBAYcxAXwBAQE X-IPAS-Result: A2A0AgBEI8tW/yYyC4deDgsBAQEBDwEBAQGCPiErUm0GuDqCEwENgV8HFwEIhW0CHIEgOBQBAQEBAQEBZCeEQQEBAQEDEhEKOiICAQgNBAEDAQELHQMCAgIwFAMGCAEBBAESCBqHeQENnyeKSY5bAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYThDmEBDEWFwmCEjgTGIEPBYVPjSSEFAGFVoJugmSEEUqDeYMZhTuOSR4BAUKBTIFdO2oBAYcxAXwBAQE X-IronPort-AV: E=Sophos;i="5.22,484,1449550800"; d="scan'208,217";a="143648331" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Feb 2016 10:05:37 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 22 Feb 2016 10:05:36 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 22 Feb 2016 16:05:34 +0100 From: "Romascanu, Dan (Dan)" To: "Blumenthal, Uri - 0553 - MITLL" , Linda Dunbar , "opsawg@ietf.org" Thread-Topic: [OPSAWG] automatic attachment of applications and services at the edge Thread-Index: AdFtfrYv/4iUfe55M0+oKbBfuK/nagAA5etg Date: Mon, 22 Feb 2016 15:05:33 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF23A5C@AZ-FFEXMB04.global.avaya.com> References: <20160222143844.18296912.70526.52991@ll.mit.edu> In-Reply-To: <20160222143844.18296912.70526.52991@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF23A5CAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] automatic attachment of applications and services at the edge X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 15:05:44 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF23A5CAZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW0gaXMgc2NhbGluZy4gT3Igb25lIG9mIHRoZSBwcm9ibGVtcy4gT3ZlcmxvYWRp bmcgdGhlIHJvdXRpbmcgcHJvdG9jb2wgd2l0aCBzZXJ2aWNlL2FwcGxpY2F0aW9uIGluZm9ybWF0 aW9uIGRvZXMgbm90IHNjYWxlIHdlbGwuDQoNClJlZ2FyZHMsDQoNCkRhbg0KDQoNCkZyb206IEJs dW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTCBbbWFpbHRvOnVyaUBsbC5taXQuZWR1XQ0KU2Vu dDogTW9uZGF5LCBGZWJydWFyeSAyMiwgMjAxNiA0OjM5IFBNDQpUbzogUm9tYXNjYW51LCBEYW4g KERhbik7IExpbmRhIER1bmJhcjsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09QU0FX R10gYXV0b21hdGljIGF0dGFjaG1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBzZXJ2aWNlcyBhdCB0 aGUgZWRnZQ0KDQpUaGVuIHdvdWxkIGl0IGJlIHByYWN0aWNhbCB0byBoYXZlIG9uZSBwcm90b2Nv bCB0aGF0IG1hbmFnZWQgY2FycmllcyBib3RoIGtpbmRzIG9mIGRhdGE/DQoNClNlbnQgZnJvbSBt eSBCbGFja0JlcnJ5IDEwIHNtYXJ0cGhvbmUgb24gdGhlIFZlcml6b24gV2lyZWxlc3MgNEcgTFRF IG5ldHdvcmsuDQpGcm9tOiBSb21hc2NhbnUsIERhbiAoRGFuKQ0KU2VudDogTW9uZGF5LCBGZWJy dWFyeSAyMiwgMjAxNiAwOToxOQ0KVG86IExpbmRhIER1bmJhcjsgb3BzYXdnQGlldGYub3JnPG1h aWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09QU0FXR10gYXV0b21hdGljIGF0 dGFjaG1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBzZXJ2aWNlcyBhdCB0aGUgZWRnZQ0KDQoNCkhp IExpbmRhLA0KDQpUaGFua3MgZm9yIHlvdXIgaW50ZXJlc3QgYW5kIGNvbW1lbnQuIEZyb20gYSB0 b3BvbG9neSBhbmQgYXJjaGl0ZWN0dXJlIHBvaW50IG9mIHZpZXcgdGhlIGlkZWEgaXMgaW5kZWVk IHNpbWlsYXIgdG8gRVMtSVMuIFRoZSBkaWZmZXJlbmNlIGlzIGluIHRoZSBjb250ZW50IG9mIHRo ZSBpbmZvcm1hdGlvbiB0aGF0IGlzIGJlaW5nIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBlbmQtc3Rh dGlvbiBhbmQgdGhlIGVkZ2Ugcm91dGVyLg0KDQpSZWdhcmRzLA0KDQpEYW4NCg0KDQpGcm9tOiBM aW5kYSBEdW5iYXIgW21haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbV0NClNlbnQ6IFNhdHVy ZGF5LCBGZWJydWFyeSAyMCwgMjAxNiAyOjA0IEFNDQpUbzogUm9tYXNjYW51LCBEYW4gKERhbik7 IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtP UFNBV0ddIGF1dG9tYXRpYyBhdHRhY2htZW50IG9mIGFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMg YXQgdGhlIGVkZ2UNCg0KRGFuLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBicmluZ2luZyBh dHRlbnRpb24gdG8gdGhpcyBkcmFmdC4NCldoYXQgYmVpbmcgcHJvcG9zZWQgYnkgdGhlIGRyYWZ0 IGlzIGFsbW9zdCBsaWtlIEVTLUlTIHByb3RvY29sLCBpc27igJl0IGl0Pw0KDQpJIHRoaW5rIGl0 IGlzIHF1aXRlIHVzZWZ1bC4NCg0KVGhhbmtzLCBMaW5kYSBEdW5iYXINCg0KDQoNCg0KRnJvbTog T1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb21h c2NhbnUsIERhbiAoRGFuKQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxNSwgMjAxNiA5OjEwIEFN DQpUbzogb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpDYzogVW5iZWhh Z2VuIEpyLCBQYXVsIEUgKFBhdWwpDQpTdWJqZWN0OiBbT1BTQVdHXSBhdXRvbWF0aWMgYXR0YWNo bWVudCBvZiBhcHBsaWNhdGlvbnMgYW5kIHNlcnZpY2VzIGF0IHRoZSBlZGdlDQoNCkhpLA0KDQpJ IHdvdWxkIGxpa2UgdG8gZHJhdyB0aGUgYXR0ZW50aW9uIG9mIHRoZSBwYXJ0aWNpcGFudHMgaW4g dGhlIE9QU0FXRyBvbiBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gdGhhdCBJIGFtIGNvLWF1dGhv cmluZy4gVGhlIHByb2JsZW0gd2UgYXJlIHRyeWluZyB0byBzb2x2ZSBpcyB0aGUgb3B0aW1pemF0 aW9uIC8gbWluaW1pemluZyBvZiB0aGUgYW1vdW50IG9mIGNvbmZpZ3VyYXRpb24gdGhhdCBhbiBv cGVyYXRvciBuZWVkcyB0byBkbyB3aGVuIG5ldyBhcHBsaWNhdGlvbnMgcmVxdWlyZSB0aGUgY3Jl YXRpb24gb2YgcGF0aHMgb3IgdHVubmVscyBpbiB0aGUgY29yZSBuZXR3b3JrLiBJbiBvcmRlciB0 byBhdm9pZCB0aGUgcmVjb25maWd1cmF0aW9uIG9mIHRoZSBjb3JlIG9yIGhlYXZ5IGNvbmZpZ3Vy YXRpb24gYXQgdGhlIGVkZ2UgdGhlIHByb3Bvc2VkIG1ldGhvZCB3aGljaCB3ZSBjYWxsIGF1dG8t YXR0YWNobWVudCBhbGxvd3MgZm9yIHRoZSB1c2FnZSBvZiBhIHByb3RvY29sIHJ1bm5pbmcgYmV0 d2VlbiB0aGUgZW5kIHN0YXRpb25zIGFuZCB0aGUgZmlyc3QgKGVkZ2UpIHJvdXRlciB0aGF0IGFk ZHMgdGhlIGluZm9ybWF0aW9uIGFuZCBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIG5ldyBwYXRoIGFj Y29yZGluZyB0byB0aGUgcG9saWNpZXMgb3IgbWFwcGluZyB0YWJsZXMgb2YgdGhlIG9wZXJhdG9y cy4gQSBmaXJzdCBpbXBsZW1lbnRhdGlvbiB0aGF0IHdlIGhhdmUgcnVubmluZyBjb2RlIGZvciBh bmQgaXMgZGVwbG95ZWQgaXMgZGVzY3JpYmVkIGluIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXVuYmVoYWdlbi1sbGRwLXNwYi88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJh ZnQtMkR1bmJlaGFnZW4tMkRsbGRwLTJEc3BiXyZkPUJRTUZBZyZjPUJGcFdRdzhic3VLcGwxU2dp Wkg2NFEmcj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09NEZt SVdTS0JSbkU2elk5Z2drZ2V3NUQ0OUdUaERJYzhYYXZxTjYwdTZJayZzPW5kdEcyZlFTNzZNZW1r bmhFd3g3bklDSTN6Y0ZQVGxTLTVYbV9ERHdIM3MmZT0+IGFuZCB1c2VzIHRoZSBMaW5rIExheWVy IERpc2NvdmVyeSBQcm90b2NvbCAoTExEUCkgd2l0aCBhbiBJRUVFIDgwMi4xYXEgU2hvcnRlc3Qg UGF0aCBCcmlkZ2luZyAoU1BCKSBuZXR3b3JrLg0KDQpQbGVhc2UgaGF2ZSBhIGxvb2sgYW5kIGxl dCBtZSBrbm93IGlmIHRoZXJlIGlzIGludGVyZXN0IGFuZC9vciBzaW1pbGFyIG9uLWdvaW5nIHdv cmsuIElmIHRoZXJlIGlzIGVub3VnaCBpbnRlcmVzdCBJIHBsYW4gdG8gcmVxdWVzdCBhIHNob3J0 IHNsb3QgdG8gZGlzY3VzcyB0aGUgaWRlYSBhdCB0aGUgT1BTQVdHIG1lZXRpbmcgYXQgSUVURiA5 NS4NCg0KVGhhbmtzIGFuZCBSZWdhcmRzLA0KDQpEYW4NCg0KDQoNCg== --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF23A5CAZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb2No cGRlZmF1bHQsIGxpLm1zb2NocGRlZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0DQoJe21zby1zdHls ZS1uYW1lOm1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uYmFsbG9vbnRleHRjaGFyMA0KCXttc28tc3R5bGUtbmFtZTpiYWxsb29u dGV4dGNoYXI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uZW1h aWxzdHlsZTE5DQoJe21zby1zdHlsZS1uYW1lOmVtYWlsc3R5bGUxOTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5lbWFpbHN0 eWxlMjANCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxzdHlsZTIwOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmVtYWlsc3R5bGUyMQ0K CXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMjE7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTIyDQoJe21zby1z dHlsZS1uYW1lOmVtYWlsc3R5bGUyMjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMjMNCgl7bXNvLXN0eWxlLW5h bWU6ZW1haWxzdHlsZTIzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLmVtYWlsc3R5bGUyNA0KCXttc28tc3R5bGUtbmFtZTplbWFp bHN0eWxlMjQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hp dGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+VGhlIHByb2JsZW0gaXMgc2NhbGluZy4gT3Igb25lIG9mIHRoZSBwcm9ibGVtcy4g T3ZlcmxvYWRpbmcgdGhlIHJvdXRpbmcgcHJvdG9jb2wgd2l0aCBzZXJ2aWNlL2FwcGxpY2F0aW9u IGluZm9ybWF0aW9uIGRvZXMgbm90IHNjYWxlIHdlbGwuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTCBbbWFpbHRvOnVyaUBsbC5taXQuZWR1 XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMjIsIDIwMTYgNDozOSBQTTxi cj4NCjxiPlRvOjwvYj4gUm9tYXNjYW51LCBEYW4gKERhbik7IExpbmRhIER1bmJhcjsgb3BzYXdn QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT1BTQVdHXSBhdXRvbWF0aWMgYXR0 YWNobWVudCBvZiBhcHBsaWNhdGlvbnMgYW5kIHNlcnZpY2VzIGF0IHRoZSBlZGdlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlbiB3b3VsZCBpdCBi ZSBwcmFjdGljYWwgdG8gaGF2ZSBvbmUgcHJvdG9jb2wgdGhhdCBtYW5hZ2VkIGNhcnJpZXMgYm90 aCBraW5kcyBvZiBkYXRhPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5TZW50Jm5ic3A7ZnJvbSZuYnNwO215Jm5ic3A7QmxhY2tCZXJy eSZuYnNwOzEwJm5ic3A7c21hcnRwaG9uZSZuYnNwO29uJm5ic3A7dGhlJm5ic3A7VmVyaXpvbiZu YnNwO1dpcmVsZXNzJm5ic3A7NEcmbmJzcDtMVEUmbmJzcDtuZXR3b3JrLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7YmFja2dy b3VuZDp3aGl0ZTtib3JkZXItc3BhY2luZzowcHgiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2ZvbnQtc2l6ZTppbml0aWFsO3RleHQt YWxpZ246aW5pdGlhbCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206DQo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Sb21hc2NhbnUsIERhbiAoRGFuKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50Og0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+TW9uZGF5LCBGZWJydWFyeSAyMiwgMjAxNiAwOToxOTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbzoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkxpbmRhIER1bmJhcjsNCjxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0 Zi5vcmciPm9wc2F3Z0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+U3ViamVjdDoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlOiBb T1BTQVdHXSBhdXRvbWF0aWMgYXR0YWNobWVudCBvZiBhcHBsaWNhdGlvbnMgYW5kIHNlcnZpY2Vz IGF0IHRoZSBlZGdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJfb3JpZ2luYWxD b250ZW50Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SGkgTGluZGEsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5U aGFua3MgZm9yIHlvdXIgaW50ZXJlc3QgYW5kIGNvbW1lbnQuIEZyb20gYSB0b3BvbG9neSBhbmQg YXJjaGl0ZWN0dXJlIHBvaW50IG9mIHZpZXcgdGhlIGlkZWEgaXMgaW5kZWVkIHNpbWlsYXIgdG8g RVMtSVMuIFRoZSBkaWZmZXJlbmNlIGlzIGluIHRoZSBjb250ZW50IG9mIHRoZSBpbmZvcm1hdGlv biB0aGF0IGlzIGJlaW5nIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZQ0KIGVuZC1zdGF0aW9uIGFuZCB0 aGUgZWRnZSByb3V0ZXIuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRhbjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTGluZGEgRHVuYmFyIFs8 YSBocmVmPSJtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20iPm1haWx0bzpsaW5kYS5kdW5i YXJAaHVhd2VpLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEZlYnJ1YXJ5 IDIwLCAyMDE2IDI6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IFJvbWFzY2FudSwgRGFuIChEYW4pOyA8 YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIj5vcHNhd2dAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbT1BTQVdHXSBhdXRvbWF0aWMgYXR0YWNobWVudCBvZiBhcHBs aWNhdGlvbnMgYW5kIHNlcnZpY2VzIGF0IHRoZSBlZGdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRhbiwg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgdmVyeSBtdWNo IGZvciBicmluZ2luZyBhdHRlbnRpb24gdG8gdGhpcyBkcmFmdC4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5X aGF0IGJlaW5nIHByb3Bvc2VkIGJ5IHRoZSBkcmFmdCBpcyBhbG1vc3QgbGlrZSBFUy1JUyBwcm90 b2NvbCwgaXNu4oCZdCBpdD8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SSB0aGluayBpdCBpcyBxdWl0ZSB1c2VmdWwuIDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5UaGFua3MsIExpbmRhIER1bmJhcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT1BTQVdHIFs8YSBocmVmPSJt YWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbWFzY2FudSwgRGFuIChEYW4pPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMTUsIDIwMTYgOToxMCBBTTxicj4NCjxiPlRv OjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnQGlldGYub3JnPC9h Pjxicj4NCjxiPkNjOjwvYj4gVW5iZWhhZ2VuIEpyLCBQYXVsIEUgKFBhdWwpPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtPUFNBV0ddIGF1dG9tYXRpYyBhdHRhY2htZW50IG9mIGFwcGxpY2F0aW9ucyBh bmQgc2VydmljZXMgYXQgdGhlIGVkZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRv IGRyYXcgdGhlIGF0dGVudGlvbiBvZiB0aGUgcGFydGljaXBhbnRzIGluIHRoZSBPUFNBV0cgb24g YW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIHRoYXQgSSBhbSBjby1hdXRob3JpbmcuIFRoZSBwcm9i bGVtIHdlIGFyZSB0cnlpbmcgdG8gc29sdmUgaXMgdGhlIG9wdGltaXphdGlvbiAvIG1pbmltaXpp bmcgb2YgdGhlIGFtb3VudCBvZiBjb25maWd1cmF0aW9uIHRoYXQgYW4gb3BlcmF0b3INCiBuZWVk cyB0byBkbyB3aGVuIG5ldyBhcHBsaWNhdGlvbnMgcmVxdWlyZSB0aGUgY3JlYXRpb24gb2YgcGF0 aHMgb3IgdHVubmVscyBpbiB0aGUgY29yZSBuZXR3b3JrLiBJbiBvcmRlciB0byBhdm9pZCB0aGUg cmVjb25maWd1cmF0aW9uIG9mIHRoZSBjb3JlIG9yIGhlYXZ5IGNvbmZpZ3VyYXRpb24gYXQgdGhl IGVkZ2UgdGhlIHByb3Bvc2VkIG1ldGhvZCB3aGljaCB3ZSBjYWxsIGF1dG8tYXR0YWNobWVudCBh bGxvd3MgZm9yIHRoZSB1c2FnZSBvZiBhDQogcHJvdG9jb2wgcnVubmluZyBiZXR3ZWVuIHRoZSBl bmQgc3RhdGlvbnMgYW5kIHRoZSBmaXJzdCAoZWRnZSkgcm91dGVyIHRoYXQgYWRkcyB0aGUgaW5m b3JtYXRpb24gYW5kIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbmV3IHBhdGggYWNjb3JkaW5nIHRv IHRoZSBwb2xpY2llcyBvciBtYXBwaW5nIHRhYmxlcyBvZiB0aGUgb3BlcmF0b3JzLiBBIGZpcnN0 IGltcGxlbWVudGF0aW9uIHRoYXQgd2UgaGF2ZSBydW5uaW5nIGNvZGUgZm9yIGFuZCBpcyBkZXBs b3llZA0KIGlzIGRlc2NyaWJlZCBpbiA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFm dC0yRHVuYmVoYWdlbi0yRGxsZHAtMkRzcGJfJmFtcDtkPUJRTUZBZyZhbXA7Yz1CRnBXUXc4YnN1 S3BsMVNnaVpINjRRJmFtcDtyPUk0ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBo cEJzRkEmYW1wO209NEZtSVdTS0JSbkU2elk5Z2drZ2V3NUQ0OUdUaERJYzhYYXZxTjYwdTZJayZh bXA7cz1uZHRHMmZRUzc2TWVta25oRXd4N25JQ0kzemNGUFRsUy01WG1fRER3SDNzJmFtcDtlPSIg dGFyZ2V0PSJfQkxBTksiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dW5iZWhhZ2VuLWxsZHAtc3BiLzwvYT4gYW5kIHVzZXMgdGhlIExpbmsgTGF5ZXIgRGlzY292ZXJ5 IFByb3RvY29sIChMTERQKSB3aXRoIGFuIElFRUUgODAyLjFhcSBTaG9ydGVzdCBQYXRoIEJyaWRn aW5nIChTUEIpIG5ldHdvcmsuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGhhdmUg YSBsb29rIGFuZCBsZXQgbWUga25vdyBpZiB0aGVyZSBpcyBpbnRlcmVzdCBhbmQvb3Igc2ltaWxh ciBvbi1nb2luZyB3b3JrLiBJZiB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3QgSSBwbGFuIHRvIHJl cXVlc3QgYSBzaG9ydCBzbG90IHRvIGRpc2N1c3MgdGhlIGlkZWEgYXQgdGhlIE9QU0FXRyBtZWV0 aW5nIGF0IElFVEYgOTUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGFuZCBSZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF23A5CAZFFEXMB04globa_-- From nobody Mon Feb 22 07:29:32 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5A21B369A for ; Mon, 22 Feb 2016 07:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham 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 FclJgveBeOnB for ; Mon, 22 Feb 2016 07:29:29 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2451B3649 for ; Mon, 22 Feb 2016 07:29:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 361486A5; Mon, 22 Feb 2016 15:29:28 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXAjfeLTcN7E; Mon, 22 Feb 2016 15:29:28 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 81D771B1; Mon, 22 Feb 2016 15:29:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56C7538F.4000209@cisco.com> Date: Mon, 22 Feb 2016 10:29:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56C7538F.4000209@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 15:29:31 -0000 On Feb 19, 2016, at 12:40 PM, Eliot Lear wrote: > My suggestion is that working group consensus (not any particular = individual's or company's point of view) determine what is in a proposed = standard. Operational experience with what is running is going to = dictate what many people believe should and should not be in in that = doc. Whether there is an informational document won't change this. = That's a good thing. If someone said we should rewrite TACACS+ to use = EBCDIC encoding, for instance, I'm pretty sure you'd see a lot of people = complain. If the WG diverges substantially from what is running code, = then two documents seem called for. But I don't see that we've crossed = that bridge yet. Adding TLS is a substantial divergence, IMHO. There are no TACACS+ = servers I'm aware of which implement TLS. Why not document TACACS+ as a historical protocol, and then "TLS = transport for legacy network admin protocols"? If the changes are = minor, then the TLS document is minor. If the work to add TLS is not minor, then I think that would fall = under the rubric of it "diverges substantially from what is running = code, then two documents seem called for." I'd like to just pick one path forward, and be done with it. But the = reasons for doing things change, depending on who's answering, and what = the question is. To me, this indicates that not only we don't have WG = consensus on the document(s), but that the people *proposing* the = document(s) can't even reach consensus among themselves as to what = they're proposing. Alan DeKok. From nobody Mon Feb 22 07:37:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE47E1B36FF for ; Mon, 22 Feb 2016 07:37:21 -0800 (PST) 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] autolearn=ham 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 qE9VveKu1Gva for ; Mon, 22 Feb 2016 07:37:20 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 925211B36FC for ; Mon, 22 Feb 2016 07:37:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id F3463D45; Mon, 22 Feb 2016 15:37:19 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqwUepU_sDrx; Mon, 22 Feb 2016 15:37:19 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 7D9991B1; Mon, 22 Feb 2016 15:37:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Mon, 22 Feb 2016 10:37:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <81589497-305F-49DF-BACD-B3701902B285@deployingradius.com> References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> <56C65A2A.1050304@gmail.com> <017b01d16b34$d3c92020$4001a8c0@gateway.2wire.net> To: Robert Drake X-Mailer: Apple Mail (2.3112) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 15:37:21 -0000 On Feb 22, 2016, at 10:02 AM, Robert Drake wrote: > That seems like something you need to worry about no matter what the = protocol is or where it originally came from. If a company wants to = torpedo the standards process then they've always got lawyers. It = doesn't matter how silly their claim is, they can tie it up in lawsuits = for years. True. > The flip side to this is, if the IETF drags out this fight for too = long, I could see major vendors making their own efforts to secure the = protocol prior to anyone making a standard (possibly because a large = customer demands the protocol be secured for whatever reason). If that = happens, we might be stuck with TACACS+TLS from one vendor that doesn't = interoperate with TACACS+blowfish from another (hopefully all with the = ability to fallback to the defacto standard if needed.. or perhaps we = just run 3 separate servers with different extensions to support = multiple vendors..) >=20 > Maybe not. It's been 20 years. It's possible it's just too obscure = to worry about, but we won't know until it happens. I think since TACACS+ has waited 20+ years for standardization, it's = worth waiting a few more months to be sure we get it right. And since TACACS+ is largely used *within* the enterprise, the issue = of securing it is less relevant than (say) RADIUS, which is used across = the wider internet. Alan DeKok. From nobody Mon Feb 22 09:11:51 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605491A0469 for ; Mon, 22 Feb 2016 09:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 801GISMHjAvJ for ; Mon, 22 Feb 2016 09:11:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EFF1A01D5 for ; Mon, 22 Feb 2016 09:11:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIZ74447; Mon, 22 Feb 2016 17:11:43 +0000 (GMT) Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 22 Feb 2016 17:11:42 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 22 Feb 2016 17:11:42 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Mon, 22 Feb 2016 09:11:37 -0800 From: Linda Dunbar To: "Romascanu, Dan (Dan)" , "Blumenthal, Uri - 0553 - MITLL" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] automatic attachment of applications and services at the edge Thread-Index: AdFtfrYv5dIlRaa7MEalLssJhUQaUgARtHuAAAygttA= Date: Mon, 22 Feb 2016 17:11:37 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DEE440@dfweml701-chm> References: <20160222143844.18296912.70526.52991@ll.mit.edu> <9904FB1B0159DA42B0B887B7FA8119CA6BF23A5C@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF23A5C@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.236] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DEE440dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56CB414F.01FF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9da4adff03c04911a222333218b15db8 Archived-At: Subject: Re: [OPSAWG] automatic attachment of applications and services at the edge X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 17:11:50 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DEE440dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkl0IG1ha2VzIG1vcmUgc2Vuc2UgZm9yIHNlcnZpY2UgcmVsYXRlZCBpbmZvcm1hdGlvbiB0 byBiZSBleGNoYW5nZWQgYmV0d2VlbiBuZXR3b3JrIGNvbnRyb2xsZXIgYW5kIHRoZSBlZGdlIHJv dXRlcnMgYW5kIGhhdmUgdGhlIHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBleGNoYW5nZWQgZGly ZWN0bHkgYmV0d2VlbiBlZGdlIHJvdXRlciBhbmQgdGhlIGVuZCBkZXZpY2UuDQoNCk9JRiBoYWQg c3BlbnQgbWFueSB5ZWFycyB3b3JraW5nIG9uIFVOSSAoVXNlciAgTmV0d29yayBJbnRlcmZhY2Up LCBidXQgc2VlbiB2ZXJ5IGxpdHRsZSBkZXBsb3ltZW50LiBNYW55IG9wZXJhdG9ycyBleHByZXNz ZWQgdGhhdCB0aGVpciBPU1MvQmlsbGluZyBzeXN0ZW1zIGhhdmUgdG8gYmUgaW52b2x2ZWQgaW4g ZW5hYmxpbmcvZGlzYWJsaW5nIHNlcnZpY2VzIGJlY2F1c2Ugb2YgdGhlIHRydXN0IGlzc3VlcyB0 byB0aGUgZW5kIGRldmljZXMgYXR0YWNoZWQuIFNvIGl0IGlzIG1vcmUgcHJhY3RpY2FsbHkgZm9y IGVuZCBkZXZpY2UgdG8gaW50ZXJmYWNlIHdpdGggdGhlIG5ldHdvcmsgY29udHJvbGxlciBmb3Ig dGhlaXIgZGVzaXJlZCBmZWF0dXJlLiBUaGUgbmV0d29yayBjb250cm9sbGVyIHRoZW4gZGlzc2Vt aW5hdGUgdGhlIHBvbGljeS9pbmZvcm1hdGlvbiB0byB0aGUgZWRnZSByb3V0ZXJzLg0KDQpJbiBh ZGRpdGlvbiwgc29tZXRpbWVzLCBpdCBpcyBub3QgZmVhc2libGUgdG8gdXBkYXRlIHNvbWUgb2Yg dGhlIGVkZ2Ugcm91dGVycyBkZXBsb3llZCBhdCB0aGUgZWRnZSB0byBzdXBwb3J0IHRoZSBuZXds eSBkZXZlbG9wZWQgcHJvdG9jb2wuDQoNCk15IHR3byBjZW50cy4NCg0KTGluZGENCg0KRnJvbTog Um9tYXNjYW51LCBEYW4gKERhbikgW21haWx0bzpkcm9tYXNjYUBhdmF5YS5jb21dDQpTZW50OiBN b25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2IDk6MDYgQU0NClRvOiBCbHVtZW50aGFsLCBVcmkgLSAw NTUzIC0gTUlUTEw7IExpbmRhIER1bmJhcjsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W09QU0FXR10gYXV0b21hdGljIGF0dGFjaG1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBzZXJ2aWNl cyBhdCB0aGUgZWRnZQ0KDQpUaGUgcHJvYmxlbSBpcyBzY2FsaW5nLiBPciBvbmUgb2YgdGhlIHBy b2JsZW1zLiBPdmVybG9hZGluZyB0aGUgcm91dGluZyBwcm90b2NvbCB3aXRoIHNlcnZpY2UvYXBw bGljYXRpb24gaW5mb3JtYXRpb24gZG9lcyBub3Qgc2NhbGUgd2VsbC4NCg0KUmVnYXJkcywNCg0K RGFuDQoNCg0KRnJvbTogQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMIFttYWlsdG86dXJp QGxsLm1pdC5lZHVdDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2IDQ6MzkgUE0NClRv OiBSb21hc2NhbnUsIERhbiAoRGFuKTsgTGluZGEgRHVuYmFyOyBvcHNhd2dAaWV0Zi5vcmc8bWFp bHRvOm9wc2F3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT1BTQVdHXSBhdXRvbWF0aWMgYXR0 YWNobWVudCBvZiBhcHBsaWNhdGlvbnMgYW5kIHNlcnZpY2VzIGF0IHRoZSBlZGdlDQoNClRoZW4g d291bGQgaXQgYmUgcHJhY3RpY2FsIHRvIGhhdmUgb25lIHByb3RvY29sIHRoYXQgbWFuYWdlZCBj YXJyaWVzIGJvdGgga2luZHMgb2YgZGF0YT8NCg0KU2VudCBmcm9tIG15IEJsYWNrQmVycnkgMTAg c21hcnRwaG9uZSBvbiB0aGUgVmVyaXpvbiBXaXJlbGVzcyA0RyBMVEUgbmV0d29yay4NCkZyb206 IFJvbWFzY2FudSwgRGFuIChEYW4pDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2IDA5 OjE5DQpUbzogTGluZGEgRHVuYmFyOyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbT1BTQVdHXSBhdXRvbWF0aWMgYXR0YWNobWVudCBvZiBhcHBs aWNhdGlvbnMgYW5kIHNlcnZpY2VzIGF0IHRoZSBlZGdlDQoNCg0KSGkgTGluZGEsDQoNClRoYW5r cyBmb3IgeW91ciBpbnRlcmVzdCBhbmQgY29tbWVudC4gRnJvbSBhIHRvcG9sb2d5IGFuZCBhcmNo aXRlY3R1cmUgcG9pbnQgb2YgdmlldyB0aGUgaWRlYSBpcyBpbmRlZWQgc2ltaWxhciB0byBFUy1J Uy4gVGhlIGRpZmZlcmVuY2UgaXMgaW4gdGhlIGNvbnRlbnQgb2YgdGhlIGluZm9ybWF0aW9uIHRo YXQgaXMgYmVpbmcgZXhjaGFuZ2VkIGJldHdlZW4gdGhlIGVuZC1zdGF0aW9uIGFuZCB0aGUgZWRn ZSByb3V0ZXIuDQoNClJlZ2FyZHMsDQoNCkRhbg0KDQoNCkZyb206IExpbmRhIER1bmJhciBbbWFp bHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tXQ0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDIw LCAyMDE2IDI6MDQgQU0NClRvOiBSb21hc2NhbnUsIERhbiAoRGFuKTsgb3BzYXdnQGlldGYub3Jn PG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW09QU0FXR10gYXV0b21hdGlj IGF0dGFjaG1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBzZXJ2aWNlcyBhdCB0aGUgZWRnZQ0KDQpE YW4sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIGJyaW5naW5nIGF0dGVudGlvbiB0byB0aGlz IGRyYWZ0Lg0KV2hhdCBiZWluZyBwcm9wb3NlZCBieSB0aGUgZHJhZnQgaXMgYWxtb3N0IGxpa2Ug RVMtSVMgcHJvdG9jb2wsIGlzbuKAmXQgaXQ/DQoNCkkgdGhpbmsgaXQgaXMgcXVpdGUgdXNlZnVs Lg0KDQpUaGFua3MsIExpbmRhIER1bmJhcg0KDQoNCg0KDQpGcm9tOiBPUFNBV0cgW21haWx0bzpv cHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFzY2FudSwgRGFuIChEYW4p DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE1LCAyMDE2IDk6MTAgQU0NClRvOiBvcHNhd2dAaWV0 Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCkNjOiBVbmJlaGFnZW4gSnIsIFBhdWwgRSAo UGF1bCkNClN1YmplY3Q6IFtPUFNBV0ddIGF1dG9tYXRpYyBhdHRhY2htZW50IG9mIGFwcGxpY2F0 aW9ucyBhbmQgc2VydmljZXMgYXQgdGhlIGVkZ2UNCg0KSGksDQoNCkkgd291bGQgbGlrZSB0byBk cmF3IHRoZSBhdHRlbnRpb24gb2YgdGhlIHBhcnRpY2lwYW50cyBpbiB0aGUgT1BTQVdHIG9uIGFu IGluZGl2aWR1YWwgc3VibWlzc2lvbiB0aGF0IEkgYW0gY28tYXV0aG9yaW5nLiBUaGUgcHJvYmxl bSB3ZSBhcmUgdHJ5aW5nIHRvIHNvbHZlIGlzIHRoZSBvcHRpbWl6YXRpb24gLyBtaW5pbWl6aW5n IG9mIHRoZSBhbW91bnQgb2YgY29uZmlndXJhdGlvbiB0aGF0IGFuIG9wZXJhdG9yIG5lZWRzIHRv IGRvIHdoZW4gbmV3IGFwcGxpY2F0aW9ucyByZXF1aXJlIHRoZSBjcmVhdGlvbiBvZiBwYXRocyBv ciB0dW5uZWxzIGluIHRoZSBjb3JlIG5ldHdvcmsuIEluIG9yZGVyIHRvIGF2b2lkIHRoZSByZWNv bmZpZ3VyYXRpb24gb2YgdGhlIGNvcmUgb3IgaGVhdnkgY29uZmlndXJhdGlvbiBhdCB0aGUgZWRn ZSB0aGUgcHJvcG9zZWQgbWV0aG9kIHdoaWNoIHdlIGNhbGwgYXV0by1hdHRhY2htZW50IGFsbG93 cyBmb3IgdGhlIHVzYWdlIG9mIGEgcHJvdG9jb2wgcnVubmluZyBiZXR3ZWVuIHRoZSBlbmQgc3Rh dGlvbnMgYW5kIHRoZSBmaXJzdCAoZWRnZSkgcm91dGVyIHRoYXQgYWRkcyB0aGUgaW5mb3JtYXRp b24gYW5kIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbmV3IHBhdGggYWNjb3JkaW5nIHRvIHRoZSBw b2xpY2llcyBvciBtYXBwaW5nIHRhYmxlcyBvZiB0aGUgb3BlcmF0b3JzLiBBIGZpcnN0IGltcGxl bWVudGF0aW9uIHRoYXQgd2UgaGF2ZSBydW5uaW5nIGNvZGUgZm9yIGFuZCBpcyBkZXBsb3llZCBp cyBkZXNjcmliZWQgaW4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdW5i ZWhhZ2VuLWxsZHAtc3BiLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRHVuYmVoYWdlbi0y RGxsZHAtMkRzcGJfJmQ9QlFNRkFnJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPUk0ZHpHeFIz MU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmbT00Rm1JV1NLQlJuRTZ6WTlnZ2tn ZXc1RDQ5R1RoREljOFhhdnFONjB1NklrJnM9bmR0RzJmUVM3Nk1lbWtuaEV3eDduSUNJM3pjRlBU bFMtNVhtX0REd0gzcyZlPT4gYW5kIHVzZXMgdGhlIExpbmsgTGF5ZXIgRGlzY292ZXJ5IFByb3Rv Y29sIChMTERQKSB3aXRoIGFuIElFRUUgODAyLjFhcSBTaG9ydGVzdCBQYXRoIEJyaWRnaW5nIChT UEIpIG5ldHdvcmsuDQoNClBsZWFzZSBoYXZlIGEgbG9vayBhbmQgbGV0IG1lIGtub3cgaWYgdGhl cmUgaXMgaW50ZXJlc3QgYW5kL29yIHNpbWlsYXIgb24tZ29pbmcgd29yay4gSWYgdGhlcmUgaXMg ZW5vdWdoIGludGVyZXN0IEkgcGxhbiB0byByZXF1ZXN0IGEgc2hvcnQgc2xvdCB0byBkaXNjdXNz IHRoZSBpZGVhIGF0IHRoZSBPUFNBV0cgbWVldGluZyBhdCBJRVRGIDk1Lg0KDQpUaGFua3MgYW5k IFJlZ2FyZHMsDQoNCkRhbg0KDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657DEE440dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb2NocGRlZmF1bHQsIGxp Lm1zb2NocGRlZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOm1zb2No cGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4uYmFsbG9vbnRleHRjaGFyMA0KCXttc28tc3R5bGUtbmFtZTpiYWxsb29udGV4dGNoYXI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uZW1haWxzdHlsZTE5DQoJ e21zby1zdHlsZS1uYW1lOmVtYWlsc3R5bGUxOTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5lbWFpbHN0eWxlMjANCgl7bXNv LXN0eWxlLW5hbWU6ZW1haWxzdHlsZTIwOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmVtYWlsc3R5bGUyMQ0KCXttc28tc3R5bGUt bmFtZTplbWFpbHN0eWxlMjE7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTIyDQoJe21zby1zdHlsZS1uYW1lOmVt YWlsc3R5bGUyMjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMjMNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxzdHls ZTIzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLmVtYWlsc3R5bGUyNA0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMjQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAx LjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IG1ha2VzIG1vcmUgc2Vuc2UgZm9yIHNlcnZpY2Ug cmVsYXRlZCBpbmZvcm1hdGlvbiB0byBiZSBleGNoYW5nZWQgYmV0d2VlbiBuZXR3b3JrIGNvbnRy b2xsZXIgYW5kIHRoZSBlZGdlIHJvdXRlcnMgYW5kIGhhdmUgdGhlIHJlYWNoYWJpbGl0eSBpbmZv cm1hdGlvbiBleGNoYW5nZWQgZGlyZWN0bHkgYmV0d2VlbiBlZGdlIHJvdXRlciBhbmQgdGhlIGVu ZCBkZXZpY2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk9JRiBoYWQg c3BlbnQgbWFueSB5ZWFycyB3b3JraW5nIG9uIFVOSSAoVXNlciZuYnNwOyBOZXR3b3JrIEludGVy ZmFjZSksIGJ1dCBzZWVuIHZlcnkgbGl0dGxlIGRlcGxveW1lbnQuIE1hbnkgb3BlcmF0b3JzIGV4 cHJlc3NlZCB0aGF0IHRoZWlyIE9TUy9CaWxsaW5nIHN5c3RlbXMgaGF2ZSB0byBiZSBpbnZvbHZl ZCBpbiBlbmFibGluZy9kaXNhYmxpbmcgc2VydmljZXMgYmVjYXVzZQ0KIG9mIHRoZSB0cnVzdCBp c3N1ZXMgdG8gdGhlIGVuZCBkZXZpY2VzIGF0dGFjaGVkLiBTbyBpdCBpcyBtb3JlIHByYWN0aWNh bGx5IGZvciBlbmQgZGV2aWNlIHRvIGludGVyZmFjZSB3aXRoIHRoZSBuZXR3b3JrIGNvbnRyb2xs ZXIgZm9yIHRoZWlyIGRlc2lyZWQgZmVhdHVyZS4gVGhlIG5ldHdvcmsgY29udHJvbGxlciB0aGVu IGRpc3NlbWluYXRlIHRoZSBwb2xpY3kvaW5mb3JtYXRpb24gdG8gdGhlIGVkZ2Ugcm91dGVycy4g Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JbiBhZGRpdGlvbiwg c29tZXRpbWVzLCBpdCBpcyBub3QgZmVhc2libGUgdG8gdXBkYXRlIHNvbWUgb2YgdGhlIGVkZ2Ug cm91dGVycyBkZXBsb3llZCBhdCB0aGUgZWRnZSB0byBzdXBwb3J0IHRoZSBuZXdseSBkZXZlbG9w ZWQgcHJvdG9jb2wuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk15IHR3 byBjZW50cy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MaW5kYSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBSb21hc2NhbnUsIERhbiAoRGFuKSBbbWFpbHRvOmRyb21hc2NhQGF2YXlhLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2IDk6MDYgQU08YnI+DQo8Yj5U bzo8L2I+IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTDsgTGluZGEgRHVuYmFyOyBvcHNh d2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPUFNBV0ddIGF1dG9tYXRpYyBh dHRhY2htZW50IG9mIGFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMgYXQgdGhlIGVkZ2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhlIHByb2JsZW0gaXMgc2NhbGluZy4gT3Igb25lIG9mIHRoZSBwcm9ibGVt cy4gT3ZlcmxvYWRpbmcgdGhlIHJvdXRpbmcgcHJvdG9jb2wgd2l0aCBzZXJ2aWNlL2FwcGxpY2F0 aW9uIGluZm9ybWF0aW9uIGRvZXMgbm90IHNjYWxlIHdlbGwuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTCBbPGEgaHJlZj0ibWFpbHRvOnVy aUBsbC5taXQuZWR1Ij5tYWlsdG86dXJpQGxsLm1pdC5lZHU8L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgRmVicnVhcnkgMjIsIDIwMTYgNDozOSBQTTxicj4NCjxiPlRvOjwvYj4gUm9t YXNjYW51LCBEYW4gKERhbik7IExpbmRhIER1bmJhcjsgPGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0Bp ZXRmLm9yZyI+b3BzYXdnQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09Q U0FXR10gYXV0b21hdGljIGF0dGFjaG1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBzZXJ2aWNlcyBh dCB0aGUgZWRnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlRoZW4gd291bGQgaXQgYmUgcHJhY3RpY2FsIHRvIGhhdmUgb25lIHByb3RvY29sIHRoYXQg bWFuYWdlZCBjYXJyaWVzIGJvdGgga2luZHMgb2YgZGF0YT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U2VudCZuYnNwO2Zyb20mbmJz cDtteSZuYnNwO0JsYWNrQmVycnkmbmJzcDsxMCZuYnNwO3NtYXJ0cGhvbmUmbmJzcDtvbiZuYnNw O3RoZSZuYnNwO1Zlcml6b24mbmJzcDtXaXJlbGVzcyZuYnNwOzRHJm5ic3A7TFRFJm5ic3A7bmV0 d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJTtiYWNrZ3JvdW5kOndoaXRlO2JvcmRlci1zcGFj aW5nOjBweCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQ7Zm9udC1zaXplOmluaXRpYWw7dGV4dC1hbGlnbjppbml0aWFsIj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlJvbWFzY2FudSwgRGFuIChEYW4pPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlNlbnQ6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5N b25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2IDA5OjE5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlRvOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TGluZGEg RHVuYmFyOw0KPGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0Og0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6IFtPUFNBV0ddIGF1dG9tYXRpYyBhdHRh Y2htZW50IG9mIGFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMgYXQgdGhlIGVkZ2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9Il9vcmlnaW5hbENvbnRlbnQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBMaW5kYSw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBpbnRlcmVz dCBhbmQgY29tbWVudC4gRnJvbSBhIHRvcG9sb2d5IGFuZCBhcmNoaXRlY3R1cmUgcG9pbnQgb2Yg dmlldyB0aGUgaWRlYSBpcyBpbmRlZWQgc2ltaWxhciB0byBFUy1JUy4gVGhlIGRpZmZlcmVuY2Ug aXMgaW4gdGhlIGNvbnRlbnQgb2YgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXMgYmVpbmcgZXhjaGFu Z2VkIGJldHdlZW4gdGhlDQogZW5kLXN0YXRpb24gYW5kIHRoZSBlZGdlIHJvdXRlci4gPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+RGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBMaW5kYSBEdW5iYXIgWzxhIGhyZWY9Im1haWx0bzpsaW5kYS5k dW5iYXJAaHVhd2VpLmNvbSI+bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgRmVicnVhcnkgMjAsIDIwMTYgMjowNCBBTTxicj4N CjxiPlRvOjwvYj4gUm9tYXNjYW51LCBEYW4gKERhbik7IDxhIGhyZWY9Im1haWx0bzpvcHNhd2dA aWV0Zi5vcmciPm9wc2F3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtP UFNBV0ddIGF1dG9tYXRpYyBhdHRhY2htZW50IG9mIGFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMg YXQgdGhlIGVkZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RGFuLCA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIGJyaW5naW5nIGF0dGVudGlv biB0byB0aGlzIGRyYWZ0Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldoYXQgYmVpbmcgcHJvcG9zZWQgYnkg dGhlIGRyYWZ0IGlzIGFsbW9zdCBsaWtlIEVTLUlTIHByb3RvY29sLCBpc27igJl0IGl0Pw0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIHRoaW5rIGl0IGlzIHF1aXRlIHVz ZWZ1bC4gPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcywgTGlu ZGEgRHVuYmFyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBPUFNBV0cgWzxhIGhyZWY9Im1haWx0bzpvcHNhd2ctYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Um9tYXNjYW51LCBEYW4gKERhbik8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBG ZWJydWFyeSAxNSwgMjAxNiA5OjEwIEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 b3BzYXdnQGlldGYub3JnIj5vcHNhd2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiBVbmJl aGFnZW4gSnIsIFBhdWwgRSAoUGF1bCk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09QU0FXR10gYXV0 b21hdGljIGF0dGFjaG1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBzZXJ2aWNlcyBhdCB0aGUgZWRn ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGxpa2UgdG8gZHJhdyB0aGUgYXR0ZW50aW9uIG9m IHRoZSBwYXJ0aWNpcGFudHMgaW4gdGhlIE9QU0FXRyBvbiBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Np b24gdGhhdCBJIGFtIGNvLWF1dGhvcmluZy4gVGhlIHByb2JsZW0gd2UgYXJlIHRyeWluZyB0byBz b2x2ZSBpcyB0aGUgb3B0aW1pemF0aW9uIC8gbWluaW1pemluZyBvZiB0aGUgYW1vdW50IG9mIGNv bmZpZ3VyYXRpb24gdGhhdCBhbiBvcGVyYXRvcg0KIG5lZWRzIHRvIGRvIHdoZW4gbmV3IGFwcGxp Y2F0aW9ucyByZXF1aXJlIHRoZSBjcmVhdGlvbiBvZiBwYXRocyBvciB0dW5uZWxzIGluIHRoZSBj b3JlIG5ldHdvcmsuIEluIG9yZGVyIHRvIGF2b2lkIHRoZSByZWNvbmZpZ3VyYXRpb24gb2YgdGhl IGNvcmUgb3IgaGVhdnkgY29uZmlndXJhdGlvbiBhdCB0aGUgZWRnZSB0aGUgcHJvcG9zZWQgbWV0 aG9kIHdoaWNoIHdlIGNhbGwgYXV0by1hdHRhY2htZW50IGFsbG93cyBmb3IgdGhlIHVzYWdlIG9m IGENCiBwcm90b2NvbCBydW5uaW5nIGJldHdlZW4gdGhlIGVuZCBzdGF0aW9ucyBhbmQgdGhlIGZp cnN0IChlZGdlKSByb3V0ZXIgdGhhdCBhZGRzIHRoZSBpbmZvcm1hdGlvbiBhbmQgY2hhcmFjdGVy aXN0aWNzIG9mIHRoZSBuZXcgcGF0aCBhY2NvcmRpbmcgdG8gdGhlIHBvbGljaWVzIG9yIG1hcHBp bmcgdGFibGVzIG9mIHRoZSBvcGVyYXRvcnMuIEEgZmlyc3QgaW1wbGVtZW50YXRpb24gdGhhdCB3 ZSBoYXZlIHJ1bm5pbmcgY29kZSBmb3IgYW5kIGlzIGRlcGxveWVkDQogaXMgZGVzY3JpYmVkIGlu IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEdW5iZWhhZ2VuLTJEbGxkcC0y RHNwYl8mYW1wO2Q9QlFNRkFnJmFtcDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9STRk ekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNGQSZhbXA7bT00Rm1JV1NLQlJu RTZ6WTlnZ2tnZXc1RDQ5R1RoREljOFhhdnFONjB1NklrJmFtcDtzPW5kdEcyZlFTNzZNZW1rbmhF d3g3bklDSTN6Y0ZQVGxTLTVYbV9ERHdIM3MmYW1wO2U9IiB0YXJnZXQ9Il9CTEFOSyI+DQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC11bmJlaGFnZW4tbGxkcC1zcGIvPC9h PiBhbmQgdXNlcyB0aGUgTGluayBMYXllciBEaXNjb3ZlcnkgUHJvdG9jb2wgKExMRFApIHdpdGgg YW4gSUVFRSA4MDIuMWFxIFNob3J0ZXN0IFBhdGggQnJpZGdpbmcgKFNQQikgbmV0d29yay4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgaGF2ZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93 IGlmIHRoZXJlIGlzIGludGVyZXN0IGFuZC9vciBzaW1pbGFyIG9uLWdvaW5nIHdvcmsuIElmIHRo ZXJlIGlzIGVub3VnaCBpbnRlcmVzdCBJIHBsYW4gdG8gcmVxdWVzdCBhIHNob3J0IHNsb3QgdG8g ZGlzY3VzcyB0aGUgaWRlYSBhdCB0aGUgT1BTQVdHIG1lZXRpbmcgYXQgSUVURiA5NS4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgYW5kIFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657DEE440dfweml701chm_-- From nobody Mon Feb 22 09:15:51 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138181ACEDB for ; Mon, 22 Feb 2016 09:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 3s2doj2_3zOo for ; Mon, 22 Feb 2016 09:15:47 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC401A21AD for ; Mon, 22 Feb 2016 09:15:47 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id y8so91550134igp.0 for ; Mon, 22 Feb 2016 09:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y+CxrzU/ZxcWxYEInxnDkHdrdQN92KoKOYlFxV/41KU=; b=V1mrOS3DvCSM79ip7bHy5gQLGlj6fK+WxD4f8CroV5TnrNv6AsX/bpiqyETWWo6DaC PC7UciSMiT6QS2VFZ6ryek2kc/7mCKGIlJ2SxCSJcPL21vnRsFKX13FRYC29D4WqZhSO 3jxlAJbyksKEGLmufDSpZjO7LO/qH3Pqc33KVI6GulO5hM6BKvz3D3quemqCjrbBD3ze zDYhh81YyvAUm+Mo26w2zQj76PvV9WKfjPRHn0I7iQFuOPzQxqWzS4cV7CttuLu3U7FV WET2I9DiAR2S1Aqr+OyWCd+QAaPXGZA9TA7Y2lb5kXrkW3rTSgXOj06JPOt86XhXikj/ F4tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y+CxrzU/ZxcWxYEInxnDkHdrdQN92KoKOYlFxV/41KU=; b=Mh7Xgx+Oa/VeCTNYSJwmuSm6rz+IXG3tCZwRucMTwmRAM1ul+sidu5jSHVrxx2vHfr GXDQkc+Lq/9Eo6bnpACwafr8OdoEdWz8SZW1OUQpi+Pddwo3JK+4/r9tzo2UEqluLK1c IeLqRfDk9qiVgKqyRnopRvba9K+Hvkhhsfl4Bwdpi/6tGQje4S2UKSYgC2tRJPSk2QWn TE6hIYVC2cwyBJJo0ki9aIVBqe7Z1TaWlSUkqG3Vvf2WEDxuuoPzuAEtwtgiKfiBw+E2 wD7XopHXHvyG64leen6TLJhvekxlNR6H9yrtfxx73adhsXDPCtENAQxq9gibXbnrMdZR D0Cg== X-Gm-Message-State: AG10YOTDhf2sHsASN1oXeIjXvNfkF1Vu40bLtOAcdYDr00juisd8nk6yM0/wvhtospf4xU8w3jk803PK2hWJX8Ur MIME-Version: 1.0 X-Received: by 10.50.155.71 with SMTP id vu7mr12656894igb.69.1456161346646; Mon, 22 Feb 2016 09:15:46 -0800 (PST) Received: by 10.64.1.112 with HTTP; Mon, 22 Feb 2016 09:15:46 -0800 (PST) In-Reply-To: References: Date: Mon, 22 Feb 2016 17:15:46 +0000 Message-ID: From: Andrej Ota To: Warren Kumari Content-Type: multipart/alternative; boundary=001a11339b94cde6b3052c5efb7d Archived-At: Cc: draft-ietf-opsawg-tacacs.authors@ietf.org, "opsawg@ietf.org" Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 17:15:50 -0000 --001a11339b94cde6b3052c5efb7d Content-Type: text/plain; charset=UTF-8 I'm am double checking with in-house IPR legal. I have also sent off e-mails to David Carrel and Lol Grant so they know about the call. On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari wrote: > Dear WG (and specifically draft-ietf-opsawg-tacacs authors), > > So far we have received an IPR acknowledgment from Douglas ( > https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) > , but are still missing it from the rest of the authors: Thorsten > Dahm, Andrej Ota, David Carrel, Lol Grant. > > Please reply to this email regardless of whether or not you are personally > aware of any relevant IPR... > > (I have just noticed that David and Lol do not have email addresses > listed. Thorsten said that he spoke with them (recording from Prague) - > please add their email addresses - they will need to ack the IPR, and also > the AUTH48 if / when it happens...) > > W > > > On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari wrote: > >> Dear WG, >> >> Thanks to everyone who has been participating. It is refreshing to see >> this much passion and involvement in OpsAWG! We wanted to give this a bit >> of time to settle down, and also to see where this ended up. >> >> We are going to do a series of steps to get as clear a view of the >> consensus of the WG about this document. This message is a explicit call >> for any known IPR. >> >> We will follow up with two other messages, each with a particular >> question - the reason for such formality is to try to untangle the many >> threads that erupted on the main list. >> >> Many of you have already expressed your opinion but can you please do so >> again in response to the forthcoming two messages so that the record is >> clear. We expect to determine the path forward in 2 weeks. >> >> Are you personally aware of any IPR that applies to >> draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance >> with IETF IPR rules? >> (See RFCs 3979, 4879, 3669, and 5378 for more details.) >> >> If you are a document author or listed contributor on this document, >> please reply to this email regardless of whether or not you are personally >> aware of any relevant IPR. >> >> Scott, Tianran and Warren >> > -- -- Andrej Ota Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland Registered in Dublin, Ireland - Registration # 368047 --001a11339b94cde6b3052c5efb7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm am double checking with in-house IPR legal.
I have also sent off e-mails to David Carrel and Lol Grant so = they know about the call.

On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari <warren= @kumari.net> wrote:
Dear WG (and specifically draft-ietf-opsawg-tacacs authors),
=
So far we have received an IPR acknowledgment from Douglas (= https://mailarchive.ietf.org/arch/msg/opsawg/FL= I-7qqaD3AbArBKM42iNRiMxq8) , but are still missing it from the rest of = the authors:=C2=A0Thorsten Dahm,=C2=A0Andrej Ota,=C2=A0David Carrel,=C2=A0L= ol Grant.

Please reply to this email regardle= ss of whether or not you are personally aware of any relevant IPR...
<= /div>

(I have just noticed that David and=C2=A0Lol do no= t have email addresses listed.=C2=A0Thorste= n said that he spoke with them (recording from Prague) - please add their e= mail addresses - they will need to ack the IPR, and also the AUTH48 if / wh= en it happens...)
=
W


On Tue, Feb 16, 2016 at 7:46 AM Warre= n Kumari <warren@= kumari.net> wrote:
Dear WG,

Thanks to everyone who has = been participating. It is refreshing to see this much passion and involveme= nt in OpsAWG! We wanted to give this a bit of time to settle down, and also= to see where this ended up.

We are going to do a = series of steps to get as clear a view of the consensus of the WG about thi= s document. =C2=A0 This message is a explicit call for any known IPR.=C2=A0=

We will follow up with two =C2=A0other messages, = each with a particular question - the reason for such formality is to try t= o untangle the many threads that erupted on the main list.

Many of you have already expressed your opinion but can you please= do so again in response to the forthcoming two messages so that the record= is clear.=C2=A0 We expect to determine the path forward in 2 weeks.
<= div>
Are you personally aware of any IPR that applies to draf= t-ietf-opsawg-tacacs?=C2=A0 If so, has this IPR been disclosed in complianc= e with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for m= ore details.)

If you are a document author or list= ed contributor on this document, please reply to this email regardless of w= hether or not you are personally aware of any relevant IPR.

<= /div>
Scott, Tianran and Warren



--
--
Andrej Ota

Google Ireland Ltd., Google Do= cks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland - =C2= =A0Registration # 368047
--001a11339b94cde6b3052c5efb7d-- From nobody Fri Feb 26 09:38:28 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846E31B2A71 for ; Fri, 26 Feb 2016 09:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 7CH_Qt0dWyXY for ; Fri, 26 Feb 2016 09:38:24 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68901B2B47 for ; Fri, 26 Feb 2016 09:38:23 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id z7so38511495yka.3 for ; Fri, 26 Feb 2016 09:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SB8Ma1WDtquNyKhwL6KxiK/lwDXU82bQtBAjDPOVsew=; b=sL2KFvCQxFSn/UJomQeEI8Nn+oGMmilCUQg0qZzFYH1vfKIgx2ZzhQRCWL1mh7RQ2l S/X1uoLCYZ9DZLGB/0vozNyFMpX2kbHuVvCjsyONm+LSfgapZiFPMxB3Wn8JUkg5FwyI oj/s4GeqXbyWv43C+0plf2WFU3pfZOo083x6QMK8ycz/7d9zGqzlqAY8nJIeRYJg0FNb VXx6jJtDQ2T++j1t0ufC9FDyOGg3bhWKkOhfsRppO5QjCGqB/Yn6tK/1uadLM/Ov5nRr 1vOMdfe0Hg1+au/T2ow5NB6bFDQvJb92t/k373Qg9NYRLg9D58UyPQJZPI0RDvpeexlk JMpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SB8Ma1WDtquNyKhwL6KxiK/lwDXU82bQtBAjDPOVsew=; b=gghTOEVxauClD+6/+l7jNcMnJv3E46yWXnKBE/MR41LoKrgXTKiFX4LWXcNB3EmZzy vQCEVNXvXrRQ7co8MUrSiYJ8fF7/9mFqkIoptwNixVY4U6pkCYB/5KePoHEemgExipsD 9gbrzrA0tO2c738phGP6YEkx2TkfW2Foc6ZUtB7/40XP9az8f2Gm+F4Waa7h/+1Lpjmx G0hCCtbHMobQAas4l6G+VO+82qkS0stRSrtbMxbiEvrBl3hRokXeDPf1TxcJi3gN83V/ IKNgcPtDx6Opr73SoGZJvqFXnYypXxq2V5yDp1WPWZLMVCSCmxg2EuTRz0CBUNHoH1bo mSEQ== X-Gm-Message-State: AD7BkJKhBRDsjqlJHK4FGZUESCuf0Re6Yh3OF2nUbzhJRBwHASoevS5pJKNBFgcDtHIpl3CmDFShnYNF8bVC75Oy X-Received: by 10.37.35.198 with SMTP id j189mr1597497ybj.98.1456508302910; Fri, 26 Feb 2016 09:38:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Fri, 26 Feb 2016 17:38:13 +0000 Message-ID: To: Andrej Ota Content-Type: multipart/alternative; boundary=001a113d40cc02126b052cafc4e0 Archived-At: Cc: draft-ietf-opsawg-tacacs.authors@ietf.org, "opsawg@ietf.org" Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 17:38:26 -0000 --001a113d40cc02126b052cafc4e0 Content-Type: text/plain; charset=UTF-8 It is now almost 2 weeks since we asked for explicit IPR ACKs from all the authors. We have only received one. The document starts out with: "This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79" The explicit IPR check should simply be affirming the above. None of the authors should be "surprised" authors (2 of the authors have been very active, and it has been stated that David and Lol were contacted and checked). Frankly I'm starting to lose my sense of humor on this... W On Mon, Feb 22, 2016 at 12:15 PM Andrej Ota wrote: > I'm am double checking with in-house IPR legal. > > I have also sent off e-mails to David Carrel and Lol Grant so they know > about the call. > > On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari wrote: > >> Dear WG (and specifically draft-ietf-opsawg-tacacs authors), >> >> So far we have received an IPR acknowledgment from Douglas ( >> https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) >> , but are still missing it from the rest of the authors: Thorsten >> Dahm, Andrej Ota, David Carrel, Lol Grant. >> >> Please reply to this email regardless of whether or not you are >> personally aware of any relevant IPR... >> >> (I have just noticed that David and Lol do not have email addresses >> listed. Thorsten said that he spoke with them (recording from Prague) - >> please add their email addresses - they will need to ack the IPR, and also >> the AUTH48 if / when it happens...) >> >> W >> >> >> On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari wrote: >> >>> Dear WG, >>> >>> Thanks to everyone who has been participating. It is refreshing to see >>> this much passion and involvement in OpsAWG! We wanted to give this a bit >>> of time to settle down, and also to see where this ended up. >>> >>> We are going to do a series of steps to get as clear a view of the >>> consensus of the WG about this document. This message is a explicit call >>> for any known IPR. >>> >>> We will follow up with two other messages, each with a particular >>> question - the reason for such formality is to try to untangle the many >>> threads that erupted on the main list. >>> >>> Many of you have already expressed your opinion but can you please do so >>> again in response to the forthcoming two messages so that the record is >>> clear. We expect to determine the path forward in 2 weeks. >>> >>> Are you personally aware of any IPR that applies to >>> draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance >>> with IETF IPR rules? >>> (See RFCs 3979, 4879, 3669, and 5378 for more details.) >>> >>> If you are a document author or listed contributor on this document, >>> please reply to this email regardless of whether or not you are personally >>> aware of any relevant IPR. >>> >>> Scott, Tianran and Warren >>> >> > > > -- > -- > Andrej Ota > > Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland > Registered in Dublin, Ireland - Registration # 368047 > --001a113d40cc02126b052cafc4e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is now almost 2 weeks since we asked for explicit IPR A= CKs from all the authors.=C2=A0

We have only received on= e.

The document starts out with:
&q= uot;This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79"

The e= xplicit IPR check should simply be affirming the above.

None of the authors should be "surprised" authors (2 of the= authors have been very active, and it has been stated that David and Lol w= ere contacted and checked).=C2=A0

Frankly I'm = starting to lose my sense of humor on this...

W
On Mon, Feb 22, 2016 at = 12:15 PM Andrej Ota <aota@google.com> wrote:
I'm am double checking with in-house IPR legal.

=
I have also sent off e-mails to David Carrel and Lol Grant so th= ey know about the call.

On Sun, Feb 21, 2016 at = 9:55 PM, Warren Kumari <warren@kumari.net> wrote:
Dear WG (and specifically draft-ie= tf-opsawg-tacacs authors),

So far we have received an IP= R acknowledgment from Douglas (https://mailarch= ive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) , but are sti= ll missing it from the rest of the authors:=C2=A0Thorsten Dahm,=C2=A0Andrej= Ota,=C2=A0David Carrel,=C2=A0Lol Grant.

Plea= se reply to this email regardless of whether or not you are personally awar= e of any relevant IPR...

(I have just notice= d that David and=C2=A0Lol do not have email addresses listed.=C2=A0Thorsten said that he spoke with them (recording fr= om Prague) - please add their email addresses - they will need to ack the I= PR, and also the AUTH48 if / when it happens...)

W


On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari <<= a href=3D"mailto:warren@kumari.net" target=3D"_blank">warren@kumari.net= > wrote:
D= ear WG,

Thanks to everyone who has been participat= ing. It is refreshing to see this much passion and involvement in OpsAWG! W= e wanted to give this a bit of time to settle down, and also to see where t= his ended up.

We are going to do a series of steps= to get as clear a view of the consensus of the WG about this document. =C2= =A0 This message is a explicit call for any known IPR.=C2=A0

=
We will follow up with two =C2=A0other messages, each with a par= ticular question - the reason for such formality is to try to untangle the = many threads that erupted on the main list.

Many o= f you have already expressed your opinion but can you please do so again in= response to the forthcoming two messages so that the record is clear.=C2= =A0 We expect to determine the path forward in 2 weeks.

Are you personally aware of any IPR that applies to draft-ietf-opsawg= -tacacs?=C2=A0 If so, has this IPR been disclosed in compliance with IETF I= PR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)=

If you are a document author or listed contributo= r on this document, please reply to this email regardless of whether or not= you are personally aware of any relevant IPR.

Sco= tt, Tianran and Warren



--
--
Andrej Ota

Google Ireland Ltd., Goog= le Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland - = =C2=A0Registration # 368047
--001a113d40cc02126b052cafc4e0-- From nobody Fri Feb 26 09:56:02 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD08D1B2CBD for ; Fri, 26 Feb 2016 09:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 WZQfN_ZT08AG for ; Fri, 26 Feb 2016 09:55:59 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38451B2C2C for ; Fri, 26 Feb 2016 09:55:58 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id y8so40662094igp.1 for ; Fri, 26 Feb 2016 09:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ezRqk9bnQGoslNPtpNGkKNvoJRd4JRe3tl6Slr6nj1w=; b=cKj8Fimkrr2dbUIArXS71QsrcdlAyrb3i4DEZlFGdf1mcX+ptkWI/JUlnRdfrFq7c1 m1wjMvFyCdgUCojxgKX/N+birH4StJ58My6Ra8wMByigtkleJKcDVEZeNVF2wG4pMalx yVQXZAo9ET4sdoVe9rkQSpHqvRZXe5S4wZ3DNa8OuPZ3QI/+wOOZ4lPgmlRBDnjsfQsu 26FI0hf4uSqokOq97VMXpiKUj6BRRmn35HVf9x0PV2LPI5xp3iHpk7CKPF8QvCKcxYHs KRE42wLVWfIq8hIjMBcSpIsSYmf3CJOMRzRIfh8BFBVorWAcniDJjz2C5UmG91Hao8KF ZtwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ezRqk9bnQGoslNPtpNGkKNvoJRd4JRe3tl6Slr6nj1w=; b=c7p1P9m30Nd3TOYvC00oNV16NZglwW2QrILo2ROyYb82u/fmH3K1I6gf5h6q7z6/oZ 94eJOrldNg4pvFxXkxJfUTFAvg3GmgUS/BdDtqvaa2++6YsS132bHqQ7SCE9EupFC7Yl nLG98HZ3xx9pebtfVDZ3wSdTI267ZSIpb0UTuGl2RP4oecKPUhPMXuMLLNcT0qUbN5jt WmJZcANNLenaSOlmtACN4Ews97BJdOfYLQ0KB0TrXaPW24J88xU1mTmaOAc2DUKVoccf dfN2mmx+FCZti4J3GP1Q7ooz5eORDtof5omBcumZ3cWxW3jQhMlnEoVhyjSGdhQ+wP0U 3Bhg== X-Gm-Message-State: AD7BkJLb28Gweg0F24y47tWP3WOV1LbflXiqTS4wKxsJ7Znw0FXIGEb8tldD0zH5qvVhKs72X/1u2JcxiVBTe3sl MIME-Version: 1.0 X-Received: by 10.50.73.133 with SMTP id l5mr4037873igv.69.1456509358125; Fri, 26 Feb 2016 09:55:58 -0800 (PST) Received: by 10.64.1.112 with HTTP; Fri, 26 Feb 2016 09:55:58 -0800 (PST) In-Reply-To: References: Date: Fri, 26 Feb 2016 17:55:58 +0000 Message-ID: From: Andrej Ota To: Warren Kumari Content-Type: multipart/alternative; boundary=089e0129483ae7c26c052cb002db Archived-At: Cc: draft-ietf-opsawg-tacacs.authors@ietf.org, "opsawg@ietf.org" Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 17:56:01 -0000 --089e0129483ae7c26c052cb002db Content-Type: text/plain; charset=UTF-8 As a coauthor, I am not aware of any IPR related to the submitted internet draft. I did contact David and Lol and I will politely contact them again so they can ack/nack as well. On Fri, Feb 26, 2016 at 5:38 PM, Warren Kumari wrote: > It is now almost 2 weeks since we asked for explicit IPR ACKs from all the > authors. > > We have only received one. > > The document starts out with: > "This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79" > > The explicit IPR check should simply be affirming the above. > > None of the authors should be "surprised" authors (2 of the authors have > been very active, and it has been stated that David and Lol were contacted > and checked). > > Frankly I'm starting to lose my sense of humor on this... > > W > > On Mon, Feb 22, 2016 at 12:15 PM Andrej Ota wrote: > >> I'm am double checking with in-house IPR legal. >> >> I have also sent off e-mails to David Carrel and Lol Grant so they know >> about the call. >> >> On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari wrote: >> >>> Dear WG (and specifically draft-ietf-opsawg-tacacs authors), >>> >>> So far we have received an IPR acknowledgment from Douglas ( >>> https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) >>> , but are still missing it from the rest of the authors: Thorsten >>> Dahm, Andrej Ota, David Carrel, Lol Grant. >>> >>> Please reply to this email regardless of whether or not you are >>> personally aware of any relevant IPR... >>> >>> (I have just noticed that David and Lol do not have email addresses >>> listed. Thorsten said that he spoke with them (recording from Prague) - >>> please add their email addresses - they will need to ack the IPR, and also >>> the AUTH48 if / when it happens...) >>> >>> W >>> >>> >>> On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari wrote: >>> >>>> Dear WG, >>>> >>>> Thanks to everyone who has been participating. It is refreshing to see >>>> this much passion and involvement in OpsAWG! We wanted to give this a bit >>>> of time to settle down, and also to see where this ended up. >>>> >>>> We are going to do a series of steps to get as clear a view of the >>>> consensus of the WG about this document. This message is a explicit call >>>> for any known IPR. >>>> >>>> We will follow up with two other messages, each with a particular >>>> question - the reason for such formality is to try to untangle the many >>>> threads that erupted on the main list. >>>> >>>> Many of you have already expressed your opinion but can you please do >>>> so again in response to the forthcoming two messages so that the record is >>>> clear. We expect to determine the path forward in 2 weeks. >>>> >>>> Are you personally aware of any IPR that applies to >>>> draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance >>>> with IETF IPR rules? >>>> (See RFCs 3979, 4879, 3669, and 5378 for more details.) >>>> >>>> If you are a document author or listed contributor on this document, >>>> please reply to this email regardless of whether or not you are personally >>>> aware of any relevant IPR. >>>> >>>> Scott, Tianran and Warren >>>> >>> >> >> >> -- >> -- >> Andrej Ota >> >> Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland >> Registered in Dublin, Ireland - Registration # 368047 >> > -- -- Andrej Ota Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland Registered in Dublin, Ireland - Registration # 368047 --089e0129483ae7c26c052cb002db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a coauthor, I am not aware of any IPR related to the su= bmitted internet draft.


I did contact Dav= id and Lol and I will politely contact them again so they can ack/nack as w= ell.

O= n Fri, Feb 26, 2016 at 5:38 PM, Warren Kumari <warren@kumari.net> wrote:
It is now a= lmost 2 weeks since we asked for explicit IPR ACKs from all the authors.=C2= =A0

We have only received one.

= The document starts out with:
"This Internet-Draft is s= ubmitted in full conformance with the
provisions of BCP 78 and BC= P 79"

The explicit IPR check should sim= ply be affirming the above.

None of the authors sh= ould be "surprised" authors (2 of the authors have been very acti= ve, and it has been stated that David and Lol were contacted and checked).= =C2=A0

Frankly I'm starting to lose my sense o= f humor on this...

W

On Mon, Feb 22, 2016 at 12:15 PM Andrej O= ta <aota@google.com= > wrote:
I&= #39;m am double checking with in-house IPR legal.

I have= also sent off e-mails to David Carrel and Lol Grant so they know about the= call.

On Sun, Feb 21, 2016 at 9:55 PM, Warren K= umari <warren@kumari.net> wrote:
Dear WG (and specifically draft-ietf-opsawg-tacacs = authors),

So far we have received an IPR acknowledgment = from Douglas (https://mailarchive.ietf.org/arch= /msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) , but are still missing it fro= m the rest of the authors:=C2=A0Thorsten Dahm,=C2=A0Andrej Ota,=C2=A0David = Carrel,=C2=A0Lol Grant.

Please reply to this = email regardless of whether or not you are personally aware of any relevant= IPR...

(I have just noticed that David and= =C2=A0Lol do not have email addresses listed.=C2=A0Thorsten said that he spoke with them (recording from Prague) - ple= ase add their email addresses - they will need to ack the IPR, and also the= AUTH48 if / when it happens...)

W
=


On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari <warren@kumari.net> wrote:
=
Dear WG,

Thanks to everyone who has been participating. It is refr= eshing to see this much passion and involvement in OpsAWG! We wanted to giv= e this a bit of time to settle down, and also to see where this ended up.

We are going to do a series of steps to get as clea= r a view of the consensus of the WG about this document. =C2=A0 This messag= e is a explicit call for any known IPR.=C2=A0

We w= ill follow up with two =C2=A0other messages, each with a particular questio= n - the reason for such formality is to try to untangle the many threads th= at erupted on the main list.

Many of you have alre= ady expressed your opinion but can you please do so again in response to th= e forthcoming two messages so that the record is clear.=C2=A0 We expect to = determine the path forward in 2 weeks.

Are you per= sonally aware of any IPR that applies to draft-ietf-opsawg-tacacs?=C2=A0 If= so, has this IPR been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

If you are a document author or listed contributor on this documen= t, please reply to this email regardless of whether or not you are personal= ly aware of any relevant IPR.

Scott, Tianran and W= arren



--
--
Andrej Ota

Google Ireland Ltd., Goog= le Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland - = =C2=A0Registration # 368047



--
--
Andrej Ota

Google Ireland Ltd., Google Do= cks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland - =C2= =A0Registration # 368047
--089e0129483ae7c26c052cb002db-- From nobody Fri Feb 26 13:29:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC521B30C1; Fri, 26 Feb 2016 13:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 lyEv8Ufor6oq; Fri, 26 Feb 2016 13:29:18 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0061B30C0; Fri, 26 Feb 2016 13:29:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 03A0916FAA36; Fri, 26 Feb 2016 16:29:18 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV8K7EwwP_i9; Fri, 26 Feb 2016 16:29:17 -0500 (EST) Received: from [10.0.1.16] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id 71D0416FAA27; Fri, 26 Feb 2016 16:29:17 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Scott O. Bradner" In-Reply-To: Date: Fri, 26 Feb 2016 16:29:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1ECB18A3-592D-458E-81E4-A27DEE63D944@sobco.com> References: To: Andrej Ota X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-opsawg-tacacs.authors@ietf.org, "opsawg@ietf.org" Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:29:20 -0000 thanks Scott > On Feb 26, 2016, at 12:55 PM, Andrej Ota wrote: >=20 > As a coauthor, I am not aware of any IPR related to the submitted = internet draft. >=20 >=20 > I did contact David and Lol and I will politely contact them again so = they can ack/nack as well. >=20 > On Fri, Feb 26, 2016 at 5:38 PM, Warren Kumari = wrote: > It is now almost 2 weeks since we asked for explicit IPR ACKs from all = the authors.=20 >=20 > We have only received one. >=20 > The document starts out with: > "This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79" >=20 > The explicit IPR check should simply be affirming the above. >=20 > None of the authors should be "surprised" authors (2 of the authors = have been very active, and it has been stated that David and Lol were = contacted and checked).=20 >=20 > Frankly I'm starting to lose my sense of humor on this... >=20 > W >=20 > On Mon, Feb 22, 2016 at 12:15 PM Andrej Ota wrote: > I'm am double checking with in-house IPR legal. >=20 > I have also sent off e-mails to David Carrel and Lol Grant so they = know about the call. >=20 > On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari = wrote: > Dear WG (and specifically draft-ietf-opsawg-tacacs authors), >=20 > So far we have received an IPR acknowledgment from Douglas = (https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8)= , but are still missing it from the rest of the authors: Thorsten Dahm, = Andrej Ota, David Carrel, Lol Grant. >=20 > Please reply to this email regardless of whether or not you are = personally aware of any relevant IPR... >=20 > (I have just noticed that David and Lol do not have email addresses = listed. Thorsten said that he spoke with them (recording from Prague) - = please add their email addresses - they will need to ack the IPR, and = also the AUTH48 if / when it happens...) >=20 > W >=20 >=20 > On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari = wrote: > Dear WG, >=20 > Thanks to everyone who has been participating. It is refreshing to see = this much passion and involvement in OpsAWG! We wanted to give this a = bit of time to settle down, and also to see where this ended up. >=20 > We are going to do a series of steps to get as clear a view of the = consensus of the WG about this document. This message is a explicit = call for any known IPR.=20 >=20 > We will follow up with two other messages, each with a particular = question - the reason for such formality is to try to untangle the many = threads that erupted on the main list. >=20 > Many of you have already expressed your opinion but can you please do = so again in response to the forthcoming two messages so that the record = is clear. We expect to determine the path forward in 2 weeks. >=20 > Are you personally aware of any IPR that applies to = draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in = compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) >=20 > If you are a document author or listed contributor on this document, = please reply to this email regardless of whether or not you are = personally aware of any relevant IPR. >=20 > Scott, Tianran and Warren >=20 >=20 >=20 > --=20 > -- > Andrej Ota >=20 > Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland > Registered in Dublin, Ireland - Registration # 368047 >=20 >=20 >=20 > --=20 > -- > Andrej Ota >=20 > Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland > Registered in Dublin, Ireland - Registration # 368047 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Feb 26 13:52:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8291B3154 for ; Fri, 26 Feb 2016 13:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 jE4ETjX2Ewb5 for ; Fri, 26 Feb 2016 13:52:44 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89CD1B30EE for ; Fri, 26 Feb 2016 13:52:43 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id l127so135536164iof.3 for ; Fri, 26 Feb 2016 13:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=T7PIjx1wFdsmNGmEILuDxjh/m+i+/kbW7GIkhA9ANNI=; b=f7Zi/S6BGH7sRaS3NdMeQ+EWRcF07+z1ULhv9flhkh1eaGVVPGsYKKs9m7l//JGCPK u7KTXyV48uH7vIJCyMzLAadbHU15OqLrwf/3Ed8+dvUb8jr7/3opN7gHUxnJYE9bdRe3 orDBK6mmvG87lxDksFNBYQ5NN3hddlQSOmJxeE/ZIZ90eBVEhmtAGwjQ9cS9M46MT8Tp E3Ab94CX4jXUFdBqYD3mLk1+6s3l2jp0Puw7pi+YvpvLqGTd5nwBTF/DdBWP7SOQUnLP V92IBSYBcjCtS1avxEwbQUgMPXoZJdzwK29+wyoBgKJiO9X+sFpns8hDiFJLluFe0Wxb GS1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=T7PIjx1wFdsmNGmEILuDxjh/m+i+/kbW7GIkhA9ANNI=; b=AVcTIola9Khacqib/rZDZ/S0XKZPZokvrGFic2o3/wEa5FYS4SxMqdNQQOhnXek7Fx bubigahS7xwP4l6NaXZ6Ku8Ha8mYgeYTN/iRnOe62hWWEnynuvFwj+Z8B15n4QI37D8r j60LthJ2YeGSc+V4ZznWU2XYbnldQLyeDuPHXWtUSFoDBYJKnNwPj4Ac4wiS+8aDXQ/B GwGkqMTafuamBho7sIPp9vNJLJoSVG0ynseV9N4u975LMPWmlcFWWTVwylO6qZwKV5TN VYfcbCSrteyC4/1SkKD2JWyU0IXYW3bTc2mkqaxn0jmDnwsMhhZ7SiEvdWDBRgnOblLG RD3g== X-Gm-Message-State: AG10YOR+q4cITBb/4sAEVgD7W4Mh0CITyiPHbSaqq4I7dwNjJw8irJYdcdRW0WEty9uxy0BKPg537AIRys7mxEBN MIME-Version: 1.0 X-Received: by 10.107.150.2 with SMTP id y2mr10803274iod.113.1456523563010; Fri, 26 Feb 2016 13:52:43 -0800 (PST) Received: by 10.64.1.112 with HTTP; Fri, 26 Feb 2016 13:52:42 -0800 (PST) In-Reply-To: References: Date: Fri, 26 Feb 2016 21:52:42 +0000 Message-ID: From: Andrej Ota To: Warren Kumari Content-Type: multipart/alternative; boundary=001a1140ed3a94f486052cb351f7 Archived-At: Cc: draft-ietf-opsawg-tacacs.authors@ietf.org, "opsawg@ietf.org" Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:52:46 -0000 --001a1140ed3a94f486052cb351f7 Content-Type: text/plain; charset=UTF-8 I received the following statement from David Carrel: ---------- Forwarded message ---------- From: David Carrel Date: Fri, Feb 26, 2016 at 6:41 PM Subject: Re: IETF explicit call for IPR (related to TACACS+ IETF draft) To: Andrej Ota , Lol Grant Cc: Thorsten Dahm , "Gash, Douglas" < dcmgash@cisco.com> Hi Andrej, I know of no IPR related to TACACS+ and/or draft-grant-tacacs-02 and/or draft-ietf-opsawg-tacacs. I cannot speak for cisco (my former employer), but I do speak for myself. I hope this statement is what you need. If you need something more, please let me know. Thanks David Carrel On Fri, Feb 26, 2016 at 5:55 PM, Andrej Ota wrote: > As a coauthor, I am not aware of any IPR related to the submitted internet > draft. > > > I did contact David and Lol and I will politely contact them again so they > can ack/nack as well. > > On Fri, Feb 26, 2016 at 5:38 PM, Warren Kumari wrote: > >> It is now almost 2 weeks since we asked for explicit IPR ACKs from all >> the authors. >> >> We have only received one. >> >> The document starts out with: >> "This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79" >> >> The explicit IPR check should simply be affirming the above. >> >> None of the authors should be "surprised" authors (2 of the authors have >> been very active, and it has been stated that David and Lol were contacted >> and checked). >> >> Frankly I'm starting to lose my sense of humor on this... >> >> W >> >> On Mon, Feb 22, 2016 at 12:15 PM Andrej Ota wrote: >> >>> I'm am double checking with in-house IPR legal. >>> >>> I have also sent off e-mails to David Carrel and Lol Grant so they know >>> about the call. >>> >>> On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari >>> wrote: >>> >>>> Dear WG (and specifically draft-ietf-opsawg-tacacs authors), >>>> >>>> So far we have received an IPR acknowledgment from Douglas ( >>>> https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) >>>> , but are still missing it from the rest of the authors: Thorsten >>>> Dahm, Andrej Ota, David Carrel, Lol Grant. >>>> >>>> Please reply to this email regardless of whether or not you are >>>> personally aware of any relevant IPR... >>>> >>>> (I have just noticed that David and Lol do not have email addresses >>>> listed. Thorsten said that he spoke with them (recording from Prague) >>>> - please add their email addresses - they will need to ack the IPR, and >>>> also the AUTH48 if / when it happens...) >>>> >>>> W >>>> >>>> >>>> On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari >>>> wrote: >>>> >>>>> Dear WG, >>>>> >>>>> Thanks to everyone who has been participating. It is refreshing to see >>>>> this much passion and involvement in OpsAWG! We wanted to give this a bit >>>>> of time to settle down, and also to see where this ended up. >>>>> >>>>> We are going to do a series of steps to get as clear a view of the >>>>> consensus of the WG about this document. This message is a explicit call >>>>> for any known IPR. >>>>> >>>>> We will follow up with two other messages, each with a particular >>>>> question - the reason for such formality is to try to untangle the many >>>>> threads that erupted on the main list. >>>>> >>>>> Many of you have already expressed your opinion but can you please do >>>>> so again in response to the forthcoming two messages so that the record is >>>>> clear. We expect to determine the path forward in 2 weeks. >>>>> >>>>> Are you personally aware of any IPR that applies to >>>>> draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance >>>>> with IETF IPR rules? >>>>> (See RFCs 3979, 4879, 3669, and 5378 for more details.) >>>>> >>>>> If you are a document author or listed contributor on this document, >>>>> please reply to this email regardless of whether or not you are personally >>>>> aware of any relevant IPR. >>>>> >>>>> Scott, Tianran and Warren >>>>> >>>> >>> >>> >>> -- >>> -- >>> Andrej Ota >>> >>> Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland >>> Registered in Dublin, Ireland - Registration # 368047 >>> >> > > > -- > -- > Andrej Ota > > Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland > Registered in Dublin, Ireland - Registration # 368047 > -- -- Andrej Ota Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland Registered in Dublin, Ireland - Registration # 368047 --001a1140ed3a94f486052cb351f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I received the following statement from David Carrel:
=

---------- Forwarded message ----------
From:= David Carrel <david@carrel.net&= gt;
Date: Fri, Feb 26, 2016 at 6:41 PM
Subject: Re: IET= F explicit call for IPR (related to TACACS+ IETF draft)
To: Andre= j Ota <aota@google.com>, Lol G= rant <lol.grant@gmail.com>=
Cc: Thorsten Dahm <thorstendlux@google.com>, "Gash, Douglas" <dcmgash@cisco.com>


Hi Andrej,

I know of no IPR relat= ed to TACACS+ and/or draft-grant-tacacs-02 and/or draft-ietf-opsawg-tacacs.= =C2=A0 I cannot speak for cisco (my former employer), but I do speak for my= self.

I hope this statement is what you need.=C2= =A0 If you need something more, please let me know.

Thanks

David Carrel

On Fri, Feb 26, 2016 at 5:5= 5 PM, Andrej Ota <aota@google.com> wrote:
As a coauthor, I am not aware of any IPR rel= ated to the submitted internet draft.


I d= id contact David and Lol and I will politely contact them again so they can= ack/nack as well.

On Fri, Feb 26, 2016 a= t 5:38 PM, Warren Kumari <warren@kumari.net> wrote:
It is now almost 2 weeks since w= e asked for explicit IPR ACKs from all the authors.=C2=A0

We have only received one.

The document starts o= ut with:
"This Internet-Draft is submitted in full conf= ormance with the
provisions of BCP 78 and BCP 79"

The explicit IPR check should simply be affirming the = above.

None of the authors should be "surpris= ed" authors (2 of the authors have been very active, and it has been s= tated that David and Lol were contacted and checked).=C2=A0

<= /div>
Frankly I'm starting to lose my sense of humor on this...

W

On Mon, Feb 22, 201= 6 at 12:15 PM Andrej Ota <aota@google.com> wrote:
I'm am double checking with in-house IPR legal.
I have also sent off e-mails to David Carrel and Lol Grant = so they know about the call.

On Sun, Feb 21, 201= 6 at 9:55 PM, Warren Kumari <warren@kumari.net> wrote:
Dear WG (and specifically dra= ft-ietf-opsawg-tacacs authors),

So far we have received = an IPR acknowledgment from Douglas (https://mai= larchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) , but ar= e still missing it from the rest of the authors:=C2=A0Thorsten Dahm,=C2=A0A= ndrej Ota,=C2=A0David Carrel,=C2=A0Lol Grant.

Please reply to this email regardless of whether or not you are personally= aware of any relevant IPR...

(I have just n= oticed that David and=C2=A0Lol do not have email addresses listed.=C2=A0Thorsten said that he spoke with them (recordi= ng from Prague) - please add their email addresses - they will need to ack = the IPR, and also the AUTH48 if / when it happens...)
<= br>
W


On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari = <warren@kumari.ne= t> wrote:
<= div>Dear WG,

Thanks to everyone who has been parti= cipating. It is refreshing to see this much passion and involvement in OpsA= WG! We wanted to give this a bit of time to settle down, and also to see wh= ere this ended up.

We are going to do a series of = steps to get as clear a view of the consensus of the WG about this document= . =C2=A0 This message is a explicit call for any known IPR.=C2=A0

We will follow up with two =C2=A0other messages, each with = a particular question - the reason for such formality is to try to untangle= the many threads that erupted on the main list.

M= any of you have already expressed your opinion but can you please do so aga= in in response to the forthcoming two messages so that the record is clear.= =C2=A0 We expect to determine the path forward in 2 weeks.

Are you personally aware of any IPR that applies to draft-ietf-ops= awg-tacacs?=C2=A0 If so, has this IPR been disclosed in compliance with IET= F IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more detail= s.)

If you are a document author or listed contrib= utor on this document, please reply to this email regardless of whether or = not you are personally aware of any relevant IPR.

= Scott, Tianran and Warren



--
--
Andrej Ota

Google Ireland Ltd., Goog= le Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland - = =C2=A0Registration # 368047



--
--
A= ndrej Ota

Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, I= reland
Registered in Dublin, Ireland - =C2=A0Registration # 368047



--
=
--
Andrej Ota

Google Ireland Ltd.,= Google Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Irela= nd - =C2=A0Registration # 368047
--001a1140ed3a94f486052cb351f7-- From nobody Fri Feb 26 13:55:24 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C0C1B3153 for ; Fri, 26 Feb 2016 13:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 xXuha4tikLsJ for ; Fri, 26 Feb 2016 13:55:20 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1B31B3124 for ; Fri, 26 Feb 2016 13:55:20 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id z135so136573346iof.0 for ; Fri, 26 Feb 2016 13:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tltxxPNlP7BF38H9usziyepXOyAC1Cy8VXcVMiqUnQA=; b=YhoZ2Hzm0mS1gr+LDr4IxgnUlkEk+E8Fa/3wxXO8rEv8k14HxFXv/lYwzUNJuMqlO9 okwLxVdmV0SVG9HXLE4TAqbIKctzR6xJgVcAKGPPmC7krOmycfZbd/XFowUFsXp83Ura g7S/N8ZnAmIWeYzEE/anIINmDEG7gYnieuVJOtH2WYn0zc2T10Z1KAtX73fOq1vFk9kC y91dovdGNXjptKSsSby/PrOE41sxdgXD2fwSlbFN6GBF/IjY+IKD4k3cF72rJZ7KXW/x HEzUvsvilQwxMZYraYQXo3wM0Swg1yJB8fmXKBoXiHixoUr+6L7ZpkjNx8ZER2kB4QYT DXkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tltxxPNlP7BF38H9usziyepXOyAC1Cy8VXcVMiqUnQA=; b=ZijRwfk8SUIR7/AGqHyrjUCEtRZJ+uSYSxhJgNc4fZNWkPaFy3PFuTOE1mqWNLfEYh SBQi2o7tcsAaXgnxFLAbvdH5qbeQmRRGeyg4VVC4dOJDBqAfaWhgsM+TB50sTZl9U6dI MGu84jwgRmqiC0olY4BMaYIp2vSJEHX2La70TjMNpOBUfnsogjnagoh5fYkS0pn+oDlB AH8rNKHWixdYiE08upV5HMLgrdA0DYVms8s5Pubh824BBe1EORVPhf8+UT0VhuIHAJWk /UYyAPzgSrobZllFsLyyBc11MIXmO2SuiwyGindlf3KmF+tchpeHGZnGYYTitV8z/E5Q anNw== X-Gm-Message-State: AG10YOS2Ol3fGxxGRTxWtAzvsYyi5JyYBFgU3MDn2I96eUgYPirBLEjvPRSELW3dVy0JjRtIzASCKsocELypHx0v MIME-Version: 1.0 X-Received: by 10.107.159.148 with SMTP id i142mr9693901ioe.29.1456523719933; Fri, 26 Feb 2016 13:55:19 -0800 (PST) Received: by 10.64.1.112 with HTTP; Fri, 26 Feb 2016 13:55:19 -0800 (PST) In-Reply-To: References: Date: Fri, 26 Feb 2016 21:55:19 +0000 Message-ID: From: Andrej Ota To: Warren Kumari Content-Type: multipart/alternative; boundary=001a1140fe22ef6a4a052cb35a9b Archived-At: Cc: draft-ietf-opsawg-tacacs.authors@ietf.org, "opsawg@ietf.org" Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:55:23 -0000 --001a1140fe22ef6a4a052cb35a9b Content-Type: text/plain; charset=UTF-8 Below is the copy of the statement I received from Lol Grant. I believe we're now only one statement short and Thorsten should be back on-line on Monday at latest. ---------- Forwarded message ---------- From: Lol Grant Date: Fri, Feb 26, 2016 at 9:40 PM Subject: Re: IETF explicit call for IPR (related to TACACS+ IETF draft) To: Andrej Ota Cc: David Carrel , Thorsten Dahm , "Gash, Douglas" Hi Andrej, I know of no IPR related to TACACS+ and/or draft-grant-tacacs-02. Like Dave, I can speak only for myself, not for Cisco. Best wishes, Lol Grant On Fri, Feb 26, 2016 at 5:55 PM, Andrej Ota wrote: > As a coauthor, I am not aware of any IPR related to the submitted internet > draft. > > > I did contact David and Lol and I will politely contact them again so they > can ack/nack as well. > > On Fri, Feb 26, 2016 at 5:38 PM, Warren Kumari wrote: > >> It is now almost 2 weeks since we asked for explicit IPR ACKs from all >> the authors. >> >> We have only received one. >> >> The document starts out with: >> "This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79" >> >> The explicit IPR check should simply be affirming the above. >> >> None of the authors should be "surprised" authors (2 of the authors have >> been very active, and it has been stated that David and Lol were contacted >> and checked). >> >> Frankly I'm starting to lose my sense of humor on this... >> >> W >> >> On Mon, Feb 22, 2016 at 12:15 PM Andrej Ota wrote: >> >>> I'm am double checking with in-house IPR legal. >>> >>> I have also sent off e-mails to David Carrel and Lol Grant so they know >>> about the call. >>> >>> On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari >>> wrote: >>> >>>> Dear WG (and specifically draft-ietf-opsawg-tacacs authors), >>>> >>>> So far we have received an IPR acknowledgment from Douglas ( >>>> https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) >>>> , but are still missing it from the rest of the authors: Thorsten >>>> Dahm, Andrej Ota, David Carrel, Lol Grant. >>>> >>>> Please reply to this email regardless of whether or not you are >>>> personally aware of any relevant IPR... >>>> >>>> (I have just noticed that David and Lol do not have email addresses >>>> listed. Thorsten said that he spoke with them (recording from Prague) >>>> - please add their email addresses - they will need to ack the IPR, and >>>> also the AUTH48 if / when it happens...) >>>> >>>> W >>>> >>>> >>>> On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari >>>> wrote: >>>> >>>>> Dear WG, >>>>> >>>>> Thanks to everyone who has been participating. It is refreshing to see >>>>> this much passion and involvement in OpsAWG! We wanted to give this a bit >>>>> of time to settle down, and also to see where this ended up. >>>>> >>>>> We are going to do a series of steps to get as clear a view of the >>>>> consensus of the WG about this document. This message is a explicit call >>>>> for any known IPR. >>>>> >>>>> We will follow up with two other messages, each with a particular >>>>> question - the reason for such formality is to try to untangle the many >>>>> threads that erupted on the main list. >>>>> >>>>> Many of you have already expressed your opinion but can you please do >>>>> so again in response to the forthcoming two messages so that the record is >>>>> clear. We expect to determine the path forward in 2 weeks. >>>>> >>>>> Are you personally aware of any IPR that applies to >>>>> draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance >>>>> with IETF IPR rules? >>>>> (See RFCs 3979, 4879, 3669, and 5378 for more details.) >>>>> >>>>> If you are a document author or listed contributor on this document, >>>>> please reply to this email regardless of whether or not you are personally >>>>> aware of any relevant IPR. >>>>> >>>>> Scott, Tianran and Warren >>>>> >>>> >>> >>> >>> -- >>> -- >>> Andrej Ota >>> >>> Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland >>> Registered in Dublin, Ireland - Registration # 368047 >>> >> > > > -- > -- > Andrej Ota > > Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland > Registered in Dublin, Ireland - Registration # 368047 > -- -- Andrej Ota Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland Registered in Dublin, Ireland - Registration # 368047 --001a1140fe22ef6a4a052cb35a9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Below is the copy of the statement I received from Lol Gra= nt.

I believe we're now only one statement short and= Thorsten should be back on-line on Monday at latest.

---------- Forwarded message ----------
From:=C2=A0Lol Grant=C2=A0<lol.grant@gmail.com>
Date: Fri,= Feb 26, 2016 at 9:40 PM
Subject: Re: IETF explicit call for IPR (relate= d to TACACS+ IETF draft)
To: Andrej Ota <aota@google.com>
Cc: David Carrel <david@carrel.net>, Thorsten Dahm <thorstendlux@google.com>, "Gash, Do= uglas" <dcmgash@cisco.com&= gt;


Hi Andrej,

I know of no = IPR related to TACACS+ and/or draft-grant-tacacs-02.=C2=A0

Like Dave, I can speak only for myself, not for Cisco.
<= br>
Best wishes,

Lol Grant

On Fri, Feb 26, 2016 at 5:55 PM, Andrej Ota <aota@google.com> wrote:
As = a coauthor, I am not aware of any IPR related to the submitted internet dra= ft.


I did contact David and Lol and I wil= l politely contact them again so they can ack/nack as well.

On Fri, Feb 26, 2016 at 5:38 PM, Warren Kumari <warren@= kumari.net> wrote:
It is now almost 2 weeks since we asked for explicit IPR ACKs from= all the authors.=C2=A0

We have only received one.
=

The document starts out with:
"This= Internet-Draft is submitted in full conformance with the
provisi= ons of BCP 78 and BCP 79"

The explicit = IPR check should simply be affirming the above.

No= ne of the authors should be "surprised" authors (2 of the authors= have been very active, and it has been stated that David and Lol were cont= acted and checked).=C2=A0

Frankly I'm starting= to lose my sense of humor on this...

W

On Mon, Feb 22, 2016 at 12:15 PM Andrej Ota <aota@google.com> wro= te:
I'm am dou= ble checking with in-house IPR legal.

I have also sent o= ff e-mails to David Carrel and Lol Grant so they know about the call.
=

On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari <warr= en@kumari.net> wrote:
Dear WG (and specifically draft-ietf-opsawg-tacacs authors),
So far we have received an IPR acknowledgment from Douglas= (https://mailarchive.ietf.org/arch/msg/opsawg/= FLI-7qqaD3AbArBKM42iNRiMxq8) , but are still missing it from the rest o= f the authors:=C2=A0Thorsten Dahm,=C2=A0Andrej Ota,=C2=A0David Carrel,=C2= =A0Lol Grant.

Please reply to this email rega= rdless of whether or not you are personally aware of any relevant IPR...

(I have just noticed that David and=C2=A0Lol d= o not have email addresses listed.=C2=A0Tho= rsten said that he spoke with them (recording from Prague) - please add the= ir email addresses - they will need to ack the IPR, and also the AUTH48 if = / when it happens...)

W


On = Tue, Feb 16, 2016 at 7:46 AM Warren Kumari <warren@kumari.net> wrote:
Dear WG,

Thanks to everyone who has been participating. It is refreshing to se= e this much passion and involvement in OpsAWG! We wanted to give this a bit= of time to settle down, and also to see where this ended up.
We are going to do a series of steps to get as clear a view of = the consensus of the WG about this document. =C2=A0 This message is a expli= cit call for any known IPR.=C2=A0

We will follow u= p with two =C2=A0other messages, each with a particular question - the reas= on for such formality is to try to untangle the many threads that erupted o= n the main list.

Many of you have already expresse= d your opinion but can you please do so again in response to the forthcomin= g two messages so that the record is clear.=C2=A0 We expect to determine th= e path forward in 2 weeks.

Are you personally awar= e of any IPR that applies to draft-ietf-opsawg-tacacs?=C2=A0 If so, has thi= s IPR been disclosed in compliance with IETF IPR rules?
(See RFCs= 3979, 4879, 3669, and 5378 for more details.)

If = you are a document author or listed contributor on this document, please re= ply to this email regardless of whether or not you are personally aware of = any relevant IPR.

Scott, Tianran and Warren
<= /div>



--
--
Andrej Ota

Google Ireland Ltd., Goog= le Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland - = =C2=A0Registration # 368047



--
--
A= ndrej Ota

Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, I= reland
Registered in Dublin, Ireland - =C2=A0Registration # 368047



--
=
--
Andrej Ota

Google Ireland Ltd.,= Google Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Irela= nd - =C2=A0Registration # 368047
--001a1140fe22ef6a4a052cb35a9b-- From nobody Fri Feb 26 14:02:26 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5739C1B317B for ; Fri, 26 Feb 2016 14:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 Ix-fatVfla8w for ; Fri, 26 Feb 2016 14:02:20 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFCD1B317A for ; Fri, 26 Feb 2016 14:02:19 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id z7so41386939yka.3 for ; Fri, 26 Feb 2016 14:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zQmozIJ8iCZp9rLLSjtLGCfyncsVnOlTaAa3QQ/Zi5o=; b=EHhuZTnE9zzC3E8Yql8/PQsjQcyEdr0M3q58dHDdv12i6myFNFby8J0rIZovlwWHrs GkjviS3KtS44nNModpLjw1OJp3p/IqBAcMaqjMsOaCEBtaAtpiaO2PKHbqmLo6apizhX IJ7q+Blkr7XN3XpanhLL8qlzQ93zROvaHumSsMTXjJyOfOIe1ShQwcm2HYow9nsNATqY MKqC6P9ye2MnmT6PH8xKdUoTcg76wGQEoteJOAoTFeQzt0ZwYYg+UV8dD4FBlSv6g55B ZlSAfGTNq290/v71ZTYMZZ7neamSUnliyAyLYxYz8je3qvIoK5JYvdLnR11sxdS/Fjfz ovWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zQmozIJ8iCZp9rLLSjtLGCfyncsVnOlTaAa3QQ/Zi5o=; b=EwO/jIrtxdZw8YK9GEKCGPrmjkaP8CH/scw3rq+uy55b9TDxB+VMiPtFdF85e/MzVX vSKN6yBZXiyaKeZZouHxZKeMNnu8UfXgnE2PvCc5p+vXBsUeg0Xh5yLpJ48TgVaY5b07 Wk0iQud2bSNRAMNH3dAWThKyrDbbAx/SFFmdiwMQ2QDWPWh7Jk/Fy1f5RYIwjbvLFD/C I9ifJOy0A5+RG2ujifrWpkrt1bI1/xoDwcUciSHNG670w2rMmoNdTUGvQbWhKcv2sRNI IEe440o1N8jUBCXIgq+vniv42irlG+1Ujji60H+KzibJ4btpMuutYW31f9vBketrYKaM 21+Q== X-Gm-Message-State: AD7BkJLjd6wwrlZHxpKvd5uf5HsklsmJoEoDUsp6Cv47up2FRXNy5InqwH1TVaOpt6J5V1+kxUsUPPpM0SSsUyX/ X-Received: by 10.37.45.196 with SMTP id t187mr2313181ybt.174.1456524139237; Fri, 26 Feb 2016 14:02:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Fri, 26 Feb 2016 22:02:09 +0000 Message-ID: To: Andrej Ota Content-Type: multipart/alternative; boundary=001a11c1697ced479f052cb373d3 Archived-At: Cc: draft-ietf-opsawg-tacacs.authors@ietf.org, "opsawg@ietf.org" Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 22:02:22 -0000 --001a11c1697ced479f052cb373d3 Content-Type: text/plain; charset=UTF-8 Awesome, thank you. W On Fri, Feb 26, 2016 at 4:55 PM Andrej Ota wrote: > Below is the copy of the statement I received from Lol Grant. > > I believe we're now only one statement short and Thorsten should be back > on-line on Monday at latest. > > > ---------- Forwarded message ---------- > From: Lol Grant > Date: Fri, Feb 26, 2016 at 9:40 PM > Subject: Re: IETF explicit call for IPR (related to TACACS+ IETF draft) > To: Andrej Ota > Cc: David Carrel , Thorsten Dahm < > thorstendlux@google.com>, "Gash, Douglas" > > > Hi Andrej, > > I know of no IPR related to TACACS+ and/or draft-grant-tacacs-02. > > Like Dave, I can speak only for myself, not for Cisco. > > Best wishes, > > Lol Grant > > > On Fri, Feb 26, 2016 at 5:55 PM, Andrej Ota wrote: > >> As a coauthor, I am not aware of any IPR related to the submitted >> internet draft. >> >> >> I did contact David and Lol and I will politely contact them again so >> they can ack/nack as well. >> >> On Fri, Feb 26, 2016 at 5:38 PM, Warren Kumari wrote: >> >>> It is now almost 2 weeks since we asked for explicit IPR ACKs from all >>> the authors. >>> >>> We have only received one. >>> >>> The document starts out with: >>> "This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79" >>> >>> The explicit IPR check should simply be affirming the above. >>> >>> None of the authors should be "surprised" authors (2 of the authors have >>> been very active, and it has been stated that David and Lol were contacted >>> and checked). >>> >>> Frankly I'm starting to lose my sense of humor on this... >>> >>> W >>> >>> On Mon, Feb 22, 2016 at 12:15 PM Andrej Ota wrote: >>> >>>> I'm am double checking with in-house IPR legal. >>>> >>>> I have also sent off e-mails to David Carrel and Lol Grant so they know >>>> about the call. >>>> >>>> On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari >>>> wrote: >>>> >>>>> Dear WG (and specifically draft-ietf-opsawg-tacacs authors), >>>>> >>>>> So far we have received an IPR acknowledgment from Douglas ( >>>>> https://mailarchive.ietf.org/arch/msg/opsawg/FLI-7qqaD3AbArBKM42iNRiMxq8) >>>>> , but are still missing it from the rest of the authors: Thorsten >>>>> Dahm, Andrej Ota, David Carrel, Lol Grant. >>>>> >>>>> Please reply to this email regardless of whether or not you are >>>>> personally aware of any relevant IPR... >>>>> >>>>> (I have just noticed that David and Lol do not have email addresses >>>>> listed. Thorsten said that he spoke with them (recording from Prague) >>>>> - please add their email addresses - they will need to ack the IPR, and >>>>> also the AUTH48 if / when it happens...) >>>>> >>>>> W >>>>> >>>>> >>>>> On Tue, Feb 16, 2016 at 7:46 AM Warren Kumari >>>>> wrote: >>>>> >>>>>> Dear WG, >>>>>> >>>>>> Thanks to everyone who has been participating. It is refreshing to >>>>>> see this much passion and involvement in OpsAWG! We wanted to give this a >>>>>> bit of time to settle down, and also to see where this ended up. >>>>>> >>>>>> We are going to do a series of steps to get as clear a view of the >>>>>> consensus of the WG about this document. This message is a explicit call >>>>>> for any known IPR. >>>>>> >>>>>> We will follow up with two other messages, each with a particular >>>>>> question - the reason for such formality is to try to untangle the many >>>>>> threads that erupted on the main list. >>>>>> >>>>>> Many of you have already expressed your opinion but can you please do >>>>>> so again in response to the forthcoming two messages so that the record is >>>>>> clear. We expect to determine the path forward in 2 weeks. >>>>>> >>>>>> Are you personally aware of any IPR that applies to >>>>>> draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance >>>>>> with IETF IPR rules? >>>>>> (See RFCs 3979, 4879, 3669, and 5378 for more details.) >>>>>> >>>>>> If you are a document author or listed contributor on this document, >>>>>> please reply to this email regardless of whether or not you are personally >>>>>> aware of any relevant IPR. >>>>>> >>>>>> Scott, Tianran and Warren >>>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Andrej Ota >>>> >>>> Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland >>>> Registered in Dublin, Ireland - Registration # 368047 >>>> >>> >> >> >> -- >> -- >> Andrej Ota >> >> Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland >> Registered in Dublin, Ireland - Registration # 368047 >> > > > > -- > -- > Andrej Ota > > Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland > Registered in Dublin, Ireland - Registration # 368047 > --001a11c1697ced479f052cb373d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Awesome, thank you.

W

On Fri, Feb 26, 2016 at 4:55 PM A= ndrej Ota <aota@google.com> wr= ote:
Below is the = copy of the statement I received from Lol Grant.

I belie= ve we're now only one statement short and Thorsten should be back on-li= ne on Monday at latest.


---------- Forwarded message ----------
From= :=C2=A0Lol Grant=C2=A0&= lt;lol.grant@gmail= .com>
Date: Fri, Feb 26, 2016 at 9:40 PM
Subject: Re: I= ETF explicit call for IPR (related to TACACS+ IETF draft)
To: Andrej Ota= <aota@google.com>
<= div class=3D"gmail_extra">
As a coauthor, I am not aware of any IPR related = to the submitted internet draft.


I did co= ntact David and Lol and I will politely contact them again so they can ack/= nack as well.

On Fri, Feb 26, 2016 at 5:38 PM, Warren Kumari <warren@= kumari.net> wrote:
It is now almost 2 weeks since we asked for explicit IPR ACKs from= all the authors.=C2=A0

We have only received one.
=

The document starts out with:
"This= Internet-Draft is submitted in full conformance with the
provisi= ons of BCP 78 and BCP 79"

The explicit = IPR check should simply be affirming the above.

No= ne of the authors should be "surprised" authors (2 of the authors= have been very active, and it has been stated that David and Lol were cont= acted and checked).=C2=A0

Frankly I'm starting= to lose my sense of humor on this...

W

On Mon, Feb 22, 2016 at 12:15 PM Andrej Ota <aota@google.com> wro= te:
I'm am dou= ble checking with in-house IPR legal.

I have also sent o= ff e-mails to David Carrel and Lol Grant so they know about the call.
=

On Sun, Feb 21, 2016 at 9:55 PM, Warren Kumari <warr= en@kumari.net> wrote:
Dear WG (and specifically draft-ietf-opsawg-tacacs authors),
So far we have received an IPR acknowledgment from Douglas= (https://mailarchive.ietf.org/arch/msg/opsawg/= FLI-7qqaD3AbArBKM42iNRiMxq8) , but are still missing it from the rest o= f the authors:=C2=A0Thorsten Dahm,=C2=A0Andrej Ota,=C2=A0David Carrel,=C2= =A0Lol Grant.

Please reply to this email rega= rdless of whether or not you are personally aware of any relevant IPR...

(I have just noticed that David and=C2=A0Lol d= o not have email addresses listed.=C2=A0Tho= rsten said that he spoke with them (recording from Prague) - please add the= ir email addresses - they will need to ack the IPR, and also the AUTH48 if = / when it happens...)

W


On = Tue, Feb 16, 2016 at 7:46 AM Warren Kumari <warren@kumari.net> wrote:
Dear WG,

Thanks to everyone who has been participating. It is refreshing to se= e this much passion and involvement in OpsAWG! We wanted to give this a bit= of time to settle down, and also to see where this ended up.
We are going to do a series of steps to get as clear a view of = the consensus of the WG about this document. =C2=A0 This message is a expli= cit call for any known IPR.=C2=A0

We will follow u= p with two =C2=A0other messages, each with a particular question - the reas= on for such formality is to try to untangle the many threads that erupted o= n the main list.

Many of you have already expresse= d your opinion but can you please do so again in response to the forthcomin= g two messages so that the record is clear.=C2=A0 We expect to determine th= e path forward in 2 weeks.

Are you personally awar= e of any IPR that applies to draft-ietf-opsawg-tacacs?=C2=A0 If so, has thi= s IPR been disclosed in compliance with IETF IPR rules?
(See RFCs= 3979, 4879, 3669, and 5378 for more details.)

If = you are a document author or listed contributor on this document, please re= ply to this email regardless of whether or not you are personally aware of = any relevant IPR.

Scott, Tianran and Warren
<= /div>



--
--
Andrej Ota

Google Ireland Ltd., Goog= le Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland - = =C2=A0Registration # 368047



--
--
A= ndrej Ota

Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, I= reland
Registered in Dublin, Ireland - =C2=A0Registration # 368047



--
--
Andrej Ota

Google Irelan= d Ltd., Google Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin= , Ireland - =C2=A0Registration # 368047
--001a11c1697ced479f052cb373d3-- From nobody Sat Feb 27 09:58:52 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D871AD2C4 for ; Sat, 27 Feb 2016 09:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 qIF3zahbum5K for ; Sat, 27 Feb 2016 09:58:49 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD071AD291 for ; Sat, 27 Feb 2016 09:58:49 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id m1so70445006lfg.0 for ; Sat, 27 Feb 2016 09:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Orp4TykEGY744FYMLS0tB1oLY4RCCNgBGjvLJiFXATM=; b=SHX/w+AFQmBdO8KMAyvSSis5T6Oqm82Har3Ed7Y6JU84DwOJ5q3yxEyOLBvHze1u1N sbQEC2WpDkX+53q74HAfez2XC+q4WRlOEuDwLXZfcW0YhulLZfN7YN6+GuYnJu2Tw/8W cA3L1gLZqpHxeT5mepkq8Bhhu8uLaIv5W0fMKcINWHQvDi/4dLLcsoemnsIbjxwI4eGK X/B5bQ+RX5yMn+W8LVi/GOARRUzaWsculJqnKVSnbPq5iKPX4NQ+Ujoh1QzyQYgRLZP6 YjX4cAKXrcOrFQuGsbRmbxTP/SJbOt07xWn/fektuN4pBlrVN2sG4wWMuq4aKprfRiZU 0Dqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Orp4TykEGY744FYMLS0tB1oLY4RCCNgBGjvLJiFXATM=; b=MUzxpD/f/cRR/cDT2F93faQxvXwNWJb/dDTpHQqwidDj+ju345lfCR5pZAYmo4vxo3 +0SaiwR2QkX1YcRYHUn7InUnlBpjb9TD6VhNkYYmOtjaQsk9hUFCuyasRaSLWTw5AAPN 0TtRnVY5nwUQYWsqm6C3VoZYHXzrRn/dpAjEllWFBG8ZWnadRlgXURjoSu32ydZ09uBc Ir3jyULT8/SJ2Fb41EwvKsb/sncpthXrB7GCirofYI/Knd6DtRodZINJx75mh5ipDd6x YiglR4+UfH3BHYrgQlSielMTK3jwDGzm553+aXIgWSQcfIG3MyWg9igLwSszFDuhW3VU vrcw== X-Gm-Message-State: AD7BkJKG0WStBw/Lwu/6HPCkcM0wx9rFsHozTUXG+b+LRsv4orrtvN21vTs4PHZkOYJ3V1P6SvRE7+IlHdnxMqM5 X-Received: by 10.25.33.1 with SMTP id h1mr941041lfh.151.1456595927390; Sat, 27 Feb 2016 09:58:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.203.104 with HTTP; Sat, 27 Feb 2016 09:58:17 -0800 (PST) In-Reply-To: References: From: Thorsten Dahm Date: Sat, 27 Feb 2016 17:58:17 +0000 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=001a1140245ad5a766052cc42acd Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 17:58:51 -0000 --001a1140245ad5a766052cc42acd Content-Type: text/plain; charset=UTF-8 As a coauthor, I am not aware of any IPR related to the submitted internet draft. Regards, Thorsten On 15 February 2016 at 18:46, Warren Kumari wrote: > Dear WG, > > Thanks to everyone who has been participating. It is refreshing to see > this much passion and involvement in OpsAWG! We wanted to give this a bit > of time to settle down, and also to see where this ended up. > > We are going to do a series of steps to get as clear a view of the > consensus of the WG about this document. This message is a explicit call > for any known IPR. > > We will follow up with two other messages, each with a particular > question - the reason for such formality is to try to untangle the many > threads that erupted on the main list. > > Many of you have already expressed your opinion but can you please do so > again in response to the forthcoming two messages so that the record is > clear. We expect to determine the path forward in 2 weeks. > > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-tacacs? If so, has this IPR been disclosed in compliance > with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are personally > aware of any relevant IPR. > > Scott, Tianran and Warren > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > -- Thorsten Dahm Network Engineer Google Ireland Ltd. The Gasworks, Barrow Street Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047 --001a1140245ad5a766052cc42acd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a coauthor, I am not a= ware of any IPR related to the submitted internet draft.

Regards,
Thorst= en

On 15 February 2016 at 18:46, Warren Kumari <warren@kumari.net>= wrote:
Dear= WG,

Thanks to everyone who has been participating= . It is refreshing to see this much passion and involvement in OpsAWG! We w= anted to give this a bit of time to settle down, and also to see where this= ended up.

We are going to do a series of steps to= get as clear a view of the consensus of the WG about this document. =C2=A0= This message is a explicit call for any known IPR.=C2=A0

We will follow up with two =C2=A0other messages, each with a partic= ular question - the reason for such formality is to try to untangle the man= y threads that erupted on the main list.

Many of y= ou have already expressed your opinion but can you please do so again in re= sponse to the forthcoming two messages so that the record is clear.=C2=A0 W= e expect to determine the path forward in 2 weeks.

Are you personally aware of any IPR that applies to draft-ietf-opsawg-taca= cs?=C2=A0 If so, has this IPR been disclosed in compliance with IETF IPR ru= les?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

If you are a document author or listed contributor on = this document, please reply to this email regardless of whether or not you = are personally aware of any relevant IPR.

Scott, T= ianran and Warren

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg




--
Thorsten Dahm

Network Engineer
Google Irel= and Ltd.
The Gasworks, Barrow Street
Dublin 4,=C2=A0 Ireland

R= egistered in Dublin, Ireland
Registration Number: 368047
--001a1140245ad5a766052cc42acd-- From nobody Mon Feb 29 16:47:06 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E731A6FF7 for ; Mon, 29 Feb 2016 16:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 vVu4LHjtezQI for ; Mon, 29 Feb 2016 16:47:04 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB411A7004 for ; Mon, 29 Feb 2016 16:47:03 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id e63so136164901ywc.3 for ; Mon, 29 Feb 2016 16:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=uFhiXVPrvTWhSz8l2xLF7Uw11XkMM4TaxvWwStfgysU=; b=sf7cHiAz76/13dBcJrmsiDY1H7d7DxdEPbqh7EVZwXXEQ+JDo5cZI3Wn+oYuGdyNQ2 iL3hQziugZbGYDJRvcu4HKHTcY5mVjT1ucb4kdPqjQvX7GjHlcdw4zWopUtvr+pvaFn2 8hdU3coT+c7HU8aEYam4op4v5EELDAXfzYm8y3ovl20s3IYhcom2CGjVY6hhdHC+8C/t Ctz1EPU4vZ+C8BP9nnvz/blntPZBLPIAi0ock+j52N4nl7YfQvJvWpFP0O2gDwOCmJmc tGV5/gkJs6UIc/EVhYwbLEy5atWzwjwjSIsnVHEF2H0dJCcmdc++oOyjMXBnCrorinzy nDxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uFhiXVPrvTWhSz8l2xLF7Uw11XkMM4TaxvWwStfgysU=; b=AqOj0q4+1AlgSFNRwKHEgmvwI1YfP+b6sXAwwq9QQFHL5i3Ht+7ViOVGcKPsGS/7fW qWHBhacPd1NGLLI3PbNZ6Hc09z4R/hV9LM8fjmZLhAbej3jqXJWRe/gLaK60fjlriVFP Q2ePovJ3l8rhznYf1m/r8kR05qA6TB9mxH5CsSpJ506zL4uTX2MMyydSNt5Ezgx3CEqX EbkhInWLhpFMG6VBXPe/u5nEv5Xfij2dH6fhCYcHAadk5NQNLMOYn2baY64obD7MUgTU a9oYb9ZePwOkhQaCRd+HN+zLJg0zfZ05YqX+1fvVvb0u6uDTkLLwRqqDtKSAW3D6OLrG 7jZw== X-Gm-Message-State: AD7BkJIZVoc4IU4tzfDgIT3+CF2bKiSw5VPCrh6Rce6xKz5aIcSirnMdOGokdn9ZQm9CSlLDTuT6rs1mFxyjlzxJ X-Received: by 10.129.145.82 with SMTP id i79mr10191773ywg.345.1456793223107; Mon, 29 Feb 2016 16:47:03 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Tue, 01 Mar 2016 00:46:53 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c093a3e9343b7052cf21a42 Archived-At: Subject: [OPSAWG] Detangling TACACS+ - the outcome X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 00:47:05 -0000 --94eb2c093a3e9343b7052cf21a42 Content-Type: text/plain; charset=UTF-8 Dear OpsAWG, Thank you for your time and patience during this process. We note that we now have all IPR ACKs. Based upon the responses we have decided on a path forward: 1: Produce an informational document which documents the TACACS+ protocol as it stands today (as best as we can). 2: After the WG has agreed to the above text, the plan is to produce a new, Standards Track document which describes TACACS+ with the additions / enhancements. Please noodle on the name for this new and improved protocol - I'm partial to TACACS++, but that may be overly cute. Thanks, Scott, Tianran and Warren --94eb2c093a3e9343b7052cf21a42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear OpsAWG,
Thank you for your time and patience duri= ng this process. We note that we now have all IPR ACKs.

<= /div>
Based upon the responses we have decided on a path forward:
=
1: Produce an informational document which documents the TACACS+ proto= col as it stands today (as best as we can).

2: Aft= er the WG has agreed to the above text, the plan is to produce a new, Stand= ards Track document which describes TACACS+ with the additions / enhancemen= ts. Please noodle on the name for this new and improved protocol - I'm = partial to TACACS++, but that may be overly cute.

= Thanks,
Scott, Tianran and Warren
--94eb2c093a3e9343b7052cf21a42-- From nobody Mon Feb 29 17:17:50 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30941A87A0 for ; Mon, 29 Feb 2016 17:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 ya3KNWgzMQsa for ; Mon, 29 Feb 2016 17:17:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E868F1A8796 for ; Mon, 29 Feb 2016 17:17:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFD69210; Tue, 01 Mar 2016 01:17:40 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Mar 2016 01:17:39 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0235.001; Tue, 1 Mar 2016 09:17:34 +0800 From: Zhoutianran To: "opsawg@ietf.org" Thread-Topic: Call for Agenda Items for Buenos Aires Thread-Index: AdFzWApUxZoyzCGZR2WickFNLOEKMQ== Date: Tue, 1 Mar 2016 01:17:33 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56D4EDB5.0099, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f1b89e9b4c1aaf1562ea825599638786 Archived-At: Subject: [OPSAWG] Call for Agenda Items for Buenos Aires X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 01:17:46 -0000 Greetings WG, Our meeting in Buenos Aires is fast approaching. We have requested a slot f= or the joint OpsAWG / OpsArea meeting. Please send over requests for agenda time.=20 Please remember that we give time to drafts that have already received sign= ificant discussion on list. Thanks, Scott, Warren & Tianran